Experimental Physics and
Industrial Control System

Philippe and all,

 

I have made the improvements in the poller and fixed the problems with waveform records when the Modbus data type is not UINT16 or INT16.  This is from the release notes for upcoming release R2-8.

·         Improved the logic in the poller thread.

o    Previously there was a call to epicsThreadSleep at the end of the poller loop. This meant that the poller always ran at least once, which might not be desirable. It also meant that it one could only temporarily disable the poller by calling pasynManager->lockPort(), or to make it run infreqently by setting POLL_DELAY to a long sleep time. In R2-5 the MODBUS_READ command was added. However, this just did a read operation without triggering the poller thread, so records with I/O Intr scan would not process. It also required disabling the poller thread with pasynManager->LockPort.

o    The poller thread has been changed so that if the POLL_DELAY is >0 then it calls epicsEventWaitWithTimeout, using the POLL_DELAY as the timeout. If POLL_DELAY is ≤0 then it calls epicsEventWait, with no timeout. This allows the poller to be suspended indefinitely and only run when the epicsEvent is signalled. The MODBUS_READ command now signals the epicsEvent to trigger the poller, rather than directly doing a read operation.

o    Added a new template file, poll_trigger.template which loads a record with the MODBUS_READ drvInfo string to trigger the poller.

·         Fixed problems when using waveform records with the asynInt32Array interface.

o    If the Modbus data type was not UINT16 or INT16 then the data were not read into the waveform record correctly. This bug has been fixed, and a new file iocBoot/iocTest/array_test.cmd and array_test.substitions were added to test it using the Modbus Slave Simulator. New adl files, modbusTestArray.adl and array_test.adl were added for these tests. array_test.adl also contains controls for POLL_DELAY and POLL_TRIGGER to verify the improvements to the poller thread above.

o    Previously the first element in the waveform record was always the first register in that modbus driver, i.e. it did not allow specifying a register offset using the asyn ADDR address. This was improved so now one can specify an offset using the ADDR field, as with the non-array records in modbus.

o    The Modbus data type to use is determined using the data type assigned to the first register to be read. All subsequent registers in the array are assumed to be this data type.

I have pushed the changes to the master branch on github, https://github.com/epics-modules/modbus.

 

Please test these fixes and new features, particularly if you are using the MODBUS_READ command.

 

I will release R2-8 next week if the tests are successful.

 

Cheers,

Mark

 

 

 

 

 

 

Hi Marks,

 

That sounds great to me and Chistophe Haquin.

 

Best regards.

 

 

Hi Philippe,

 

In Modbus R2-5 I added a new drvUser value on the asynInt32 interface called MODBUS_READ.  If you have a bo record, for example, with this drvUser value then when that record processes it will force the driver to do a read, even if the poller is disabled.  The poller can be disabled by calling pasynManager->lockPort().  This was intended to allow atomic read/modify/write operations, as explained in the R2-5 release notes.

 

This has the disadvantage that it only really works from C code, not from the database, because you can’t call pasynManager->lockPort() from the database.  Because it does not actually run the poller it also has the disadvantage that it does not do callbacks for I/O Intr scanned records.

 

However, I think I see a solution that will work for both applications.

 

-          Change the poller so that a poller delay <=0 means sleep until an epicsEvent is signaled.   This means you don’t need to use a huge poller delay, you just use 0.

-          Change the behavior of the MODBUS_READ parameter in writeInt32 so it just calls epicsEventSignal for that event.  This will cause the poller to run once.

 

Does this sound like it will do what you want?

 

Mark

 

 

Préservons notre environnement, n’imprimez ce mail que si nécessaire.
Preserve our environment, print this email only if necessary.

Préservons notre environnement, n’imprimez ce mail que si nécessaire.
Preserve our environment, print this email only if necessary.