Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: sgsims on November 24, 2015, 01:56:16 PM
-
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?
-
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.
-
Yep...I get that part about looping more than once during one PLC scan. I can post the project file..would that work?
-
Sure, Just zip and post.
-
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.
-
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.
-
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...
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
It's tied to the instruction, not the source data.
-
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?
-
Actually, that's the clearest explanation I've seen of code-block <-> edge instruction interaction I've seen (because it includes the why). Thank you!
-
We're implementing subroutines now and a major discussion is what instructions to allow. We'd like to give y'all the longest, stoutest rope we can, but the more we give, the greater the potential for confusion. We'll probably include as many as make sense, but provide detailed warnings (which can now be turned off ;) ).
-
Just getting a response in here before the Thanksgiving festivities. Thanks for the explanation Bob. Your explanation that talks about the behavior being tied to the Instruction NOT the Source data made the most sense to me.
Just so I can solidify my understanding of the PD contact behavior in the Do-More CPUs, will you compare how the behavior in the Do-More platform compares to that in the DL CPUs? It looks like to me that in the DL line the behavior was tied to the Source data not the Instruction.
Thanks
-
I don't have any insight to Koyo's DL implementation, but I suspect they have a second copy of the image register to implement edges. That would give the "once everywhere" behavior rather than the "once per instruction" implementation that Do-more has. We considered that approach, but with Do-more's larger image register the performance hit to do that was unacceptable. I actually like theirs better conceptually if the hit wasn't so bad, but engineering is all about values and trade-offs.
And wow...I just realized I completely misspoke about our implementation. We don't use workspace for that, because it doesn't work right during bumpless run mode updates. We started with that and weren't happy with the results. We use edge memory, which is assigned on a per instruction basis by DmD. Behavior is the same, but where we store the prior state is different. Critical issue is run mode update behavior...needs to work perfectly.
-
And DL has loops, or can have, but it doesn't have code blocks to anything like the degree that Do-More does, so this particular issue is very limited wrt discussing DL's handling of the analogous case.
IOW, if you write a DL style program in a Do-More, you probably won't notice any differences in one-shot handling.
-
And DL has loops, or can have, but it doesn't have code blocks to anything like the degree that Do-More does, so this particular issue is very limited wrt discussing DL's handling of the analogous case.
IOW, if you write a DL style program in a Do-More, you probably won't notice any differences in one-shot handling.
True.
I'm generalizing, but one-shots tend to fall into two categories, events and first scan (of a state change) detection. I'm sure you old-school guys view this differently, but I tend to write those behaviors differently in Do-more and use one-shots far less often than in DL.
-
Thanks everyone for the replies...Mission accomplished as far as understanding the differences in execution of the PD contact in Do-More vs DL. Now I can continue to program in Do-More accordingly.
Cheers