I cannot test Omron, and it's been many years since I last did one, I do remember a similar problem I had, I deduced that the Keep function (although the equivelent to the SR function does use edge triggering, as only Omron know how the compiled code works we can only guess.
Many PLC's do not actually compile the ladder code directly into machine code (this is due to the legacy of early PLC's not having structured blocks, i.e. the program was effectively one long block of code, This becomes a problem for on-line changes, compiling the complete ladder & downloading it will cause major delays so many had different ways to do it, I know many actually had an interpreter so the plc ladder was not exactly compiled but much like basic, it generated operation codes, these called compiled functions if you like.
Siemens S5 was a typical example, S5 used what they called MC5 (I suppose it was short for machine code 5), for example an instruction like AND I0.3 was converted into a 16 bit MC5 hex value, cannot off hand remember them but let's assume the Hex code was C05E, part of it was the AND & the other was the address, the interpreter would then call the machine code the processor understood, you must remember that like basic, it interprets the basic into a block of machine instructions I suppose you could call it a lookup table, this called the compiled instruction.
So it is probable that when Omron designed their PLC, the Keep instruction (call it a function block or AOI but in Machine code) would be a jump to a function that did the actual work.
so for example:
What would seem a simple instruction would contain probably many instructions I do not know the actual instructions but ....
if it was in plain language the keep function might be
load Set bit
Pulse a temp
AND the temp
Set The keep
Reset the temp
Load Reset Bit
Pulse a temp
Reset The Keep
Reset the Temp
Whereas, the normal Set/Reset in other PLC's may not have the reset of the pulse ones hot.
Siemens were way ahead of most PLC's, their system was structured into blocks, the ram that held the program was sort of formatted like a hard disk so it contained a type of File Allocation Table, when you downloaded a a program block (PB,FB,DB,OB) the original if it existed was not overitten but was loaded into spare ram, at the PLC housekeeping (at the end of program scan or before) the FAT table was updated with the address of the new block, the original block was not deleted just like your PC, your hard disk contains many old files, these are then written over as new files are saved to the HD, Originally Siemens did not automatically overwrite the old data & you had to compress the ram with the Programming console when there was no spare room, later this was done automatically, this was the reason that on Siemens you could download the whole program while in run mode, most even now you cannot (before some bright spark says that can cause problems yes, but if those blocks are downloaded in order i.e. PB,FB,DB, OB then it is safe).
I know that Mitsubishi is limited to about a max of 500 byte on-line change, effectively the PLC code is one long bit of code, the main routine has what they call an FEND this is the end of the main routine (Scan), jumps or calls to other blocks like functions jump to labels past the FEND instruction run the routine then return, when an on-line change is done I do believe parts of the code may be padded out with NOP's when changed code is downloaded this allows small changes without having to shift the program too much that may cause extra long scan time.
I do not pretend to know exactly how all of the above is achieved, some I'm sure about & some is assumed on what I have learnt working with a couple of engineers who have designed their own systems, who most certainly had some inside information.
