Re: Scan question

[Ralph Lange <Ralph.Lange@bessy.de>]

I did a similar thing using a small database:

When changing (setting) a certain setpoint PV, a seq record (connected 
through a CP input link to that setpoint) will set the SCAN fields of a 
fixed list of related readback PVs to the fastscan setting and 
reset/restart a countdown timer (calcout record scanned every second 
counting its value down). Any subsequent "turning the knob" will again 
reset the counter and thus extend the countdown timer period.
When the calcout reaches zero, it fires another seq record, which resets 
the SCAN fields to the slowscan values.

Three more records, less functionality, but doesn't need changes to the 
record definition and code, and is more robust: Reference counting 
always implies statefulness, which introduces a number of problems 
(handling of IOC reboots, clients not deassigning properly etc.)
Doesn't work for attached meters, though. Only for getting fast 
responses on readbacks that are related to a knob that someone is turning.

It's the flexibility that makes EPICS confusing. And wonderful.

Ralph


John Sinclair wrote:
> Actually, when I ported the tandem controls to EPICS, I modified a 
> couple of the
> standard records (ai, ao, mbbiDirect, mbboDirect) to be able to 
> manipulate the scan value inside
> the record's own code. The remote I/O throughput was too low to have 
> all the records scan at
> a rate fast enough to make I/O sufficiently responsive during beam 
> tuning. In the old system
> (no network), several process variables could be assigned to knobs and 
> meters which would
> cause them to be processed at a higher scan rate. So I used the same 
> scheme. I added a
> fastscan and slowscan field to the database along with several fields 
> to manage the assignment
> operation. When the PV was "assigned" (to a knob or meter, in this 
> case), an assignment reference
> count was incremented. When deassigned, the count was decremented. 
> When the count became
> non-zero or zero, the scan field got the value of fastscan or slowscan 
> respectively. In this case
> I obviously needed the record to manage the scan value rather than 
> some external agent.
>
> Ain't EPICS wonderful.
>
> John Sinclair
>
> Mark Rivers wrote:
> > I think it would be a bad idea for a record to change the SCAN field.
> > That is something that you should let the database designer do.  They
> > may want to use your record in ways you never thought of.
> >
> > However, if you really want your record to process again when something
> > happens then the record code can request reprocessing without changing
> > the SCAN field.  There are several ways to do this (scanOnce,
> > processRequestProcessCallback) depending on the application.  Look at
> > the Application Developer's Guide.
> >
> > Mark
> >  
> > > -----Original Message-----
> > > From: tech-talk-bounces@aps.anl.gov 
> > > [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Heinrich du Toit
> > > Sent: Thursday, July 12, 2007 9:05 AM
> > > To: TechTalk EPICS
> > > Subject: Scan question
> > >
> > > Can I change the SCAN field at runtime?
> > > E.g. inside my own custom record.
> > >
> > > Some devices normally needs only be scanned say once a sec or every 5
> > > secs. But then when you change the value you want the scanned faster at
> > > say 0.2 secs.