MSG .ER Bit never clearing ?

Using an L81 - I have the arrangement below that will try the Ethernet Radio first and if that fails use the Cellular Radio. The Failover works ... until the Cellular Radio fails a cycle. When it does the ER bit for the CELL radio NEVER clears. I can toggle it off in Logix and it will go merrily on its way again.

FYI the POLL bit stays true until all MSG to this RTU either DN or ER.

I have this set up on 3 RTUs after a main microwave link failure and I did it very late at night as an emergency workaround expecting to find stupidity when I returned to it. But even in the fresh light of a new day I can't imagine why this is happening.

The Flowchart for the MSG instruction says that when the rung transitions true one of the things it does if the EN bit is not already set is to clear the ER bit. In my code an ER bit means move on to the next radio in the cycle so the rung will not be true for more than one scan. I thought that might be related so I added a delay to that process and it didn't change this behavoir.

Next I added a 500ms timer to reset the ER bit and that "fixes" it but why would it not reset on every new poll cycle in the same manner that the upper one does?

Using the [ONS] before your msg instructions is causing your problems. The msg instructions would need 2 cycle's to execute if the .er is set. The first scan would clear the .er bit, then if cleared next scan would allow it to execute.

The instruction will not execute every scan if you remove the one-shots. It will only re-execute on a false - true transition

chelton said:

Using the [ONS] before your msg instructions is causing your problems. The msg instructions would need 2 cycle's to execute if the .er is set. The first scan would clear the .er bit, then if cleared next scan would allow it to execute.

The instruction will not execute every scan if you remove the one-shots. It will only re-execute on a false - true transition

Click to expand...

I am skeptical this is the issue. As TheWaterboy indicates, per the instruction flowchart, when the instruction becomes true it will clear .ER (among other things) and then execute as if .EN had been true. I have used ONS with MSG before without issues.

You are correct that the oneshots are likely redundant as MSG are triggered by false-to-true transitions already.

TheWaterboy said:

FYI the POLL bit stays true until all MSG to this RTU either DN or ER.

Click to expand...

I suspect you have an issue in your logic here. The .ER bit will stay true until the MSG runs again (or you clear it), so it remaining true indicates that the second MSG is never being triggered after it becomes errored.

I see from the green rails that your screenshot was taken online... but the first MSG shown is not DN or ER, and yet POLL has become false. As a result, even when the first MSG errors the second will not run because it has POLL being true as a condition. Separate your branch onto its own rung without the POLL XIC and it should work.

I suspected the ONS at first too and I would agree they are possibly redundant depending on what you are doing with the output bits, but removing it didn't change behavior.

I should have captured when the first msg errs, and I can as this is easily reproducible.
When I clear the second ER bit, it works normally, the first MSG enables, errors and then the second msg runs. When I set the second ER bit, the first one does its normal thing but the second MSG never enables.

I never noticed the POLL bit like the pic shows when I am looking at it live, I'll keep looking at the surrounding logic, perhaps I'm clearing the poll bit before the end of scan and when the evaluation takes place the poll bit is evaluated as reset. That would certainly explain it.

The status bits on the MSG operate a little differently than on other instructions. The EN in particular.

The EN bit turns on when the logic ahead of it goes true. That's normal of course. It turns off when the message DN or ER is set AND the rung goes false. That is very different from other instructions where the EN turns off when the logic ahead of it goes false. It means the EN can be on when the rung is false, while it waits for the DN or EN to set. Which is exactly what that live screenshot is showing us on the top branch. That looks very normal to me.

In the bottom of the branch, the ER is set from a previous failed attempt and it remains set until the next time the bottom MSG is triggered. Again that looks very normal to me.

In looking at that screenshot as a snapshot in time, the MSG instruction for the Radio is false. The instruction is not executing. The ER bit is not being written to. It has been left in its last state. You can toggle that bit on and off since nothing is currently writing to it.

I don't see anything wrong with the logic or its operation here. Everything is doing what it is supposed to do. I agree that the ONS instructions are redundant. But they shouldn't hurt anything in the operation.

OG

