Experimental Physics and
Industrial Control System

"Allison, Stephanie" <[email protected]> · Fri, 6 Aug 2010 17:42:32 -0700

Hi Andrew,

> My first newbie question is why is SEVR: INVALID? The VAL is certainly what I want it
> to be. 

The custom conversion routine (readMEAS) must reset the UDF field of the record (see devGpib.html in the section that describes GPIBREAD).  So you need to add this line:

>   pai->val = meas;

pai->udf = 0;

>   return 0;

Unfortunately, this won't solve your other problem with the sscanf not working properly.  BTW - you should check the return from sscanf.  Hopefully, someone else will immediately see the problem.  I have no gpib support like yours (with those embedded special characters).

Stephanie Allison

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
> Of Andrew Wagner
> Sent: Friday, August 06, 2010 4:56 PM
> To: [email protected]
> Subject: aiRecord/devGpib problem
> 
> Hey guys,
> 
> I've got EPICS and ASYN running and have successfully followed one of Eric Norum's
> examples to talk to an Agilent 34970A MUX (over IP) and store the *IDN in a stringin
> record. I'm having problems however with reading a voltage measurement back reliably. I
> create device support with the devGpib template and the commands:
> 
>   /* Param 0 -- Read identification string */
>   {&DSET_SI, GPIBREAD, IB_Q_HIGH, "*IDN?\n++read eoi",NULL, 0, 200, NULL, 0,
> 0, NULL, NULL, NULL},
> 
>   /*Param 1 -- Read Measurement @ Channel */
>   {&DSET_AI, GPIBREAD, IB_Q_HIGH, "MEAS:VOLT:DC? (@203)\n++read eoi",
> NULL, 0, 200, readMEAS, 0, 0, NULL, NULL, NULL}
> 
> I'm interfacing with the GPIB device via the PROLOGIX GPIB-Ethernet controller,
> (Google them, they're pretty neat) so you can ignore the ++read eoi part of the command
> string. The conversion method is:
> 
> 
> static int readMEAS( struct gpibDpvt *pdpvt, int P1, int P2, char **P3){
> 
>   struct aiRecord *pai= (struct aiRecord *)pdpvt->precord;
> 
>   double meas;
>   sscanf(pdpvt->msg,"%lg",&meas);
>   printf("meas %f\n",meas);
>   printf("Messge Length %d. Msg %s\n",pdpvt->msgInputLen,pdpvt->msg);
>   meas = (double)atof(pdpvt->msg);
>   printf("meas %f\n",meas);
>   pai->val = meas;
> 
>   return 0;
> 
> }
> 
> I set:
> 
> asynSetTraceMask("L0",-1,0x9)
> asynSetTraceIOMask("L0",-1,0x2)
> 
> in my st.cmd to do some debugging. When I force one of my voltage measurement records
> to process the first time I get:
> 
> epics> dbtr AG34970:VOLT:Coil
> epics> 2010/08/06 15:39:30.848 172.25.100.85:1234 write 32
> MEAS:VOLT:DC? (@203)\n++read eoi\n
> 2010/08/06 15:39:31.011 172.25.100.85:1234 read 17
> +2.99865210E+00\n\003
> meas 2.998652
> Messge Length 15. Msg +2.99865210E+00
> meas 2.998652
> 
> This is exactly what I expect since I'm supplying the MUX with 3 V at Channel 203. So far
> so good. When I print the record I get:
> 
> epics> dbpr AG34970:VOLT:Coil
> ASG:                DESC: Coil Voltage  DISA: 0             DISP: 0
> DISV: 1             NAME: AG34970:VOLT:Coil                 RVAL: 0
> SEVR: INVALID       STAT: UDF           SVAL: 0             TPRO: 0
> VAL: 2.9986521
> 
> My first newbie question is why is SEVR: INVALID? The VAL is certainly what I want it
> to be. The problem occurs if I try to process the record more than once:
> 
> epics> dbtr AG34970:VOLT:Coil
> epics> 2010/08/06 15:39:49.785 172.25.100.85:1234 write 32
> MEAS:VOLT:DC? (@203)\n++read eoi\n
> 2010/08/06 15:39:49.948 172.25.100.85:1234 read 17
> +2.99867890E+00\n\003
> meas 0.000000
> Messge Length 16. Msg +2.99867890E+00
> meas 0.000000
> 
> Hmmm........an ASCII string indicating an appropriate value is read but converted into a
> double of 0.0000 . Note the message length has increased by 1. Its as if a hidden character is
> appended somewhere that screws up the sscanf and atof functions. Perhaps there is a more
> error proof way to convert ASCII to doubles? Has anyone seen this before? I have no such
> problem with my stringin record. I can send *IDN? and read the device name reliably.
> 
> Thanks very much for your help. I will happily make any device support I get working
> public.
> 
> Cheers,
> 
> Andrew Wagner
> 
> 
> 
> 
> 
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System