RSLogix5000 - PIDE Instruction - ProgProgReq and ProgOperReq Conflict?

Hello All,


Looking to get a better understanding behind an issue that I had earlier today with a PIDE Instruction that was not changing it's CV but was calculating/displaying an error.


I copied the PIDE Block over from another PLC that I was under the impression had been tested/was working but now it sounds more like a 'maybe was tested' (yet to be put in service), but Monday i'll be able to confirm when it's safe to change it's SP and see if the CV reacts.


When I copied the PIDE Block over to this new PLC I did confirm all values/parameters matched to the one I copied from (did a .L5X Export/Import). After quite a long bit of trouble-shooting I discovered both "ProgProgReq" and "ProgOperReq" were set to a 1 in the PIDE Block. We do set ProgOperReq to a constant 1 via a link in the FBD Sheet, however it looks like the 1 for ProgProgReq got carried over somehow from somewhere else as we ONLY use Oper commands for our PIDE Blocks.

(screenshot was taken after I set ProgProgReq to 0, but they were both initially 1).



After I sent a OperManualReq and OperAutoReq the problem cleared itself and the PIDE began calculating a CV. I am guessing that cleared the fight between the two ProgXReq's.

Would anyone be able to provide a basic explanation of why both ProgProgReq and ProgOperReq should not be set to a 1 at the same time / and or confirm that this is what the issue was here? I'd just like to explain this to one of my colleagues and want to be sure I'm right that this was causing a conflict in mode selections. The weird thing is that "ProgOper" on the right hand side of the PIDE Block showed as 0 the whole time (indicating that the PIDE was in Oper mode) which is super misleading.

If I can get confirmation that my theory was right here then I'll be able to get these changed in our template so the issue isn't carried over going forward.


Much appreciated to anyone who can take the time to share some input.

Cheers!

Bumping

It would seem as though the manual request followed by the auto request effectively put the loop in auto. The description, included above, indicates Opr mode takes precedence when both Req inputs are set (1).

Mispeld said:

It would seem as though the manual request followed by the auto request effectively put the loop in auto. The description, included above, indicates Opr mode takes precedence when both Req inputs are set (1).

Click to expand...

Thank you for the reply! And that makes total sense, apologies for my messy writing, it is actually Prog that takes precedence when both inputs are set to 1. The toggle of Oper Auto/Manual seemed to get it back into Oper mode and stay there.