I have a project which i need to capture serial data using RS232 from fire alarms which the fire alarms have different status like RESET, Technical Alarm, Fire or POWER FAILURE, for e.g. RESET is 60H followed by 3 hexadecimal bytes.

My task is to map all the different fire alarm serial data to MODBUS addresses using Visual Basic VB.

The information i'm given is each serial data is to be mapped to MODBUS addresses like 30000.1. I'm clueless about this. I have read through MODBUS document but what in it is just things like data format, MODBUS/RTU, parity, CRC and other things which i find not directly relevant to my task.

Since i'm a newbie, can anyone give me some clues what it's all about? Or any technical resources which i can read?
Or, some sample codes which anyone is kind enough to send to my email [email protected]?

Any help is appreciated.

 

Have you read the MODBUS Application Protocol Specification? This document explains the different MODBUS application commands. They deal with coils and register, so you will have to "map" those concepts to the ones relevant to your application.

Do not miss the Encapsulated Interface Transport function code, that can be helpful when mapping to coils and registers is not possible.

Regards.

 

You can use a controller like a WAGO 750-816 or -815 PLC with a serial module. The Serial module can poll the fire alarms and bring the data to the programmable controller. This data can be mapped to registers. The VB application would read the Modbus registers. Since it is RS-232 this would require a serial module for each fire alarm.

 

Thanks for your reply.

My VB project actually just acts as a MODBUS RTU Slave. It will receive data via RS232 from Fire Alarm, for e.g.
1) RESET is 1C 85 19 A1 54
2) FIRE AT ZONE 1 is 1C 28 18 13 54

and all the different data need to be mapped to input registers of MODBUS like RESET is being mapped to 30000.1 bit, FIRE is being mapped to 30000.2 bit and etc...

A Modbus RTU based PLC will query/poll my VB Project (a MODBUS SLAVE) periodically via RS485 with commands like "READ INPUT REGISTER" 04 and etc... and my VB Project needs to response to it with the data the Master requests.

Some concerns here:
1) Since the communication between my PC where the VB project resides on and the PLC is RS485, do i need to implement different codes in VB for RS485 as it's in RS232?

2) I read thru MODBUS documents. It's being mentioned that the RTU framing is something like
START: 3.5 Char Times ADDRESS: 8 bits
FUNCTION: 8 bits DATA: n x 8 bits
CRC: 16 bits END: 3.5 Char Times
I understand that this is a typical MODBUS frame but then there's something like RTU Character Framing with

START: 1 bit DATA: 8 bits
PARITY(Odd or Even): 1 bit STOP: 1 bit
The total bit is 11 bits.
I'm confused with this in which isnt it the number of bits in the Frame is made up of 8 bits block? How can i relate the 11 bits of RTU frame with the above RTU framing?

Please help. Thanks.

 

> Thanks for your reply.
>
> My VB project actually just acts as a MODBUS RTU Slave. It will receive data via RS232 from Fire Alarm, for e.g.
> 1) RESET is 1C 85 19 A1 54
> 2) FIRE AT ZONE 1 is 1C 28 18 13 54
>
> and all the different data need to be mapped to input registers of MODBUS like RESET is being mapped to 30000.1 bit, FIRE is being mapped to 30000.2 bit and etc...
>
> A Modbus RTU based PLC will query/poll my VB Project (a MODBUS SLAVE) periodically via RS485 with commands like "READ INPUT REGISTER" 04 and etc... and my VB Project needs to response to it with the data the Master requests.
>
> Some concerns here:
> 1) Since the communication between my PC where the VB project resides on and the PLC is RS485, do i need to implement different codes in VB for RS485 as it's in RS232? <

No. RS485 is just a physical specification. A full-duplex RS485 bus has 2 pairs (one for master transmissions and the other for the slaves' responses; obviously, only one slave can be active in every moment). A semi-duplex RS485 bus has only 1 pair, which is usually driven by the master. When the master has sent a request to a slave, it releases the bus for the slave take it over. RS485 and RS232 don't know about the logical meaning of the codes you transmit over them.

If your PC has an RS-485 port, I don't think you need to worry. Your VB application will be notified whenever a data arrives on that port, the same way as if it were an RS-232. And you can send whatever data as well.

If your PC doesn't have an RS-485, what you will need is an interface that transforms the RS-232 lines to RS-485 bus(es).

> 2) I read thru MODBUS documents. It's being mentioned that the RTU framing is something like
> START: 3.5 Char Times ADDRESS: 8 bits
> FUNCTION: 8 bits DATA: n x 8 bits
> CRC: 16 bits END: 3.5 Char Times
> I understand that this is a typical MODBUS frame but then there's something like RTU Character Framing with
>
> START: 1 bit DATA: 8 bits
> PARITY(Odd or Even): 1 bit STOP: 1 bit
> The total bit is 11 bits.
> I'm confused with this in which isnt it the number of bits in the Frame is made up of 8 bits block? How can i relate the 11 bits of RTU frame with the above RTU framing? <

It is easy, also . The character format concerns only the PC RS-232/RS-485 hardware configuration. You have to tell it how many bits make a byte, what kind of parity it should use and the like. But when a data arrives to the PC, your VB will be given just a normal byte, whit 8 bits. It is up to you to check if parity has been ok or the serial hardware has notified any anormal status.

Conversely, when your VB application sends data to the PLC, the serial port hardware will take care of inserting parity and stop bits.

Regards

 

> > Some concerns here:
> > 1) Since the communication between my PC where the VB project resides on and the PLC is RS485, do i need to implement different codes in VB for RS485 as it's in RS232? <

> No. RS485 is just a physical specification. A full-duplex RS485 bus has 2 pairs (one for master transmissions and the other for the slaves' responses; obviously, only one slave can be active in every moment). A semi-duplex RS485 bus has only 1 pair, which is usually driven by the master. When the master has sent a request to a slave, it releases the bus for the slave take it over. RS485 and RS232 don't know about the logical meaning of the codes you transmit over them.
>
> If your PC has an RS-485 port, I don't think you need to worry. Your VB application will be notified whenever a data arrives on that port, the same way as if it were an RS-232. And you can send whatever data as well.
>
> If your PC doesn't have an RS-485, what you will need is an interface that transforms the RS-232 lines to RS-485 bus(es). <

Thanks. My PC has no RS485 ports.
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 pools 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 didn't work.

 

Sorry, I don't understand what you are doing. Are you using a converter or are you trying to perform the conversion conecting the RS485 A+ wire to RS232 pin 2 and the RS485 B- wire to RS232 pin 3?

 

I was trying to do the latter, connecting the RS485 A+ wire to RS232 pin 2 and the RS485 B- wire to RS232 pin 3. The slave could receive the request from the Master but the slave data couldnt be sent back to Master.

I just realised that both sides must be RS485 to be able to communicaticate to each other.

thanks.

 

I was trying to do the latter, connecting the RS485 A+ wire to RS232 pin 2 and the RS485 B- wire to RS232 pin 3. The slave could receive the request from the Master but the slave data couldnt be sent back to Master.

I just realised that both sides must be RS485 to be able to communicaticate to each other.

thanks.

A+ and B- in RS485 do not equate to transmit and receive as in RS232.

You were able to receive in one direction because of the similarity between signal levels on the 485 TX- and 232 RX.


From: http://www.piclist.com/techref/io/serial/rs232.htm