XBee3 + Modbus (Max3483)

[lambu0815]

Hi,
our setup is
sensor (RS485) - transceiver (Max3485, half duplex) - XBee 3
It seems I'm unable to send a valid "read holding registers". I verified hex code b'\x01\x03\x08\x29\x00\x0a\x16\x65' to be the right command (via QModbus).
The regular modbus libraries don't fit on the XBee, as it seems. I am aware that there might be timing issues for writing TX that I might not be handling right (19200 baud, 2 stop bits).
This is what I'm trying to do:

dio7 = Pin("D7",mode=Pin.IN,pull=Pin.PULL_DOWN)
sleep_ms(100)

while True:
    dio7.pull(Pin.PULL_UP) #set writing mode on Max3483
    sleep_ms(10)
    stdout.write(b'\x01\x03\x08\x29\x00\x0a\x16\x65') #there's only the primary UART on XBee3

    sleep_us(450) #expected time for 8 bit at 19200 baud: 416 µs, plus some extra (???)

    dio7.pull(Pin.PULL_DOWN) #RE low, RO enabled (receiver output)
    sleep_ms(10) #tried with and without this line
    data=stdin.buffer.read()
    sleep_ms(3000)

I assume I must be doing something fundamentally wrong. Or is it just playing aroung with the sleep_us?
With a different sensor which keeps sending by itself I only have to read from stdin. That works just fine. So I guess either my message or the timing must be wrong.

[jimmo]

I don't know much about the XBee port (Digi have never released much info or the source code).

I'm curious that you're using pull up/down on dio7 rather than driving it high low? If there's any other sort of pull up/down on the line then this will have no effect.

Do you have a scope or logic analyser? Can you probe the UART TX/RX lines?

[robert-hh]

I made a Python driver for a pressure sensor connected to the XBEE3 device a while ago. The device works reasonable well per se, but one habit was strange and I created and issue for that. The time it takes to set a Pin level is surprisingly long, like 2.5 ms. See digidotcom/xbee-micropython#55
Maybe that's interfering here.

[lambu0815]

Thanks for your hint, jimmo. And Robert, that's acutally us :-) Your help with the pressure sensor is still highly appreciated.
I found that dio7 on the XBee3 can be set to AF7_RS485_ENABLE_LOW or AF7_RS485_ENABLE_HIGH and will keep playing around with that. Due to lack of knowledge I find it strange that this setting is independent of the pull (can be both up or down) which gives me an additional degree of freedom :-/. Also, the description says, this setting is for TX high or TX low. So I'm not even sure if this is for switching RE/DE or actually for talking. To me it appears that there's hardly any documentation or examples for this, can't find any at least.
Thank you so far.
André

[lambu0815]

So I hooked on the the scope. Then I had to learn a little more about UART and Modbus than I expected to need. And to my surprise, The XBee is sending
01 03 08 29 00 0d 0a 16 65 instead of
01 03 08 29 00 0a 16 65
I could verify this by looking at the same message sent from my USB port. There the message is right and I do get an answer from the sensor.
Can you think of any reason why the XBee would insert a "0x0d" after the fifth byte? And how to get rid of that???
All I do is stdout.write(b'\x01\x03\x08\x29\x00\x0a\x16\x65')

[robert-hh]

try stdout.buffer.write, if available. That does not do the NL to CR NL translation.

[lambu0815]

Thanks Robert, I'll try tomorrow, don't have it here at home.

[lambu0815]

stdout.buffer.write() does trigger an answer from the sensor. Great. I can't read it though. Upon the very first signal from the sensor, the XBee freezes. The signal is already on the RO (transceiver) - DIN (XBee) line, but even without a stdin.buffer.read() the XBee hangs immediatly.
As long as RO-DIN is not connected, I keep getting the sensor's answer on RO. Interestingly though, only if I do not trigger DE/RE. I only do AF7_RS485_ENABLE_HIGH on XBee's DIO7 (connected to DE/RE) before writing to the sensor. Only then can I see an answer on RO (when I trigger DE/RE, the answer is on the A/B lines, but the low bits don't go down to zero). Both, RO and DIn are high when idle.

[robert-hh]

• I do not know how exactly you read from stdin. stdin.read(n) and stdin.buffer.read(n) are blocking, if you specify a number of bytes to read. If you do not specify a number, it returns immediately.

• As long as no code is running, DIN is connected to the REPL of MicroPython. And it may be that data is scanned e.g. for Ctrl-C 0x03. You should be able to disable Ctrl-C scanning with:

from micropython import kbd_intr
kbd_intr(-1)

But that works only as long as a script setting it is running. Every prompt at REPL enables Ctrl-C detection again.

[lambu0815]

Thank you so much Robert,
the second byte is always 0x03. Nothing more to say. I learned a lot, it took quite a while.

[Leo5126]

Hi, @lambu0815

I recommend you this documentation about the Modbus protocol. There you can find a lot of informations about how the modbusmessages are created. You can find detailed infos about the Function Codes starting from page 11.

https://modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf