Experimental Physics and
| |||||||||||||||||
|
Thompson, David H. wrote: I agree that all this is possible with the existing records. It can be handled in the device support.[...] It is all a matter of how to package what is in fact a new device support function (input) and trick the existing record support into posting the monitors while the device support does nothing. [...] I think now that passing input function pointer as an argument to the registration function would be cleaner. This is something that could be added to core without breaking anything and would provide a standard way to implement bi-directional IO. [...]I think all information required for the device support should come through the link field. Link Support <http://www.aps.anl.gov/asd/people/anj/lnkSup.html> would be a good solution to configure a bi-directional output record and make the bi-directional feature visible in the database. I withdraw from my proposal of new records. It would be good if the device support functionality "bi-directional" could be encapsulated, like it's done for the asynDriver, to make it reusable for other device supports. With a growing number of intelligent devices it would be useful to handle all updates from different origins, some only known to the device itself, in the same way as a modification done by CA clients. Like for CA clients you'll need to handle interferences of multiple processes trying to control the same device but that is not an argument against treating it in the same way. Cheers Andreas
| ||||||||||||||||
ANJ, 10 Aug 2010 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing · |