Thanks Mark, the ND Array is working as expected by setting the NDimensions and Dimensions PVs.
Best Regards,
Abdalla Al-Dalleh
Control Engineer
SESAME
From: Mark Rivers <rivers at cars.uchicago.edu>
Sent: Thursday, July 24, 2025 10:34 PM
To: Abdalla Ahmad <Abdalla.Ahmad at sesame.org.jo>; Johnson, Andrew N. <anj at anl.gov>; Pearson, Matthew <pearsonmr at ornl.gov>; tech-talk at aps.anl.gov
Subject: RE: Using AD plugins on asyn port
Hi Abdalla,
NDDriverStdArrays comes with a Python test program that does extensive testing.
https://github.com/areaDetector/NDDriverStdArrays/blob/master/NDDriverStdArraysApp/src/Python_tests/test_NDDriverStdArrays.py
I just updated that program to be compatible with Python 3 and ran it on the example IOC in that repository. The new version is now on Github. It worked fine.
I just looked at the screenshot you sent, and it appears that you have not set the NDimensions and Dimensions PVs. You need to do that so that the driver knows what dimensions to use for the NDArrays it
is creating. Remember that it is designed to accept 1-D waveform records and convert those into multi-dimensional NDArrays.
The documentation here:
https://areadetector.github.io/areaDetector/NDDriverStdArrays/NDDriverStdArraysDoc
says this:
mplementation of Parameters in asynNDArrayDriver.h and ADDriver.h, and EPICS Record Definitions in ADBase.template and NDFile.template
|
Parameter index variable
|
EPICS record name
|
Description
|
NDNDimensions
|
$(P)$(R)NDimensions
|
The number of dimensions in the NDArray to be created. Must be set before the waveform record is written.
|
NDDimensions
|
$(P)$(R)Dimensions
|
An array containing the dimensions of the NDArray to be created. Must be set before the waveform record is written.
|
Note that it says that you must set the NDimensions and Dimensions PVs before you write to the waveform record. I suspect you have not done this.
Mark
Here are the outputs of the two commands:
epics> dbpr NDSA:cam1:ArrayIn 2
ACKS: NO_ALARM ACKT: YES AMSG: APST: Always
ASG : BKPT: 00 BUSY: 0 DESC:
DISA: 0 DISP: 0 DISS: NO_ALARM DISV: 1
DTYP: asynFloat32ArrayOut EGU : EVNT:
FLNK: CONSTANT FTVL: FLOAT HOPR: 0
INP : INST_IO @asyn(NDSA,0,1)NDSA_ARRAY_DATA LCNT: 0
LOPR: 0 MPST: Always NAME: NDSA:cam1:ArrayIn
NAMSG: NELM: 200 NORD: 200 NSEV: NO_ALARM
NSTA: NO_ALARM PACT: 0 PHAS: 0 PINI: NO
PREC: 0 PRIO: LOW PUTF: 0 RARM: 0
RPRO: 0 SCAN: Passive SDIS: CONSTANT SDLY: -1
SEVR: NO_ALARM SIML: CONSTANT SIMM: NO SIMS: NO_ALARM
SIOL: CONSTANT SSCN: 65535 STAT: NO_ALARM
TIME: 2025-07-24 14:02:33.691146878 TPRO: 0 TSE : 0
TSEL: CONSTANT UDF : 0 UDFS: INVALID VAL : PTR (nil)
$ caget NDSA:cam1:ArrayIn
NDSA:cam1:ArrayIn 200 -74.6667 52.8155 -11.0769 -10.9714 -10.8679 52.6355 -11.2593 -11.156 -11.0545 -10.955 -10.8571 -74.1947 53.3333 -10.5739 52.9655 52.5128 -11.3898 -11.2941 -74.6667
-10.5785 52.9836 -10.9268 -10.8387 52.736 -74.6667 116.409 -11.5 -11.4109 52.1846 51.7863 -12.1212 115.008 -76.4179 -202.904 -10.8235 -74.2774 -73.7391 117.41 -74.0571 -9.98582 -9.91549 -73.3986 -9.33333 -9.26897 -72.7671 -72.2721 -8.21622 -71.7315 -7.68 -134.781
-70.3158 57.3072 -133.818 57.8064 -6.15385 121.07 -70.481 -6.44025 57.2 -6.75776 -6.71605 56.9325 -7.02439 -6.98182 -6.93976 -6.8982 -6.85714 56.8047 -70.7765 -6.73684 -6.69767 -6.65896 -6.62069 -70.2171 -6.18182 -6.14689 -6.11236 57.5642 57.2444 56.9282 -7.03297
-70.6448 -6.6087 -6.57297 -6.53763 -6.50267 -6.46809 -70.0952 -6.06316 -69.6963 58 -5.96891 -5.93814 -5.90769 -69.551 -5.52284 -5.49495 -69.1457 -68.8 0 -48 64 53.3333 45.7143 -16 -14.2222 -12.8 46.5455 -16 44.3077 41.1429 38.4 36 33.8824 -28.4444 33.6842
-28.8 -88.381 -84.3636 41.7391 -21.3333 -81.92 -17.2308 -16.5926 45.7143 -17.6552 -17.0667 45.4194 -18 -17.4545 -16.9412 107.886 -19.5556 -81.2973 -79.1579 -77.1282 -12.8 -12.4878 50.2857 -13.3953 49.4545 48.3556 -77.913 49.0213 -14.6667 -14.3673 -14.08 48.9412
48 47.0943 46.2222 -80.2909 46.8571 -16.8421 -16.5517 -16.2712 -16 47.2131 46.4516 -17.2698 -17 -16.7385 -16.4848 -79.2836 48 -15.7681 -15.5429 47.7746 -16 -78.9041 -77.8378 -13.6533 49.6842 -14.1299 49.2308 48.6076 -15.2 -15.0123 -14.8293 48.5783 -15.2381
48.1882 -15.6279 47.8161 47.2727 -16.5393 -16.3556 47.1209 46.6087 -17.2043 46.2979 -17.5158 -80.6667 46.8454 -16.9796 46.5455 -17.28 -80.4753 47.0588 -16.7767
After some investigation, I noticed that the compiler (gcc 8.5.0) is throwing
-Wsign-compare on the
unsigned int i defined inside
writeXXXArray. I changed it to int and for some reason the IOC is now working, the array is acquiring but only one item. I
opened ADBase.ui and I noticed the following:
- Data type is always set to Int8, despite FTVL in the st.cmd is being passed “FLOAT”
- # Elements is 1 despite being passed value of 200.
- Sensor size is 1 by 1 at the beginning, but when I start acquire, X and Y sensor sizes go to strange values (something similar to printing an uninitialized integer).
Re-running the IOC, it started to throw “Floating-point exception” after fixing
-Wsign-compare and the core dump is showing the same exact location.
Best Regards,
Abdalla Al-Dalleh
Control Engineer
SESAME
After your primary IOC should have sent waveforms to the NDSA driver, but before you start acquire in the NDSA driver please send the output of this command in the NDSA IOC:
And from a Linux shell do:
Hi all
Thanks for the feedback, I created an IOC with NDDriverStdArrays support, attached is the startup file. The ArrayIn PV is receiving data from my waveform record through an intermediate ‘aao’ record in the attached nd.db database,
where the DOL field is set to a waveform of size 200 scanned at 1 second. The IOC boots but when I press acquire on the GUI, the IOC segfaults immediately. I added the gdb output of loading the core dump at the end of the startup file, it always crashes here:
https://github.com/areaDetector/NDDriverStdArrays/blob/master/NDDriverStdArraysApp/src/NDDriverStdArrays.cpp#L259 .
I used the IOC in the source code but I got the same segfault at the same location. Could it be related to the fact that the array size is 0? I also attached a screenshot of the NDDriverStdArrays UI file. Am I missing something?
Best Regards,
Abdalla Al-Dalleh
Control Engineer
SESAME
That’s a very useful addition.
Whether it can be used with NDDriverStdArrays depends on the behavior of the input waveform record you are copying via the aao record. If it only posts monitors when the waveform is “done” then it could work. But in some applications the input waveform
may process many times with “intermediate results” before it is really done. One example would be a waveform digitizer with relatively slow sample rate. The waveform record may be processing multiple times during an acquisition so the operator can see the
waveform trace update before it is complete. Another example is an MCA spectrum which is acquiring for a relative long time. The waveform will update during acquisition so the operator can see the waveform amplitude grow. In these cases you probably don’t
want the intermediate values of the waveform to be sent to NDDriverStdArrays, you only want to write the final value. That is where a more sophisticated CA client may be needed.
Mark
You can use an aao (array analog output) record to read array data from another record using the DOL input link and write it through
the OUT output link to another record. The DOL and OMSL fields were added to it in EPICS 7.0.7.
- Andrew
--
Complexity comes for free, Simplicity you have to work for.
Hi,
Apologies, I haven’t used that driver myself, and I assumed it would work like the pvaDriver. Mark is right, seems like you need an extra step to copy the waveform data into ArrayIn. One other option might be an array subroutine record.
Cheers,
Matt
Hi Abdalla, it is exactly what I need, but it is still unclear how it interfaces with my existing waveform record, i. e.
How to pass data from my waveform record to $(P)$(R)ArrayIn. My waveform record already has its INP field set to read input
Hi Abdalla,
·
it is exactly what I need, but it is still unclear how it interfaces with my existing waveform record, i.e. How to pass data from my waveform record to $(P)$(R)ArrayIn. My waveform record
already has its INP field set to read input from a compress record doing circular buffer at 200 Hz from the hardware.
You probably need to use some additional code, for example in Python or SNL. That code will read from your existing waveform record and write to ArrayIn. It can also
configure the other records in NDDriverStdArrays, and decide when to copy the waveform record. For example, it may only copy when the waveform record is "full", not on each incremental update.
There are examples of Python and IDL code in the NDDriverStdArrays repository.
Mark
Thanks Matt, it is exactly what I need, but it is still unclear how it interfaces with my existing waveform record, i.e. How to pass data from my waveform record to $(P)$(R)ArrayIn. My waveform record
already has its INP field set to read input from a compress record doing circular buffer at 200 Hz from the hardware.
Best Regards,
Abdalla Al-Dalleh
Control Engineer
SESAME
Hi Abdalla,
This might be what you need:
https://areadetector.github.io/areaDetector/NDDriverStdArrays/NDDriverStdArraysDoc.html
It monitors a waveform record and can turn it into an NDArray, which can then be processed by other areaDetector plugins as needed. It doesn’t connect to the Asyn port that is producing the waveform data directly, but instead sets
up a channel access monitor.
Cheers,
Matt
Hi Is there a way to apply AD plugins on a waveform record processed from asyn port without rewriting an asynNDArrayDriver class? i. e. ,
something to be done in the st. cmd maybe? Best Regards, Abdalla Al-Dalleh Control Engineer SESAME
Hi
Is there a way to apply AD plugins on a waveform record processed from asyn port without rewriting an asynNDArrayDriver class? i.e., something to be done in the st.cmd maybe?
Best Regards,
Abdalla Al-Dalleh
Control Engineer
SESAME