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:
http://automatedsolutions.com/products/modbusrtu.asp

Modbus Slave:
http://automatedsolutions.com/products/modbusslave.asp

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):

http://www.kksystems.com/index.htm

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:

http://www.win-tech.com/html/demos.htm

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.

http://www.automatedsolutions.com/products/modbusslave.asp

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.

Dave Slee wrote:

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.

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 GND<->GND and TX<->RX and RX<->TX,
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 convert one end of teh comm to 485, do i have to
convert the other port to 485 as well?  I'm not sure if this can be
done with a single RS232 to RS485 converter or not.

Dave Slee wrote:

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:-)