As noted above I can not get any answer back from the analyzer. This is the third analyzer/Modbus connection I have worked with in the last 6 months and each is different (first was with Provox DCS and second an old Taylor system). Using a protocol analyzer I have monitered the DCS request and also using our analyzer communication software repeated the request. Nothing is different except for the CRC.
05 03 00 22 00 06
Analyzer address 05
Read holding register 03
Address start 35 - 00 22
Number of blocks 6 - 00 06
Rosemount CRC - 24 06 or 64 06 or 24 46 (switchs between the three with no apparent pattern)
Analyzer software CRC - 64 46
Also when we change the configuration parity it changes the data request and I thought that this would have nothing to do with the data request string??? DCS has parity settings of none, even, odd, mark or space. Space is the only setting that will generate the correct 05 03 00 22 00 06. None which is my normal default gives 85 83 81 ..... Ideas on this??
Any idea why the CRC would not match up when the rest of the string is the same? I am limited in my pc language skills but continue to learn more and more each day, so be kind to me.
the analyzer will not reply certain data until it get the correct frame from the master device:
050300220006 64 46
you get the similar crc but not correct,
so maybe two reasons:
1.you set the different parity parameter in master and slave nodes;
2.communication link has problem,maybe cable is to long, or rs485 link is poor quality...
becuase you get different crc code time to time, so second problem is more possible.
I am sorry for my poor englsih, wish you understand me.
The request string with correct CRC is:
05 03 00 22 00 06 64 46
This is calculated with Modbus Poll from
With MODBUS RTU you must use 8-bit communications. Your description of the parity leads me to think that you are using 7-bit on the transmit side and the parity bit is making up the eighth bit. You must have both Master and Slave set to the same number of bits and parity.
> Also when we change the configuration parity it changes the data request
> and I thought that this would have nothing to do with the data request
You are correct!
> Any idea why the CRC would not match up when the rest of the string is
> the same? I am limited in my pc language skills but continue to learn
> more and more each day, so be kind to me.
Seems to me that you've found a bug in the Rosemount hardware. You probably want to call them up and see if they know about it/have fixed it/have some magical switch setting.
Alex Pavloff - firstname.lastname@example.org Eason Technology -- www.eason.com
You didn't mention what type of analyzer you were trying to communicate with or what type of data you're trying to retrieve.The RS3 modbus RTU can only read 16 bit integer format. Often times in analyzers or rtu's, the data is either floating point or long integer format. If this is the case, than, in the analyzer, try moving the data into a 16 bit register location.
Also, the RS3 is very picky about it's serial communication, it enjoys perfect serial comms, in less than perfect situations I've used mailbox registers in a Niobrara plus port expander as a data concentrator to buffer the errors, then have the RS3 read the mailbox registers.