g+
g+ Communities
Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
<== Date ==> <== Thread ==>

Subject: Re: Waveform read problems
From: Eric Norum <eric@norum.ca>
To: Mark Rivers <rivers@cars.uchicago.edu>
Cc: "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>, "apwagner@u.washington.edu" <apwagner@u.washington.edu>
Date: Sun, 29 Jul 2012 22:45:47 -0700
Or just run the program under gdb:
gdb ../../bin/linux-x86_64/DrvTest 
run st.cmd
......
where

On Jul 27, 2012, at 8:56 PM, Mark Rivers wrote:

> If you are getting a segmentation violation then you can get a lot more information on what happened.
> 
> Enable core dumps:
> 
> limit core 10000000
> 
> Now when it seg faults you will get a core dump.
> 
> Run gdb on the core file:
> 
> gdb ./../bin/linux-x86_64/DrvTest core.xxxx
> 
> When gdb starts type the command
> 
> bt
> 
> That will give you a stack trace, and we will know where it crashed.
> 
> Mark
> 
> ________________________________________
> From: tech-talk-bounces@aps.anl.gov [tech-talk-bounces@aps.anl.gov] on behalf of apwagner@u.washington.edu [apwagner@u.washington.edu]
> Sent: Friday, July 27, 2012 9:22 PM
> To: Eric Norum
> Cc: tech-talk@aps.anl.gov
> Subject: Re: Waveform read problems
> 
> 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)
> ##asynAutoConnect "L0" -1 1
> ##epicsThreadSleep 2
> 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.0725!
 00!
> 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: apwagner@u.washington.edu [mailto:apwagner@u.washington.edu]
>>>>> Sent: Friday, July 27, 2012 7:24 PM
>>>>> To: Mark Rivers
>>>>> Cc: tech-talk@aps.anl.gov
>>>>> 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: tech-talk-bounces@aps.anl.gov [tech-talk-bounces@aps.anl.gov] on behalf of apwagner@u.washington.edu [apwagner@u.washington.edu]
>>>>>> Sent: Friday, July 27, 2012 4:53 PM
>>>>>> To: tech-talk@aps.anl.gov
>>>>>> 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
>>>> eric@norum.ca
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> --
>> Eric Norum
>> eric@norum.ca
>> 
>> 
>> 
>> 
>> 
> 
> 

-- 
Eric Norum
eric@norum.ca






References:
Re: Waveform read problems Eric Norum
Re: Waveform read problems apwagner
RE: Waveform read problems Mark Rivers

Navigate by Date:
Prev: The many uses of libCom (tomography reconstruction!) Mark Rivers
Next: seq_pvPut() Bradley Pietrzak
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
Navigate by Thread:
Prev: RE: Waveform read problems Mark Rivers
Next: Re: Waveform read problems Eric Norum
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICSv4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·