Hi Bruce,
If you look through aSubRecord.h, the data type of val field is
epicsInt32. I think RMS, mean, etc. are usually double. In this case,
'prec->val = do_sub(prec)' might not work well.
However, you don't need to make any change on aSubRecord.c. There're
many ways to process waveform/array data(RMS, Max, Min, Sum, data
fitting, FFT, etc.) using aSub record. As the wiki [1] says, aSub has
array-valued input and output fields. In your aSub record, you can use
one input link(i.e. INPA) for your waveform record, then use multiple
output fields (i.e. OUTA, OUTB, etc.) for the processed data(i.e. VALA
for average, VALB for Max, etc.). Here's one example from EPICS driver
for GE ICS-710 digitizer [2] I've been working on.
record(waveform,"${PREFIX}VoltWf-I")
{
field(SCAN,"I/O Intr")
field(DESC,"voltage waveform data")
field(DTYP,"ics710")
field(NELM,"${NELM}")
field(FTVL,"DOUBLE")
field(INP,"@C${CARD} S${CHANNEL} WVOL")
field(PREC,"6")
field(EGU,"V")
#forward link to aSub record to process waveform data: mean, min,
max, rms, integral, std, etc. ;
field(FLNK,"${PREFIX}VoltWf-aSub_")
}
#see ics710ProcessWfAsub.cpp: process the waveform record: mean, min,
max, integral(sum), std(RMS noise), etc. ;
record(aSub,"${PREFIX}VoltWf-aSub_")
{
field (DESC,"process waveform data")
field (INAM,"ics710InitWfAsub")
field (SNAM,"ics710ProcessWfAsub")
field (INPA, "${PREFIX}VoltWf-I")
field (FTA, "DOUBLE")
field (NOA, "${NELM}")
field (OUTA, "${PREFIX}AveVolt-I PP")
field (FTVA, "DOUBLE")
field (NOVA, "1")
field (OUTB, "${PREFIX}MaxVolt-I PP")
field (FTVB, "DOUBLE")
field (NOVB, "1")
field (OUTC, "${PREFIX}MinVolt-I PP")
field (FTVC, "DOUBLE")
field (NOVC, "1")
field (OUTD, "${PREFIX}SumVolt-I PP")
field (FTVD, "DOUBLE")
field (NOVD, "1")
field (OUTE, "${PREFIX}StdVolt-I_ PP")
field (FTVE, "DOUBLE")
field (NOVE, "1")
}
record(ai,"${PREFIX}AveVolt-I")
{
field(DESC,"averaged voltage")
field(INP,"${PREFIX}VoltWf-aSub_.VALA")
field(PREC,"6")
field(EGU,"V")
}
...
Here's the simplified source code:
...
static double *pwfData;
static long ics710InitWfAsub(aSubRecord *precord,processMethod process)
{
if (Initialized) return (0);
if (NULL == (pwfData = (double *)malloc(precord->noa *
sizeof(double)))) return -1;
else Initialized = TRUE;
return(0);
}
static long ics710ProcessWfAsub(aSubRecord *precord)
{
//get array data from input link
memcpy(pwfData, (double *)precord->a, precord->noa *
sizeof(double));
//data processing on pwfData: std, max, min, fft,...
...
/* put the calculated results into ai records*/
*(double *)precord->vala = ave;
...
return(0);
}
You might think about using EPICS waveProc [3] for processing array.
Good luck!
Yong
[1]
http://www.aps.anl.gov/epics/wiki/index.php/RRM_3-14_Array_Subroutine
[2]
http://epics.hg.sourceforge.net/hgweb/epics/ics710/file/1f6166468c9c/ics
710App/Db/ics710Channel.db
http://epics.hg.sourceforge.net/hgweb/epics/ics710/file/1f6166468c9c/ics
710App/src/ics710ProcessWfAsub.cpp
[3] http://www.aps.anl.gov/epics/modules/soft/waveProc/index.html
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Bruce Hill
Sent: Thursday, September 15, 2011 1:05 AM
To: Techtalk
Subject: aSubRecord VAL field
I have an application where I'm using aSub to calculate RMS for an
array.
It worked fine when I just wanted to generate the RMS value and return
it
via VAL. However, when I extended the routine to also calculate MIN
and MAX
and return them via OUT links, I found that if my SNAM routine returns a
non-zero value, it's treated as a status error and aSubRecord.c
suppresses the
updates of the output links.
I'm getting around it by returning zero from my SNAM routine and
returning
all my results via OUT link waveforms, but it seems we should either
update
the wiki documentation to note this behaviour or modify aSubRecord.c to
not
treat the SNAM return value as an error code.
i.e.
--- rec/aSubRecord.c (revision 7338)
+++ rec/aSubRecord.c (working copy)
@@ -269,8 +269,7 @@
}
if (!status) {
- status = do_sub(prec);
- prec->val = status;
+ prec->val = do_sub(prec);
}
I'm running base version 3.14.12.
Comments welcome.
Thanks,
- Bruce