Experimental Physics and
Industrial Control System

The term “asynchronous” used in my message is a loose definition (search those terms on https://epics.anl.gov/modules/soft/asyn/R4-38/asynDriver.html ). EPICS handles “asynchronous” through the field “PACT”. In your case, if you change the value of “myPV1” while “myCommand” is still being processed (because “myCommand” takes a relative long time to complete its processing), myCommand.PACT is still true and “myCommand” will not be processed (its processing is ignored).  

 

Here is a simple demonstration of “asynchronous”  vs. “synchronous”: myCommand:just4Test is “asynchronous” because of the field “HIGH” (its value stays 1 for 10 seconds, then reset to 0); mySetPoint:just4Test is “synchronous”.

 

Put the following records to a file “test.db”, go to the directory where “test.db” is, then type “softIoc -d test.db” (assuming softIoc is in your $PATH).

record(ao, "myPV1:just4Test"){

    field(TPRO, "1")

}

record(seq,"mySequence:just4Test"){

    field(DLY1,"0")

    field(DOL1,"myPV1:just4Test CP")

    field(LNK1,"mySetPoint:just4Test PP")

    field(DLY2,"0.5")

    field(DOL2,"1")

    field(LNK2,"myCommand:just4Test PP")

    field(TPRO, "1")

}

record(ao, "mySetPoint:just4Test") {

    field(MDEL, "-1")

    field(TPRO, "1")

}

record(bo, "myCommand:just4Test") {

    field(ZNAM, "Zero")

    field(ONAM, "One")

    field(TPRO, "1")

    field(HIGH, "10")

}

 

Change myPV1:just4Test to 1, then quickly change it to 0 again (you should be able to do this kind of change within 10 seconds):

WPS-168245:~ yonghu$ caput myPV1:just4Test 1

Old : myPV1                          0

New : myPV1                          1

WPS-168245:~ yonghu$ caput myPV1:just4Test 0

Old : myPV1                          1

New : myPV1                          0

 

Here is the output from the EPICS shell:

WPS-168245:epics yonghu$ softIoc -d test.db

Starting iocInit

############################################################################

## EPICS R7.0.5

## Rev. 2021-05-13T07:10-0400

############################################################################

iocRun: All initialization complete

scanOnce: dbProcess of 'mySequence:just4Test'

cbLow: dbProcess of 'mySetPoint:just4Test'

epics> cbLow: dbProcess of 'myCommand:just4Test'

cbLow: dbProcess of 'myCommand:just4Test'

ca:yonghu at WPS-168245.home: dbProcess of 'myPV1:just4Test'

scanOnce: dbProcess of 'mySequence:just4Test'

cbLow: dbProcess of 'mySetPoint:just4Test'

cbLow: dbProcess of 'myCommand:just4Test'

ca:yonghu at WPS-168245.home: dbProcess of 'myPV1:just4Test'

scanOnce: dbProcess of 'mySequence:just4Test'

cbLow: dbProcess of 'mySetPoint:just4Test'

cbLow: dbProcess of 'myCommand:just4Test'

cbLow: dbProcess of 'myCommand:just4Test'

 

Here is the output from “camonitor” on another terminal:

WPS-168245:~ yonghu$ camonitor -n mySetPoint:just4Test myCommand:just4Test myPV1:just4Test

mySetPoint:just4Test           2022-02-11 07:21:45.068196 0

myCommand:just4Test            2022-02-11 07:21:55.563370 0

myPV1:just4Test                <undefined> 0 UDF INVALID

myPV1:just4Test                2022-02-11 07:22:21.366964 1

mySetPoint:just4Test           2022-02-11 07:22:21.367016 1

myCommand:just4Test            2022-02-11 07:22:21.867136 1

myPV1:just4Test                2022-02-11 07:22:23.372623 0

mySetPoint:just4Test           2022-02-11 07:22:23.372691 0

myCommand:just4Test            2022-02-11 07:22:33.868769 0

 

As you see, mySetPoint:just4Test follows myPV1:just4Test. Normally we expect myCommand:just4Test to change from 1 to 0 twice. However, it only changes once.

 

If you type “caput myPV1:just4Test 1”, wait for more than 10 seconds, then type “caput myPV1:just4Test 0”, you will see myCommand:just4Test change from 1 to 0 twice.

 

It is a little bit tricky to handle this kind of asynchronous logic through link options PP, CP, CPP, CA or through fields FLNK, PROC. Personally, I do this kind of logic in codes which are more robust, either in sub/aSub record or in Python (https://github.com/dls-controls/cothread )

 

Good luck!

~Yong

 

Hi Alexis,

 

I guess your “mySetPoint” and “myCommand” might be asynchronous records, meaning it probably takes one or a few seconds to be completely processed.

 

If that is the case, you’d better to use CA instead of PP in LNK*, something like this: field(LNK1,"mySetPoint CA"). If “mySetPoint” does not take its value from “myPV1”, you probably should use something like this: field(LNK1,"mySetPoint.PROC CA"). The same rule for LNK2, either field(LNK2,"myCommand CA") or field(LNK2,"myCommand.PROC CA")

 

Additionally set mySetPoint.TPRO and myCommand.TPRO to 1. Also, check if there are other records or programs which write (or caput) to “mySetPoint” and “myCommand”.

 

If this problem happens again, type this command although I am not sure if it is really helpful: caget mySetPoint.LCNT myCommand.LCNT

 

Cheers,

~Yong

 

Obsolete EPICS Wiki: https://wiki-ext.aps.anl.gov/epics/index.php?title=RRM_3-14_dbCommon