crc16 | command line crc16 calculator | Apps library

Does the library auto-assign the slave number, or we have to define it?

With MinimalModbus you pass the slave ID through in the minimalmodbus.Instrument('/dev/ttyUSB0', 1) call (the 1 is the Slave ID). How you set the slave ID on the device itself varies (this is not covered by the Modbus over serial line spec; could be a configuration program, DIP switches, based on the serial number etc. Other libraries may take different approaches (for example defaulting to Slave ID 1).

From the datasheet, is it the register number is the address?

The header in the spec tables says "No(Address)" so "10001(0000)" means register 1, address 0 (these refer to the same thing; I recommend reading the "Modbus: When 40001 Really Means 1, or 0 Really Means 1" section in this article which explains some of the issues around addressing).

And how many decimals do I expect if there's two data sequence as a response?

Not quite sure what you mean by "two data sequence". The Modbus spec only details the sending of bits (coils) and 16 bit values (input/holding registers). From a quick look at your spec it looks like this device just uses a single registers; for instance "OUT1 Output time" has "unit: ×10㎳" so take whatever is in the register and divide by 10 to get ms.

Is the CRC16 check already included within the library as i shouldn't code it?

Any decent Modbus library will look after the protocol details (such as CRC) for you (so no you don't need to code this; MinimalModbus will calculate it for you)

Just initialize crc result to 0xFFFF not zero as I expect. such:

What you describe, and what your desired result corresponds to, is CRC-16/UMTS. The description from Greg Cook's catalog is:

It's not standard C or C++^(a) but, given the context (CRC16 and the variable names), it almost certainly takes two 8-bit bytes and forms a 16-bit word.

^(a) Hence it's probably defined somewhere in the libraries or source code you have available to you.

The CRC implemented in the provided Python code is not the CCITT CRC-16. It is referred to interestingly as a false CCITT CRC-16 in this catalog. The CRC implemented in the provided C code is in fact the CCITT CRC-16.

The Python code is easily modified to reflect the correct definition:

If you do this:

Your issue is not with the byte strings really, it's a logical error. You're trying to corrupt the wrong thing. You don't want to corrupt the checksum, you want to corrupt the original message and then take a checksum of the corrupted version. Then you can compare if the two checksums match or not.

Try:

Based on the linked appendix, the initial value of the CRC is 0xffff, not 0, and you need to exclusive-or the result with 0xffff to get the FCS to put in the packet.

However that still doesn't work for your example packet. I can only guess that your example packet was not correctly extracted or identified.

Update:

From the OP comment below and some deduction, the actual data in the message is "~\x00\x03\x00\x02\x04\x00\x9b\x38~". The OP left out three zero bytes for some reason, and the OP printed it in a way that obscured one byte as a question mark.

Now the CRC calculates correctly as 0x389b, stored in the message little-endian as 0x9b 0x38. To get that, you must apply my comments above on the initial value and final exclusive-or.

There are many CRC-16's. I count 30 here alone, and I'm sure there are more in use that are not in that catalog.

The one you have implemented is the CRC-16/UMTS in that catalog, also known as CRC-16/BUYPASS and CRC-16/VERIFONE. It is the most straightforward of definitions, with the bits in and bits out not reflected, with an initial value of zero, and with no final exclusive-or.

The result CRC you implemented on the message 34 ec can in fact be found directly in your linked "correct result", on the fourth row of the table which is labeled "CRC-16/BUYPASS".

If you want to implement a different CRC-16, the first thing you need to do is specify which one. That specification is the polynomial, reflection of input and output, initial value, and final exclusive-or value.