Conversion of RS232 serial data from Fire Alarm to MODBUS

Save yourself considerable development time by using a readily available Modbus ActiveX Control in VB.

Check out Automated Solutions' Modbus ActiveX Controls. Master and Slave versions are available. Using field-proven, off-the-shelf components will significantly cut your development time.

Modbus Master:

Modbus Slave: Fully functioning trial versions are available for download.

OK. Got that. So what you want to make is an arbitray RS232 telegram to MODBUS ASCII gateway?

You can probably buy what you want rather than hand-rolling it. Are you doing this for fun or employment? If it is for employment then I would suggest to you that you might spend weeks playing about with MODBUS stacks on serial ports on PC computers, especially if you are going to play with VB. The result will most likely be a flaky implementation of a gateway that two or three times a month is offline whilst being re-booted for the latest security "upgrade" which will break your code.

Right. That's my prejudice against PC computers running Windows and VB in mission critical applications out in the open. I feel better now.

How about this for an idea...

Can you persuade the person who said "use VB on a PC computer" to look at the problem from a different angle?

What you are looking for is a way to make fire alarms with RS232 serial telegrams look like PLCs that support MODBUS. I think that you might be better to avoid the PC computer altogether (personal opinion from above). So what you need is a little black box next to every fire alarm that understands their proprietary protocol, speaks it fluently, polls the local device and holds a copy of its current status in memory. Then in response to MODBUS interrogation, "plays out" the current values from the internal database. In the reverse direction, if MODBUS writes take place, then the appropriate telegram needs to be sent out, possibly if you want to be clever by looking for change of state, but probably just writing it anyway. You then make sure that the MODBUS port is RS485, assign adresses to each converter and daisy chain/multi-drop them together. Then one MODBUS master can talk to all of the fire alarms and get their status. You have also invented a "product" that has a part number that matches a given make and model of fire alarm panel. I beleive that in an industrial setting this is the way to go.

Hardware platform? There are many manufacturers out there with programable protocol converters or gateways. As an example (one that I have used in the past for this sort of problem):

Look at KD485-PROG in "Products" and the example code in the "Software" section.

Its not a black box, more a purple and green one. Each converter is about £195 (per fire alarm panel) and the MODBUS library is £300 (need only one license). Using the example code I would guess that it would only take you a couple of days of coding to get up and running with something like this.

Key to all of this is software and more explicitly the software specification. The hardware is straight-forward, you can just buy this. The protocol stack is also straightforward - you can just buy this also.

What you need to do is think object orientated. What properties does the generic "fire alarm" object have? You have already identified some examples:

Outputs:

Fault (Boolean) Power Failure (Boolean) Alarm Sounding (Boolean)

Inputs:

Reset (Boolean)

There are many, many more in the generic "Fire Alarm" object. As examples, what about the zone of a detected fire, the type of the detector that found it, the time and date of the last alarm, the status of the backup battery and so on?

As I said above, the key to the problem is to identify these properties and then map them into MODBUS registers - in case you hadn't made the connection, MODBUS regsisters are just elements of a number of honking great big arrays inside each device.

I would imagine that in your situation you would describe the most complex fire alarm panel that you are likely to see and that every "real" panel is an inherited version of your "master" structure with some of the parameters unused.

To drop into a pseudo high level language, you are going to define two STRUCTs - one is the properties of a generic fire alarm panel, the other is a handfull of arrays making up the MODBUS registers. You pass the MODBUS data to the MODBUS stack that you buy in. You write some code to decode the RS232 telegrams and put that data in the 'FireAlarm' STRUCT. You define some events like MODBUS_read_received, MODBUS_write_received, Fire_Alarm_Poll_Due, Fire_Alarm_Unsolcited_Message and tie those to the appropriate transfer of elements of FireAlarm STRUCT to ModBusRegisters STRUCT. You might need the odd timer or two.

I realise now that I re-read the above that I'm probably teaching my granny to suck eggs, but I might as well go on and finish...

What you need to do now is to write a functional specification. This will document all of the information you have to hand now and will clearly point you in the right direction towards a solution. If you are not familiar with the term, a functional specification tells the world what your complete system will do - what its response to a particular stimulus will be. A functional specification also studiously avoids the question of "How?" unless the client specifically tells you that a particular approach MUST be used. Even then I dump that information in an annexe at the end becuase it often turns out that there is a cheaper, better and faster way. Your functional specification will probably include a timing diagram - perhaps a sequential flow diagram of a state machine to define what happens at what time in response to what event.

