Micro810 equal and counter instruction bug?

In this project I wanted two pumps to alternate between lead and lag. The controller is a Micro810.

I'm using a counter to dictate whether pump 1 or pump 2 is in lead.
If the lead pump happens to fail I wanted to force the lag pump to become the lead pump using the MOV instruction to move a number to ALT_COUNT.

ALT_COUNT was 1 so P2 = lead. I failed P2 in testing so rung 9 moved a 0 into ALT_COUNT making rung 9 true. My main concern was Rung 7 & 8 for some reason remained true

This is how I normally do it on RSLogix500, but it didn't for me here. But I programmed a workaround in the Micro810 so now that works.

There's a oneshot before the counter maybe the counter doesn't work like a counter in Logix500 and 5000. These are the only MOV instructions in the program and there is only one counter I can upload another picture later of how I have that working.

The problem is the title of this thread; please burn the following statement into memory: the PLC cares not a whit what you want it to do, but it will inexorably and mercilessly do exactly what you tell it to do.

CCW displays a value for ALT_COUNT sampled at some moment in time; that time maybe between program scans, but who knows.

Perhaps there is another line of code assigning a value of 1 to ALT_COUNT before rung 7 on each scan.

To test this, try creating a new INT and MOVing the value of ALT_COUNT into it just before rung 7; that will tell us what the value of ALT_COUNT is at the start of rungs 7, 8, and 9.

Here is a subset of the rungs shown in the OP, plus one more inferred.

The first image shows the case with Pump 2 failed: P1 is lead; P2 is lag; ALT_COUNT is 0.

The second image shows the case with Pump 1 failed: P2 is lead; P1 is lag; ALT_COUNT is 1.

Toggling the PUMP_x_FAIL switches toggles between those two states.

The last image shows the case with both pumps failed: P1_LEAD is 0; P2_LEAD is 1; P2_LAG and P1_LAG are both 1; ALT_COUNT is 1, but it seems likely that was ALT_COUNT was 1 just before Rung 3 and 0 just before Rung 4. Yet all four displays of ALT_COUNT show a value of 1.

The PLC cares not a whit ... you have the rest memorized, right?

Yup I see it now I just had to think of it one rung at a time.

I couldn't move a number into the counter count value. Unless there is a way I didn't know. I was just thinking of logix5000's counter.acc.

So I made a tag and put it in the counter's count value. I see now that only moves that value into the tag.

I'm not always right, but it does usually work out that way .

Also,

• Since there are only two pumps, the ALT_COUNT lead/lag driver has but two possible values, 0 and 1, so we can use the low bit of the CTU object's .CV DINT instead,
  • and when that .CV DINT reaches the value of 2, we can use the CTU object's .Q value to reset the counter and write a value 0 to .CV.
  • See Rung 1 below for an implementation of this; the TON is there to trigger synthetic lead changes, but note that whatever triggers the CTU does need to be a one-shot.
• Again since there are only two pumps, if a pump is lead, then that pump is not lag, and vice versa, so the P1_LAG and P2_LAG booleans are both redundant.
  • If two pumps should run, then there does not need to be an ANDed [XIC run_two_pumps XIC Px_LAG], because the [XIC run_two_pumps] by itself will be enough to run the lag pump, and where it is ORed with the [XIC Py_LEAD] of the the lead pump, which simply becomes [1 OR 1] i.e. telling the lead pump to run "twice" does no harm. See the bottom branches on Rungs 5 and 6 below.
• Yet again since there are only two pumps, if one pump is lead, the other must be lag, and vice versa, so one of the P1_LEAD and P2_LEAD booleans is redundant.
  • Rung 6 in the image below uses [XIO P1_LEAD] to detect when Pump 2 is the lead pump.
• Twiddling the ALT_COUNT lead/lag driver to get the lag pump to run in place of a failed lead pump is a rather indirect approach; for the final time since there are only two pumps, below is, IMNSHO, a cleaner way to handle a failed lead pump.