Experimental Physics and
Industrial Control System

Hey Eric,

Thanks for looking at this. Here is my startup script:

#!../../bin/linux-x86_64/DrvTest
## You may have to change DrvTest to something else
## everywhere it appears in this file
< envPaths
epicsEnvSet("ARCH","linux-x86_64")
epicsEnvSet("IOC","iocDrvTest")
epicsEnvSet("TOP","/home/admx/admxepics/iocs/DrvTest")
epicsEnvSet("ASYN","/home/admx/epics/asyn4-18")
epicsEnvSet("AG8657B","/home/admx/admxepics/devices/ag8657B")
epicsEnvSet("AG8648B","/home/admx/admxepics/devices/ag8648B")
epicsEnvSet("AGE5071C","/home/admx/admxepics/devices/agE5071C")
epicsEnvSet("PROLOGIXGPIB","/home/admx/admxepics/devices/PrologixGPIB")
epicsEnvSet("EPICS_BASE","/home/admx/epics/base-3.14.12.2")
epicsEnvSet(EPICS_CA_MAX_ARRAY_BYTES, 100000)
cd /home/admx/admxepics/iocs/DrvTest
## Register all support components
dbLoadDatabase "dbd/DrvTest.dbd"
DrvTest_registerRecordDeviceDriver pdbbase
##Load Prologix Driver
##prologixGPIBConfigure("L0", "10.95.101.60:1234",0,1)
##asynOctetSetInputEos("L0", -1, "\n")
##asynSetTraceIOMask("L0_TCP", -1, 0x2)
##asynSetTraceMask("L0_TCP", -1, 0x9)
##asynSetTraceIOMask("L0", 5, 0x2)

prologixGPIBConfigure("L0", "10.95.101.60:1234")
drvAsynIPPortConfigure("L1","10.95.101.61:5025",0,0,0)
asynOctetSetInputEos("L1",0,"\n")
asynOctetSetOutputEos("L1",0,"\n")
asynSetTraceIOMask("L1", -1, 0x2)
asynSetTraceMask("L1", -1, 0x9)
asynSetTraceIOTruncateSize("L1", -1, 16384)
## Load record instances
cd /home/admx/admxepics/devices/ag8648B
dbLoadRecords("db/devAG8648B.db","SIGGEN=AG8648B,L=0,A=19")
dbLoadRecords("db/devAG8648B.db","SIGGEN=AG8648D,L=0,A=10")
cd /home/admx/admxepics/devices/agE5071C
dbLoadRecords("db/devAGE5071C.db","NETWA=AGE5071C,L=1,A=0")
cd /home/admx/admxepics/iocs/DrvTest/iocBoot/iocDrvTest

Actually, I think I figured out some of what was confusing me earlier. By Setting the asynSetTraceIOTruncateSize sufficiently large I can at least see the entirety of what asyn is reading. When processing a wf record the behavior is, read 2048 characters at a time until message ends then Segmentation violation. When processing asynOctetWriteRead the behavior is read first 2048 characters then stop. If you can't guess what could cause the segfault (see first message in this thread) then I'll try updating to a stream device driver. Thanks again for all your help.

Cheers,

Andrew

epics> asynOctetConnect("NW","L1")
epics> asynOctetWriteRead("NW",":SENS1:FREQ:DATA?")
2012/07/27 19:11:07.620 10.95.101.61:5025 write 18
:SENS1:FREQ:DATA?\n
2012/07/27 19:11:07.622 10.95.101.61:5025 read 2048
+4.50000000000E+008,+4.55250000000E+008,+4.60500000000E+008,+4.65750000000E+008,+4.71000000000E+008,+4.76250000000E+008,+4.81500000000E+008,+4.86750000000E+008,+4.92000000000E+008,+4.97250000000E+008,+5.02500000000E+008,+5.07750000000E+008,+5.13000000000E+008,+5.18250000000E+008,+5.23500000000E+008,+5.28750000000E+008,+5.34000000000E+008,+5.39250000000E+008,+5.44500000000E+008,+5.49750000000E+008,+5.55000000000E+008,+5.60250000000E+008,+5.65500000000E+008,+5.70750000000E+008,+5.76000000000E+008,+5.81250000000E+008,+5.86500000000E+008,+5.91750000000E+008,+5.97000000000E+008,+6.02250000000E+008,+6.07500000000E+008,+6.12750000000E+008,+6.18000000000E+008,+6.23250000000E+008,+6.28500000000E+008,+6.33750000000E+008,+6.39000000000E+008,+6.44250000000E+008,+6.49500000000E+008,+6.54750000000E+008,+6.60000000000E+008,+6.65250000000E+008,+6.70500000000E+008,+6.75750000000E+008,+6.81000000000E+008,+6.86250000000E+008,+6.91500000000E+008,+6.96750000000E+008,+7.02000000000E+008,+7.072500!
00000E+008,+7.12500000000E+008,+7.17750000000E+008,+7.23000000000E+008,+7.28250000000E+008,+7.33500000000E+008,+7.38750000000E+008,+7.44000000000E+008,+7.49250000000E+008,+7.54500000000E+008,+7.59750000000E+008,+7.65000000000E+008,+7.70250000000E+008,+7.75500000000E+008,+7.80750000000E+008,+7.86000000000E+008,+7.91250000000E+008,+7.96500000000E+008,+8.01750000000E+008,+8.07000000000E+008,+8.12250000000E+008,+8.17500000000E+008,+8.22750000000E+008,+8.28000000000E+008,+8.33250000000E+008,+8.38500000000E+008,+8.43750000000E+008,+8.49000000000E+008,+8.54250000000E+008,+8.59500000000E+008,+8.64750000000E+008,+8.70000000000E+008,+8.75250000000E+008,+8.80500000000E+008,+8.85750000000E+008,+8.91000000000E+008,+8.96250000000E+008,+9.01500000000E+008,+9.06750000000E+008,+9.12000000000E+008,+9.17250000000E+008,+9.22500000000E+008,+9.27750000000E+008,+9.33000000000E+008,+9.38250000000E+008,+9.43500000000E+008,+9.48750000000E+008,+9.54000000000E+008,+9.59250000000E+008,+9.64500000000E+0!
08,+9.69750000000E+008,+9.75000000000E+008,+9.80250000000E+008!
,+9.85500
eomReason 0x1
+4.50000000000E+008,+4.55250000000E+008,+4.60500000000E+008,+4.65750000000E+008,+4.71000000000E+008,+4.76250000000E+008,+4.81500000000E+008,+4.86750000000E+008,
epics>