Only once your Functional Specification is complete should you move on to a Software Specification detailing hardware platform, language, structures and algorithms. At this point you will revisit your Functional Specification when you find that some of the things you said you would do turn out to be impossible with the platform that you choose later - the compromise loop.

Nearly done.

There are many clever and knowledgable people on this forum that are going to help you, but you need to get the jargon right and be unambigous otherwise you will get more answers to questions you didn't mean to ask than you can probably handle. Google will be your friend here.

And the last point. To reinforce the above. On a given software type contract I usually spend about 50% of the time figuring out and documenting the specification(s), 25% of the time coding and the remaining 25% testing. So don't dive straight for the nearest keyboard and crank up VB - try Word and Excel to write your specification first.

I'll get off my soap box now. Thanks for listening.

Dave Slee Riding Mill Energy Contracts Ltd.

Thanks a lot Dave...

Thanks a lot for your detailed explanation.

My VB project is to act as a Modbus Slave that receives data from a Fire Alarm and will response to requests/polls from a Modbus Master which issues a 04 Read Input Registers commands to the project. The data from Fire Alarm is continuous while the requests/polls from the Modbus Master are periodical.

I'm doing this for employment. Since the timeframe given is very short and my company is cost-conscious, i dont think i can switch my programming platform other than VB. That means i still have to stick to using VB for this.

I'm writing a functional specifications now before i jump into writing codes. That will be better.

Perhaps you can give me some more advice for this project like functions to use, data types, timing and so on since this is my first VB project. I may post questions from time to time.

Sincerely Thank You again.

Dave Slee wrote:

OK. VB6 or .net? If your background is computer science, you will probably get along better with .net, but for a quick and dirty hack VB6 is probably easier to start with.

You say the company is cost concious. I think we all know what you mean! I would still suggest that you persuade the dark forces of finance to shell out for some development assistance for you. At the very least get an ActiveX or OCX for a MODBUS slave otherwiuse you will spend weeks of work understanding and interpreting standards to write a standard block of code that you can download a trial of today and buy tomorrow. I googled and picked one at random that seemed to have good documentation:

Mbsv7OCX.zip (206K)

Read the documentation that comes with the control. You can see how many API calls that are supported and the depth of the structure of the whole thing. This is more than half of your project! Now you can see why these components cost from $0 to $1000 each - you save days of work. I don't know about your line of business, but if I spend $1000 and save between 1 and 2 days of time, I got a bargain. Ask yourself what sort of support and assistance you are going to get for $0 too. The control above costs $300 - bet you can't code that in a day!

Another poster on this group suggested a different control - probably very good - so bend his arm to give you a free trial and report back to us telling you about your experience. Don't forget that if the code turns out to be good, buy it and thank the vendor. As someone who is setting out on the road of becoming a software author, you will appreciate that its good to get paid too!

Take a look at the documentation on the above control. That will give you a mighty leg up on the project.

The other side of the project might cause you some fun and games. One of the things wrapped up in the MODBUS ActiveX controls is all of the serial port handling, which can be very tricky if you are new to either VB or serial comms. You will no doubt go down the road of using the MSCOMM control in VB. It all *looks* very simple when things go right. But the world is a complex place, so you have to figure out what to do if your serial message is corrupt. For example, what happens if you come in half-way through a message? Are the fire alarm messages fixed length or are they delimited by say a [CR][LF]? Is there a checksum? What happens if the fire alarm is not connected? Do you set a value in a register that says "Fire Alarm Communications Fault". How long do you wait for a new message? All this stuff goes in your functional specification - don't worry yet about how to fix it.

There are alternatives to the MSCOMM control and in .net 2.0 you will find that there is a similar control for serial ports.

There is lots and lots of help on all of the above out on the Web. There are some other newsgroups that can probably help you with the programming part of this project - sci.engr.control is a good place for specifics like MODBUS and control in the real world. Other groups that might help could be:

microsoft.public.vb.*

Best of luck...

Dave Slee Riding Mill Energy Contracts Ltd.

Here is a link to our Modbus Slave ActiveX Control.

All you need to do is load the control's arrays with your fire alarm data. The control will handle the rest. A pre-built VB6 HMI application is included that you can use to test it out without writing any code.

We also offer a Modbus Master ActiveX Control that can be used to test your slave application.

Thanks. I tried to simulate Master and Slave in my PC with ModScan and ModSlave from win-tech. They worked well where Slave could response to the polls by ModScan without any error.

