Experimental Physics and
Industrial Control System

Ralph Lange <[email protected]> · Mon, 22 Dec 2014 12:54:28 +0100

Hi Mark,

On 17/12/2014 01:09, Mark Rivers wrote:

It is correct that noted that asyn does provide for I/O Intr scanning on output records, but that it has never been implemented.  However, there are circumstances that might arise where that would be implemented.  For example an output device that generates an interrupt when it is ready for more data, and the EPICS record should process to fetch the next piece of data.

Yup. Devices might generate interrupts for output for different reasons,

and the supported mechanisms should be configurable through the record,

with record instance granularity.

However, what Peter and Ralph really want is for the output record to update its VAL field to reflect the state of the device when it has changed for whatever reason.  I agree that we definitely should add this to asyn.  The solution we have been using is a database kluge using the _RBV record (which is I/O Intr scanned) to process the output record, but using SDIS to prevent actually writing to the hardware if the output record is processing because the RBV_ record processed.

Yes. Correct. Thanks a lot for this response!

We want this new behavior to be user-selectable option, so that existing IOCs don't change how they work.  I can think of 2 ways to select it:

1) A new device support name for output records that should have this new behavior.  For example for the asynInt32 interface the device support would be changed from "asynInt32" to "asynInt32Update" or "asynInt32Callback".

2) Use a record info tag like "Update" or "Callback" which causes the new behavior if it is set to 1.  I like this solution better, since it is just one new "keyword" that would be used for all device support (asynInt32, asynFloat64, etc.)

Logically this is part of I/O configuration, so it would belong to the

OUT link. On the other hand, blowing up the INP/OUT link field syntax in

a compatible way will add a lot of complexity. As long as asyn does not

support run-time I/O link changes, the INFO field is as good as an

INP/OUT option, minus visibility.

We need to be able to handle the following situations:

I assume the following:
- asyn driver is asynchronous, i.e. ASYN_CANBLOCK was 1.
- asyn device support registers for callbacks from the driver when the value has changed.  This is done now for input records with SCAN=I/O Intr.

The first case is simple:

1) Output record is processed.
2) asyn device support queues a request to asynManager, sets PACT and returns
3) asynManager callback writes to the driver, and requests second phase of record processing.
4) Record processes again, calls device support.  PACT is true, so it completes record processing and sets PACT=false.

Some time later the driver gets a new value for that output:
1) Driver does a callback to device support passing the new value
2) asyn device support stores the new value, sets PACT, sets a flag saying there was a driver callback, and requests record processing
3) Record processes and calls device support.  Device supports sees that both PACT and the flag are set, copies data to the record and sets PACT=false.

Correct.

However, there is a more complicated situation where the driver callback happens in the middle of asynchronous record processing:
1) Output record is processed.
2) asyn device support queues a request to asynManager, sets PACT and returns
3) Driver does a callback to device support passing the new value
4) asyn device support stores the new value, sets PACT, sets a flag saying there was a driver callback, and requests record processing
5) asynManager callback writes to the driver, and requests second phase of record processing.
6) Record processes again, calls device support.  PACT is true, so it completes record processing and sets PACT=false.

However, after step 5 above second phase record processing has been requested twice, once because of the normal output record asynchronous processing, and once because of a driver callback that happened to occur when a new output transaction was in progress.

How should this be handled?

One option would seem to be that in step 4) the device support could notice that PACT is already true, so it knows that the record will process again anyway so it does not request processing.

Another option would be that in step 5) it sees that the flag saying a driver callback has occurred is true, and so it does not request record processing.

I would keep it simple, and not handle this case different at all.

After all, the device saw the value change twice (else it wouldn't have

sent two updates), so the IOC should transparently get both updates.

Even more, the updates should be queued in the asyn driver together with

device-set timestamps (in such cases), so that the record processing

takes place once for every update the device sends, with the correct

pair of value/timestamp that was sent. Maybe the queuing should be

configurable, but it is mandatory when you are interested in e.g. all

state changes with correct timestamp

While suppressing one of the processing requests sounds reasonable at

first, in the end it leads to - say - an archiver connected to the

record to miss updates that it should see, making it hard to correlate

happenings (e.g. actions on local and remote GUI) to the archived events.

When you try to sort out all kinds of race conditions between a local

controller and the IOC both writing values to the device at the same

time, I would think the simplest approach is the only fully transparent

one: any write to the record should be sent to the device, any update

from the device should be written to the record.

We will never be able to solve the race between two masters sending: we

only know that one will eventually win. As long as the device sends any

change, and the record processes each of them, this is perfectly fine:

All transactions are transparent, and every player is well aware of

everything all the time.

We also need to support the case where the asyn driver is synchronous (ASYN_CANBLOCK is 0).  But I think this case is easy, it is just:

1) Output record is processed.
2) asyn device support calls pasynManager->queueRequest, does not set PACT, and the queue request callback is called immediately in the same thread
3) asynManager callback writes to the driver and returns.  Record processing is complete.

Some time later the driver gets a new value for that output:
1) Driver does a callback to device support passing the new value
2) asyn device support stores the new value, sets PACT, sets a flag saying there was a driver callback, and requests record processing
3) Record processes and calls device support.  Device supports sees that both PACT and the flag are set, copies data to the record and sets PACT=false.

Yup. That should do it.

Again, thanks for jumping on this issue. Awesome!
~Ralph

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System