Edge bit remapping

[FAHOutdoors]

I have an identical program that I write to several PLCs that has several rising and falling edge bits. I need to be able to do a run time edit to these, but the remapping of internal hidden edge bits plays havoc with this process as it will trigger some logic even though it didn't actually occur, the remapping of the EXXX locations still triggers it.

Is there any existing way around this? and if not, can a built in data block STXXXX be added in a future release that fires the first scan after a runtime edit occurs? similar to st0 $firstscan but "$runtimeedit" or something like that? So that I can put that in series with the problem rising edge bits to prevent them from firing when the remapping occurs.

[franji1]

I have an identical program that I write to several PLCs that has several rising and falling edge bits. I need to be able to do a run time edit to these, but the remapping of internal hidden edge bits plays havoc with this process as it will trigger some logic even though it didn't actually occur, the remapping of the EXXX locations still triggers it.

Is there any existing way around this? and if not, can a built in data block STXXXX be added in a future release that fires the first scan after a runtime edit occurs? similar to st0 $firstscan but "$runtimeedit" or something like that? So that I can put that in series with the problem rising edge bits to prevent them from firing when the remapping occurs.

The runtime edit edge bit behavior is a pregnant moment, say for an edge contact changing from X0 to X1, what is the CORRECT edge transition behavior on the exact PLC scan when the logic changes?  The way it works now is that a new edge bit (previous scan state value of OFF) gets assigned to this "new" instruction.

One option is to utilize the POWERFLOW based edge contacts vs. ELEMENT based.  Then you can tweak your runtime edit logic to get it to behave exactly as you want based on the POWERFLOW - it's a burden to figure that out, but it at least gives you the tools to customize it on a contact-by-contact basis.

Another option is to roll your own edge bit block (MyE) containing previous scan state and do the NC previous scan contact (MyE42) in series with NO X42 current scan contact to detect OFF->ON transition.  Then you can tweak (force?) your previous scan bits (MyE42 or MyE43 or whatever) to get the exact runtime behavior you want.  In $tBottomOfScan, move all your NO contact states (X) to the NC (MyE), e.g. MEMCOPY X0:SD MyE0:SD 10 would move 320 bits as 10 DWORDs pretty fast.

[franji1]

Look at ST193 - "Indicates active program buffer. Toggles when new program is downloaded".

In $tTopOfScan task, I would MANUALLY roll my own DELTA contact logic (e.g. burn C998 and C999) of ST193 (built-in Delta contact utilizes the same Edge memory)
STRNE ST193 C998  // current ST193 different than previous scan's ST193?
OUT C999  // turn on C999 for one PLC scan
// move ST193 to "previous" scan C998
STR ST193
OUT C998

I guess in $tFirstScan, just do
STR ST193
OUT C998
to initialize C998 to the current ST193 value

EDIT
or just
RST ST193 in $tFirstScan
? ? ?

[FAHOutdoors]

As best I can tell testing various start up methods (power loss, switching to stop then back to run, runtime edit of program),  $ST0 and the task first scan don't trigger/happen after a runtime edit, only power cycle or stop/run cycle. I couldn't get the ST193 idea to work with either a delta contact or a leading and trailing edge contact in parallel to create a "Program changed" pulse for some reason, the condition definitely changes everytime it's programmed, but it never prevented the problem. So I just used a burner bit that I make sure is always on, and if it triggers a rising edge in the top of scan because I'm updating a PLC in runtime and the oneshot fires because its edge bit gets remapped, then I pulse the "program changed" bit on for one scan. Thanks for the ideas!