Skip to content
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

Closed
gsingh-cp opened this issue Sep 18, 2015 · 5 comments
Closed

Command Line seems to only send max of #7

gsingh-cp opened this issue Sep 18, 2015 · 5 comments

Comments

@gsingh-cp
Copy link

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

@pjkundert
Copy link
Owner

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:

python -m cpppo.server.enip.client -a 127.0.0.2 'MYTAG=(INT)32767' 'MYTAG=(DINT)50000' 'MYARRAY[5-6]=(REAL)1.23,4.56'

This is documented in the README.org or README.pdf chapter on the "EtherNet/IP Controller Client".

@gsingh-cp
Copy link
Author

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.

@pjkundert
Copy link
Owner

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.

@gsingh-cp
Copy link
Author

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):
python -m cpppo.server.enip -a 127.0.0.2 --print 'MYTAG[0]=INT[1]' 'MYTAG[1]=DINT[1]'

Client:
python -m cpppo.server.enip.client -a 127.0.0.2 'MYTAG[0]=(INT)32767' 'MYTAG[1]=(DINT)500000'

I had a read through the document, seems I am missing something.

Thanks

@datasim
Copy link

datasim commented Sep 18, 2015

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:

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):
python -m cpppo.server.enip -a 127.0.0.2 --print 'MYTAG[0]=INT[1]'
'MYTAG[1]=DINT[1]'

Client:
python -m cpppo.server.enip.client -a 127.0.0.2 'MYTAG[0]=(INT)32767'
'MYTAG[1]=(DINT)500000'

I had a read through the document, seems I am missing something.

Thanks


Reply to this email directly or view it on GitHub
#7 (comment).

-pjk

pjkundert added a commit that referenced this issue Jan 30, 2018
# 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants