Experimental Physics and
Industrial Control System

Hi Ralph, Nick,

Thank you for your responses.

I took a look at  http://www-csr.bessy.de/control/SoftDist/OPCsupport/ and downloaded 3.8.0.1.

Unfortunately, there seem to be files missing from the install, so I am unable to exercise it.

The readme is informative, I am struck by the comments:

For out-records the SCAN field is ignored by the device support and should be set to "Passive".

Out records: The value written by EPICS is ignored by the PLC.

I have been working with this definition:

record(bo, "$(P)StartStop")

{

       field(DESC, "StartStop")

       field(DTYP, "asynInt32")

       field(OUT,  "@asyn($(PORT),0,1)STARTSTOP")

       field(SCAN, "I/O Intr")

       field(ZNAM,  "OFF")

       field(ONAM,  "ON")

}

Can you tell me whether this is valid, for what I’m trying to do?

To my knowledge, Asyn will not process input changes without setting the scan type in this way.

What I find is that, while this works as an input, driven by its SCAN specification, it fails to work correctly as an output.

A value that is output by a caput enters the database (and can be read back with a caget), but isn’t applied to the device layer.

I was able to determine why this is.

The execution path to output the new value is blocked by the condition in dbPutField in base\src\ioc\db\dbaccess.c:

        if (paddr->pfield == (void *)&precord->proc ||

            (pfldDes->process_passive &&

             precord->scan == 0 &&

             dbrType < DBR_PUT_ACKT))

As an experiment, I commented out the highlighted clause.

Having done so, my (AsynPortDriver) code worked perfectly, in just the manner that I had been expecting, for both input and output.

Is the above condition clause necessary?

Many thanks,

Peter.

On 28/11/2014 14:09, [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