-
-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Command Line seems to only send max of #7
Comments
Yes, you can specify one of the CIP data types (SINT), (INT), (DINT) or (REAL) -- and now also (BOOL) for the data on the command line. It applies to all data being written to that tag. You can write different data types in a separate Tag request, eg:
This is documented in the README.org or README.pdf chapter on the "EtherNet/IP Controller Client". |
Thanks for your reply. In your above example, should I not have indexes for MYTAG? python -m cpppo.server.enip.client -a 127.0.0.2 'MYTAG[0]=(INT)32767' 'MYTAG[1]=(DINT)50000' 'MYARRAY[5-6]=(REAL)1.23,4.56' Also I looked at the documentation for setting for the corresponding server for a message like this, but was unsuccessful. What would be the correct server syntax for this? python -m cpppo.server.enip -a 127.0.0.2 --print MYTAG=DINT[1] ...? Thanks again for your assistance. |
Yes, if your MYTAG is an array, then you need to include indices. If you look here: https://github.com/pjkundert/cpppo#ethernetip-cip-controller-communications-simulatorclient there is a description of how to start a simulator with Tags of various data types; you're on the right track. |
Hi I am able to start the server to look for different tags with various data types, but not 1 tag with various data types. Server/Listener (not correct): Client: I had a read through the document, seems I am missing something. Thanks |
No, you must make separate tags; each tag must be if one single type. On Friday, September 18, 2015, gsingh-cp notifications@github.com wrote:
|
# This is the 1st commit message: Initial foray in to support for generic CIP Service Code requests # This is the commit message #2: No requirement for existence of .multiple segment in failed responses # This is the commit message #3: Correct handling of service_code operations in client connector I/O # This is the commit message #4: HART Requests almost working o Cannot derive HART from Logix; service codes overlap # This is the commit message #5: Initial working HART I/O card request # This is the commit message #6: Support intermixed Tags and already parsed operation in parse_operations # This is the commit message #7: Test and decode the Read primary variable response, however: o Still broken; the CIP Encapsulation path is still suppsed to be to the Connection Manager @0x06/1! The 0x52 Route Path is Port 1, Address 2, and the message path should be to @0x035D/8. # This is the commit message #8: Success. Still needs cleanup # This is the commit message #9: Further attempts to refine HART pass-thru. o HART I/O card is not responding as defined in documentation # This is the commit message #10: Cleanups for python3, source analysis, unit tests # This is the commit message #11: Attempt to parse Read Dynamic Variables reply; 3 unrecognzied bytes? # This is the commit message #12: Update to attempt to parse real HART I/O card response o Minimal Read Dynamic Variables status response? Not successful o Implement minimal simulated pass-thru Init/Query, HART commands 1,2,3 o Minor changes to client.py Send RR Data, to have timeout and ticks compatible with RSLogix; no difference
Hi
It seems command line usage requires that a number be int16 when being sent.
It is possible to send 32bit aka DINT via command line?
struct.error: short format requires SHRT_MIN <= number <= SHRT_MAX
user$ python -m cpppo.server.enip.client -a 127.0.0.2 MYTAG2=32768
Also, is it possible to have multiple different data types be sent for 1 tag? Furthermore, is there a way to state what type of datatype is being sent?
eg.
python -m cpppo.server.enip.client -a 127.0.0.2 MYTAG2=(int16)32767, (dint)50000
Thanks
The text was updated successfully, but these errors were encountered: