g+
g+ Communities
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  <20122013  2014  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
<== Date ==> <== Thread ==>

Subject: Re: [db] simple command ?
From: Benjamin Franksen <benjamin.franksen@helmholtz-berlin.de>
To: <tech-talk@aps.anl.gov>
Date: Sat, 7 Apr 2012 02:24:12 +0200
Hi Tim

On Friday 06 April 2012 23:30:28 you wrote:
> ----- Original Message -----
>
> > From: "Benjamin Franksen" <benjamin.franksen@helmholtz-berlin.de>
> > To: tech-talk@aps.anl.gov
> > Sent: Friday, April 6, 2012 5:45:10 PM
> > Subject: Re: [db] simple command ?
> >
> > On Wednesday 04 April 2012 18:43:29 Pavel Masloff wrote:
> > > You are right - I want the record to automatically switch its value
> > > back to
> > > 0 after somebody sets it to 1. Time doesn't really matter. Imagine a
> > > pneumatic valve. I have two records two control it: cmd:valve_ON and
> > > cmd:valve_OFF. The reason I use two records instead of one is simply
> > > because there are two buttons on the front panel of my control
> > > cubicle. And
> > > the PLC logic is that it checks whether only one button is pressed
> > > at a
> > > time. This is local control. Yet, at the same time I want to
> > > remotely
> > > control my system by means of EPICS.
> >
> > Beware, though: using the HIGH field causes the record to process
> > (again) when
> > VAL gets reset to zero.
> >
> > The bo machinery with all the extra processing, setting up timers etc
> > seems to
> > be overkill for this commonly requested feature. I tend to use mbbo
> > records
> > (one for each command) and let clients write to the PROC field (they
> > can write
> > any value they like).
>
> I understood the problem to require that a pulse be sent to the PLC.

Ah, I missed that. Sorry for being off-topic, then.

> In
> that case, processing again seems inevitable, and in any case something
> must define the pulse width.  If a sub-millisecond pulse were ok, you
> could just forward link to a "reset" record that would write to the VAL
> field via a CA link.
>
> > One feature that I miss with this solution: a (simple) way to make the
> > VAL
> > field immutable, so chosing /which/ command is executed cannot be
> > changed at
> > runtime. Any ideas how to do that except writing a new record type?
>
> When I don't want users writing to a PV, I usually just decline to give
> them the record name, and instead provide a second record that forward
> links to it.  If they're well enough informed to figure it out by looking
> at the forward link, then I assume they know what they're doing and just
> try to stay out of their way.

Sure, same here. Though adding another record just to avoid stupid mistakes, I
don't know. And then you have to invent another record name...

I tried another solution to allow only one value:

record(mbbo,"myDevice:cmdOn") {
        field(VAL,"1")
        field(ONST,"On")
}

and similarly for "Off". Unfortunately this does not work as expected, it does
not prevent VAL from being set to a different value:

ben@sarun[3]: ~ > caput myDevice:cmdOn 3
Warning: enum index value '3' may be too large.
Old : myDevice:cmdOn                 Illegal Value
New : myDevice:cmdOn
ben@sarun[3]: ~ > caget -n myDevice:cmdOn
myDevice:cmdOn                 3

I wonder why the record support does not prevent VAL from being set to a value
that was not configured.

> If I'm /really/ worried about somebody writing to a record, or if they want
> the ability to forbid each other from writing to a record, I usually
> control DISA and DISP, as in this excerpt from the motor module's motor.db
> (DISV==1):
>
> record(transform, "$(P)$(M)_ableput") {
>   field(CLCB, "a")
>   field(CLCC, "a")
>   field(OUTA, "$(P)$(M).DISA NPP NMS")
>   field(OUTB, "$(P)$(M).DISP NPP NMS")
>   field(OUTC, "$(P)$(M).DISA NPP NMS")
> }
>
> This isn't bulletproof, because a database link will still succeed in
> changing $(P)$(M).<field>, even though it won't succeed in processing the
> record.  It's bulletproof to CA clients, though.

I tend to use a state machine (SNL program); usually in such cases the logic
is too complex to define everything with records and links anyway.

Cheers
Ben

________________________________

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. Vorsitzende Dr. Beatrix Vierkorn-Rudolph
Geschäftsführerin: Prof. Dr. Anke Rita Kaysser-Pyzalla

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

http://www.helmholtz-berlin.de


References:
Re: [db] simple command ? Tim Mooney

Navigate by Date:
Prev: Re: [db] simple command ? Benjamin Franksen
Next: asynPortDriver, I/O INTR and missing updates Jimmy Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
Navigate by Thread:
Prev: Re: [db] simple command ? Tim Mooney
Next: devLib2 2.3 release Michael Davidsaver
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICSv4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·