tlf30
Lifetime Supporting Member
Darn, I got 0x0E and 0x03 backwards in my head, I even checked my notes and read them wrong
Just tried 0x0E and 0x03 the correct way, same result.
I'll give it a try, I'll probably just write a bit of code to do it for me.
I get the rack info by hitting port 1 on the controller or comm adapter (see screenshot of attached code.)
EDIT:
Just tried 0x0E and 0x03 the correct way, same result.
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'll give it a try, I'll probably just write a bit of code to do it for me.
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.
I get the rack info by hitting port 1 on the controller or comm adapter (see screenshot of attached code.)
EDIT:
A word of warning on rack optimization, I was part of an FCO on a new plant where we had many racks set to rack optimization. When comms were lost to a rack, then came back online, for a single scan all DI were a value of 0 in the controller even though the field value never changed. The value would hold in the controller while the rack was offline, we would only see the 0 value for one scan on all points when comms were re-established. For this reason I never use rack optimization anymore.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 getting module data on its own.
Last edited: