j123b567
commented
1 year ago It would be really interesting to see the real waveform on the bus e.g. from the logic analyzer.
From my experience, this happens to me when the device does not respect the spec. In the past, our developers have created devices that responded immediately upon request, ignoring the silence between request and response. Here's what happens when master M tries to communicate with two such devices (A and B).
| From the perspective of M | From the perspective of B |
|---|---|
| M -> send request to A | M sends request to A |
| A -> send response to M | Continuation of the previous request |
| M -> send request to B | Probably response of the A. The second message is always the response, right? ignoring |
| Response timeout | It wasn't for me, was it? |
If you can't fix the device, you will probably end up with the sleep approach. You can derive a serial port class and override read and/or write functions to add some delay there so you don't need to add them everywhere in the code (see example implementation of manual handling of DE in RS485 https://github.com/pyserial/pyserial/blob/master/serial/rs485.py)
thalesmaoa
I'm using minimalmodbus to read multiple drivers in a roll. When there is only one device, I have no problem. When I use two units, I start to get unresponsiveness. After debugging, I noticed that this arise due to silent period not being respected. Same problem as stated here.
To fix it, I just added a
time.sleep(.0031)before each minimalmodbus call.Now comes the issue. I'm using async to improve the code performance and avoid blocking it. During those 3,1ms that I'm blocking my code, I could be doing something else. Is there a way to put this silent period inside the minimalmodbus function?
When I call
self.instrument.read_registers(49, 1), it should block it self for another writing. I'm kind lost how to fix it.