EDIT: (I think this might be your last comment in the previous post but I already wrote this ), one other thing to consider is that the status bits update asynchronously to the scan. So if POLL turns on, we trigger the top MSG and move on to the next instruction. It does not sit there and wait for the ER or DN before moving on. So it could execute the top instruction and then continue down through the logic. Lets say further down in the code the ER bit for the MSG finally turns on. Then we finish the logic. But at the end, you turn off the POLL bit. On the next scan since the POLL bit is off we do not execute that rung and the bottom message never executes.

I would like to see the actual logic for POLL.

If POLL is false when the first MSG finishes (whether DN or ER) then the lower branch MSG will not execute since the common input condition is false. When POLL then next becomes true the upper branch MSG will execute, but that clears the ER, meaning when the lower branch is evaluated immediately after the MSG will still not execute and its ER will continue to be set.

Based on screenshot provided and described behaviour, this is what is happening -- when ReadCHRCell.ER is true then POLL is being set false before ReadCHR finishes executing.

I think I remember some funkiness about the timing of when things, like the transition from .EN=1 to either .DN=1 or .ER=1, happenin, i.e. they happen asynchronously with the MSG instruction rung itself (this is a littl like the issue with TONs in Siemens, so the equivalent of the A-B-canonical pattern [XIO the_ton.DN TON the_ton] will not work to make a repeating timer in TIA).

If that is the case, then I could imagine a scenario, where the MSG on the top branch is about to fail, and ReadCHRCELL.ER is 1 from a previous scan's execution of the second branch and the ReadCHRCELL MSG, but ReadCHR.EN is still 1 and ReadCHR.ER is still 0 when the second branch executes, so there is no rising edge (ONS.2) and the ReadCHRCELL MSG does not execute on this scan.

Later during that same scan, but before the rung that can clear Poll, the ReadChr MSG completes and fails asynchronously with the MSG branches, which failure assigns 1 to ReadCHR.ER, and even later during that same scan, that clears the Poll, because ReadCHR.ER just became 1 and ReadCHRCELL.ER is still 1 because the one-shot (ONS.2) did not fire.

On subsequent scans Poll is 0 so which prevents the second branch's one-shot (ONS.2) from ever firing, which puts the two .ER=1 values in the bank, and only ReadCHR.ER will be cleared on the next rising edge of Poll, which clearing will keep that second one-shot (ONS.2) from triggering as well.

The problem I see with this scenario is that the timing of the ReadCHR.ER transition to 1 should be essentially random during any given scan, so eventually it should occur after the previous Poll assignment and before the second branch's one-shot and ReadCHRCELL MSG, which would clear ReadCHRCELL.ER to 0.

Two possible fixes:

1) Assume my scenario is bollocks and the second one-shot (ONS.2) gets triggered: clear ReadCHRCELL.ER on that trigger before the MSG

2) Make a copy of ReadCHR.ER in between - i.e. in time - the two MSG branches, and use that duplicate to trigger the second one-shot and to assign a value to Poll. I think this [XIC ReadCHR.ER ReadCHR_ER_copy] should be dependent on the [XIC Poll] only, not on the first one-shot (ONS.0); or maybe these need to be three separate rungs:In this case, when MSG ReadCHR fails after the cellular MSG rung, clearing Poll will be postponed until the next scan, which gives this rung another chance to try the cellular MSG.
_

How many msg instructions are you calling when Poll is set? It is possible that the msg queue is full. This would prevent the .er from resetting.

I fought that queue issue on PLC-5 far too much so polling for me is done one MSG at a time and doesn't proceed until each MSG finishes. to make that palatable I force the .TO at 5 seconds because it should never take that long and a .TO sets the .ER bit which increments the poll.

As others have pointed out I found that the previously set .ER bit on the second failed MSG is incrementing the poll before it triggers the MSG. So on the next scan the poll bit is no longer active.

All my fault - Rookie mistake.
Thanks guys

Excellent.

To give credit where credit is due: I just re-read OG's last post, and now realize that my post was unneeded as it was essentially a duplicate of what OG had already said; I think @plvlce's first post was also going down the same road.

TheWaterboy said:

...All my fault - Rookie mistake. ...

Click to expand...

No fault or blame need be assigned; this is a subtle "feature" of the MSG instruction and I imagine you are not the first to be bitten by it.

