Hello Andy,
I often connect the record the same way you did. In addition, I use PRIO „HIGH“ for the set records, so that they are not delayed by queued read records.
Mark correctly described what happens. Processing „only“ puts the records in the queue. The actual protocol work runs in the context of the asyn port thread, sorted by PRIO and then FIFO among same PRIO. The record is blocked from processing (PACT=1) while
it is in the queue, thus it will not be queued again when something tries to process it. But after the first processing finishes, another processing should be started if it had been triggered once or more while PACT was 1 (AFAIK).
Am 06.08.2022 um 13:36 schrieb Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>:
Since "get_voltage" is also asynchronous, will it just simply not do anything until "set_voltage" completes and processes it through the forward-link? I guess my question is more about what "get_voltage" would be doing in this situation while "set_voltage"
has the protocol locked.
If get_voltage tries to process because of the 1 second SCAN while set_voltage has the device locked then my understanding is that the following happens:
- get_voltage queues a request to get access to the device
- The queue request has a 5 second timeout by default.
- If set_voltage completes before the 5 second timeout the get_voltage will process.
- If set_voltage takes longer than 5 seconds then the queue request will time out, there will be an error message, and get_voltage will not process from the 1 second scan. But it will process due to FLNK from set_voltage.
Mark
Sent from my iPhone
On Aug 6, 2022, at 3:41 AM, Wang, Andrew via Tech-talk <tech-talk at aps.anl.gov> wrote:
Hi all,
This is more of a conceptual question and some insight would be greatly appreciated.
In my EPICS drivers, I employed something an architecture known as "Slow Periodic Scan with Fast Change Response" seen in page 28 (Link:
EPICS Re: Recommendations for StreamDevice "architecture" flow (anl.gov)). Thus far, the instruments for which I have written drivers are pretty responsive. However, as I've been using EPICS more
and more, I am curious to know more about how StreamDevice handles this particular and possible situation.
Suppose I have a setter and getter for changing the voltage. Using the architecture above, the records can be linked together in the following manner (pseudo-code).
record(fanout, "slow_scan")
{
field(SCAN, "1 second")
field(FLNK, "get_voltage")
}
record(ao, "set_voltage")
{
field(DTYP, "stream")
field(SCAN, "Passive")
field(OUT, ...)
field(FLNK, "get_voltage")
}
record(ai, "get_voltage")
{
field(DTYP, "stream")
field(SCAN, "Passive")
field(INP, ...)
}
When I process "set_voltage", a asynchronous passively-scanned record, it will start the protocol in another thread. What if it takes about 5 seconds after the first OUT command is sent to the instrument to receive a reply back. My understanding is that the
protocol will lock the device, so no other records can communicate with the instrument. However, in the example above, "get_voltage" will process every 1 second, but won't be allowed access. Since "get_voltage" is also asynchronous, will it just simply not
do anything until "set_voltage" completes and processes it through the forward-link? I guess my question is more about what "get_voltage" would be doing in this situation while "set_voltage" has the protocol locked.
Thanks,
Andy
|