Help regarding CRC in NI Modbus Library

[Giridhar_Rajan]

Hi all,

I have a Fatek PLC with which I have to comunicate over the serial port using the modbus protocol. I am using the NI Modbus library. I am able to send a modbus command to enable one of the outputs of the PLC. But the problem is that, if I switch off the PLC or remove the cable, no error message is displayed. I wish to retransmit in case of an error and display timeout error after the timeout period expires. Also I have to know if the correct data is sent or not. For this I have to calculate the CRC while sending the command and recalculate after the response is received and compare if they are equal. But I dont know how to acquire the response given by the PLC. I have attached my code. Please help.

[KiwiAdrift]

Hi Giridhar,

Receiving a modbus RTU message is a lot harder for a slave than the master because of message synching issues if an error occurs. The algorythm I have used successfully goes like this:

1. Wait until the header (2 bytes) have been received. This gives you the message type as well as address.
2. Feed the msg type into a case structure.
3. For special msg types (e.g. 15, Force Coils) receive bytes as necessary and interpret on the fly how many more bytes to receive. In cases like 15, this means receiving a byte count and feeding this into the next serial receive stage.
4. For normal msgs (default case for types 1, 2, etc ) just receive another 4 bytes.
5. Receive the CRC (2 bytes) and check it.

If you have done this in stages, then you will have all portions of the msg. I bundled then into a cluster with address, function, data, crc, status. The status indicated whether all was received correctly or if an error occurred. I have considered altering this to run a string through the stages and add the data to it as it arrives.

To deal with timeouts etc, I ran an standard error cluster through the above vi stages. Things like serial port timeouts were then captured and blocked the rest of the message handler from putting together a message with bad data.

If a timeout occurred, I had an error handler that cleared characters from the buffer until a gap occurred  (i.e. a timeout of about a three character time length indicating the message had finished). This is actually the trickier part of the whole thing – recovering from an error (like a missed msg byte) and resynching again. Easier for the master – you just wait awhile and clear the receive buffer, but the slave must be ready to receive the next message header.

Note that this procedure does not handle multiple slaves, where each slave must reject msgs from other slaves. The way I was going to handle this was to check the address as it was received and if it did not match, then to handle the message according to the error case above.

Hope this helps, it is a lot more verbose than I intended when I stated writing this reply!

Derek