#Read error modbus poll serial
Modscan is the master and you can have it display the serial data sent/ received. If you are using Windows, there is modscan and modsim. It is not very big as it doesnt have to do too much. If you want some open source modbus code, if you are using linux, look at mbusd which is a modbus gateway app. With the extra 0 on the end of the packet, the crc will fail and the packet will be rejected. Then it will do a crc check on the packet.
#Read error modbus poll code
Most receiver code will simply receive any number of bytes until there is no data for the required 3.5 char times. Therefore if there really is the extra byte of 0 it will upset the receiver. With modbus rtu, the data packet is framed by time. I guess I need to find either an open source MODBUS master program that I can compile and run in gdb, or I need to find a closed MODBUS master program that will give me more detailed access to the frame data. Once again, I'm stuck on the fact that I am not able to directly observe the data that the modpoll program is receiving. So, I guess that the thing to do would be to see what the master is receiving. This all appears to check out with the spec. Then we get the CRC for 2 bytes, and then the end of the frame. Only the first register has any data in it, so we get that data plus 3 empty registers, or 6 bytes of 0x00.
This is 0x08 which is exactly correct as the number of registers to be read was 4. Next byte (address 0x02) is the data byte count, which is to say the number of 16 bit registers x 2.
So the response frame is supposed to go like this I think.įirst 2 bytes are slave address followed by function code. Then we have 2 bytes to define the quantity of input registers to read, 0x00 & 0x04 which is to say 4. (this refers to register 1000 as it is subject to the same "starting at zero" thing as described in the spec) It seems that the master is sending function code 0x04 which corresponds to "Read Input Register" in the MODBUS spec.Īccording to that function spec, there are 2 bytes that define the starting register which are 0x03 & 0圎7, which is 999 in decimal. Ok, so dissecting the master's output frame. It seems that the spec calls for the frame length to be counted from zero so 0-7 is in fact 8 bytes, and that the 0x00 at 0x0D on the end is actually beyond the frame.Īlso, the length that I posted is the buffer length generated in the code, so it includes the crc.