I believe with the IA driver that when you're on your device diagnostics/stats page you can turn on TRACE debugging, and you'll see messages showing tags and the name of the logger will have 2 names (don't recall them off the top of my head), but one is something like ReadTag and the other is ReadStructuredTag (I feel like that's close, but unsure). The ReadTag one is individual tags and the ReadStructuredTag is the one where it read it as a group/structure.
1 Like
That's not generally done. Class1 requires PLC code, so you pick the information that is most valuable to have at high speed. There are multiple approaches, with various pros and cons. In all cases, you are going to have to segment your data structures into chunks of ~500 bytes (really 496 in most cases). Class1 traffic will easily move these at 100ms intervals. In most cases, the starting point is to export the PLC code as L5X and import into a Host Device to replicate the data types and tags. (Discard what you do not need.)
-
1:1 Producer/Consumer tags. This is the simplest approach, but requires the scanner+adapter options, so is most $$. Break your application into UDTs that are small enough to be producer tags in your PLC, and subscribe to them in Ignition. The consuming tag structs in Ignition (in a Host Device instance) would typically be byte-for-byte identical to the PLC structs. The major con to this is the difficulty editing the program--you cannot change producer tags in Rockwell PLCs except in offline mode and then a complete download.
-
Indirect Producer/Consumer tags. This approach allows you to have large source UDTs, if you are careful with boundaries. Create many Producer Tags in the PLC of type DINT[125] and use CPS instructions to populate them from the real tags. You don't have to break up big UDTs, and can change the CPS instructions in run mode editing. You may have to waste some DINTs to avoid breaking up inner structures in bad places. The major con to this is that you cannot make the Ignition data layout exactly match the PLC layout.
-
Ignition as I/O adapter. Create many I/O buffers where the output buffers (DINT[124]) are treated like the indirect producer tags. Same cons as that, but also that you usually have to shuffle the data through the multi-slot "Target" device, which can be either tricky or tedious. The primary advantage of this is minimum $$, as you do not need the scanner option.
1 Like
I don't know why, or how, but I noticed there were a lot of individual read requests on one particular element of a UDT that didn't really make sense. It was just a value for a color. Anyway, it was one of those tags where I only ever need to read once, so I put that in my driven group that only runs when requested and for some reason that just opened my comms wide open. I'm currently sitting at 66% utilization when my main overview screen is open, on a 1,000ms leased rate and a 300,000 base rate. Zero overload. When I open one of the drill down screens to only look at a single section, it drops WAY down from there, to like 14% utilization. I have no idea just one UDT member could do that much.