RMA
Member
I think I'm getting to the stage where I should give up before I get a headache!
So now I need to ask if anybody out there has an example of using Alarm_S messages in practice. In particular how, exactly, they have to be called.
However, before we get that far, I need the answer to another question. In the specification for the 317-2 DP CPU, it specifies the maximum number of simultaneously active Alarm_S Blocks as being 60. What do they consider as being active in this sense - does it mean an active alarm condition, or does it mean the Block is active, in the sense that it is being run every cycle? If it's the latter case, I can abandon Alarm_S now, as far as I can see!
A second question, which is possibly related, regards the use of the SIG Parameter which tells the SFC that an alarm condition has occurred. According to the help files you should only call the SFC when the SIG input has changed it's state compared with the previous call of the SFC (I assume, in this instance). This seems to imply that I can't simply couple SIG to my fault detector output (because then it would be called every cycle even though SIG hasn't changed). Nor, if I understand it correctly, will simply putting in an edge detector suffice, because the second change of state of SIG, presumably signals the "Alarm gone" condition. So effectively, I need to put in a complete new layer of handling overhead between actually detecting a fault condition and reporting it with Alarm_S!
Maybe Jesper's right and I should stick to Alarm Bit signals! On the other hand, I would quite like to understand how Alarm_S works, because I assume the principles may well also apply to the other Alarm Blocks, like Alarm_8P for example. This may be about to become relavent, because there are whispers about that my next project may be a PCS7 one.
So now I need to ask if anybody out there has an example of using Alarm_S messages in practice. In particular how, exactly, they have to be called.
However, before we get that far, I need the answer to another question. In the specification for the 317-2 DP CPU, it specifies the maximum number of simultaneously active Alarm_S Blocks as being 60. What do they consider as being active in this sense - does it mean an active alarm condition, or does it mean the Block is active, in the sense that it is being run every cycle? If it's the latter case, I can abandon Alarm_S now, as far as I can see!
A second question, which is possibly related, regards the use of the SIG Parameter which tells the SFC that an alarm condition has occurred. According to the help files you should only call the SFC when the SIG input has changed it's state compared with the previous call of the SFC (I assume, in this instance). This seems to imply that I can't simply couple SIG to my fault detector output (because then it would be called every cycle even though SIG hasn't changed). Nor, if I understand it correctly, will simply putting in an edge detector suffice, because the second change of state of SIG, presumably signals the "Alarm gone" condition. So effectively, I need to put in a complete new layer of handling overhead between actually detecting a fault condition and reporting it with Alarm_S!
Maybe Jesper's right and I should stick to Alarm Bit signals! On the other hand, I would quite like to understand how Alarm_S works, because I assume the principles may well also apply to the other Alarm Blocks, like Alarm_8P for example. This may be about to become relavent, because there are whispers about that my next project may be a PCS7 one.