Operaghost
Member
That said, when coded in that way i.e. in a context where only one CTU is used, .CU functions as the one-shot history/storage bit, as my code proves, even to the point that you can unlatch it manually to override the one-shot when needed.
Also, IIRC, the A-B non-SLC programming manuals that provide flowcharts of each instruction show that it also functions as the history bit internally.
I understand what you are getting at, but because the counter increments on the rising edge of the CU and not the rising edge of the logic preceding it, it just does not have the capability to give us a history. There is nothing to tell it that the logic ahead of it has or has not changed state. That's not a flaw or a bug. It's just how it works.
The only instruction I can think of off the top of my head that provides a sort of history is the BTR/BTW (PLC-5) and MSG instructions. With those, the EN turns on when the logic goes true and then if the rung goes false it remains set until the DN or ER is set. That provides more of a one-shot/history than any other instruction. Unlike the CTU/CTD where they simply mirror the status of the rung logic preceding it.
To me, this timing chart (PLC-5) does not show any sort of history function
OG