EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  2025  <2026 Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  2025  <2026
<== Date ==> <== Thread ==>

Subject: Re: ASYN parameter value vs VAL field relationship
From: André Favoto via Tech-talk <tech-talk at aps.anl.gov>
To: Jörn Dreyer <j.dreyer at hzdr.de>, Tech Talk <tech-talk at aps.anl.gov>
Date: Mon, 22 Jun 2026 12:19:33 +0000

Thanks for the reply,

The problem you have is that you assume that an output record will be updated when you change the value inside the driver code.
From asyn docs, I understand that `info(asyn:READBACK, "1")` was added exactly for this purpose:

By default output records do not update when a driver does interrupt callbacks. However, if the following info tag is added for a record in the database file then callbacks will be enabled and the output record will be updated whenever the driver does a callback for that value.
info(asyn:READBACK, "1")

I would expect that after I modify the parameter and run "callParamCallbacks", the PV should be updated with the correct value and always stay in sync, even if that means seeing a momentary "glitch" in the VAL field.
I have successfully used that for systems that can be controlled from more than one place, say, a local HMI or the IOC.
The -SP record is always updated with the current hardware value gotten via readXXX, without driving the output.

Maybe the infotag only works if the parameter is updated via the readXXX overrides?

The other alternative I see is adding an intermediary calcout that changes DRVH field whenever the absolute maximum is changed, like:
record(ai, "$(P)$(R)#$(PUMP)AbsMaxPressure") {
    field(DESC, "Max pressure for selected syringe")
    field(DTYP, "asynFloat64")
    field(EGU,  "bar")
    field(PREC, "2")
    field(INP,  "@asyn($(PORT),$(ADDR),$(TIMEOUT))SYR_MAX_PRESSURE")
    field(FLNK, "$(P)$(R)#$(PUMP)ClipMaxPressure")

    info(asyn:READBACK, "1")
}

record(calcout, "$(P)$(R)#$(PUMP)ClipMaxPressure") {
    field(DESC, "Clip max pressure to AbsMaxPressure")
    field(INPA, "$(P)$(R)#$(PUMP)AbsMaxPressure")
    field(CALC, "A")
    field(OUT, "$(P)$(R)$(PUMP)MaxPressure.DRVH PP")
}



From: Jörn Dreyer <j.dreyer at hzdr.de>
Sent: Monday, June 22, 2026 13:49
To: Tech Talk <tech-talk at aps.anl.gov>; André Favoto <andrefavotto at outlook.com>
Cc: André Favoto <andrefavotto at outlook.com>
Subject: Re: ASYN parameter value vs VAL field relationship
 
Hi Andre,

The problem you have is that you assume that an output record will be updated when you change the value inside the driver code.
To achive what you want, you need to define an input record that reads back the value from the driver:

record(ai, "$(P)$(R)$(PUMP)MaxPressure_RBV") {
     field(DESC, "set max pressure for process")
     field(DTYP, "asynFloat64")
     field(EGU,  "bar")
     field(PREC, "2")
     field(INP,  "@asyn($(PORT),$(ADDR),$(TIMEOUT))PROC_MAX_PRESSURE")
}
 And display this in the GUI. You can not use the forward link of the input record to set the correct value on the output record because this would lead to a infinite loop,
where the records call each other recursively.
If you set in the output record the HIGH and LOW limits for the alarm to the maximum and minimum values of the hardware, you could use those to give the user feedback
that  the the value might be clipped by the code.

Regards

Jörn

