CaspianSage
Member
Good afternoon.
I have seen many ways to monitor and reset alarm conditions but most seem to use a lot of logic that I think can be simplified.
I am starting a new project and I value the contributors experience on this forum so I would like to know if you see any potential issues with the solution I have been using.
I "always" put alarm bits in one file that contains nothing else.
Using the real world I/O to set a bit in the "Alarm Bit file" for discreet I/o. Monitoring Integer files that are out of range also sets a bit in the "Alarm Bit File"
Just to be clear these files are only for alarm conditions.
I Latch most alarms and unlatch them with a mov or fll instruction as follows. (I do not agree with those who suggest using seal in logic since they get reset on a power fail.)
For small systems that only need 16 bits ie. one word. I check that the word is a 0, If not I turn on a light and a sounding device with a silence option if absolutely needed. To reset the alarm I use a MOV to move "0" into the word.
For larger systems. I use an FSC. I have it free running. ie, rung with FSC goes from high to low for one scan when done bit gets set. I use an unconditional rung to keep the inhibit bit off, and mode is set to "ALL". Scan time does not seem to be a problem.
FSC
Control R6:0
Length 10
MODE ALL
expression #B9:0<>0
The alarm light, cycle stop, auto stop or sounding device is initiated by monitoring the FOUND bit.
I use a FLL to move zeros into the entire file with a reset button hard wired or HMI based.
FLL
Source 0
Dest #B9:0
Length 10
Of course if an HMI is used the bits are examined to display the alarm condition.
This eliminates a lot of ladder logic and so far I have not had any problems. Any alarm conditions that remain after the reset is activated don't get reset because I place the reset logic before the alarm i/o. (I create a separate program file that is executed before all other program files.) (I break up my ladder logic into multiple program files pertaining to different parts of the machines)
Of course alarm condition bits that need specific attention are examined.
I can do any number of alarms even if I have to add another file (unlikely) with just a few lines of logic. Instead of lines to act on each alarm condition and to reset. If the file has any bits set the light comes on and a fault is reported. Of course this is only for monitoring and reset, Actions for individual alarms are treated as needed. For most machines I do a "Cycle Stop" required anytime the file is not equal "0". For some conditions an "Auto Stop" is all that is necessary.
I do the same thing for WARNING conditions that do not require immediate action, setting usually a Yellow light. and using a different file.
So far I have not had any problems but You guys have much more experience than I do and I don't want to cause a problem by doing this in this new project so I would appreciate your feedback.
My guess is there is someone out there that has a better way.
I think I covered everything needed to provide me an answer and If it is not clear what I do here I can post the logic.
Thank you,
Caspian
I have seen many ways to monitor and reset alarm conditions but most seem to use a lot of logic that I think can be simplified.
I am starting a new project and I value the contributors experience on this forum so I would like to know if you see any potential issues with the solution I have been using.
I "always" put alarm bits in one file that contains nothing else.
Using the real world I/O to set a bit in the "Alarm Bit file" for discreet I/o. Monitoring Integer files that are out of range also sets a bit in the "Alarm Bit File"
Just to be clear these files are only for alarm conditions.
I Latch most alarms and unlatch them with a mov or fll instruction as follows. (I do not agree with those who suggest using seal in logic since they get reset on a power fail.)
For small systems that only need 16 bits ie. one word. I check that the word is a 0, If not I turn on a light and a sounding device with a silence option if absolutely needed. To reset the alarm I use a MOV to move "0" into the word.
For larger systems. I use an FSC. I have it free running. ie, rung with FSC goes from high to low for one scan when done bit gets set. I use an unconditional rung to keep the inhibit bit off, and mode is set to "ALL". Scan time does not seem to be a problem.
FSC
Control R6:0
Length 10
MODE ALL
expression #B9:0<>0
The alarm light, cycle stop, auto stop or sounding device is initiated by monitoring the FOUND bit.
I use a FLL to move zeros into the entire file with a reset button hard wired or HMI based.
FLL
Source 0
Dest #B9:0
Length 10
Of course if an HMI is used the bits are examined to display the alarm condition.
This eliminates a lot of ladder logic and so far I have not had any problems. Any alarm conditions that remain after the reset is activated don't get reset because I place the reset logic before the alarm i/o. (I create a separate program file that is executed before all other program files.) (I break up my ladder logic into multiple program files pertaining to different parts of the machines)
Of course alarm condition bits that need specific attention are examined.
I can do any number of alarms even if I have to add another file (unlikely) with just a few lines of logic. Instead of lines to act on each alarm condition and to reset. If the file has any bits set the light comes on and a fault is reported. Of course this is only for monitoring and reset, Actions for individual alarms are treated as needed. For most machines I do a "Cycle Stop" required anytime the file is not equal "0". For some conditions an "Auto Stop" is all that is necessary.
I do the same thing for WARNING conditions that do not require immediate action, setting usually a Yellow light. and using a different file.
So far I have not had any problems but You guys have much more experience than I do and I don't want to cause a problem by doing this in this new project so I would appreciate your feedback.
My guess is there is someone out there that has a better way.
I think I covered everything needed to provide me an answer and If it is not clear what I do here I can post the logic.
Thank you,
Caspian
Last edited: