Positive Differential Contacts in a While Loop

[sgsims]

I am using a set of Positive Differential Contacts in a WHILE loop inside of a PROGRAM and am getting some unexpected results.  I am also using the simulator,  not connected to an actual DO More CPU.

The unexpected result is that they are closing like a normal set of contacts not the positive differential.  I checked to see that the BIT controlling the PD was indeed HIGH for a few scans using the single scan feature of the debugger before calling the program containing the WHILE loop.

Thinking it might be something to do with the Simulator?

[plcnut]

The Differential is true for ONE CPU SCAN. That means if the loop is repeating over and over inside of a SINGLE PLC SCAN, the contacts state will not change. If you could post/ describe what you are trying to do then maybe we can help you find an alternative way to accomplish what you need.

[sgsims]

Yep...I get that part about looping more than once during one PLC scan.  I can post the project file..would that work?

[plcnut]

Sure, Just zip and post.

[Controls Guy]

Handle the one-shotting yourself in the logic in the loop.

Create a memory bit for what the status of the main was on the previous loop iteration.  If the bit is false, clear the memory bit.  If the bit is true, and the memory bit is false, this is the "first scan".  Do what you want to do on first scan and set the memory bit.  If both the main bit and memory bit are set, do nothing.

[sgsims]

Ok here it is.

The rungs in question are rungs 3 & 4 in the LOOP Program.

I also added a rungs 3-6 in MAIN to test my theory.  It looks like to me that ONE Shotness occurs at the instruction level and not at the overall program level.  (That probably didn't make sense)

Looking at rungs 3-6 in MAIN if I disable S0 then turn X7 ON and leave it on for more than one scan then Enable S0 then y15 goes ON.  So it looks like the One shot is being evaluated at the rung level not the overall program level.  

I would have expected in the above example that Y15 would not turn ON because X7 went from OFF to ON and remained ON for more than one scan before rung 6 was evaluated.  I am pretty sure this is how things worked in the DL line of CPUs was this changed in the DO-More line or am I just massively confused.

[plcnut]

Just remember that any time you have a loop, then the .time slice comes in to play. $Main's timeslice is not adjustable like the user program structures, so loops can act much differently. I will be away from my computer till tomorrow...

[plcnut]

It appears that the program works fine. I did do a couple of minor changes, as well as I added some INC's to N memory for monitoring what was going on.
I have attached the project back on here. After downloading the program and the memory image to your simulator, let me know what is not working as expected.

[sgsims]

Thanks for the help PLCnut...I took a look at the revised program and I agree everything works as expected the first time the program runs after a Program to Run transition.  I was experiencing the same results.

The program begins to act unexpectedly the second time the loop program is run. 

Within the LOOP Program rungs 1 & 2 acts as expected,  however when rung 3 is reached the CycleBendDie.Done PD COntact is evaluated as true thus allowing power flow to the DEC / INC / INC instructions.  So the WHILE Loop inside of the LOOP program only performs one loop and the Pointers point to V12 & V102 instead of V11 & V101 as desired.

i was expecting the PD on Rung 3 to not be true because the CycleBendDie.Done bit had been HIGH for more than one scan prior to calling the LOOP program. 

[plcnut]

The documentation is just a little fuzzy on this, so I'm not quite sure whether to consider this a bug or not...
The reason that the CycleBendDie.Done does not evaluate true the first time that Loop is run, is because the .done bit is false after a Program-to-Run mode transition.
It would appear that the Positive differential bit compare is unique to each program block. So it sounds like the best thing for you to do, is to set your own bits inside your programs.
See the attached example.

[sgsims]

Thanks for the help....I am glad to see that you are seeing the same thing I am seeing.  Would be nice to know from Host if this is a bug or the intended behavior of the PD contact.  Seems a little odd that this contact would behave as it appears to be behaving.  Not really the true definition of a "One-Shot" contact.  Anyway what do I know.

I took another approach to the problem,  I changed the execution order of the programs to be SetBackstop / CycleBendDie / Loop...and changed the PD contact using CycleBendDie.Done bit to a NO Contact using the CycleBendDie.DoneThisScan bit.  Seems to produce the behavior I am after.

I'll study your approach as well.

[BobO]

Edge behaviors are true for a single invocation of the instruction. They really shouldn't be used in a loop, and if there isn't a program check warning for that we need to add one.

So weird, but no, not a bug.

[plcnut]

Bob, the behavior is the same even without a loop. I added a test program block with a .done PD from another block, and as long as .done was true when the block was enabled, the PD would be true for the first scan.

[BobO]

It's tied to the instruction, not the source data.

[BobO]

Ok...back from grocery store doing last minute Thanksgiving shopping.

There is a workspace register for every instruction which stores the powerflow state from the prior invocation of that instruction. When powerflow is true and previous is false, the contact in energized for that execution of the instruction. In loops, the instruction is executed as many times as the loop spins, so each pass looks like a new scan, but after the first invocation, prior and current are both true.

A single source value (like .Done) will trigger every contact it is used in, since there is a workspace for every instance of a PD contact, but only the first time that instance is invoked following the input state transition.

Clear as mud?