RE: PV Seq not process everytime

[GAGET Alexis via Tech-talk <tech-talk at aps.anl.gov>]

Hi Yong,

Thanks a lot for all this explanation, I think I understand better where is the problem, and "asynchronous" can explained why it's does not occured everytime.

I will try some solutions.

Thanks again

Alexis Gaget

CEA saclay

---

De : Hu, Yong <yhu at bnl.gov>
Envoyé : vendredi 11 février 2022 14:12:51
À : GAGET Alexis; Ralph Lange; tech-talk at aps.anl.gov
Objet : Re: PV Seq not process everytime

 

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

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Hu, Yong via Tech-talk <tech-talk at aps.anl.gov>
Date: Thursday, February 10, 2022 at 9:47 AM
To: GAGET Alexis <alexis.gaget at cea.fr>, Ralph Lange <ralph.lange at gmx.de>, tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: PV Seq not process everytime

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

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Reply-To: GAGET Alexis <alexis.gaget at cea.fr>
Date: Thursday, February 10, 2022 at 3:00 AM
To: Ralph Lange <ralph.lange at gmx.de>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Subject: RE: PV Seq not process everytime

 

Hi Ralph,

Thanks for your suggestion (and answering the CEA team all the day yesterday ;) )

Sorry I forgot to mention that i had tested the FLNK before (without the CP), the CP was my second solution to test if it was the problem.

MDEL of myPV1 is at 0...I've tried -1 yesterday just in case, doesn't change anything.

the problem is I wasn't able to reproduce the problem yesterday, except at the end of the day when beam started I have to find the causality of this correlation .... In the meantime I've noticed that when I'm processing myPV1, by reintroducing value in CSS, it process correctly the sequence, but get stuck few step later, BUT if I execute a dbtr of mySequence it seems to correct the problem until the next reboot of the IOC.

Any idea ?

---

De : Tech-talk <tech-talk-bounces at aps.anl.gov> de la part de Ralph Lange via Tech-talk <tech-talk at aps.anl.gov>
Envoyé : mercredi 9 février 2022 10:51:18
À : EPICS Tech Talk
Objet : Re: PV Seq not process everytime

 

On Wed, 9 Feb 2022 at 09:02, GAGET Alexis via Tech-talk <tech-talk at aps.anl.gov> wrote:

record(ao, "myPV1"){

}

record(seq,"mySequence"){

     field(DLY1,"0")

     field(DOL1,"myPV1 CP")

     field(LNK1,"mySetPoint PP")

     field(DLY2,"0.5")

     field(DOL2,"1")

     field(LNK2,"myCommand PP")

}

 

myPV1 is the destination i want to reach, each time I change it, it process this sequence to set the destination in mySetPoint, and 0.5s later to activate the command. It works well most of the time. But yesterday sometimes, myPV1 was changed but mySequence was not processed .... it causes the whole sequence (emittance measurement) to get stuck. It can be unstuck by processing "mySequence" but it's a long sequence and we don't stay in front of the computer.

 

Hi Alexis,

 

CP input links are using monitors. If you have a myPV1.MDEL setting, it could suppress changes to be sent to mySequence.

 

Unless you have a specific reason to use a CP inlink, you could also set myPV1.FLNK to point to mySequence. That would make this a very tight coupling, with the sequence being run basically as part of changing myPV1. (Remove the CP in mySequence.DOL1 in that case.)

 

Cheers,
~Ralph