SolarNinja
Member
I have been tasked with implementing a spark detection/spark suppression system in our low pressure (.9" w.c. 28" dia. round duct) main dust control trunk.
Our chief electrician (also a PLC guy, x military, super smart, installed and programmed automation systems in bottling plants, mills, processing facilities, etc.) and I decided that we would have a CompactLogix L32 be the heart of our spark detection system. This was about 6 months ago. We already have a hardware based system built in 1984 that has been refurbished by a reputable fire safety company, but it cannot monitor velocity. Since we are constantly changing our ducting and controlling flow manually with the use of dampeners I feel it is important to monitor velocity in our main trunk line. The reason it is important is that it takes time for the suppressors to actuate, so we need to make sure that sparks do not make it past the suppressors before water is applied. I am using the same spark sensors and suppression units supplied by the fire protection company, as well as their test lights and field data.
The system is VERY simple. In a nutshell (not explaining redundancy systems) there are two sensor banks, each with two spark sensors. Zone 1 and zone 2. Zone 1 detects a spark, then a downstream suppression unit energizes for a period of 5 seconds after the last spark is detected. If by some chance a spark makes it past the suppression unit into zone 2, zone 2 sensors will see the spark and actuate an "abort gate", which completely stops air flow immediately. SIMPLE.
This thread should be interesting. I was advised (by the manufacturer of the fire safety system) that I had to use their hardware. Well, licensing and code aside, what I am looking for is safety first, forget everything else. They failed to tell me WHY I cant use a PLC to detect spark. I mentioned something I said in another thread and a gentleman there said that I cannot use a PLC to run fire safety equipment, that there were dedicated systems for that. He asked others to chime in, so I started a new thread on the topic because I cannot afford to be making stupid mistakes here.
So far I have used the PLC to collect spark sensor data, and actuate the suppression units. No problem there. I am trying to visualize a circumstance where a PLC is not "safe"...a situation where the program will not protect against fire. Thus far, every single circumstance that I can foresee can be handled by redundancy programmed into the PLC.
(1) sensors faulting (prevented by periodic automatic sensor tests)
(2) PLC shut down (make an alarm happen if PLC faults)
(3) Suppression actuators not functioning (monthly actuator checks, this may not seem ideal, but that's the same way the dedicated fire safety system works...there is no way to "test" them without physically turning them on and making sure water is coming out)
...you get the picture. I can't see a damaging event or failure that cannot be solved by redundancy. The fire system that we have is rebuilt, so it should be operational and "safe", but I didn't build the thing, so I can't work on it. Plus, electronic components fail. PLC, if you adhere to the ISA-88 standard, can be worked on by any competent ladder logic programmer. True, years of R&D went into these fire safety systems, but you have to think, they make a **** ton of money on these systems, for something that performs a relatively simple task. If they switched to PLC systems (I can see why they would not want to do so) they wouldn't make NEARLY as much money. And money, my friend, is the whole reason they are in business. Code and licenses aside, I want something that WORKS, is PRACTICAL, and SERVICEABLE.
So far at least two people have told me that I cannot use a PLC for spark detection/suppression, however, no one has given me any reason why. The PLC seems far superior in every way than a bunch of hardware that can fail at any point just as easily as the PLC. That being said I very much welcome and value ANYTHING anyone has to say on the subject. Thank you so much for reading, and I am more than happy to post my experience these next few months detailing how this project unfolds.
Our chief electrician (also a PLC guy, x military, super smart, installed and programmed automation systems in bottling plants, mills, processing facilities, etc.) and I decided that we would have a CompactLogix L32 be the heart of our spark detection system. This was about 6 months ago. We already have a hardware based system built in 1984 that has been refurbished by a reputable fire safety company, but it cannot monitor velocity. Since we are constantly changing our ducting and controlling flow manually with the use of dampeners I feel it is important to monitor velocity in our main trunk line. The reason it is important is that it takes time for the suppressors to actuate, so we need to make sure that sparks do not make it past the suppressors before water is applied. I am using the same spark sensors and suppression units supplied by the fire protection company, as well as their test lights and field data.
The system is VERY simple. In a nutshell (not explaining redundancy systems) there are two sensor banks, each with two spark sensors. Zone 1 and zone 2. Zone 1 detects a spark, then a downstream suppression unit energizes for a period of 5 seconds after the last spark is detected. If by some chance a spark makes it past the suppression unit into zone 2, zone 2 sensors will see the spark and actuate an "abort gate", which completely stops air flow immediately. SIMPLE.
This thread should be interesting. I was advised (by the manufacturer of the fire safety system) that I had to use their hardware. Well, licensing and code aside, what I am looking for is safety first, forget everything else. They failed to tell me WHY I cant use a PLC to detect spark. I mentioned something I said in another thread and a gentleman there said that I cannot use a PLC to run fire safety equipment, that there were dedicated systems for that. He asked others to chime in, so I started a new thread on the topic because I cannot afford to be making stupid mistakes here.
So far I have used the PLC to collect spark sensor data, and actuate the suppression units. No problem there. I am trying to visualize a circumstance where a PLC is not "safe"...a situation where the program will not protect against fire. Thus far, every single circumstance that I can foresee can be handled by redundancy programmed into the PLC.
(1) sensors faulting (prevented by periodic automatic sensor tests)
(2) PLC shut down (make an alarm happen if PLC faults)
(3) Suppression actuators not functioning (monthly actuator checks, this may not seem ideal, but that's the same way the dedicated fire safety system works...there is no way to "test" them without physically turning them on and making sure water is coming out)
...you get the picture. I can't see a damaging event or failure that cannot be solved by redundancy. The fire system that we have is rebuilt, so it should be operational and "safe", but I didn't build the thing, so I can't work on it. Plus, electronic components fail. PLC, if you adhere to the ISA-88 standard, can be worked on by any competent ladder logic programmer. True, years of R&D went into these fire safety systems, but you have to think, they make a **** ton of money on these systems, for something that performs a relatively simple task. If they switched to PLC systems (I can see why they would not want to do so) they wouldn't make NEARLY as much money. And money, my friend, is the whole reason they are in business. Code and licenses aside, I want something that WORKS, is PRACTICAL, and SERVICEABLE.
So far at least two people have told me that I cannot use a PLC for spark detection/suppression, however, no one has given me any reason why. The PLC seems far superior in every way than a bunch of hardware that can fail at any point just as easily as the PLC. That being said I very much welcome and value ANYTHING anyone has to say on the subject. Thank you so much for reading, and I am more than happy to post my experience these next few months detailing how this project unfolds.