Chris Elston

AB PLC Firmware or Hardware Producer/Consumer Limits?

6 posts in this topic

Does anyone know if there is a firmware or hardware compatibly issues with producer / consumer tags? I've run into an issue where a newer PLC (version 28.0) works fine with Producer / Consumer tags, however and older (version 16.0) PLC doesn't seemed to want to work. I am trying to chase down the firmware trail and see if there is a compatibly matrix or hardware matrix somewhere that lists some limits or "not support" somewhere.

Is anyone aware of such a thing?

Share this post


Link to post
Share on other sites

Chris,

 

Pretty sure you are more experienced than any of us concerning the produced/consumed topic.

I've done some limited produced/comsumed at v13, v15, v16, v19 and v20.  Between various PLC processor types and at differing firmware levels.  Never a lot of data.

Haven't done it yet at v24, haven't even done a project at v28, so no help there.

Generally, I prefer to do so through memory areas not directly in my code.  Rather, in arrays then I MOV or COP or CPS to and from, in the case that something is not correct.  Before the later firmware versions, I tended to create my own "heartbeat" signal on each side such that it could be examined for alarming and for use or execution of the various MOV, COP or CPS rungs of code.

To your original point, can't remember ever seeing a compatibility matrix.

Is there any chance that the manual for v28 describes a different method for P/C than the older firmware version manuals?

 

Checking the instruction in v20 RSLogix5000, there are none.  Checking in v24 Logix Designer, there are some useful help topics.  Seems the limit is in the max connection capability of the communications module.  Hints that Unicast is preferred.  Have to define the maximum number of tags (i.e. other processors) that can consume the tag being produced.

Edited by pcmccartney1

Share this post


Link to post
Share on other sites

I've had people complain about Produced/Consumed compatibility in the past and assert that it absolutely had to be a firmware compatibility issue.

100% of those who followed up found something other than firmware was the issue.    I can't say about those who didn't follow up.

Somewhere around v17, RA added the option of a status header on a Consumed tag, so that you could tell the run/prog/fault status of the Producer and (I think) the status of the connection.    I suppose if the v28 controller was configured to send the Status but the v16 controller can't consume it (there would be 4 bytes too many in the packet) there would be a size mismatch.

A common issue is the path to the controller;  the modern 5370 series CompactLogix consider the CPU and the Ethernet module to be the same, rather than considering the CPU to be in Slot 0 and the Ethernet module in Slot 1 and requiring a hop through the virtual backplane.  Depending on which CPU is Consuming the connection (and thus initiating the connection), the workaround probably involves inserting a different model of controller into the I/O tree.

 

1 person likes this

Share this post


Link to post
Share on other sites

We found a limitation in regards to firmware versions.  If your consumer is much older than the producer, you won't be able to get it to work "normally".  You have to add the producer into the I/O tree of the consumer and you can't add the producer if the processor didn't exist when the software version in the consumer was created.  For example, I tried to set up a produce/consume pair between a v16 L55 and a v24 L71.  The L71 can see the L55, so the L55 can produce data for the L71 to consume, but the L7x series wasn't out yet when v16 was released so I can't produce data in the L71 and have the L55 consume it.

I didn't experiment with "tricking" the v16 consumer into thinking that the L71 was really an L55, but that might work.

If you're trying to set this up with a v16 and a v28, I would be amazed if the v16 can consume from the v28 without lying to it.  I would expect the other way to work, though.

Share this post


Link to post
Share on other sites

Ken and Joe. Thanks.

Ken, good pointer what to check.

Share this post


Link to post
Share on other sites
Quote

"tricking" the v16 consumer into thinking that the L71 was really an L55, but that might work.

That's  exactly how it works.   I choose the closest similar ControlLogix model and it has always worked between 1756 series controllers.

As far as I know, Produced/Consumed tag connections do not perform any electronic keying, so telling the Consumer that a 1756-L71 is actually a 1756-L1 or L55 or L61 should not matter.   I'm not sure why Rockwell allows you to select the controller type or revision at all.

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