I'm using one-shots wrong?

[OrionHE]

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.

[Garyhlucas]

[/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!

[BobO]

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?

[OrionHE]

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.

[OrionHE]

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.

[BobO]

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.

[OrionHE]

Sounds fun/nightmarish.

[BobO]

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.

[plcnut]

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.

[BobO]

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.

[plcnut]

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

[franji1]

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.

[Mike Nash]

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.