Also, I'd be curious to know what your eventual solution was. I still think it's odd that the radio .ER apparently always gets set between the MSGs and the Poll assignment, and never the other way round. Are these MSGs early in the scan, and the Poll assignment late in the scan?

Anyway, it's all just bookkeeping and timing; take care of the bits ...
_

This is one that is a DOH! moment when realized.

The polling sequencer looks for either a DN or an ER to indicate the MSG is done for whatever reason. in this case I had to add a second set of bits to account for the additional MSG.

I assumed that the second ER would be cleared in the same scan when the first ER went true, but as I often do I neglected to remember that the second ER bit is still considered set until the end of the ladder and since it was evaluated that way, the polling sequencer dutifully incremented and released the Poll bit so that second branch never had a chance to run with the first ER bit set.

It's so obvious now.
.

TheWaterboy said:

I assumed that the second ER would be cleared in the same scan when the first ER went true, but as I often do I neglected to remember that the second ER bit is still considered set until the end of the ladder and since it was evaluated that way, the polling sequencer dutifully incremented and released the Poll bit so that second branch never had a chance to run with the first ER bit set.

Click to expand...

I am either not understanding what you are saying, or this does not get to the bottom of the issue. To wit ...

IF the one-shot (ONS.2) feeding the cell MSG (ReadCHRCELL) goes true, it will definitely reset the value of ReadCHRCELL.ER to 0 for the rest of that scan. The problem as I see it is that the radio MSG's ReadCHR.ER becomes 1 asynchronously after the MSGs but before the Poll assignment, as OG mentioned, so yes the ReadCHRCELL.ER is 1 through the rest of that scan after the MSGs' rung, but it is not "since it was evaluated that way [I assume you mean by the MSG instruction]"

I assume the Poll assignment is summat like this:And I think the only change needed would be to add a one-shot*:By adding the rising edge to the ReadCHRCELL completion bits we ensure the cell MSG gets triggered on a radio MSG failure. So the Poll does not get reset to a value of 0 unless

• EITHER the radio MSG succeeds (ReadCHR.DN is 1)
  • cell MSG is irrelevant and will not need to be triggered
• OR the cell MSG completes, whether
  • Successfully (ReadCHRCELL.DN has a rising edge) or
  • Unsuccessfully (ReadCHRCELL.ER has a rising edge)

* I could still be wrong about why it was happening, so a grain of salt is in order here.

The poll bit comes from a numeric tag value.

Each RTU program has a Public scoped Poll bit and I set one of those based on the numeric tag value. That value gets incremented when each program completes it's MSG sequence by seeing either an ER or DN bit for both the read and write MSGs. When all RTUs are done the value gets reset and the cycle repeats.

The original late night logic that caused the value to increment was :

((Msg1.DN or Msg1.ER) or (Msg2.DN or Msg2.ER))

When Msg2.ER got set from a previous failed attempt, at the end of the scan the incrementing logic found an .ER bit and incremented. That Msg1.ER bit never got reset because every subsequent scan evaluation the .ER bit was already set so it just incremented the poll bit.
This occurs because the entire ladder is scanned and evaluated by the PLC before any memory locations are updated. So on every scan the poll just incremented.

What fixed it was

((Msg1.DN OR (Msg1.ER AND (Msg2.DN or Msg2.ER)))

This allowed Msg2 to see a logical transition its input that it never could see before incrementing logic moved on.

oh, and I got rid of all the ONS on the MSG's

Ah, thanks.

Oh wow, so once Msg1.ER becomes 1, then even the Msg1 MSG instruction won't get a True rung input?

I think my proposed scenario, with the external ReadCHR.ER changing at some point other than at the execution of the MSG instruction, is not going to happen. There is an MSG-internal .ER bit, and that probably can change asynchronously with the MSG instruction, but that would not affect the external .ER bit until the next time the MSG instruction executes.

I'm not sure about the internal vs external bits part. The bits get evaluated at the end of the ladder scan and while I have heard of unexpected results occurring because bit changes took place after the rung has been scanned, I'm not doing anything at anywhere near the speed where that would be noticeable.
This was just a poor logic choice on my part.

Gotta play by the rules of the machine.