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.

Sign up for GitHub

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

Jump to bottom

Support for 16-bit instance segment #5

Closed
johanfforsberg opened this issue Sep 1, 2015 · 3 comments
Closed

Support for 16-bit instance segment #5

johanfforsberg opened this issue Sep 1, 2015 · 3 comments

Comments

@johanfforsberg
Copy link

While looking into how Rslinx acquires the list of tags from a PLC I ran across an apparently non-standard CIP Service 0x55 which AFAICT may be used to get the tag names from the PLC. However, for this it uses 16 bit instance segments. It looks like cpppo only supports 8 bit segments, is this something that might change?

The possibility to read the tag names (and particularly the tag addresses) would be highly useful.
@pjkundert
Copy link
Owner

Hmm. It supports 16-bit instance segments in the CIP EPATH. If you could capture the request/response packets, it would be interesting to see what it looks like. Unfortunately, the EtherNet/IP CIP documentation leaves much to be desired...

@johanfforsberg
Copy link
Author

Yes, I was probably being too hasty in my conclusions, there's a lot going on there.

I have a wireshark capture of the communication, but it contains a bunch of unrelated traffic so I'll have to clean it up it before sending it to you.

Also found this page that has some very similar capture files: http://condel.cc/~reaper/kool/rakenduslik%20andmeside/labor.html

@johanfforsberg
Copy link
Author

Another find, this .NET library supports listing the tags in the PLC: https://controllogixnet.codeplex.com/

pjkundert added a commit that referenced this issue Jan 30, 2018
@pjkundert
# This is a combination of 12 commits.
f4901cc 
# 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
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@pjkundert @johanfforsberg