Produced/Consumed Tags vs Explicit Messaging

[ImDaz]

Hi,

Can a tag configured as a Produced or Consumed tag be read or written to with Explicit Messaging?

Context: we are retrofitting an AV system, which currently has a CompactLogix PLC that communicates with another PLC in a different system. They share tag data with Produced and Consumed tags.

We would like to remove the PLC in the AV system, to be replaced by an AV Show Controller (Alcorn V16X). This Show Controller can communicate with PLC's, but only via Ethernet/IP Explicit Messaging, with Native CIP “Read” and “Write” commands.

We cannot change or touch this other system. Therefore I'm wondering if there is any way for the Show Controller to communicate with the Produced and Consumed Tags in this other system via Explicit Messaging. If not, I guess we'll have to keep the AV PLC.

Many thanks in advance!
Daz

 

[ASF]

I've never tried, but I don't see why it wouldn't be possible. You'll have to both read and write from the new show controller, of course.

The produced tag in the PLC you can't touch should be easy - it just needs to have the data in the tag (which it already is) and I don't suppose there would be any issues reading a produced tag via an explicit message.

The consumed tag will of course be disconnected from the producer once you take the AV PLC offline. I know that when a consumed tag is disconnected from the producer, you can manually manipulate the consumed tag data using Logix, and it does not change back, so I should imagine that you can write to it with an explicit message and it will behave as if the data was changed by the now-disconnected producer.

One thing that might be a complication is how the untouchable PLC detects the state of the communication link, and if it takes any action upon disconnection. It's possible to communicate connection status of a produced/consumed tag with no ladder logic, using a UDT where the first element is a connection_status data type. If they are doing that, there's no way to fool it - if the producer is gone, it will detect the communication failure regardless of what you try and do with explicit messaging.

If they use a heartbeat encoded in the produced/consumed data and use ladder logic to check the heartbeat, you've got no problems as long as your new AV controller can replicate the heartbeat.

This sounds like an interesting project; are you able to share any more details about what you're working on, just for my curiosity?


Also, welcome to the forum!

 

[ImDaz]

Hi ASF,

Many thanks for the detailed reply! Really appreciate it.

So if I understand correctly, directly using Explicit Messaging with those tags to read and write should be possible, however the connection_status would be removed.

I'm going to try get my hands on the other PLC's code and see its means of detecting connection status. My other worry is if removing the AV PLC from the system also cause the other PLC to throw a tantrum in other ways, like by showing an I/O fault, as it would be added as a device on their program.

We've also realised that our other potential option of replacing the AV PLC with a newer one and using Produced/Consumed tag would probably also not work, as the other PLC is expecting a specific model of (now obsolete) PLC.

are you able to share any more details about what you're working on

Can't share much, aside that it's for an AV system in a theme park ride. We're upgrading the AV side, which communicates with the bigger boy Ride System. Always fun retrofitting old systems that you can't fully test until the very short window to upgrade

Also, welcome to the forum!

Thanks! I've lurked for a few years now and found it incredibly helpful, with amazingly intelligent people offering help. Great resource.

Thanks again!

 

[ASF]

Thanks for the additional details! I completely understand why you can't touch the other PLC; I'm sure there are a lot of very strict validation procedures going into a theme park ride's code.

We've also realised that our other potential option of replacing the AV PLC with a newer one and using Produced/Consumed tag would probably also not work, as the other PLC is expecting a specific model of (now obsolete) PLC.

Actually, that would almost certainly be possible. Produced and consumed tags are very backward-compatible.

For example, I have set up a produced tag between a 1769-L35E (which I'd hazard a guess is the same as the PLC you're looking to replace) and a 5069-L306ERS2 Compact Guard Logix. In the 5069 PLC I can easily add a 1769-L35E to the ethernet tree as the target, but in the L35E, well, it's old version of RSLogix doesn't know that the 5069 series even exists. So I added it to the tree of the L35E as another L35E, gave it the IP address of the 5069 controller, and away it went. The 5069 controller recognises a connection request targeted at a legacy PLC and goes "sure, I can pretend to be an L35E and exchange data with you". So if you were to get a new 5370 or 5380 compact logix and give it the same IP address and the same produced/consumed tags, the old PLC would probably continue to exchange data the way it always has without being any the wiser that the box it's talking to has changed.

I'm assuming you've got a copy of the PLC code for the PLC to be removed? If so, post a screenshot of it's produced and consumed tags data structure. They must be identical at the other end, even if you can't see them, and that will tell you whether or not they're using the inbuilt connection status or not. In my screenshot below you can see a produced tag that does use that functionality - as shown, the product and consumed tags are UDT's, and the first element of the UDT has the data type CONNECTION_STATUS, which contains a RunMode BOOL and a ConnectionFaulted BOOL. When you set up produced/consumed tags, those two BOOL's are updated automatically by the processor regardless of connection status or whether either PLC is actually running code. It all happens in a system task of some sort, so you can't override the RunMode or ConnectionFaulted bit with user code. You could write the whole UDT, CONNECTION_STATUS included, with an explicit message, but then the background system tasks would just change the CONNECTION_STATUS tags back straight away. If that's how your produced/consumed tags are set up, then you might have to look at retaining (or upgrading) the existing AV CompactLogix, because if the programmer has gone to the trouble of using a UDT with the CONNECTION_STATUS element built in, it's very likely they're using it to monitor the connection status and take certain actions if it goes down.

