Sending serial MODBUS command

This is most likely a simple misunderstanding of serial communications on my part.

I have a RS485 relay module that will accept commands formatted in ASCII or MODBUS messages. I can use "serial transmit ASCII" to send five ASCII characters ( AT+T1) and get the module to work. So the hardware link/baudrate has been validated.

When I try and send the 8 hex numbers (01 06 00 01 03 00 D8 FA) for the MODBUS message, I get not response at all. Could it have something to do with the last two being 2 byte numbers??

Im not sure how to add Blockly Code to this post for you to see.

Patience with me. I've looked at the SPIN MODBUS objects in the OBEX and they seem to just be using FullDuplexSerial and sertx out the hex numbers.



  • Looking again at the object I do see that they split the crc word into bytes using crc.byte[1] and arc.byte[0] spin commands. Then send each byte to serial. Im not sure how that could be done in Blockly.
  • Have you tried sending it as (01 06 00 01 03 00 0D 08 0F 0A) ?
    In science there is no authority. There is only experiment.
    Life is unpredictable. Eat dessert first.
  • I gave that a try with no result. I can't find the usb/rs485 converter I bought. That might help me to troubleshoot. I started to write a driver in spin, but I really don't see what that would change.
  • I got my usb to rs485 converter. When I connect propeller board to ttl/rs485 module then to usb/rs485 adapter open a terminal on laptop. Propeller transmits 8 hex numbers. With terminal set to (rx hex) the terminal shows 19 hex numbers none of which match hex numbers sent from propeller. If terminal is set to (rx ascii) terminal displays the 8 numbers sent.

    Is my ttl/rs485 module somehow converting to ascii??

    rs485 relay will respond in ASCII mode but not in modbus mode.

    I did check the relay using the modbusPol app and that app can control the relay with hex modbus commands.

    I’m confused
  • Two distinct modes in Modbus serial:
    ASCII mode protocol asynchronous 1 start bit, 7 data bits, 1 parity, 1 stop for a total of 10 bits. If no parity then 2 stop bits. Uses LRC checksum
    RTU mode is synchronous with 1 start bit, 8 data bits, 1 parity, 1 stop bit for a total of 11 bits. If no parity then 2 stop bits. Uses CRC16 checksum.
    ASCII is much more forgiving than RTU but not as efficient. Timing is critical with RTU.
    In the old days we had problems using phone modems with RTU because each frame was 11 bits. The old modems just tossed the 11th bit away!
    Anyways if you're using RTU make sure the USB converter can handle 8 bit data in11 bit frames.

Sign In or Register to comment.