Emilio Bodini

Produced-Consumed tags exchange

12 posts in this topic

Good morning,

I need to exchange data between three 1756-L83ES CPUs installed in a single 7-slot Rack. CPUs have IP addresses on three different classes. Can I use produced consumed tags with this configuration? Is there another way to exchange data?

Thanks for your help

Emilio

Share this post


Link to post
Share on other sites

I would think you'd be able to since they're in the same chassis. The routing would be through the backplane and wouldn't involve the network at all.

As a quick test (I don't have the hardware), I made a project with 3 -L83ES processors in a 7-slot chassis and set up a produced/consumed connection and compiled it with zero warnings/errors. I would be really shocked if it didn't work.

Share this post


Link to post
Share on other sites

Whether you in the same chassis is not as important as being on the same network.

The Design Considerations manual says;

"You cannot bridge produced and consumed tags over different networks. For two controllers to share produced or consumed tags, both controllers must be attached to the same network. You can produce and consume tags over ControlNet or EtherNet/IP networks".

It stops short of saying whether you can share data this way across different subnets, which is the situation you're in and is something I've never tried. Like @Joe E., I'd be surprised if it didn't work but if if doesn't, you'll have to use a MESSAGE instruction. 

Share this post


Link to post
Share on other sites

Thanks guys for the quick reply.

I thought that sharing the same network was the indispensable condition for data exchange, as the Design Considerations manual mentions. I'll try Joe's solution as soon as I have the hardware available.

Thanks again

Ciao

Emilio

Share this post


Link to post
Share on other sites

I never tested it, of course, but the Prod-cons connection path I built offline didn't involve the network at all since they're in the same chassis. I just added the other processors into the chassis in the I/O tree of the project and pointed the consumed tag's source to the other processor in the chassis. If they were in different racks and on different non-routable subnets....I think a NAT device or router of some kind might work but I've never had opportunity to test one with IT being the way they are.

Caveat: my only experiment with produce-consume tags didn't work well. I could only get it to work in one direction because one PLC was a 1756-L55M12 at v16 (max supported version) while the other was a 1769-L30ER at v20-ish (lowest supported version, I think). The -L30ER could consume tags from the -L55 but not the other way around. I saw reports of it working by lying to the lower version PLC about what was at the other end of the connection but I never was able to get back to it to test and found the flexibility of being able to edit things online made MSG instructions more attractive in that setting.

Share this post


Link to post
Share on other sites

IT and controls people are the bane of each other's existence, lol. 

My experience has been that when the generations of PLC get too far apart, it's better just to use the message instruction. This can be frustrating when all you need is something as simple as line speed to get from one controller to another, but it's reliable.

1 person likes this

Share this post


Link to post
Share on other sites

I set one up the other day and in the L55 (v16) I could not put the L73 (v32) in the tree so I put a L63 and it is working fine I just had to turn of unicast in the L73 on the consumed  as the L55 did not like that setting, after that it all worked fine, the 2 processors are in the same chassis.

1 person likes this

Share this post


Link to post
Share on other sites

There is a hurdle between RS5000 (V20 and below) and Studio5000 (V21 and above). All L6 controllers hard stopped at V20, but there are a handful of L7s that will go down to V19. Your workaround of "lying" to one controller and telling it that it's consuming a tag from an L6 instead of the actual L7 is pretty clever. I think that most or all data on the backplane is multi-cast, not unicast. I tend to switch everything in the local chassis to multi-cast, as I believe most of the default card settings are unicast.

Share this post


Link to post
Share on other sites

I either got that way of doing it from a TechNote/Tech Support or from Ken Roach.

Edited by alan_505

Share this post


Link to post
Share on other sites

Ken Roach, at least, is a good resource...

1 person likes this

Share this post


Link to post
Share on other sites

I've always found it useful to avoid UDTs in producer/consumer tags, always using a 124-element DINT array.  Then any UDT can be CPS'd to/from as needed.  New UDTs and tags for them can be created online, so that leaves a path (complicated, but doable) for runtime edits.

1 person likes this

Share this post


Link to post
Share on other sites

To pturmel's point, I've done udts quite a bit.  The only real hurdle is the limitation on the size or bytes of the udt.  The udt must also contain a connection status tag.  The limitation of normal tags is around 500 bytes while safety tags is 250 bytes, I think.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now