Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: Re: propagating value upward at init
From: Dirk Zimoch <dirk.zimoch@psi.ch>
To: Emmanuel Mayssat <emmanuel_mayssat@lynceantech.com>
Cc: tech-talk@aps.anl.gov
Date: Fri, 02 Oct 2009 10:40:27 +0200
Hi Emmanuel,

The easiest way is probably to use auto save and restore for the high level PV name. That works as long as A0 is not changed while the IOC is off. Otherwise you need some additional records to put the value of the hardware A0 into the high level A0.

But what you described is a general problem if set values are transported through several record layers. Sometime this is necessary either to translate the name or to transform from one coordinate system into an other (e.g. field -> current or center/width -> left/right). Because this problems pops up from time to time I will show a solution that works using only records.

Whenever one record is modified, the other one should be updated without re-processing the first one. Obviously the problem is that records have to be linked into a circle (A updates B and B updates A). But we don't want to write hardware twice. This can be solves using SDIS links pointing to PACT fields of the "other" path. That breaks the circle and ensures that either A updates B or B updates A but not both.

record (ao, "$(USERVAL)") {
    field (FLNK, "$(USERVAL)_CONV")
}
record (calcout, "$(USERVAL)_CONV") {
    field (INPA, "$(USERVAL)")
    field (CALC, "$(U_TO_D)")
    field (SDIS, "$(DRIVEVAL)_CONV.PACT")
    field (OUT,  "$(DRIVEVAL) PP")
}
record (ao, "$(DRIVEVAL)") {
    field (DTYP, "$(DTYP)")
    field (OUT,  "$(HWLINK)")
    field (FLNK, "$(DRIVEVAL)_CONV")
}
record (calcout, "$(DRIVEVAL)_CONV") {
    field (INPA, "$(DRIVEVAL)")
    field (CALC, "$(D_TO_U)")
    field (SDIS, "$(USERVAL)_CONV.PACT")
    field (OUT,  "$(USERVAL) PP")
    field (PINI, "YES")
}

The PINI gives $(USERVAL) a value after booting. It is assumed that $(DRIVEVAL) is initialized by the driver.

For more complicated conversions, the calcouts may be replaced with transform, sub or genSub records or a chain of calc(out) records.

For the easier case where no conversion is necessary but only a name translation is wanted, the first calcout may be skipped and the second one can be replaced with an ao:

record (ao, "$(USERVAL)") {
    field (OUT,  "$(DRIVEVAL) PP")
}
record (ao, "$(DRIVEVAL)") {
    field (DTYP, "$(DTYP)")
    field (OUT,  "$(HWLINK)")
    field (SDIS, "$(DRIVEVAL)_PUTBACK.PACT")
    field (FLNK, "$(DRIVEVAL)_PUTBACK")
}
record (ao, "$(DRIVEVAL)_PUTBACK") {
    field (OMSL, "closed_loop")
    field (DOL, "$(DRIVEVAL)")
    field (SDIS, "$(USERVAL).PACT")
    field (OUT,  "$(USERVAL) PP")
    field (PINI, "YES")
}

This probably is probably sufficient for in your case.

Dirk

Emmanuel Mayssat wrote:
Hello,

I hope you are all doing well.
I may have asked this question a months ago, but ...

I have the following DB processing scheme

AO (high level PV name) --> AO ( hardware PV name) ---> hardware ---> AI (hardware PV name) --> AI (high level PV name)

When I set the first AO, the value is propagated to the other one (on OUT field), then to the hardware and finally read back on both of the AI.

The issue is that when I reboot the IOC, the first AO is reset to 0.
Ultimately I would like it to be set at current value (read hardware first and then set value accordingly).

With AI with a PINI=YES, I can see what the hardware value in both AI.
How can I load the CURRENT hardware value in the 1st AO at init?

( I use base < 3.14.11, so not so easy to use multilayer aliasing!!)
--------------------------------------------
Additionally could someone give an example where the DOL + OMSL field are commonly used?
I wonder what the practical purposes of those fields are.

Regards,
--
Emmanuel




--
Dr. Dirk Zimoch
Paul Scherrer Institut, WBGB/006
5232 Villigen PSI, Switzerland
Phone +41 56 310 5182

Replies:
Re: propagating value upward at init Ralph Lange
References:
propagating value upward at init Emmanuel Mayssat

Navigate by Date:
Prev: Re: propagating value upward at init Liu, Gongfa
Next: Re: EPICS Python client application survey Darren Dale
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017 
Navigate by Thread:
Prev: Re: propagating value upward at init Liu, Gongfa
Next: Re: propagating value upward at init Ralph Lange
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017 
ANJ, 31 Jan 2014 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·