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
- Replies:
- Re: Waveform record missing fields Andrew Johnson
- References:
- Waveform record missing fields Mark Rivers
- Re: Waveform record missing fields Andrew Johnson
- Navigate by Date:
- Prev:
Re: Waveform record missing fields Andrew Johnson
- Next:
Re: Waveform record missing fields Andrew 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: Waveform record missing fields Andrew Johnson
- Next:
Re: Waveform record missing fields Andrew 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
|