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
<2012>
2013
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
<2012>
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|