[Logix] Produced/Consumed tags, and UDTs

Hi all,

So I've been going through my system getting things in place, and one thing I've just realized might really screw me has come up and I'm hoping I can get some clarity on produced/consumed tags, specifically with my UDTs.

So let's say I have a UDT for a pump. The pump has both input parameters (On command, Speed setpoint) and also output parameters (Running status, Speed status). I've also added custom UDTs inside the Pump UDT, like a Fail to Start Alarm, and Fail to Stop Alarm. Those also have inputs (user adjustable time delay) and outputs (alarm bit).

So here's my concern: if I use produce/consume tags for these Pumps (and all the other equipment in the system), it seems like the produce/consume tags can't be set up for each "sub" tag of the UDT...so unless I'm missing something, that would mean that if I'm communicating the Pump data from one PLC (like a remote RTU situation) to another PLC, EVERYTHING is going from the Produce side to the Consume side, EVERY TIME.

My original plan was to have a CompactLogix act as essentially an RTU, and have all the control logic and PIDs and HMI interface (InTouch) be in a ControlLogix PLC (and by "my plan", I mean that's how the system was designed). So I thought ok, just make the same Pump UDT tag in both places. But now I'm realizing that unless I'm missing something, there's no way I can both send inputs from the HMI/ControlLogix PLC to the CompactLogix PLC (like a speed setpoint, either from the HMI or from the PID loop or alarm delays) and have outputs send back (like Pump Running bits, Pump ETM, and alarm bits).

So now I'm wondering what to do; I guess I could have all the remote PLCs interface directly with my HMI instead of going through the ControlLogix PLC, but the bigger worry is now realizing that I think I have to entirely change how the programs interface with the others PLCs. For example, the project I'm working on is a water treatment plant; the treatment plant calls a remote pump station to suck water out of a nearby lake. So the treatment plant calls the remote pump station to run, but if there's a failure at the remote pump station, the treatment plant would need to shut down. So how would I both be able to send the run command to the remote pump, but also get back failure alarms? It seems like the whole point of UDTs is that you can make one tag cover all your needs, but what if there are both inputs and outputs in a single UDT?

I'm super curious to hear how you guys deal with this, as I'm hoping I'm just missing something about how AB PLCs work as this is my first project with them. Maybe I'm not creating UDTs correctly?

I'm not sure if I completely understand what you're trying to achieve, but you're right about how the UDT's and Produced/Consumed tags work.

I tend to approach it from the angle that if Motor 1's physical controls (i.e. contactor/overload/etc) are in Panel A, then they should be controlled by the PLC in Panel A (obviously there's exceptions here with remote I/O, blah blah, but you get the idea).

You can still have a separate PLC somewhere else doing calculations as to when Motor 1 should run, what speed it should run at and whatnot - it's quite common to have a central PLC overseeing a whole bunch of other process PLC's. But that PLC should not get involved directly; rather it should just tell the other PLC what it wants. The other PLC assesses the request, along with it's own internal data to make the final call on whether Motor 1 is going to run or not.

So, I just send the information I really need from the "central" PLC to the motor control PLC. I'll create a UDT for things like Run Request, Speed Reference - even a remote reset if I want - and then manually map it into the motor control PLC's motor AOI. This also means that when you open up the PLC to have a look at why that motor is doing what it's doing, anything caused by a remote PLC is much more visible

If you want, you could still set up the whole motor AOI as a produced tag and consume it in your "central" PLC, so that the central PLC has all the required information - but I don't know that that's really necessary. I would again just send the status information that's really needed back across in a similarly-shaped UDT - Motor Ready, Running, Faulted, Actual Speed, etc. If it's a visualization thing, well, most HMI's can look at multiple PLC's at once anyway. No point bogging down your network with vast amounts of unnecessary data.

That's how I look at it anyway. Food for thought I hope!

what if there are both inputs and outputs in a single UDT?

Click to expand...

In short, you don't do it that way.

I build UDTs for use inside the controller that include both command and status (i.e. Input and Output) elements.

But when I am going to run them across a network, I split it into two halves for Input and for Output.

In my opinion, if you didn't have the UDT split into input and output you would have to explicitly include a label to explain which direction that data is flowing, from the perspective of the controller that includes it.

I inherited a system where a single UDT includes all the HMI data, so whenever you want to add a feature to the HMI you have to modify the UDT offline. An all the data is called out as either ".sw." for "Status Words" or ".cw" for Command Words, so I have to very very carefully be sure I don't type the wrong one. I'm sure it was intuitive and smooth for the original author, but it's a pain for me. I'd rather have an "Input_Foo1" and "Output_Foo1" UDT where Foo1 was the name of the device.

Thanks for the replies, guys. I think the take away message with produced/consumed tags is that you have to keep in mind the direction of data flow, and that all control logic should be local and if other PLCs need that data, it can be produced and consumed but you can't split up functionality between PLCs. I guess the way I was viewing things was from a local/remote with data concetrator sort of hierarchy, but with Ethernet/IP and produce/consume that's just not the best way to go about things. My plan is to have all the PLCs connect to the HMI instead of having a "data concentrator" type setup. That way I can still use my UDTs at all my sites, and data flow makes more sense.