Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Fri, 10 Feb 2012 21:52:37 +0000

Hi Andrew,

I looked at the 3.11 and 3.12 record reference manuals and they don't mention those fields.  So they appear to have been added to the manual in 3.13 but never added to the code.

> I wonder if they couldn't just 
> be separate records though, how about using ao, bo, longout, mbbo and 
> stringout records to set parameters for the waveform acquisition

For a more complex case I agree that is the way to go.  In fact that is exactly what areaDetector does.  The records all talk to the same asyn port driver that implements the logic, and the waveform record is the image.

But what I would like to do now is write some simple, generic device support for the waveform record that will be part of asyn.  The device support is called asynInt32TimeSeries and asynFloat64TimeSeries.  The device support registers for callbacks on the asynInt32 or asynFloat64 interfaces, and as each of those callbacks arrives it puts the callback value into a time series in the waveform.  It would be cleanest to require no other records than the waveform record, then I don't even need a database for it in asyn.  

Here is what is currently working:
  RARM=1 Erase (set array to 0 and NORD=0) and start acquisition.  Register for callbacks.
  RARM=2 Stop acquisition.  Cancel callback registration.
  RARM=3 Start acquisition without erasing (don't clear array or modify NORD).  Register for callbacks.

  BUSY=1 when acquiring, 0 when done.

  When acquisition completes because NORD=NELM issue callback request to process record.  
  That way even if the record it not periodically scanned it will process when acquisition completes.

Here is what I would be able to do if we had the RATE and NINP fields:
  Stop acquisition when NORD=NINP rather than NELM, so user can request fewer time points when acquisition will automatically stop
  RATE would control averaging of callback values, so if callbacks are coming at 1kHz one could get a smoothed waveform with 
  0.1 second per point, etc.

This functionality currently requires the MCA record (with its fastSweep device support).  It is needed in areaDetector for on-the-fly scanning, which is why areaDetector currently depends on MCA, which I don't like.

I think RATE, PTSS, and NINP could be added to the record in 3.14, since they would only be used by device support and would not change any existing behavior.  I agree that changing the behavior of posting monitors on NORD needs to wait for 3.15.

Thoughts?

Mark

-----Original Message-----
From: Andrew Johnson [mailto:[email protected]] 
Sent: Friday, February 10, 2012 3:25 PM
To: [email protected]; Mark Rivers
Subject: Re: Waveform record missing fields

Hi Mark,

On 2012-02-10 Mark Rivers wrote:
> Questions:
> 
> - Did these fields ever exist?

Probably at one time, but as Michael has shown there is no record of them in 
the revision control history so they were removed before we started using CVS 
in about 1994.

> - Should they be added?
> 
> - If so, then while we are adding these fields are there others we should
>  also add that would not break backward compatibility?

How about adding some generic parameter fields instead: A double field for the 
parameter value and an associated string field that the device support can set 
it its init_record() routine to describe it.  I wonder if they couldn't just 
be separate records though, how about using ao, bo, longout, mbbo and 
stringout records to set parameters for the waveform acquisition?

> Here are is one that I can think of:
> 
> NUSE: The number of elements in the waveform to actually use.  Must be
>  <=NELM.

Is this meant to tell input device support how many elements to try and read?

> Also, the record does not post monitors on the BUSY or NORD fields.  Should
> this be the responsibility of device support, or does that code belong in
> the record?

Both those fields are currently documented as Rec Proc Monitor = NO, but that 
doesn't mean we can't change them.  The record code only looks at BUSY in one 
place and never sets it itself; I think if device support sets it and wants 
the world to know about changes it should post its own monitors on BUSY.

There are a couple of places where the record code sets NORD: after an array 
put, and in simulation mode.  I could accept that the record support should 
post monitors when it sets NORD, but it should be the device support's 
responsibility when it does so.  This would be a 3.15 change.

- Andrew
-- 
Optimization is the process of taking something that works and
replacing it with something that almost works, but costs less.
-- Roger Needham

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System