Message I/O module directly

[tlf30]

Thank you so much for the information. This was great. I am currently playing with it, and I can make this work as an alternative to messaging the IO modules directly.

If you have any other cool CIP tricks, feel free to PM me. I am always on the lookout for ways to get info from the controller. If you want some info on Stratix switches, PM me and I can send you how to grab just about any diagnostics info from a Stratix Switch via CIP. But other than Stratix, I have not had the time to brute force much else. Just now starting on Controllers since I am in need of getting all the diagnostics info.

Thank you again, you were a great help.
~Trevor

 

[JeremyM]

No problem.

 

[JeremyM]

One more thing you might try is to send a service 0x01 to Message Router (0x02) instance 1. This will return the classes that are exposed to messaging.

5069-IB16:
0x01 (Identity)
0x02 (Message Router)
0x04 (Assembly)
0x06 (Connection Manager)
0x37 (File)
0x43 (Time Sync)
0xA1 (Rockwell Nonvolatile Storage)
0x351 (unknown)
0x372 (unknown)
0x373 (Backplane Port Diagnostic)

I had time to test and these all respond to basic 0x01 service messages at instance 1 or 0 (except Assembly).

The 0x300 - 0x3FF range of classes is home to stuff like DeviceLogix and bulletin-specific objects.

5069-SERIAL:
0x01
0x02
0x04
0x06
0x0C (common range, unknown)
0x37
0x43
0xA1
0xF4 (common Port)
0x351
0x372
0x373

5069-IY4:
0x01
0x02
0x04
0x06
0x20 (common Analog Input Group)
0x37
0x43
0xA1
0x351
0x372
0x373

5069-HSC2xOB4:
0x01
0x02
0x04
0x06
0x37
0x43
0xA1
0x351
0x372
0x373

5069-OW16:
0x01
0x02
0x04
0x06
0x37
0x43
0xA1
0x351
0x372
0x373

 

[tlf30]

Thank you for the info.
I was playing around with the message router a couple weeks ago on my 1756-L61 at home. I'll do a listing from my 1756-L81 on the bench here at work and post it, along with the IO modules I have in my rack.

I noticed that with service 0x4b when using class 0x69 or 0x6b, when using the molex eip tool, it will respond with a partial transfer and return 500 bytes, but only with an unconnected message, a connected message will return all the data. But when using an unconnected message from ControlLogix, the service responds with all the data and will not respond with a partial transfer. It does not seem to matter if I am using a connected MSG or not. Did you just simply use a massive receive buffer in your program, or were you able to get it to respond with a partial transfer?

For testing, I compared the request message from the molex tool to the message from the controller using wireshark. I did not see any difference, but there must be one.

Thanks,
Trevor

 

[JeremyM]

That's interesting info.

Since my original post, I changed my receiving buffer for this class from 512 to 256 bytes (SINT[256]). For service 0x4B, that gets up to 64 instance Ids in a read. It's also more than sufficient for the returned instance attributes when using service 0x03.

My process:
a) iteratively hit up 0x69 with 0x4B until running out of instances (DN_LEN == 0)
b) hit up 0x69 with 0x03 using separate request buffer of INT[10] = {9, 1, 4, 8, 9, 10, 13, 14, 18, 31}
c) unpack returned data in receiving buffer to populate the temp 'node' UDT
d) COP this temp object to the list of other nodes. if it is already in the list, overwrite that instance, otherwise I use the next available
e) repeat

A scan-friendly 'co-routine' keeps the list sorted by node Path. New insertions and updates happen in linear time.

couple things:
- I prefer to re-use the receiving buffer across both services since Logix memory is anemic.
- I'm unsure if there's a meaningful performance improvement to be had by not calling service 0x4B for each instance without also blowing up code complexity to check to see if an instance buffer has been exhausted before calling the service again.

 

[tlf30]

Hmm, I am running firmware v33 on a 1756-L81.
I changed my buffer to be a SINT[256], testing against class 0x6B. I get the error 'Reply data too large', code 0x11.
Message config attached. No data is written to the buffer. If I increase the buffer to something large, say SINT[4096], then it works without issues.

 

[tlf30]

Hmm, I am running firmware v33 on a 1756-L81.
I changed my buffer to be a SINT[256], testing against class 0x6B. I get the error 'Reply data too large', code 0x11.
Message config attached. No data is written to the buffer. If I increase the buffer to something large, say SINT[4096], then it works without issues.

