read after changing slave not working without a delay

[Alessandro Mauro]

Hi, I am using libmodbus in a PC program that works as a master device, using RTU with a usb-to-485 adapter.

I want to poll several devices, what I do is:
modbus_set_slave( mb_p, 50);
modbus_read_registers(mb_p,0,1,dest16);

modbus_set_slave( mb_p, 51);
modbus_read_registers(mb_p,0,1,dest16);

But the latter read function fails. Watching serial dump I see the slave does not answer.

If I put a blocking delay between the first setslave/read and the second setslave/read (at least 4ms), i.e.:
modbus_set_slave( mb_p, 50);
modbus_read_registers(mb_p,0,1,dest16);

usleep(4000);   //force thread to sleep for 4 millisecs
modbus_set_slave( mb_p, 51);
modbus_read_registers(mb_p,0,1,dest16);

then it will work.

It works also if the first device is shut down and does not answer, so seems to be a "serial line problem".

I see in Modbus specifications that a 3.5-char-silent-interval is required between frames, is this implemented/guarranteed by libmodbus?
If not, this might be the cause, otherwise I cannot figure out what could be the matter. The slaves are using freemodbus (http://www.freemodbus.org/), I don't exclude that the problem could also reside there.

Thanks in advance to anyone who'll answer.

[Stéphane Raimbault]

libmodbus doesn't respect the 3.5 char silent interval between frames because it's slowdown the communications.

Your issue seems to be about the answer time of your devices.

Did you try to increase the response timeout with http://libmodbus.org/docs/v3.1.4/modbus_set_response_timeout.html?

Stéphane

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "libmodbus".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse libmodbus+unsubscribe@googlegroups.com.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

[Alessandro Mauro]

Hi Stéphane and thank you for your quick response.

Yes I have tried to increase the response timeout but does not work because the matter is not that the device answers later, but it does not answer at all.

If libmodbus does not respect the 3.5 char silent interval, then I think this is why my devices reject the message. The devices are based on freemodbus that seems to be strict to the specifications. So after the device answers, it rejects - i suppose - any message that comes too quick. This does not explain why the problem appears only switching beetwen slaves and not continuously polling the same slave, though.

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse libmodbus+...@googlegroups.com.

[Alessandro Mauro]

Hi Stephane,

for long time I could not work on my project.

I have now simply added a

 usleep(1000);

in the 

ssize_t _modbus_rtu_recv(modbus_t *ctx, uint8_t *rsp, int rsp_length)

of course it is just a test... but it works! As I thought, standard-compliant devices would reject messages if 3.5-char interval is not respected. 1000us is about 3.5char at 38400baud.

Now I would like to implement the timing correctly. That is, implementing or adjusting the finte state machine. 

It would be great if you can give me some advice on how to proceed, because I cannot clearly see the finite state machine in your code (can't see any status variable, i.e. IDLE / TX / RX / WAIT ) .

Alessandro

Il giorno lunedì 30 gennaio 2017 18:07:50 UTC+1, Stephane Raimbault ha scritto:

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse libmodbus+...@googlegroups.com.

[Chuck Watson]

When I built my applications, I made a value called “inter_request_delay”. This would be the delay as you describe below and it varies depending on the device/slave I am trying to communicate with at the other end.

 

Some devices are newer and quicker and some are older and slower.

 

The point is you don’t want this delay to be standard and built into the library. As a programmer, I want control over this value based on the slave device.

 

Chuck Watson BS, CEM, CMVP

Direct USA 724-799-1529