GPIB Error when Sending Scan Buffer from SR245

[N.Wells]

Hi.

Im trying to write a data collection routine that will talk to a Stanford Research SR245 A/D converter  using GPIB.
I have written a simple test VI to troubleshoot  the actual data collection VI.

The test VI works as follows.

The SR245 is set to Channel 1 input I=1, Sync Mode using MS, and the GPIB SRQ mask is set to respond when a scan is finished SM=16
The VI then goes to a FOR Loop. Inside the FOR loop the  SR245 is asked to scan channel 1 for 100 triggers (SC1:100).  Then the Wait for GPIB RQS is used to check when the scan is finished. The poll response from the SR245 is 112 indicating that: bit 6 on SRQ, bit 5 on Trigger recieved, bit
4 on Scan Finished.
Then the loop uses the Labview VI SR245Scan.vi, provided by, NI to dump the scan buffer from the SR245 into a Labview array.
SR245Scan.vi sends the X command to the SR245 and then reads the response using GPIB read.

The last part of the loop is  a Wait milliseconds command. I have been setting this to a high number (~1000) for debugging.

Here is the problem.
The loop will execute fine for a period of time and then randomly will cause the SR245 to lock up. Then green activity led on the SR245 stays on continiously and it no longer allows any GPIB communication .

What seems to be happening is that SR245Scan.VI some times will  time out.
I have noticed this by keeping this vi open while I run my test VI.
Every time the loop  completes with out a problem, the SR245Scan.vi run button flahses indicating that it wall called and completed.
When there is a problem the SR245Scan.vi run button will stay on and the ReadGPIB module will come back with an error.
The error is #6, which from what I can find tells, me nothing about why this happens.

Also to get this out in the air,
I have talked to tech support at SRS.
It is not a triger rate problem, as I am collecting only one channel and triggering
at 200 Hz.


Any Ideas?
thanks,

Nathan Wells
University of Minnesota
Physical Chemistry Graduate Student.
 

   






 
 

[Emilie S.]

Hi Nathan:

While this loop is executing are you getting the data that you expect?  How long does the loop usually execute?  Does it seem to be the same amount of time or the same amount of iterations of the loop whether you put the 1000ms wait or not?  Have you tried running an application example?  If so do you see any issues with it?

Regards,

Emilie S.

[N.Wells]

When the loop executes the expected data is transfered.  The loop will excecute fine for a random number of times. If I ask for 100 iterations it usually completes without issue. If I ask for 200 iterations it might execute fine for 199 iterations and have a random GPIP read error 6 some where in there.  Some times it is more like 3-5 read errors in 200  iterations.

Just to update I have also put in wait_ms (~50 ms) commands before any GPIB read or write commands in the loop. This seems to help the SR245 from  completley sezing and not accepting any more GPIB write commands. In this case I will get a rouge  (0) data point returned, but the loop will continue.

The application example SR245Scan.vi is part of the loop and is the PROBLEM.  I  have even modified  it to have wait _ms commands before  the
GPIB write (which sends the 245 the command X, which instructs it to dump its data buffer) and the GPIB read which should read the data buffer coming over. This GPIB read is the one that keeps giving me problems; it seems to time out.
The SR245 does not like it when there is a time out  on the X command.

Now it seems like I might just bite the bullet and put in some error checking routine to exclude the rogue points and redo the loop, but typically my real experiments may collect  a single trace with 500 data points and will average 6-10 scans.  This causes a problem in that the SR245 will be asked to  complete 3000-5000 iterations of SCAN the Input Channels and Dump the Data, and I usually get the SR245 to lock up if I try this many repeats.

Nathan.









 

 

[Emilie S.]

Hi Nathan:

This really sounds like some sort of timing issue.  Have you tried running the code for an extended period of time in highlight execution mode?  Do you still get an error?  What about putting large timeouts inbetween sending the X command and then reading the buffer?

Regards,

Emilie S.