Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Wed, 17 Dec 2014 19:42:50 +0000

Folks,

I have now begun to implement this for the asynInt32 device support, and it seems to be working.

In the asyn test application "testEpicsApp" I modified the database devInt32.db to add the info tag CALLBACK:

record(longout,"asyndevLoInt32") {
    field(DTYP,"asynInt32")
    field(OUT,"@asyn(int32 0)")
    info(CALLBACK,"1")
}

The int32.c driver does callbacks if the asyndevSetRateInt32 record is non-zero.

If the info field CALLBACK above is 1 then the longout record updates whenever such a callback occurs.
If the info field is not present, or its value is not 1 then the longout record does not update with the callbacks.

Questions:
The way I have currently written it the info field is only read during init_record.  This means that this feature
if set at iocInit, and cannot be turned on and off at runtime.  Is this OK?

It seems to me that it is because:

- I don't think one can access the info tags over Channel Access so one would need to
type a "dbpf" command to the IOC to change the setting.

- The info tags are not Process Passive so one would need to force the record to process to have it read the
info tag again?

Is the info tag approach acceptable, and if so is the name CALLBACK OK?

Mark

________________________________
From: Mark Rivers
Sent: Tuesday, December 16, 2014 6:09 PM
To: Ralph Lange; EPICS Tech-Talk
Subject: RE: Is it possible for an Asyn output record to be, also, an (I/O Intr - driven) input?

Hi Ralph,

In response to Peter's original post;

> /* This code is for I/O Intr scanned output records, which are not tested yet. */
> I suspect that I’m asking for a feature/behaviour that isn’t implemented, or is at any rate not commissioned.

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.

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.

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.)

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.

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.

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.

Thoughts?

Mark

________________________________
From: [email protected] [[email protected]] on behalf of Ralph Lange [[email protected]]
Sent: Friday, November 28, 2014 8:39 AM
To: EPICS Tech-Talk
Subject: Re: Is it possible for an Asyn output record to be, also, an (I/O Intr - driven) input?

On 28/11/2014 14:09, [email protected]<mailto:[email protected]> wrote:
This is possible (the motor record is a good example), but it needs the record type to support it. Most record types don’t support two way communication with device support.

When properly done in device support, it works with all standard record types, and does not need any special support from the record type. (The mentioned OPC support is a good example.)

Here's how it is basically done. It boils down to: Fake the second phase processing of an asynchronous operation.

The record processes asynchronously. (I.e. it is processed twice. First phase processing sends the request and leaves PACT true, the incoming acknowledge message from the device triggers the second phase processing.)

The device link must be set up providing definitions for a data set (command) message (from IOC to device) containing the data, and a data update message (from device to IOC) containing the data.

Device side:
When receiving a set message, the device may ignore or execute the request. It should always answer with an update message containing the result of the operation (i.e. changed or unchanged data).
When another master (local, external, whatever) changes the data, the device sends an update message containing the new data.

IOC side:
On first phase processing (PACT was false), the device support sends the set message, and sets PACT=true.
On incoming update message, the device support always sets PACT=true and triggers the second phase processing.
On second phase processing (PACT was true), the device support copies data to the record and sets PACT=false.

Simple. Effective. Works with standard record types.

Cheers,
~Ralph

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System