Am Montag, 22. Juni 2026, 13:36:42 Mitteleuropäische Sommerzeit schrieb André Favoto via Tech-talk:
> Sorry, I accidentally sent the message incomplete...
>
> I am trying to control the upper limit for a given PV via asyn (same as DRVH does, but since the value is dynamic, I'd rather handle it in the driver instead of DB links).
> I have the following record:
>
> record(ao, "$(P)$(R)$(PUMP)MaxPressure") {
>     field(DESC, "set max pressure for process")
>     field(DTYP, "asynFloat64")
>     field(EGU,  "bar")
>     field(PREC, "2")
>     field(OUT,  "@asyn($(PORT),$(ADDR),$(TIMEOUT))PROC_MAX_PRESSURE")
>
>     info(asyn:READBACK, "1")
> }
> And the asyn code that sets the value is
>
> else if (function == procMaxPressure_) {
>     double maxPressure;
>     status = getDoubleParam(addr, syrMaxPressure_, &maxPressure);
>     // do not allow process pressure to be set above syringe max pressure.
>     if (value > maxPressure) {
>       asynPrint(pasynUser, ASYN_TRACE_ERROR, "Pressure above syringe limit, clipping to %f\n", maxPressure);
>       value = maxPressure;
>     }
>     if (value < 0) {
>       value = 0;
>     }
>   }
> Later on, inside writeFloat64, I do:
>
>  if (status == asynSuccess && apiErrCode == ERR_NOERR) {
>     setDoubleParam(addr, function, value);
>     callParamCallbacks(addr);
>     asynPrint(pasynUser, ASYN_TRACEIO_DRIVER, "%s:%s: port=%s, param=%s, value=%f, status=%d\n", driverName,
>               functionName, this->portName, paramName, value, (int)status);
>   } else {
> (...)
>
> What I would expect is that the record only assumes the value that I clipped, i.e., 0 <= value <= maxPressure
>
> However, what I see is that the asyn parameter PROC_MAX_PRESSURE is indeed clipped, but the PV value assumes whatever value I put. Assuming maxPressure=517, asynReport gives:
>
> Parameter 10 type=asynFloat64, name=PROC_MAX_PRESSURE, value=517, status=0
>
> But I successfully wrote "600" to "$(P)$(R)$(PUMP)MaxPressure":
>
> > dbgf B02-CSLab:SE-Pumps:SP1MaxPressure
> DBF_DOUBLE:         600
> I understand the asyn driver and the database are on different layers, but I would expect is that the PROC_MAX_PRESSURE param and VAL field of the record stayed in sync with the setup above.
> Maybe I misinterpreted how that is supposed to behave?
>
> I have seen the same behavior in other modules, so I'd like to check if someone has any ideas on how to handle this properly.
>
> Thanks, and sorry for the previous noise 🙂
>
> Cheers,
> André Favoto
>
>
> ________________________________
> From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of André Favoto via Tech-talk <tech-talk at aps.anl.gov>
> Sent: Monday, June 22, 2026 13:28
> To: Tech Talk <tech-talk at aps.anl.gov>
> Subject: ASYN parameter value vs VAL field relationship
>
> Hi folks,
> I am trying to control the upper limit for a given PV via asyn (same as DRVH does, but since the value is dynamic, I'd rather handle it in the driver instead of DB links).
> I have the following record:
>
> record(ao, "$(P)$(R)$(PUMP)MaxPressure") {
>     field(DESC, "set max pressure for process")
>     field(DTYP, "asynFloat64")
>     field(EGU,  "bar")
>     field(PREC, "2")
>     field(OUT,  "@asyn($(PORT),$(ADDR),$(TIMEOUT))PROC_MAX_PRESSURE")
>
>     info(asyn:READBACK, "1")
> }
>
>

Replies:
Re: ASYN parameter value vs VAL field relationship Mark Rivers via Tech-talk
References:
ASYN parameter value vs VAL field relationship André Favoto via Tech-talk
Re: ASYN parameter value vs VAL field relationship André Favoto via Tech-talk
Re: ASYN parameter value vs VAL field relationship Jörn Dreyer via Tech-talk

Navigate by Date:
Prev: Re: ASYN parameter value vs VAL field relationship Jörn Dreyer via Tech-talk
Next: Re: ASYN parameter value vs VAL field relationship Mark Rivers via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  2025  <2026
Navigate by Thread:
Prev: Re: ASYN parameter value vs VAL field relationship Jörn Dreyer via Tech-talk
Next: Re: ASYN parameter value vs VAL field relationship Mark Rivers via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  2025  <2026
ANJ, 22 Jun 2026 · Home · News · About · Talk · Base · Modules · Extensions ·
· Distributions · Download · Documents · Links · Licensing ·