Permament LRC error in incomming frame - Modbus Ascii

[GoogleCodeExporter]

Configuration:
Modbus,serial,ascii

What steps will reproduce the problem?
1. Read holding register e.g. self.read_holding_registers(1,1,slave_addr)

Current behaviour:
No value received

What is the expected output? What do you see instead?
The value of the requested register should be returned

What version of the product are you using? On what operating system?
Windows XP, pymodbus v0.9.0

Original issue reported on code.google.com by Mariusz....@gmail.com on 22 May 2011 at 6:30

[GoogleCodeExporter]

The problem is in transaction.py:482 in checkFrame(self): function. Data passed 
to checkLRC()has incorrect format there should be 'row data' but now ascii 
frame is used.

Attached quick fix, that is not very smart because there are double ascii to 
row data conversion - first when computing/checking LRC and second later when 
processing the frame. However it works fine.

Original comment by Mariusz....@gmail.com on 22 May 2011 at 6:40

Attachments:

• transaction.patch

[GoogleCodeExporter]

You are right, there is an error in the check code.  However, I believe it is 
only that I am including the ':' in the LRC computation.  I don't believe that 
I need to decode the data back to binary before I perform the LRC as LRC 
operates on the ASCII text of the message (also excluding the LRC and the \r\n 
of the message).  This can be seen on page 15 of the modbus protocol reference 
guide.

Please correct me if I am wrong, otherwise I will make the necessary changes 
along with the updates to the unit tests.

Original comment by Bashw...@gmail.com on 23 May 2011 at 6:24

• Changed state: Accepted

[GoogleCodeExporter]

I reckon that LRC should be calculated on the binary representation of the 
ascii bytes, so add up all the data bytes in the message (before converting to 
ASCII when creating frame or after converting to binary when receiving frame 
without the initial colon and final CR/LF).

There is interesting discussion about it
http://www.control.com/thread/1026171238

However the LRC of the requested data is calculated in correct way, only 
checking LRC of the received frame is incorrect.

Original comment by Mariusz....@gmail.com on 23 May 2011 at 8:35

[GoogleCodeExporter]

Sounds good. I'll have to update a few of the tests, but I should have it all 
checked in tomorrow. Thanks!

Original comment by Bashw...@gmail.com on 24 May 2011 at 4:14

[GoogleCodeExporter]

This issue was closed by revision r150.

Original comment by Bashw...@gmail.com on 24 May 2011 at 2:30

• Changed state: Fixed