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
From: Philippe Laurent [mailto:[email protected]]
Sent: Wednesday, February 03, 2016 1:43 AM
To: Mark Rivers; [email protected]
Subject: RE: Active modbus read function upon request
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
Hi Marc,
I would like to active some modbus port drivers upon request for retrieving Post Mortem datas.
It is possible to configure database such that the modbus read function is called only when a record is processing ? (like write function)
If not, what is the best option to temporary desactive the modbus pooling ?
-
Dynamically start an IOC well configured
-
Just set an huge POLL DELAY on the modbus port
-
Disable the asyn port with asyn record, I observe that :
-
modbus pooling thread is always active
-
trace in ioc shell : drvModbusAsyn::doModbusIO port LBEC-DCCT31:PostMortemRd2 disconnect error=asynManager::queueLockPort queueRequest failed: port LBEC-DCCT31 disabled
-
Other
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.