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  2015  2016  2017  2018  2019  2020  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: Re: Waveform read problems
From: Eric Norum <wenorum@lbl.gov>
To: apwagner@u.washington.edu
Cc: "tech-talk@aps.anl.gov tech-talk" <tech-talk@aps.anl.gov>
Date: Mon, 30 Jul 2012 14:05:33 -0700
I don't think that it's a good idea to modify the pdpvt->msg value like that.
I suggest that you add another variable declaration at the top of your function:
	const char *cp = pdpvt->msg;
and then use 'cp' everywhere that you now use 'pdpvt->msg' in the rest of the routine.

On Jul 30, 2012, at 1:57 PM, apwagner@u.washington.edu wrote:

> Hey guys,
> 
> Thanks for all your help and advice. Using gdb I found my problem was not assigning the appropriate amount of memory to copy the record msg char* into a buffer char*. I fixed this by just accessing the record msg directly without copying it. Attached below is the custom conversion routine I found works well and reliably.
> 
> // WF read routine for AGE5071C, converts Hz to MHz for P1==1
> static int readWF(struct gpibDpvt *pdpvt,int P1, int P2, char**P3) {
> 
>  struct waveformRecord *pwf=(struct waveformRecord *)pdpvt->precord;
>  asynUser *pasynUser = pdpvt->pasynUser;
> 
>  double* value = (double *)pwf->bptr;
>  double data;
>  int n;
> 
>  pwf->nord=0;
> 
>  while ((pwf->nord < pwf->nelm) && sscanf(pdpvt->msg,"%lE,%n",&data,&n)==1) {
> 
>    if (P1==1) data/=1E6;
> 
>    memcpy(value+pwf->nord,&data,sizeof(double));
>    pwf->nord++;
>    pdpvt->msg+=n;
> 
>    asynPrint(pasynUser,ASYN_TRACE_FLOW,"(NORD,VAL) : (%i,%E)\n",pwf->nord,data);
> 
>  }
> 
>  if (pwf->nord == 0) return -1;
> 
>  pwf->udf = 0;
>  return 0;
> 
> }
> 
> I can definitely see now the the advantages of using stream device. I my system control needs become more complicated I'll switch over to using that instead of asynGpib.
> 
> Cheers,
> 
> Andrew
> 
> 
> On Mon, 30 Jul 2012, Eric Norum wrote:
> 
>> I put together a simple StreamDevice/ASYN application and a small python script to provide a dummy 'instrument'.   The instrument provides 30000 values on demand.
>> Things seem to work as expected.  Here's the output from the final command of the startup script:
>> 
>> dbpr "wchk:1:Wave"
>> ASG:                BUSY: 0             DESC: Read a long waveform
>> DISA: 0             DISP: 0             DISV: 1             NAME: wchk:1:Wave
>> NORD: 30000         SEVR: NO_ALARM      STAT: NO_ALARM      TPRO: 0
>> VAL: 0x0
>> 
>> As you can see, the IOC has successfully read 30000 double values from the instrument.
>> Andrew -- perhaps you can massage the attached application a little to match the commands of your hardware and see if things work for you as well?
>> 
>> 
> 



References:
Re: Waveform read problems apwagner

Navigate by Date:
Prev: Re: Waveform read problems apwagner
Next: Problem with the basic example Bruno Seiva Martins
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: Re: Waveform read problems apwagner
Next: The many uses of libCom (tomography reconstruction!) Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·