Experimental Physics and
Industrial Control System

Andrew Wagner <[email protected]> · Sat, 7 Aug 2010 16:43:49 -0700

Thanks Mark, 

I figured out the problem and you're right the PROLOGIX GPIB-Ethernet controller was set to send a terminating \003 that was not cleared from the buffer after the first read. Sending ++eoi 0 to the controller eliminates this problem as would flushing the buffer as you suggested. Thanks for your help. 

Andrew

On Aug 6, 2010, at 5:38 PM, Mark Rivers wrote:

> I suspect this is the same problem I recently fixed (in R4-14) in asyn.  When devGpib does a write/read operation it should really do flush/write/read so that it first clears the input buffer of any stale input characters.  That fix was applied in asyn R4-14.
> 
> Try setting 
> 
> asynSetTraceMask("L0",-1,0xFF)
> 
> so you get additional debugging.  I suspect that perhaps your device is sending additional information at the end of the first response, which is then being read at the beginning the second time you read it.
> 
> Upgrading to to R4-14 may fix this for you.
> 
> Mark
> 
> 
> 
> 
> 
> ________________________________
> 
> From: [email protected] on behalf of Andrew Wagner
> Sent: Fri 8/6/2010 6: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