Modbus RTU message computes checksum over wrong message

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Send a serial message
2. See that it is not acknowledged/answered
3.

What is the expected output? What do you see instead?
Message should be replied to. I see nothing. 

Please use labels and text to provide additional information.

Original issue reported on code.google.com by anders.h...@gtempaccount.com on 2 Mar 2009 at 7:09

[GoogleCodeExporter]

I'm having severe problems with code.google.com and my Eclipse installation so I
can't check in my changes. However -

In transacton.py change this method to the following

    def buildPacket(self, message):
        '''
        Creates a ready to send modbus packet from a modbus request/response
        unencoded message.
        @param message The request/response to send
        '''
        data = message.encode()
        packet = struct.pack('>BB',
                message.unit_id,
                message.function_code) + data 
        packet = packet + struct.pack('<H',computeCRC(packet))
        return packet

Or as a patch in my branch:
### Eclipse Workspace Patch 1.0
#P pymodbus
Index: pymodbus/transaction.py
===================================================================
--- pymodbus/transaction.py (revision 10)
+++ pymodbus/transaction.py (working copy)
@@ -315,7 +315,8 @@
         data = message.encode()
         packet = struct.pack('>BB',
                 message.unit_id,
-                message.function_code) + data + computeCRC(data)
+                message.function_code) + data 
+        packet = packet + struct.pack('<H',computeCRC(packet))
         return packet

Original comment by anders.h...@gtempaccount.com on 2 Mar 2009 at 8:05

[GoogleCodeExporter]

Managed to check in stuff from Eclipse. Turns out you MUST use https:// with the
repository to check in things. Check out only requires http:// 

Changes are now available in version r11. 

http://code.google.com/p/pymodbus/source/detail?r=11

Original comment by anders.h...@gtempaccount.com on 2 Mar 2009 at 8:46

[GoogleCodeExporter]

You are correct, the entire packet is crc/lrc-ed.  Fixed in the trunk.

Original comment by Bashw...@gmail.com on 27 Apr 2009 at 4:00

• Changed state: Fixed