Re: PINI field not working with modbus

[Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>]

Hi Marco,

I'm glad that adding the epicsThreadSleep(1.0) fixes the problem.

>  I was not aware that this is how the modbus driver worked.

The behavior for read functions is documented here:

https://epics-modbus.readthedocs.io/en/latest/#modbus-read-functions

Mark

---

From: Marco A. Barra Montevechi Filho <marco.filho at lnls.br>
Sent: Wednesday, July 27, 2022 6:57 AM
To: Mark Rivers <rivers at cars.uchicago.edu>; tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: PINI field not working with modbus

 

Oh! this makes sense and also explains the wireshark capture. I was not aware that this is how the modbus driver worked.

I tested just now and it works. Thanks!

---

From: Mark Rivers <rivers at cars.uchicago.edu>
Sent: 27 July 2022 08:52
To: Marco A. Barra Montevechi Filho <marco.filho at lnls.br>; tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: PINI field not working with modbus

 

Hi Marco,

I think I understand why you are not seeing the correct value when you use PINI=YES and SCAN=Passive.  The problem is a race condition.

As I said in a previous message, it appears that you have set the MBUS_POLL macro to 1000, which means the poller for that Modbus driver is running every 1000 ms (1 second).  The poller waits for this delay at the beginning of the poll loop.  The poller thread is started when your startup script calls drvModbusAsynConfigure().  When the record processes during iocInit() because PINI=YES it just gets the most recent value from the poller.

However, in your case because you have a slow polling rate of 1 second it is likely that the poller has not yet done the first poll when the record is processed during iocInit, so there is no value to use.

I believe you can fix the problem by adding this line to your startup script just before iocInit()

epicsThreadSleep(1.0)

Mark