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  <20152016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Reading data from bo record?
From: Michael Davidsaver <[email protected]>
To: [email protected]
Date: Mon, 02 Mar 2015 10:34:14 -0500
Hi Ryan,

On 03/02/2015 01:36 AM, Ryan Pierce wrote:
> Physical example: I've got three propane burners. I'd like PV's for each
> of them, so I can turn them on or off. But I may want to write to a
> different set of PVs that enables a thermostat mode, where code on the
> Arduino turns the burner on or off automatically based on fluid
> temperature. I'd like to be able to query that and display it on the
> control screen.

This is a common scenario for control loops.  It might help to think
about the signals involved here, and their direction (as viewed from the
IOC toward the AVR).

1. Actual switch state: on or off (input)
2. Loop Open/Closed (output).
3. Operator commanded switch state, used in open loop (output).
4. Loop commanded switch state, used in closed loop (input).

As I understand it you'd like to combine signals 3, 4, and possibly 1
into one setting.  This can be done (as has been mentioned), but I'd
like to suggest that this might not be a good idea.

> B. Do something I'm missing to make the bo truly bidirectional. I'm
> looking through the docs and am wondering if DOL and OMSL would do what
> I wanted.

In a boRecord the VAL field is signal #3, OMSL is signal #2, the DOL
link points to a different PV which is signal #4.  If you were closing
your thermostat control loop through your IOC then OMSL/DOL would do
exactly what you want.

I'm guessing that you aren't, so it might be better to think of these 4
signals as variables in your AVR.

The key point I'd suggest is that no single signal directly write the
physical output bit.  Rather, the loop in your AVR program would look
something like:

> char openClosed2, operCmd3, loopCmd4, readback1;
> ...
> loopCmd4 = iteratePID();
> if(openClosed2)
>   readback1 = loopCmd4;
> else
>   readback1 = operCmd3;
> set_switch(readback1);

This also gives a clear point to do additional checks.  For example, you
might keep track of how long the burner has been on, and force it off
after some pre-determined maximum.

It also lets you do troubleshooting in open loop and see what the loop
controller is trying to do.

So, these 4 variables would be reflected in your IOC as four records,
which are strictly uni-directional.

> record(bi, "$(P)Burner-Sts") { # signal 1
>   field(ZNAM, "Off")
>   field(ONAM, "On")
> }
> record(bo, "$(P)Burner:Op-Sel") {... set *NAM ..} # signal #3
> record(bi, "$(P)Burner:Loop-Sts") {... set *NAM ..} # signal #4
> record(bi, "$(P)Loop-Sel") { # signal 2
>   field(ZNAM, "Open")
>   field(ONAM, "Closed")
> }

The last piece is to keep the operator setpoint "in-sync" when in closed
loop.  This can be accomplished by adding one more record.

> record(calcout, "$(P)Burner:Update") {
>   field(INPA, "$(P)Loop-Sel CP")
>   field(INPB, "$(P)Burner:Loop-Sts CP")
>   field(CALC, "A")
>   field(OOPT, "When Non-zero")
>   field(DOPT, "Use OCAL")
>   field(OCAL, "B")
>   field(OUT , "$(P)Burner:Op-Sel")
> }

What this is doing is, while "$(P)Loop-Sel" is non-zero (closed) it
writes the value of loop command signal to the operator command signal.
 The " CP" magic causes this calculation to be performed when either of
the inputs changes.

> I get the feeling EPICS is a Swiss Army knife with a lot of tools, but
> being a beginner I really don't know what the best tool for the job
> would be here. I'm thinking either:

There is definitely more than one why to solve this problem, and an
element of personal preference.  Sometimes it isn't desirable to keep
the manual setting in-sync with the loop setting.

> A. I create a pair of bi and bo PV's for each burner. The bo would be
> used to send commands to turn the burner off or on. But the bi would
> indicate whether the burner actually is on of off.

However you do the setting, I'd strongly suggest a separate bi record
which unambiguously indicates if the burner is on or off.  This doesn't
seem like a good area for confusion.


Michael

References:
Reading data from bo record? Ryan Pierce

Navigate by Date:
Prev: RE: Reading data from bo record? Mark Rivers
Next: RE: Using sCalcout record Mooney, Tim M.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: Reading data from bo record? Mark Rivers
Next: Using sCalcout record Chanaka De Silva
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 16 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·