EPICS Home

Experimental Physics and Industrial Control System


 
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Patch to subArray record
From: Michael Abbott <[email protected]>
To: EPICS core <[email protected]>
Cc: EPICS Tech Talk <[email protected]>
Date: Fri, 12 Nov 2010 10:25:32 +0000 (GMT)
The subArray record is designed to provide a smaller view into a larger 
record, but unfortunately as a result of patch
	[email protected]
part of this behaviour was compromised.  I believe the patch in this 
message fixes things.

subArray uses four different numeric fields with the following meanings:

	INDX	Offset into target array for first point in subArray data
	NELM	Desired length of subArray data
	NORD	Actual length of data after processing, NORD <= NELM
	MALM	Length of working buffer

The role of MALM is to allocate workspace for the subArray record, and in 
particular NELM <= MALM at all times.

The default soft device support for subArray uses dbGetField to read the 
entire waveform of interest into the workspace before processing it, so in 
this case we are also constrained to INDX+NORD <= MALM.  This cannot be 
fixed in general (to read just the subarray of interest), as channel 
access has no notion of requests with an offset (perhaps an application 
for Andrew's meta-data?), so when using subArray it becomes necessary to 
set MALM to the size of the entire source array.

Unfortunately patch [email protected] 
changes the length reported by subArray to return MALM.  Looking at this 
patch I suspect this was an oversight, but one that hasn't been noticed 
for three years!

The patch below, I believe, fixes this.  cvt_dbaddr() now reports NORD as 
the true size of the available data, which makes this record type a bit 
more useful.

I discovered this change when a 4000 point record I was using to index 
into a 30000 point waveform exploded in size (and refused to update, 
because EPICS_CA_MAX_ARRAY_BYTES was not set) after upgrading from EPICS 
3.14.8.2 to 3.14.11.


diff --git a/src/dev/softDev/devSASoft.c b/src/dev/softDev/devSASoft.c
index 5600ac1..32b5ad7 100644
--- a/src/dev/softDev/devSASoft.c
+++ b/src/dev/softDev/devSASoft.c
@@ -81,6 +81,8 @@ static long read_sa(subArrayRecord *prec)
         memmove(prec->bptr, (char *)prec->bptr + prec->indx * esize,
                 ecount * esize);
     }
+    else
+        prec->nord = 0;
 
     if (nRequest > 0 &&
         prec->tsel.type == CONSTANT &&
diff --git a/src/rec/subArrayRecord.c b/src/rec/subArrayRecord.c
index 081304e..bc00d69 100644
--- a/src/rec/subArrayRecord.c
+++ b/src/rec/subArrayRecord.c
@@ -168,7 +168,7 @@ static long cvt_dbaddr(DBADDR *paddr)
     subArrayRecord *prec = (subArrayRecord *) paddr->precord;
 
     paddr->pfield = prec->bptr;
-    paddr->no_elements = prec->malm;
+    paddr->no_elements = prec->nord;
     paddr->field_type = prec->ftvl;
     paddr->field_size = dbValueSize(prec->ftvl);
     paddr->dbr_field_type = prec->ftvl;
@@ -180,10 +180,7 @@ static long get_array_info(DBADDR *paddr, long *no_elements, long *offset)
 {
     subArrayRecord *prec = (subArrayRecord *) paddr->precord;
 
-    if (prec->udf)
-       *no_elements = 0;
-    else
-       *no_elements = prec->nord;
+    *no_elements = prec->nord;
     *offset = 0;
 
     return 0;
@@ -194,9 +191,8 @@ static long put_array_info(DBADDR *paddr, long nNew)
     subArrayRecord *prec = (subArrayRecord *) paddr->precord;
 
     if (nNew > prec->malm)
-       prec->nord = prec->malm;
-    else
-       prec->nord = nNew;
+        nNew = prec->malm;
+    prec->nord = nNew;
 
     return 0;
 }

Replies:
Re: Patch to subArray record Andrew Johnson

Navigate by Date:
Prev: Re: whether abvisable to use win32 to host EPICS development Andrew Johnson
Next: Re: MDrive - a novice in trouble James Rezende Piton
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Unexpected BURT incompatibility after Timing upgrade Michael Abbott
Next: Re: Patch to subArray record Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024