On Fri, 27 Jul 2012, Eric Norum wrote:

An alternative question is why the interposeEOS layer is present.
What xxxxConfigure command are you using to create the asyn port?
What other asynXXXXX commands are in your startup script?
Please send the entire startup script for us to have a look at.

On Jul 27, 2012, at 6:10 PM, Andrew Wagner wrote:

Ah! Now the question why doesn't it seem to do this. In the example below I read 2048 characters then get an eomReason 0x1 then nothing. I don't think you need my network analyzer to debug this, just something that sends a long string of numbers.

Andrew

On Jul 27, 2012, at 5:52 PM, Eric Norum wrote:

Yes, there is a 2048-character buffer -- it's in the interposeEOS layer.  That's why the read is returning with EOM=COUNT.
But the interposeEOS layer should then just issue another read until the incoming message really does end.

On Jul 27, 2012, at 5:45 PM, Mark Rivers wrote:

asyn reads as much data as the device sends.  There is no buffer size limit of 2048 anywhere in asyn.  I suspect your device is sending data in 2048 character chunks, and you need to do another "read" operation to get the next chunk of data.  Is this GPIB, Ethernet, or serial?

Mark


-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Friday, July 27, 2012 7:24 PM
To: Mark Rivers
Cc: [email protected]
Subject: RE: Waveform read problems

Thanks for the advice. I'll definitely look into StreamDevice, it sounds really nice. Unfortunately, I've done a little more debugging and I'm pretty sure the problem is in asyn, not my driver. For instance when I try to connect directly with asynOctet, I get:

epics> asynOctetConnect("NW","L1")
epics> asynOctetWriteRead("NW","*IDN?")
2012/07/27 16:43:04.491 10.95.101.61:5025 write 6
*IDN?\n
2012/07/27 16:43:04.492 10.95.101.61:5025 read 47
Agilent Technologies,E5071C,MY46213997,A.10.06\n
eomReason 0x2
Agilent Technologies,E5071C,MY46213997,A.10.06
epics> asynOctetWriteRead("NW",":SENS1:FREQ:DATA?")
2012/07/27 16:43:17.503 10.95.101.61:5025 write 18
:SENS1:FREQ:DATA?\n
2012/07/27 16:43:17.505 10.95.101.61:5025 read 2048
+5.00000000000E+008,+5.05000000000E+008,+5.10000000000E+008,+5.15000000000E+008,+5.20000000000E+008,+5.25000000000E+008,
eomReason 0x1
+5.00000000000E+008,+5.05000000000E+008,+5.10000000000E+008,+5.15000000000E+008,+5.20000000000E+008,+5.25000000000E+008,+5.30000000000E+008,+5.35000000000E+008,
epics>

No Segfault this time however, the entire data stream is truncated after 2048 characters. I'm getting the impression there is something fundamental I'm not understanding about how asyn manages data. I looked over Eric's Stream device tutorial and could find no reason why converting my driver support to stream device would solve this problem since asyn is still handling the communication. My problem remains that I don't understand how to get asyn to read more than 2048 characters. The solution must be very simple otherwise asyn could never have been used with a wf record.

Cheers,

Andrew

On Fri, 27 Jul 2012, Mark Rivers wrote:

You might want to consider using streamDevice rather than the asynGpib software.  asynGpib is rather obsolete; steamDevice is much nicer.  You don't need to write any C code if you use streamDevice.