Since my PC has no RS485 ports, i used a RS232 to RS485 converter but this time, the Slave could receive the polls from the Master but the Master kept showing "Invalid response from Slave" and "Message Time Out". Fyi, i connected the A+ and B- to pin 2 and pin 3 respectively and i twisted them to try also. Also, GND to GND also. But it still didnt work.

OK.

Now you've stumbled into a whole new area of pain - the physical layer.

Are you using RS485 on 2 wires or 4 wires (forget the screen/drain for a moment or two)?

A quick "popular serial comms physical layers" primer:

RS232 is voltage level signalling on 2 wires - transmit and receive. It has poor noise immunity.

RS422 is differential voltage level signalling on 4 wires, often called A, A', B, B'. Due to being differnetial on twisted pairs, even though its typically only TTL levels, it is quite noise immune. It is point to point. Depending on the manufacturer, you connect A to B and A' to B' and vice versa.

RS485 is the same signaling levels as RS422, but with the ability to make the receiver "back channel" to the master tri-state (high impeadance) so that you can have a master and multiple slaves. In 4 wire the A and A' wires are usually the channel out from the master to all of the slaves. B and B' are often the returns from the slaves again wired in parralel.

In RS485 2 wire you devise a mechanism to change the direction of the line drivers in each interface. One simple way is to use a handshake line from the master (CTS usually) to tell the master computer line driver whether the master computer is meant to be sending or receiving. The slaves listen all of the time and control their line drivers so that they can make replies, always assuming that the master will go silent after an interrogate long enough for the required slave to reply.

Another approach is if there is data at the "master" converter (the start bit of a framed character for instance), to force the line driver into transmit. A number of timeouts after the stop bit, you can flip the line driver and listen for replies. Now you see where the 3.5 character "silent" periods are included in the MODBUS spec - a "smart" RS485 driver uses the silent periods to determin if it is a talker or a listener in 2 wire RS485.

You need a 3rd (or 5th) wire not only for screening but as a drain. The drivers and receivers might be capacitively coupled, but if you transmitted a long series of 1s or 0s then you would move the reference around unless there is a drain path for the receivers.

Checklist for your situation:

• Look at the documentation for both converters (you do have 2 converters don't you?!)

• There will often be a diagram showing typical connections.

• It is usually easiest to loop out all of the handshake lines on the PC so that you don't have to worry about hardware handshakes at the PC end. Link RTS to CTS and Link DCD to DSR to DTR at each end. Make up a cross over test lead (if you haven't already) with just GNDGND and TXRX and RXTX, handshakes looped out. Make sure that both test PCs are on the same electrical supplies so that their grounds are something like the same potential otherwise you get a surprise when you connect up this non-isolated cable.

• Now connect in the converter pair:

• If the converters are from different manufacturers (or even different models from the same manufacturer) you might need to experiment with which RS485 wires do what - often labelled differently like A, A', B, B' or RX+, Rx-, Tx+, Tx- or some other code invented by the manufacturer - especially if you run 4 wire. I often resort to trial and error and then re-label throughout UP+, UP-, DOWN+, DOWN- where DOWN goes from master to slaves and UP goes from slaves to master. Technicians much prefer this nomenclature.

• If your converters support 4 wire, try this first - that way you don't have to worry about handshaking or timing to get the line drivers to flip

• Your converters might need switches or jumpers changing to select RS485 2 wire, CTS or auto driver control. If your RS232 leads from PC to converter don't use CTS then you will need auto.

You will find a combination that works eventually. NOW DOCUMENT IT!

If in doubt, refer to Horowitz and Hill "The Art of Electronics", roughly page 700 or so onwards which explains quite clearly and succinctly the whole field of RS232, handshaking and RS485 and gives great practical advice. You don't do electroics and computers unless you have a copy of the silver "bible" on the shelf next to your desk!

Good Luck,

David.

Thanks Dave. I think i really need to have a copy "The Arts of Electronics" on my desk. :)

My 485 is 2 wires during testing while during the real application on the field, it will be 4 wires.

If i c> > I tried to simulate Master and Slave in my PC with ModScan and ModSlave

If you're simulating the link using two PC's you are going to need two converters. Try to get your test setup as close as possible to the setup in the field - in your case use 4-wire 485 because 2-wire will require different switch settings.

With comms links, it is always preferable to have the *real* hardware on the bench - that way you don't look stupid when you plug it in in front of everyone and find it doesn't work...

Good luck. Cameron:-)