Re: [db] simple command ?

[Tim Mooney <mooney@aps.anl.gov>]

----- 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.  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.

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.

Tim

> 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

-- 
Tim Mooney (mooney@aps.anl.gov) (630)252-5417
Software Services Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab