Two processors (ControlLogix) on the same backplane.

I have a couple Contrologix processors sitting on the same backplane. They produce and consume tags back and forth. One of these is a position value coming from an absolute encoder. We've seen this value going to 0 randomly (what appears to be randomly that is), for maybe a millisecond at a time (only visible by using a RTO to catch it happening).

A tech told us that the info sent along the backplane was multiplexed, so it would by nature be 0 for some times. Anyone else have experience with this? What other ways are there to bring info between two processors on the same backplane?

Tharon said:

I have a couple Contrologix processors sitting on the same backplane. They produce and consume tags back and forth. One of these is a position value coming from an absolute encoder. We've seen this value going to 0 randomly (what appears to be randomly that is), for maybe a millisecond at a time (only visible by using a RTO to catch it happening).

A tech told us that the info sent along the backplane was multiplexed, so it would by nature be 0 for some times. Anyone else have experience with this? What other ways are there to bring info between two processors on the same backplane?

Click to expand...

I have used two processors before on the same backplane 'listening' to the values from an absolute encoder in two applications. I have never experienced the encoder values dropping to zero. In my case I had an absolute binary encoder connected to an input card. Both processors had access to the encoder binary values. No produced/consumed required.

Are you sure your encoder is OK. Setup the same test with the consumed tags disabled

Ian

Hmm. We have 4 of these enconders on this machine, and all 4 are experiencing the same issue. They are connected via devicenet. The tech examined the devicenet setup and everything was good.

I'm using Sick|Stegmann Absolute Encoder ATM60-D4H13X13 (Devicenet).

Two are on one devicenet, Two are on another. The data that is being produced/consumed between the two processors is not the input number, but the number that is calculated from that (Scaled, etc.)

I'll have to look into it a bit more. It's just odd that all 4 are experiencing the same issue. I trust the Tech's knowledge, but I've not dealt with produced/consumed tags much and was wondering if this whole multiplex thing was true.

Tharon said:

Hmm. We have 4 of these enconders on this machine, and all 4 are experiencing the same issue. They are connected via devicenet. The tech examined the devicenet setup and everything was good.

I'm using Sick|Stegmann Absolute Encoder ATM60-D4H13X13 (Devicenet).

Two are on one devicenet, Two are on another. The data that is being produced/consumed between the two processors is not the input number, but the number that is calculated from that (Scaled, etc.)

I'll have to look into it a bit more. It's just odd that all 4 are experiencing the same issue. I trust the Tech's knowledge, but I've not dealt with produced/consumed tags much and was wondering if this whole multiplex thing was true.

Click to expand...

If any calcs are being performed on the input, I would double check to ensure that a situation as you describe with the random 0 is not a calc issue. I once had that problem with an absolute encoder, where every now and again I saw a large negative number. Turned out to be a loose nut behind the keyboard causing the problem

Ian

The idea that Produced tag values are sometimes naturally zero because of the data transfer mechanism is erroneous.

Something else is going on here.

Examine carefully the logic that calculates the
value from those encoders. If it uses the same tag as a destination value through several rungs or lines of logic, it's possible that the periodic timer for the Produced Tag is picking up the data before the calculation is complete.

Tharon said:

I have a couple Contrologix processors sitting on the same backplane. They produce and consume tags back and forth. One of these is a position value coming from an absolute encoder. We've seen this value going to 0 randomly (what appears to be randomly that is), for maybe a millisecond at a time (only visible by using a RTO to catch it happening).

A tech told us that the info sent along the backplane was multiplexed, so it would by nature be 0 for some times. Anyone else have experience with this? What other ways are there to bring info between two processors on the same backplane?

Click to expand...

Your tech is suggesting there is a design flaw in the hardware - he's barking up the wrong tree.

Bear in mind that all the comms involved here (DeviceNet & Producer/Consumer) are asynchronous to program scan and operate one byte (8 bits) at a time.
Almost all instructions in CLX can be interrupted at any point in their execution by periodic tasks or motion control tasks to name two possibilities.
Consider this: the integer value from the encoder is decreasing. The logic dealing with the value starts to execute when the value is 256. It reads the low order byte of the integer (0) and then is interrupted by a higher priority task. On return, the value has changed to 255, and the instruction fetches the high byte (now also 0). Result is the instruction sees a zero value.
The way to beat this is to copy the data from the DNet scanner to a separate tag using the CPS instruction. This will not be interrupted.
I believe you have a similar situation with the producer/consumer connection. The data is transferred at the RPI you've configured, asynchronous to the program scans of the two processors, one byte at a time.

Interesting idea, does anyone else knowledgable on the subject support it? I'll have to find some time to dig around in this program a bit more.

Edit:
This whole process is a fairly large machine. This issue is relatively small, and I only stumbled upon it while searching through the program to try and solve some unrelated issues and making changes/adding things as the months have gone by. It's something I just couldn't explain, and confused me.

Tharon said:

Interesting idea, does anyone else knowledgable on the subject support it? I'll have to find some time to dig around in this program a bit more.

Click to expand...

It's not idle conjecture - I have been bitten by this in the past.

In my case it was abrupt spikes in speed setpoint to a drive causing it trip.

Hmmm, in my case I think it's causing abrupt spikes in speed calculations based on the change in position over time.

This causes problems because we compare the speeds of two pieces of machinery that need to be moving at relatively the same speed, but when the spike occurs the whole system shuts down because it thinks something is wrong. It doesn't happen frequently (which would be the case in your example, because how often does the position, scan times, etc, line up in such a case.)

It's more of an annoyance than a problem, since to start up again takes only one button press.

What exactly is the CPS command? (I don't have access to RSLogix500 or 5000 here at home).

Edit:
Kinda funny, I did a google search and one of the first things I found:

Use the CPS instruction to provide buffering of communications and I/O data to minimize impact of asynchronous data arrival.

Seems to be exactly what we are talking about.