I have seen HMI programmed to reset the ONS bit. Very sloppy programming. Have even seen programs that use another ONS to OTU an bunch of ONS bits. Really sloppy programming.
I have seen HMI programmed to reset the ONS bit. Very sloppy programming. Have even seen programs that use another ONS to OTU an bunch of ONS bits. Really sloppy programming.
If 'a' is toggled and b allows 'c' to latch. Is there any instance where 'c' would not latch? This seems obvious but my troubleshooting this large program has lead me to this not always occurring for some reason. Is there limitations on how the rung is scanned?
I think your problem is the unlatch condition was true same time with your input 'a' goes high. Need to make sure that does not happen. You dont have to use oneshot. see my example below
One thing I use as a test - with an online edit add a branch around the OTL and latch another "test" bit that is not addressed anywhere else in the program. If that test bit gets latched but the monitored bit doesn't that means the monitored bit is getting unlatched somewhere. If the test bit doesn't get latched then the line is either not true or not being scanned.
If a ladder is not being scanned when you are online the XIO's & XIC's do turn green if they are controlled elsewhere, or are inputs changing.
One thing I use as a test - with an online edit add a branch around the OTL and latch another "test" bit that is not addressed anywhere else in the program. If that test bit gets latched but the monitored bit doesn't that means the monitored bit is getting unlatched somewhere. If the test bit doesn't get latched then the line is either not true or not being scanned.
Or use the cross-reference on the "monitored bit" and sort the x-ref by "destructive" to see what else could be writing that bit.... much easier than online editing.
The programming software looks at the instruction type and the current value of the tag to determine highlighting, totally irrespective if they are, or not controlled elsewhere.