If your data structure doesn't contain the CONNECTION_STATUS element, they may still be using a heartbeat of some sort. Have a look through the logic that maps tags in and out of the produced and consumed tags, to see if there's any sort of heartbeat defined. Usually it'll be either a bit that toggles on and off at a specified interval, or a number that increments continuously. At the receiving end, there will presumably be logic to make sure the bit keeps changing state (or the integer value keeps changing). Once again, if it's there, whatever solution you choose will have to be able to accurately simulate that heartbeat.

The other possibility is of course that they're using a GSV to check the connection status object of the remote PLC. It's possible, and that would be a show stopper, but I'd say it's the least likely option. Just checking that the remote PLC is connected doesn't tell you that (a) the PLC is in run mode and executing code, or (b) that your data exchange structure (be that produced/consumed or explicit message) is configured and working correctly and that data exchange is actually happening. So, it's not a good way of confirming data exchange, and because of that, I've never seen it used for that purpose.

Of course, it's possible there's no connection status monitoring at all, and all this waffling on is irrelevant. You could test this easily - just disconnect your existing AV PLC from the network, and see if you can still run the ride, or if it gives you any alarms or errors or any other indication that something is not right. If it doesn't, then this gets a whole lot simpler!

 

[ASF]

My other worry is if removing the AV PLC from the system also cause the other PLC to throw a tantrum in other ways, like by showing an I/O fault, as it would be added as a device on their program.

Just to address this one specifically - yes, it will show an I/O fault, but it's very unlikely that an I/O fault on an external PLC would cause e.g. a Major Fault. If there are any consequences from the disconnection I'd expect them to result from checking the actual data exchange with the CONNECTION_STATUS or a manual heartbeat as described above, not just the fact that there's an I/O fault present. Other than making the I/O light on the controller blink, I don't think that in itself will cause you any problems.

 

[AlfredoQuintero]

One thing that should be clarified: In order to read or write logix tags with CIP Read and Wirte commends, the tags must be in the controller scope. I think CIP Read and Write cannot access program tags.

 

[ImDaz]

I'm sure there are a lot of very strict validation procedures going into a theme park ride's code.

You would be very correct

I have set up a produced tag between a 1769-L35E (which I'd hazard a guess is the same as the PLC you're looking to replace)

We would be replacing a 1769-L32E, so damn near the same one. The other (Ride) PLC is a 1756-L62

So if you were to get a new 5370 or 5380 compact logix and give it the same IP address and the same produced/consumed tags, the old PLC would probably continue to exchange data the way it always has without being any the wiser that the box it's talking to has changed.

Is there any documentation or way to confirm this is the case, and not perhaps a lucky one off? I'd hate to be caught with my pants down if we do go down that road.

If so, post a screenshot of it's produced and consumed tags data structure.

I've attached, and it seems like they don't include the connection status. So potentially a good sign.

they may still be using a heartbeat of some sort

Yes they definitely are using one of the bits as a watchdog. One being sent and one being received. However this can be emulated using explicit messaging if that's an option.

they're using a GSV to check the connection status

I do hope not, otherwise that'd be a spanner in everyone's works. Alas no way to know until I can get my hands on the code. If I can

You could test this easily - just disconnect your existing AV PLC from the network

Alas not really an option. It's in operation, and can't really touch anything until we basically change it.

Just to address this one specifically - yes, it will show an I/O fault, but it's very unlikely that an I/O fault on an external PLC would cause e.g. a Major Fault.

Okay good to know. Again, something that can hopefully be checked. And something to let the client know if we go down that road.

One thing that should be clarified: In order to read or write logix tags with CIP Read and Wirte commends, the tags must be in the controller scope. I think CIP Read and Write cannot access program tags.

Appreciate the input. I'll confirm if I get the other PLC code. I know in the AV PLC, they are controller scope. I would be surprised if the same wasn't the case in the other PLC.

Once again, I very much appreciate the input and assistance!

 

[ASF]

Is there any documentation or way to confirm this is the case, and not perhaps a lucky one off? I'd hate to be caught with my pants down if we do go down that road.

You mean aside from the word of a random person on the internet who says he's successfully done it?
This technote specifically says that a 1756-L6x at firmware version 16.22 or higher (but not a 1756-L1) can do produced/consumed to a 5370 Compact Logix (e.g. the 1769-LxxER series)
This technote and this technote give very general answers that both indicate that to consume data from processors that cannot be added to the I/O configuration, the solution is to add the closest possible module
This technote refers only to CompactLogix, but says:

The model number and revision of the controller has to be selected but when it comes down to it, it does not matter.

It ultimately goes on to say that it doesn’t matter if the controller and the firmware revision do not match, all that is important is that the IP address is correct.

