Message I/O module directly

Molex vs local message has me a little stumped by that and more - at no point did the former do anything but receive a partial list response.

JeremyM said:

Molex vs local message has me a little stumped by that and more - at no point did the former do anything but receive a partial list response.

Click to expand...

Agreed, I did notice that when using the molex tool and setting it to be a connected send, that it does send the full list, but still with a partial list response.

One thing I do recommend you trying is to use the first returned instance after a 0x4B to 0x69 as the instance to parse with 0x03. The next time you query 0x69 with 0x4B you can use previous instance + 1 to get the next. You save lots of time vs iterating all possible since the distribution of instance Ids is effectively random.

Do you have each processor producing its own local list of IO that the concentrator later collects? Or is the concentrator doing all the querying and assembly?

If it's the latter, you might try hitting up documented common Class 0x45 (Originator Connection List) on the production CPUs. This either became a thing with 5x80 or a firmware version of 5x70 and 5x80, but I don't have any 5x70 to test with. It's a dynamic class requiring you to first send a Create service 0x08 request that responds with the new instance Id you'd use to begin parsing data with service 0x4C. Afterward, you send a Delete service 0x09 request.

The curious thing about this class is that Logix processors won't answer queries to it from itself - they can only come from an external originator. The only workaround I could find was to add a "dummy" hop through a backplane I/O module.

JeremyM said:

Do you have each processor producing its own local list of IO that the concentrator later collects? Or is the concentrator doing all the querying and assembly?

If it's the latter, you might try hitting up Class 0x45 (Originator Connection List) on the production CPUs. This either became a thing with 5x80 or a firmware version of 5x70 and 5x80, but I don't have any 5x70 to test with. It's a dynamic class requiring you to first send a Create service request that responds with the new instance Id you'd use to begin parsing data with. Afterward, you send a Delete service request.

The curious thing about this class is that Logix processors won't answer queries to it from itself - they can only come from an external originator. The only workaround I could find was to add a "dummy" hop to a backplane I/O module.

Click to expand...

That is an interesting idea. The concentrator is doing all the queries, but it is setup to run local on the controller as well instead of collecting other controllers (it can basically grab all of its own data, and/or other controllers). But there is no logic change to remote controllers to facilitate the gathering of data.

I will play with the connection list, that is an interesting idea. It is interesting that it will not respond to itself. That will make things complicated when the local controller is attempting to grab its own diagnostics information.

Right - that limitation led me to discovering class 0x69 which I've used since.

Got to test another card tonight.

5069-OF8:
0x01
0x02
0x04
0x06
0x21 (common Analog Output Group)
0x37
0x43
0xA1
0x351
0x372
0x373

Hmm, that is interesting.

I am home at the moment, and have a test rack running with several 1756 digital cards (both 120 AC and 24 DC, inputs and outputs). I will do some testing tomorrow if I get a minute.

It is interesting to see the Analog Output Group there. I will see what the message router says in my modules. Does the Analog Output Group respond to a CIP request? I read somewhere (in one of the many AB manuals, I don't remember which) that most CIP requests to IO cards will require a connected message, and that they will not respond to an unconnected message.

1734-IB4 / 1734-IB8:

0x01
0x02
0x03
0x04 (assembly, service 0x14, instance 101, attribute 3 = status of all points, responds without connections established)
0x05
0x08 (common Discrete Input Point):
* service 0x0E -> instances (1 - 8, points 0-7 ) -> attribute 3 (status)
* also attributes 5-6 per point (on/off delay)

tlf30 said:

It is interesting to see the Analog Output Group there. I will see what the message router says in my modules. Does the Analog Output Group respond to a CIP request? I read somewhere (in one of the many AB manuals, I don't remember which) that most CIP requests to IO cards will require a connected message, and that they will not respond to an unconnected message.

Click to expand...

It does in the 0x32 or so service range. I tried a couple and it changed point configs and momentarily sent a handful of points into calibration mode. Didn't have time for anything else on that one.

I got very interesting results on my 1756 IO.
For an unconnected message when querying the message router, I get: "Unsupported service requested (0x0008)"
For a connected message, I get: "Connection failure (0x0001)"
I did test sending my request to another controller in the rack just to make sure I was not loosing my mind, and it did work.

I tested the following modules:
* 1756-IB16 (firmware v2 & v3)
* 1756-OB8 (firmware v3)
* 1756-IA16 (firmware v2)
* 1756-OA16 (firmware v3)

It has me curious as to why they do not respond, as it is very different behavior from other modules.

EDIT:
I am very fascinated that you got data back from the Discrete Input Point on 1734. This makes me think the data is available on the 5069 Analog Output Group. When I get some more time, I will attempt to query the 1756 IO for the Discrete Input Point to see if I can make anything happen. Just because the message router does not reply does not mean that the other classes will not.

EDIT 2:
Even more interesting, here is sending the same request to the Digital Input Point as you, but on the 1756-IB16. (See attached screenshot) I did verify the path, a get identity works just fine. Sending as a connected message has the same result.

Do they respond to requests against common CIP IO objects?

You might try 0x0E service requests among Assembly instances 100-110, 200-210, 300-310, etc. There are gaps in attributes in these instances, so you might have to try a dozen or so before moving onto the next instance.

I suspect they all answer at 0x300 as my Point rack did. I’m now reasonably sure this is the object that exists among all chassis-based IO and provides the virtual Identity that RSLinx uses to determine stuff like whether a module lives in a 1756-A4/A7/A10 or a modular CompactIO rack of variable size. One of my early pressing questions in dabbling in all this was how exactly something like a passive or ephemeral rack could be identified externally.

tlf30 said:

EDIT:
I am very fascinated that you got data back from the Discrete Input Point on 1734. This makes me think the data is available on the 5069 Analog Output Group. When I get some more time, I will attempt to query the 1756 IO for the Discrete Input Point to see if I can make anything happen. Just because the message router does not reply does not mean that the other classes will not.

Click to expand...

The only caveat with using the the common CIP IO objects with Point IO so far is that you can only parse one point per message. By hitting the assembly above, you get them all, just not packed into an integer. There’s probably another assembly instance populated in parallel that presents the packed form.

Edit: I can set up an iterating message program that will report assembly hits.

Re: EDIT 2

Service 14 requires you to specify an attribute.

What do your path options look like?

Theoretically one should be able to set an IP on an AENT/AENTR build a 63-slot chassis of IB8 and get IO data without ever establishing a cyclic connection.

I think I’m understanding what “rack-optimized” connections really do now: create dynamic assemblies on the AENT that are populated with IO data that the AENT populates on its own by polling its own module data.