Eric Norum has recently written a new version of his "HowToDoSerial" tutorial, explaining how to use asyn with streamDevice.  It will be in the next release of asyn, but meanwhile you can find it here:

http://cars.uchicago.edu/software/epics/HowToDoSerial_StreamDevice.html

Cheers,
Mark


________________________________________
From: [email protected] [[email protected]] on behalf of [email protected] [[email protected]]
Sent: Friday, July 27, 2012 4:53 PM
To: [email protected]
Subject: Waveform read problems

Hey Everyone,

I'm using Asyn to create a driver for the Agilent E5071C Network analyzer and am trying to create a working waveform record to readout the analyzer traces. The output of the analyzer is a list of ASCII values separated by commas. For instance, :SENS1:FREQ:DATA? returns the frequency values where the power was measured in Hz. The output is:+5.00000000000E+008,+5.05000000000E+008,+5.10000000000E+008,+5.15000000000E+008,+5.20000000000E+008,+5.25000000000E+008, ... I'm able to communicate with the analyzer, however I create a Segmentation violation when processing waveform records to store this array.


epics> dbtr AGE5071C:FREQ
ACKS: NO_ALARM      ACKT: YES           APST: Always        ASG:
BKPT: 00            BUSY: 0             DESC: Frequency Series Hz
DISA: 0             DISP: 0             DISS: NO_ALARM      DISV: 1
2012/07/27 14:12:12.823 DTYP: AGE5071C      EGU: Hz             EVNT: 0             FLNK:CONSTANT 0
10.95.101.61:5025 write 18
:SEFTVL: DOUBLE        HASH: 0             HOPR: 0
NS1INP:GPIB_IO #L1 A0 @9                   LCNT: 0             LOPR: 0
:FREMPST: Always        NAME: AGE5071C:FREQ NELM: 10000         NORD: 0
Q:DANSEV: NO_ALARM      NSTA: NO_ALARM      PACT: 1             PHAS: 0
TA?PINI: NO            PREC: 0             PRIO: LOW           PROC: 0
\n
PUTF: 0             RARM: 0             RPRO: 0             SCAN: Passive
SDIS:CONSTANT       SEVR: INVALID       SIML:CONSTANT       SIMM: NO
SIMS: NO_ALARM      SIOL:CONSTANT       STAT: UDF           TIME: <undefined>
TPRO: 0             TSE: 0              TSEL:CONSTANT       UDF: 1
VAL: (nil)
epics> 2012/07/27 14:12:12.825 10.95.101.61:5025 read 2048
+5.00000000000E+008,+5.05000000000E+008,+5.10000000000E+008,+5.15000000000E+008,+5.20000000000E+008,+5.25000000000E+008,
2012/07/27 14:12:12.825 10.95.101.61:5025 read 1972
000000E+009,+1.01500000000E+009,+1.02000000000E+009,+1.02500000000E+009,+1.03000000000E+009,+1.03500000000E+009,+1.04000
Segmentation fault


I'm defining the gpibCMD as:

{&DSET_WF, GPIBREAD, IB_Q_HIGH, ":SENS1:FREQ:DATA?", NULL, 0, 32000, readWF, 0, 0, NULL, NULL, NULL},

and the custom convert routine I'm using is:

// WF read routine for AGE5071C
static int readWF(struct gpibDpvt *pdpvt,int P1, int P2, char**P3) {

printf("%s","TEST****************************************");

struct waveformRecord *pwf=(struct waveformRecord *)pdpvt->precord;
asynUser *pasynUser = pdpvt->pasynUser;

double* value = (double *)pwf->bptr;
double data;
int n;
char* buffer = "\0";

pwf->nord=0;
strcpy(buffer,pdpvt->msg);

while ((pwf->nord < pwf->nelm) && sscanf(buffer,"%lE,%n",&data,&n)==1) {

memcpy(value+pwf->nord,&data,sizeof(double));
pwf->nord++;
buffer+=n;

asynPrint(pasynUser,ASYN_TRACE_FLOW,"(NORD,VAL) : (%i,%E)\n",pwf->nord,data);

}

if (pwf->nord == 0) return -1;

return 0;

}

Since none of my error messages are printed I conclude the pdpvt->msg array is being overfilled somehow before my convert routine is even processed. I'm really not sure how to debug this since everything that I've written seems to work fine. The debug messages reveal no problems until the Segmentation violation occurs. I also don't understand why the reads can only handle a maximum of 2048 characters at a time. If anyone has experience writing device support for a waveform record your advice would be very helpful. Thanks.

Andrew

--
Eric Norum
[email protected]

--
Eric Norum
[email protected]

Replies:

RE: Waveform read problems Mark Rivers

Re: Waveform read problems Eric Norum

References:

Re: Waveform read problems Eric Norum

Navigate by Date:

Prev: Re: Waveform read problems Eric Norum

Next: RE: Waveform read problems Mark Rivers

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 read problems Eric Norum

Next: RE: Waveform read problems Mark Rivers

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