EPICS Home

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  2015  2016  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  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: [db] simple command ?
From: Benjamin Franksen <[email protected]>
To: <[email protected]>
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" <[email protected]>
> > To: [email protected]
> > 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  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
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  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024