|
Hi Mark,
I did see that and was starting to look at using asyn, but I was having trouble figuring out how to do so. Is there a minimal working example that I might be able to modify? Do I need to create separate driver and device support?
The other thought I had was if this could be handled by somehow creating record support for read/write records.
Thank you,
Patrick
Hi Patrick,
As Ralph said, if your driver is written using asyn then you can use the info(asyn:READBACK) tag on your output record.
I'm not sure what you mean here. I think the EPICS record locking an asyn port locking will guarantee that all EPICS writes get sent to the hardware atomically, and that all callbacks from the driver that update the output record will be atomic. However,
once EPICS writes the value to the hardware, the next poll of the hardware could quickly change the output record. Maybe I am not understanding your question.
Mark
Hello,
I'm attempting to write device support to handle the scenario where changes to the value of a hardware device can be made from both EPICS and another source. I would like the value of the hardware to be changed if I write a value to the record through channel
access, and also to continuously monitor the hardware device for changes made from the other source and update the value of the record to match. One approach I have considered is to use separate output and input records, where the output records write values
set from channel access to the hardware and the input records periodically scan the hardware and update their values accordingly. I am wondering however if there is a way to do this with the val field of just an output record. Is there any way to synchronize
things so that write requests coming from channel access are always written to the hardware and not overridden by periodic updates from reading the hardware?
Thank you,
Patrick
|