Today is...
Sunday, May 27, 2018
Welcome to the Modbus Community, about
the world's leading automation protocol.
Temperature Control with Labview and Modbus ASCII
I try to read a temperature control, which uses Modbus-ASCII. Sadly I do not know, which Input-string I have to send and how the answer has to be interpreted.
By Stefanie Wernet on 19 February, 2018 - 8:19 am

Hello,

I am trying to write a Labview program to read a temperature control.
It uses Modbus-ASCII. Sadly I do not complete understand the
"Communication Register" included in the instruction.

It tells me the function code: 03H to read the contents of register, 06H to write one word into register, 02H to read the bits data, 05H to write one bit into register. Secondary there is a list with the address and content of Data Register, for example 1000H belongs to the process value and 1001H to the set point.

My input strings to read the process value/ set point were:

:07031000 getting the answer: :0783096D
and :07021001 getting the answer: :0782096E

(The Controller Address was 7.)
I do not know, what the answer means or where the temperature will be indicated.

I am happy for any help, comments and ideas.
Thank you!

Apparently your Modbus app is transmitting the colon character for the start of the message, a calculated LRC value and the CR LF characters
for end-of-message because you got a response from the slave.

Your message :07031000 is requesting slave 07 to read holding registers (Function code 03) starting at register address 4096 decimal [(4)4096, or 1000h], but you have no "number of register" specified in the message.

Try :07 03 1000 0001 to read a single value (0001) from (starting at) register 4096 (decimal) [ignoring the spaces].

For examples of RTU and ASCII message formatting see the screen shot here:
https://s13.postimg.org/ef54w8siv/FC03_read_holding_registers_RTD_vs_ASCII_with_response.jpg

or look at the site http://www.modbustools.com/modbus.html#function03

The response is a valid response, addressed to slave 07 where the 83 character is an exception response to your Function Code 03.

The actual 09 exception code is not listed in the Modbus Standard "MODBUS Application Protocol Specification V1.1b" Exception codes 08h and 0Ah are listed, but not 09h. Maybe it's 'bad formatted' message' reply.

Thanks for your help!

>Apparently your Modbus app is transmitting the colon character for
>the start of the message, a calculated LRC value and the CR LF
>characters for end-of-message because you got a response from the >slave.

Sounds as a good start!

I tried :07 03 1000 0001 and still got the same answer :0783096D.

Where or how can I identify the 83 character?
In the instruction of my device are written some "Communication Error Messages" like: 8003H Input Sensor did not connect, 8004H Input Signal Error, ... . Could there be a relation to the 83?

Or any ideas, how I can solve the probably 'bad formatted' message' reply?

If a modbus slave can not answer your message, it will respond with the original command (03) and set the highest bit in that command (83). The following number (09) is the exception code. Exception code 09 is not a valid modbus exception, maybe you can ask the supplier of the slave if they are using this exception code.

Thanks! I now understood the concept of an exception response and asked the company for help with the exception code 09.

I have problems to calculate the correct checksum. Can someone explain me, how to calculate it for example with my input string :010310000001 or :070210010001?
Do I have to consider the :?

1 out of 1 members thought this post was helpful...

You calculate the CRC using the bytes starting from the address byte up to the last data byte. So in your case you use 01 03 10 00 00 01 or 07 02 10 01 00 01.

The procedure for calculating the CRC is:
1. Load a 16-bit register with FFFF hex (all 1's). Call this the CRC register.

2. Exclusive OR the first 8-bit byte of the message with the low-order byte of the 16-bit CRC register, putting the result in the CRC register.

3. Shift the CRC register one bit to the right (toward the LSB), zero-filling the MSB. Extract and examine the LSB.

4. (If the LSB was 0): Repeat Step 3 (another shift). (If the LSB was 1): Exclusive OR the CRC register with the polynomial value A001 hex (1010 0000 0000 0001).

5. Repeat Steps 3 and 4 until 8 shifts have been performed. When this is done, a complete 8-bit byte will have been processed. PI-MBUS-300 LRC/CRC Generation 113

6. Repeat Steps 2 through 5 for the next 8-bit byte of the message. Continue doing this until all bytes have been processed.

7. The final contents of the CRC register is the CRC value.

8. When the CRC is placed into the message, its upper and lower bytes must be swapped as described below.

Sample code in Visual Basic


Public Sub CalcCRC(ByVal Data() As Byte, ByRef NumberOfBytes As Short, Optional InitValue As Integer = &HFFFF, Optional Polynom As Integer = &HA001)
Dim temp As Integer
Dim teller1, teller2 As Short
Dim shiftbit As Boolean

temp = InitValue

For teller1 = 0 To NumberOfBytes - 1

temp = temp Xor Data(teller1)

For teller2 = 0 To 7
shiftbit = ((temp And &H1) >= 1)

temp = Int(temp / 2)

If shiftbit Then temp = temp Xor Polynom

Next teller2

Next teller1

Data(NumberOfBytes + 0) = temp And &HFF
Data(NumberOfBytes + 1) = Int(temp / &H100) And &HFF
End Sub

1 out of 1 members thought this post was helpful...

The app in this thread is for Modbus ASCII which uses LRC, not CRC.

SimplyModbus has an explanation for calculating an LRC value here:
http://www.simplymodbus.ca/ASCII.htm

Summarized:
To calculate the LRC:

1. Add up all the data bytes in the message (before converting to ASCII and without the initial colon and final CR/LF).

2. Throw away any bits that carry over 8 bits.

3. Make the result negative (by twos compliment) to get the LRC byte.