Again, you can test this before you commit - you'll have to purchase or borrow a PLC to match the type you intend to use, but you could do all the preparation offline (set PLC IP address to match the existing, download a program to it with the required produced/consumed tags), and then you'd only need a 10 minute shutdown window to quickly unplug the old PLC, plug in the new one, maybe power cycle the PLC's/ethernet switches to refresh any ARP caches related to the old PLC, and see if your produced/consumed tags are working. Then reverse the process to put it back the way it was.

I've attached, and it seems like they don't include the connection status. So potentially a good sign...
Yes they definitely are using one of the bits as a watchdog. One being sent and one being received. However this can be emulated using explicit messaging if that's an option...
I do hope not, otherwise that'd be a spanner in everyone's works. Alas no way to know until I can get my hands on the code. If I can ...

Yep, as you say, the connection status is not included, and they've programmed a heartbeat, so I'd say it's extremely unlikely they're also doing the GSV check. The I/O light will still flash, of course, but it's very unlikely anything else will happen I'd say. As long as you can emulate your heartbeat, you're likely all set.

Have you tried just uploading the program from the controller? I gather there may well be some security on it, but it may still allow uploading, if not editing.

Alas not really an option. It's in operation, and can't really touch anything until we basically change it.

Do you not have a single half-hour outage where the ride is not running? After hours perhaps? You'd literally just need to unplug the ethernet cable from the AV PLC, check the ride controls for any faults, try and run the ride, and note success or failure. Then plug the ethernet cable back in and you're back to normal operation

Appreciate the input. I'll confirm if I get the other PLC code. I know in the AV PLC, they are controller scope. I would be surprised if the same wasn't the case in the other PLC.

Produced/Consumed tags can only be controller scope tags as well. You can be sure they're controller-scope at both ends.

 

[ImDaz]

You mean aside from the word of a random person on the internet who says he's successfully done it?

I trust everything I see on the internet

It ultimately goes on to say that it doesn’t matter if the controller and the firmware revision do not match, all that is important is that the IP address is correct

Okay that seems positive. If we decide to go down the replace with new AV PLC route, this may well be an option.

Have you tried just uploading the program from the controller?

I haven't got access currently, plus I believe my version of LogixDesigner may not even be compatible. I'm running v30, and the AV PLC was on v17.

You'd literally just need to unplug the ethernet cable from the AV PLC, check the ride controls for any faults, try and run the ride, and note success or failure. Then plug the ethernet cable back in and you're back to normal operation

I am almost certain even without testing that there would be faults shown on the Ride side, given the info and watchdog shared across.

And while yes this could possibly be done in the evening, call it over cautiousness If the already somewhat shakey and old system decided to keel over after I did some minor messing about, I certainly wouldn't want to be in the crossfire.
Either way, if I get the Ride PLC code, I'll share my findings.

We are also exploring if we can just leave the old AV PLC as is, disconnect its 1794 Flex I/O Modules, and leave its comms with the Ride PLC. The AV PLC also has a Prosoft ASCII TCP/IP module used heavily in its program, so it may be we can emulate some things and have it believe everything was as it once was.

Produced/Consumed tags can only be controller scope tags as well. You can be sure they're controller-scope at both ends.

I suspected as such, but great to have it confirmed.

Utterly grateful for such detailed insight. I owe you a beer

 

[ASF]

I haven't got access currently, plus I believe my version of LogixDesigner may not even be compatible. I'm running v30, and the AV PLC was on v17.

Yes, you'll need to install v17 of Logix (versions that old are known as RSLogix 5000, not Studio 5000/Logix Designer), but in my view it's 100% worth the exercise. At the moment we're speculating and making educated guesses, but if you can get online with the other PLC you can remove all doubt.

Although that does raise the question - what version is the 1769-L32E? Both that and the 1756-L62 can both only go as high as v20, so you must have at least one older version installed as you've posted screenshots from the L32E program.

I am almost certain even without testing that there would be faults shown on the Ride side, given the info and watchdog shared across.

It's likely there would at least be fault indication, for sure. But I think it's at least possible that the impact would be limited to fault indication and not functional impact.

And while yes this could possibly be done in the evening, call it over cautiousness If the already somewhat shakey and old system decided to keel over after I did some minor messing about, I certainly wouldn't want to be in the crossfire.

Completely understand that position! It doesn't matter if it's completely unrelated to what you did, if you were seen in the area just before it broke, everyone is going to blame you until you can prove otherwise.

Without knowing the specifics of how this all works, I gather that the L62 controls the ride mechanics, and the L32E controls the flashing lights and visual effects. I would guess that may be possible to have the L62 still operate the ride without the flashing lights, perhaps after acknowledging the "AV system offline" notification. If this is true, it's worth knowing about because it gives you a fallback option during your upgrade - if you know that it's still possible to at least run the ride even if the L62 can't see your new AV system, it removes some of the "this must work or the ride won't run" pressure from the project

Utterly grateful for such detailed insight. I owe you a beer

If you ever make it down under I'll take you up on that. I do like having a pint and talking **** with other PLC geeks!