Comm status of a Fire Alarm connected to RS232


Thread Starter



I'm working on a VB programming project (residing in PC) which needs to receive data from a Fire Alarm 8000 series via RS232 and all the data received need to be converted to MODBUS addresses.

The Fire Alarm 8000 series will not send anything to the RS232 connected to my VB programming unless there's an event like Technical Alarm, fire in a zone, fault and reset. I manage to capture all these different events and convert them to MODBUS protocol addresses respectively.

One of our customer's requirements is that whenever the Fire Alarm 8000 series is disconnected from RS232 port of my PC, my VB program will be able to capture it and set the relevant bit in MODBUS addresses. This can't be done because as i wrote earlier, the fire alarm wont write anything to the RS232 as long as nothing happens. So, disconnecting Fire Alarm 8000 series from my PC is the same as "nothing happens".

Does someone have any idea which my VB program can know when the fire alarm is disconnected from the RS232 port of the PC?



Curt Wuollet

I know how to do it, I just don't know if you can do it in VB. And I disclaim any liability in a fire alarm system that depends on VB, seriously. But, hypothetically, with hardware handshaking it's easy to tell if the signals go away. A non blocking open on the port should fail.


Colin Bancroft

I've worked for many years in fire detection and alarms, before you start you need to do some reading,

1, License for microsoft windows, check to see if it is licensed for use in safety critical situations.
2, License for microsoft VB, again, check to see if it is licensed for use in safety critical situations.
3, Your customers' property insurance policy, especially clauses about modification and augmentation of alarm systems.
4, Your professional indemnity and general liability insurance especially with reference to damage and loss caused by use of software and systems for safety of life and property.
5, If this is just a home project, your building and contents insurance.

When you've finished reading, give the PC to the children for playing Tomb Raider, and then look into suitable systems.

Lynn A Linse

Just make sure you properly wire up DTR/DSR between the PC and the fire panel. This is actually WHY this signal exists - so a host can detect a modem being removed or powered-down back in the days when the modems weren't smart enough to answer protocol queries (no AT or [OK] back then). I'm not sure how you are accessing the serial port - in my VB..NET I use Franson's SerialTools so I'd have something like if( myCOM1.DSR = False) then (handle no panel active ...)

And for crying out load you "nay sayers" - think before you call people fools. Fire panels are closed, hard-wired systems by law/code. Albert
isn't adding anything "safety critical" to this system. When there's a fire, the bell rings, at an oil refinery a signal lamp in the fire station says "fire column 7" and off the fire truck goes. At Column 7 there is be a better, more detailed alarm panel the fire crew would look at.

But "Modern People" just ask the obvious - well, can we have an HMI display of Column 7? Could we maybe see the alarms on the remote panel
here? The bell is still ringing and the fire truck still goes regardless of the stability of Albert's VB application. I have "almost" had to do this same kind of program twice, but in the end we always quoted a high enough NRE to get out of it :) My bigger concern with these systems was just parsing the "alarm printer output" which has no feedback or retry. Any events that get garbled on the RS-232 wire are
lost ... period.

Best regards
- Lynn A Linse,
Both UL827 & NFPA 72 state you shall not connect any device to a fire alarm system that is not listed for that purpose. On top of that you should check with your local AHJ to see if your project is in compliance with local codes.

Mike Olesnevich - Vernon Software

Lynn's comments are right on the money. Grabbing and parsing data that was destined for a printer is risky business because the communications is NOT bi-directional - there's no retry, no confirmation, etc. Example of problem is intercepting box alarms from master panels. Some alarm panels send 3 or 4 rounds (instances) of the same box alarm number. You can only trust what appears on the serial port when two consecutive rounds are exactly the same. That's time consuming and often leads to erroneous results. When trapping printer output you have no way of reliably identifying the end of a message and therefore you have no way of writing foolproof code.

We've written reliable code to parse E911 messages using VB6. It can be done and you should not abandon your efforts based on advice from someone that wants to sell you a hardware solution.