Re: propagating value upward at init

[Dirk Zimoch <dirk.zimoch@psi.ch>]

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