I'm using one-shots wrong?

[OrionHE]

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?

[plcnut]

Possibly a NOT ST0 in the same rung?

[OrionHE]

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?

[franji1]

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.

[franji1]

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).

[Mike Nash]

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.

[franji1]

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"  .

[Mike Nash]

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.

[OrionHE]

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.

[OrionHE]

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.

[franji1]

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).

[BobO]

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...

[BobO]

Edge memory is retentive.

[OrionHE]

Edge memory is retentive.

Is what I'm seeing a bug then? Edge is retriggered on reboot.

[plcnut]

Is what I'm seeing a bug then? Edge is retriggered on reboot.

By reboot do you mean a simple powerdown-then-powerup?