USING FSC to monitor interupts - alarms

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

What you do with "alarms" should be inspected as permissives for your process code.

If you want to deal with "warnings", you have two choices...

Either replicate the "alarms" coding and reporting you already have, or just go for one alarm "file", and your processes decide if each set bit is an alarm or a warning.

You can have as many levels as you want, e.g. information, warning, critical warning, i'm shutting down because..., you just need to specify which alarm bits are monitored for each situation..

There are many ways of killing this cat, my favourite is to have a string of OTLs setting which bits to monitor for each category - it's very visible to onlookers

Thank you

I understand. But I am more specifically asking about the resetting of alarm conditions

The resetting logic I have seen uses a lot of ladder logic examining each alarm condition and blocking a reset on a particular bit if an alarm still exists. Seems to me using one instruction ( ie a move or fll) should be sufficient

just move a zero into a word or filling the alarm file with all zeros. If any alarm conditions still exist it simply won't reset them.

Are there any potential dangers in doing it this way?

Further, this logic to set the horn and or light seems unneccessary. http://www.plctalk.net/qanda/attachment.php?attachmentid=27169&d=1367889640
Just monitoring the value of the alarm file can do that. Many ways to monitor it without examing each alrm bit.

Caspian

CaspianSage said:

Thank you

I understand. But I am more specifically asking about the resetting of alarm conditions

The resetting logic I have seen uses a lot of ladder logic examining each alarm condition and blocking a reset on a particular bit if an alarm still exists. Seems to me using one instruction ( ie a move or fll) should be sufficient

just move a zero into a word or filling the alarm file with all zeros. If any alarm conditions still exist it simply won't reset them.

Are there any potential dangers in doing it this way?

Caspian

Click to expand...

If any alarm conditions still exist it simply won't reset them.
If any alarm conditions still exist it simply WILL reset them, but the conditions will re-instate the alarm the next time the alarm rungs are scanned. That is why you should do your alarm resetting before the code that generates them.

Are there any potential dangers in doing it this way?
Most alarm handling i've seen works this way... although some people don't like to reset all alarms in case the condition that generated it has disappeared, and a global reset means that an alarm may be "missed"..

Another solution that somewhat gets over that is to only reset alarms that have been acknowledged, and that has to be done 1 by 1 so that all alarms are actually "seen". There's obviously some file manipulation needed there, but it's not too difficult.

daba said:

-- clipped
If any alarm conditions still exist it simply WILL reset them, but the conditions will re-instate the alarm the next time the alarm rungs are scanned. That is why you should do your alarm resetting before the code that generates them.

Click to expand...

I just saw this DABA I do not think you are correct here. Image tables do not get updated until the end of the scan so the PLC will not reset the alarm bit. any True to False Transition will get overwritten by the False to True transition and that is what gets written to the output image table at the end of the scan.


So you can correct me if I am wrong but I have never seen a bit changing in the middle of scan in PLC 5s

CaspianSage said:

I just saw this DABA I do not think you are correct here. Image tables do not get updated until the end of the scan so the PLC will not reset the alarm bit. any True to False Transition will get overwritten by the False to True transition and that is what gets written to the output image table at the end of the scan.


So you can correct me if I am wrong but I have never seen a bit changing in the middle of scan in PLC 5s

Click to expand...

When you talk about "image tables" this refers to the I/O images, and yes, in most PLCs those I/O images get transferred to and from the I/O modules at the end of the scan (not the case with A-B Logix5000 PLCs, but certainly true for PLC5).


But the bits in the OUTPUT "image table" will be turned On and OFF at the time the OTE, OTL, or OTU instructions are executed, it is only later that that data goes to the output modules.


And it is the same for any data, it gets changed immediately the instructions that can change it are executed. The PLC cannot "remember" which bits go on and off until the end of the scan....