Just tested with 0x69 with more IO in my tree, same error 'Reply data too large'

 

[JeremyM]

I'm hoping to find a better way to discover the node names other than iterating through Symbol instances, filtering on TypeId, and only then updating the node list.

If there's a direct way to associate a Class 0x69 instance to a Class 0x6B instance, I'm all ears. The only uniquely identifying attribute I've come across is 0x69 attribute 13 "MapAddress" but this only enables the current method since it it is also only an attribute of class 0x6B instances, rather than a 0x6B instance Id.

 

[JeremyM]

Hmm, I am running firmware v33 on a 1756-L81.
I changed my buffer to be a SINT[256], testing against class 0x6B. I get the error 'Reply data too large', code 0x11.
Message config attached. No data is written to the buffer. If I increase the buffer to something large, say SINT[4096], then it works without issues.

Just tested with 0x69 with more IO in my tree, same error 'Reply data too large'

This is a great catch. I'm on v34. I should probably resize the buffer to anticipate more connections. I was confident the return data was a partial list, but I must have been thinking of another class.



EDIT:
your uploaded picture's error is with the Symbol class, not the IOMap class. With the Symbol class, I'm only using service 0x01 on instances > 0 after using service 0x03 on instance 0 to get the max instance Id.

 

[tlf30]

This is a great catch. I'm on v34. I should probably resize the buffer to anticipate more connections. I was confident the return data was a partial list, but I must have been thinking of another class.

EDIT: your error is with the Symbol class, not the IOMap class.

Correct, I am seeing the error with both classes.
I also tested on a 1756-L75, also running v33.

I'll get out 34 on one of my test controllers today and test that as well.

 

[JeremyM]

It would appear that the message reply on v34 would be dumping the response beyond bounds...

lesson learned:
don't put message response buffers inside AOIs and supply the message handle an alias to it... the message cannot determine the size of the destination. Party foul.

result:
v34 responds just as your setup does on v33

 

[JeremyM]

To circle back to your original problem - with this info - I'm curious how you'd go about getting the IO information in a tag-free fashion. Are you collecting the paths and hitting up specific assemblies remotely from there?

 

[tlf30]

My current implementation gets the max number of instances from the class using service code 0x03 to get attribute 2.

From there I use service 0x03 to get attributes 8, 9, 10, and 18 from every instance starting at 1 to the max instance id. It takes a bit to do this. If I get an error back, I know the instance id is not used, if it is successful, then I get the instance data.

Afterward, I use those attributes to construct a CIP path. I cannot use the EPATH because my AOI supports monitoring remote PLCs as well as the local PLC. But I only reconstruct the path to devices that have a long link path (attribute 18), I then check to confirm that these devices are ethernet adapters using a WHO.

Next I query the rack of each ethernet adapter by asking the rack for how many slots it has, see notes below on message info.

Finally, I query each module in the rack for WHO info, and then depending on the module type I grab additional information.

Notes on the rack message. Send message Service 0x01, Class 0x66, Instance 1. Ensure you send the message to the backplane of the comm adapter.

The return buffer will be:
Buffer[10] = (SINT) Minor Firmware Rev
Buffer[11] = (SINT) Major Firmware Rev
Buffer[12] = (DINT) Serial Number
Buffer[16] = (INT) Number of slots (or modules attached to adapter)

EDIT:

To circle back to your original problem - with this info - I'm curious how you'd go about getting the IO information in a tag-free fashion. Are you collecting the paths and hitting up specific assemblies remotely from there?

I agree, it would be great to get the IO info without needing to get the tag info for the IO modules.

 

[tlf30]

It would appear that the message reply on v34 would be dumping the response beyond bounds...

lesson learned:
don't put message response buffers inside AOIs and supply the message handle an alias to it... the message cannot determine the size of the destination. Party foul.

result:
v34 responds just as your setup does on v33

This has me thinking... Why is it that the molex tool can get a partial response from the controller, but not the MSG instruction?

Also, interesting that using the message inside an AOI did not see the size of the array. Did you have memory corruption in the controller, other tags getting wrong values written into them, or have it fault or crash? I am very interested by this, as I would not have expected it to work.

 

[JeremyM]

No fault or crash, but a cursory look at the AOI showed it to be unresponsive. The message may have knowledge of the destination container and stop writing at its boundary. I’m guessing the message makes its container hint to be the AOI itself rather than the array within it to which the alias points.