Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: OrionHE on May 16, 2016, 02:04:34 PM
-
I love one-shot contacts and have used them to do some very cool things over the years, but today I have discovered a limitation.
Say C0 is a retentive bit and it is SET.
Say I reference C0 with a leading edge one-shot contact to update a timestamp when C0 is first set.
Say the PLC is rebooted.
My timestamp now reflects the current time as the PLC boots. C0 is still set (never was reset), but the leading edge One-shot triggers.
This applies to do-more and DL260, I'm assuming it's "normal".
I had the notion in my head that since the bit never turned off, the off-to-on transition would not occur, and my logic was sound.
Is there any way around this idiosyncrasy?
-
Possibly a NOT ST0 in the same rung?
-
That seems to solve it. Thank you!
I'd love to know, if anyone knows and wouldn't mind explaining, how the off-to-on transition is occurring in this case. I figure that the retentive memory table would remember its last state. Is somehow the "last state" flushed at reboot, leaving the PLC to "assume" an off-to-on transition occurred and thus energize the one-shot contact?
-
There are different possible meanings for the word "reboot"
1. PLC switch is in RUN position/mode. Power down PLC. Turn back on. It "reboots" in RUN mode.
2. PLC switch is in RUN position/mode. Switch to STOP. Switch to RUN. This is a RUN->PGM->RUN mode transition.
3. PLC switch is in Terminal position in RUN mode. Use Designer to switch to PROGRAM (PGM) mode. Use Designer to switch back to RUN mode. This can occur actively via the Set PLC Mode dialog or passively during a WRITE PROJECT TO PLC action, with a SYSTEM CONFIGURATION change (you will be notified in the Download Project to PLC dialog that the PLC must "Switch to PROGRAM mode, then Download Project" with the option to "Switch back to RUN mode after download completes").
When you say "reboot", which one(s) of these do you mean? Or is there a different scenario (this is quite possible)?
Here is what you SHOULD see on your edge bits for each scenario above:
1. You should NOT see the "edge" fire (i.e. your timestamp should NOT change, it should have the OLD value)
2. and 3. You WILL see the "edge" fire and your timestamp WILL change.
-
I'd love to know...
Yes, the "edge" state is retentive and is maintained on a POWER CYCLE in RUN mode. But this state memory is CLEARED on PGM->RUN (see my earlier post).
-
I ran into this last week on a D0-06. No matter what anyone tells you, cookie cutter jobs are filled with "Gotcha!"'s
I had to add the not SP0 and I stupidly moved a few bits and registers and that moved them out of the retentive ranges. Worse, my TMRAs were also non-retentive (by default). Of course I caught all of these 2-3 years ago, but completely forgot when I went to re-use part of the code.
-
My answers are for Do-more only, since this is a topic in the Do-more CPUs forum.
Host did not write the 06 firmware (Koyo did), so we do not know for sure how DL works. But since Host Engineering wrote Designer and the firmware for Do-more, we are "in the know" ;D.
-
May be, but I had to do several things to keep it all working as I went through all the options you mentioned above. I need to keep running uptime for 4 weeks, so oopsies are frowned upon.
I sure was wishing it was the new Do-more rather than a D0-06.
-
There are different possible meanings for the word "reboot"
1. PLC switch is in RUN position/mode. Power down PLC. Turn back on. It "reboots" in RUN mode.
Here is what you SHOULD see on your edge bits for each scenario above:
1. You should NOT see the "edge" fire (i.e. your timestamp should NOT change, it should have the OLD value)
Thank you for the thorough reply. I don't mean to be ungrateful or difficult, but I DO see the edge fire in all three scenarios.
For some reason this really bothers me. It doesn't seem to fall under "logically expected" behavior, though it may very well fall under "programmatic expected" behavior. I tend to hold programming to the rules and standard of logic, so this one doesn't sit well.
Anyway, knowing is half the battle ;) and I'm still grateful for your exposition.
-
I ran into this last week on a D0-06. No matter what anyone tells you, cookie cutter jobs are filled with "Gotcha!"'s
I had to add the not SP0 and I stupidly moved a few bits and registers and that moved them out of the retentive ranges. Worse, my TMRAs were also non-retentive (by default). Of course I caught all of these 2-3 years ago, but completely forgot when I went to re-use part of the code.
If only there was a way to add rung comments to our experience. I've had to relearn some things after years past too. :)
-
I don't mean to be ungrateful or difficult, but I DO see the edge fire in all three scenarios.
I am seeing the same thing. :-\
Designer/Technology Version 1.0 and Designer/Technology Version 1.4 (the oldest and the newest).
I thought the edge state was retentive. BobO will chime in on this (he's visiting with Automation Direct).
-
Edge memory retentive? I don't even remember. I'll check the code tomorrow. Getting dinner and then Top Golf. Atlanta definitely has more available than east Tennessee... ;)
-
Edge memory is retentive.
-
Edge memory is retentive.
Is what I'm seeing a bug then? Edge is retriggered on reboot.
-
Is what I'm seeing a bug then? Edge is retriggered on reboot.
By reboot do you mean a simple powerdown-then-powerup?
-
Is what I'm seeing a bug then? Edge is retriggered on reboot.
By reboot do you mean a simple powerdown-then-powerup?
I mean that, and Run->PGM->Run, and CPU switch from Term->Stop->Run->Term. All tested types of reboot. Basically, if the PLC experiences a _FirstScan, then the edge retriggers even if the coil is retentive and set.
-
[/quote]
If only there was a way to add rung comments to our experience. I've had to relearn some things after years past too. :)
[/quote]
Experience, its what allows you to recognize a mistake. When you make it again!
-
I mean that, and Run->PGM->Run, and CPU switch from Term->Stop->Run->Term. All tested types of reboot. Basically, if the PLC experiences a _FirstScan, then the edge retriggers even if the coil is retentive and set.
In the sense that we use the term, none of those are actual reboots. I'm pretty sure transitions from program to run do clear edge memory by design. What does it do on a power cycle?
-
I mean that, and Run->PGM->Run, and CPU switch from Term->Stop->Run->Term. All tested types of reboot. Basically, if the PLC experiences a _FirstScan, then the edge retriggers even if the coil is retentive and set.
In the sense that we use the term, none of those are actual reboots. I'm pretty sure transitions from program to run do clear edge memory by design. What does it do on a power cycle?
The same thing.
-
I mean that, and Run->PGM->Run, and CPU switch from Term->Stop->Run->Term. All tested types of reboot. Basically, if the PLC experiences a _FirstScan, then the edge retriggers even if the coil is retentive and set.
In the sense that we use the term, none of those are actual reboots. I'm pretty sure transitions from program to run do clear edge memory by design. What does it do on a power cycle?
The same thing.
What I meant was "it does the same thing", not "they are the same thing". I didn't know if the discussion ended because it was perceived that I was rude, so I sought to clarify.
It would appear based on BobO's comments that the current functionality of retentive edges is unintended.
-
I didn't know if the discussion ended because it was perceived that I was rude, so I sought to clarify.
Nah. Just waist deep in alligators right now...critical phase in the development of the new platform.
-
Sounds fun/nightmarish.
-
Sounds fun/nightmarish.
A bit of both. The future is bright though. I think y'all will like the new hardware.
I checked the code. When initializing edge bits, it makes no distinction about whether we are entering run mode from startup or from program mode. This would be very easy to change...however...for things like this we are very reluctant to do so, even if 'wrong', because of the potential impact to existing projects. There are definitely a few things we would do differently given the choice, but choose not change.
-
Bob,
So you are saying that the OP is experiencing the expected results from the way that it is coded?
I only ask because I do not remembering it being that way in the past... Sometimes things get a little muddy in my brain though. I may be remembering issues with edge fired instructions.
-
Bob,
So you are saying that the OP is experiencing the expected results from the way that it is coded?
I only ask because I do not remembering it being that way in the past... Sometimes things get a little muddy in my brain though. I may be remembering issues with edge fired instructions.
It looks to me like it has always been this way. It is about a 5 second coding change to make it retain the prior state on power cycle return to run, and clear on program to run...which is what I though the behavior was. The question is whether we should or should not 'fix' it.
-
Obviously I cannot make that call, and you guys know a lot more about its effect than I would...
It would seem that fixing it may be the way to fly (with the proper warnings during the updating process).
-
Possibly make it an option to retain state on power cycle in RUN mode OR option of clearing edge bits. There could be a 3rd option of always doing a whole PGM->RUN "reset" on power-cycle in RUN mode. Make the default be retain state of the edge bits on power cycle in RUN mode.
-
Obviously I cannot make that call, and you guys know a lot more about its effect than I would...
It would seem that fixing it may be the way to fly (with the proper warnings during the updating process).
Hmm. I just tweaked on a Do-more/C-more last week. Do-more went from 1.3 to 1.4, C-more from 5.12 to 6.15. I didn't have any issues in this case on the Do-more and I did gain a Memory Image I didn't previously have. The C-more had major changes in its Alarm screen because it is very, very different now.
As often as I have had to upgrade firmware on processors/HMIs due to changing programming software, I'm maybe a little bit leery of changes that could have unknown implications. (I ran into the retentiveness of one shots on the D0-06 2-3 weeks ago also.)
Possibly make it an option to retain state on power cycle in RUN mode OR option of clearing edge bits. There could be a 3rd option of always doing a whole PGM->RUN "reset" on power-cycle in RUN mode. Make the default be retain state of the edge bits on power cycle in RUN mode.
Options are good, they just need to be transparent in the case of upgrades of the firmware as I get really twisted up over informational warnings that require more intimate knowledge of my existing program than I have. This thread is a good example of differing understandings of the true reality.