gpib write or read sometimes hogs cpu

[rmshelby]

I have written a simple vi to communicate and control a Stanford Research SR640 programmable filter.  It does a series of gpib writes and reads to get and set various controls on the instrument, and it works very well.  The problem comes when I try to call it from a more complex vi that controls the entire experiment.  Once the sr640 vi is linked into the big vi, it takes 10-20 seconds for the sr640 vi to return and it hogs the cpu, making even the mouse unresponsive, Windows task manager stops updating, etc.  This happens even when running the simple sr640 vi directly from its front panel with no other vi's executing.  In "lightbulb" mode, I can see that occassionally, the gpib write or read icons (from traditional gpib pallette) take a long time to return, and the cpu goes to 100%.

If I remove the complex calling vi from memory, the problem goes away, ie the sr640 vi runs fine.  If I load the big vi back into memory, I reproducibly get the bad behavior when running the sr640 vi. Note that the big vi does not need to be running to cause trouble, only be loaded in memory.   If I delete the sr640 vi from the big vi, i.e. it is no longer called from the big vi, the sr640 vi again runs fine.

Any idea what might be happening and how to go about debugging this?

Thanks,

Bob Shelby

[smercurio_fc]

Does the same thing happen if you place the sr640 VI in a new VI? Can you show us what the sr640 VI looks like?

[rmshelby]

Thanks for the reply. 

Attached is the SR640 vi and a calling vi that works just fine.

Bob 

[JÞB]

GPIB is a wonderful thing!

For instance- it wll poll for data on a handshake line if data is not ready and consume a lot of resources on older CPUs (until such time as TMO expires).    Is there another pollingg method you could use?  SRQ on OPC?  Add a delay?.....

[rmshelby]

Thanks Jeff,

I think something like this is essentially what is happening.  Playing with ibic, I could not get this instrument to request service in any way that made sense, so yes, I put in a delay between each gpib operation.  The thing I don't understand is this:  when the srs_filter_setparms.vi is run by itself or run by the simple test_sr640.vi I posted, about 10-15msec delay is needed to prevent the vi from pegging the cpu (which is a 3GHz P4), and the vi runs fine with this delay setting.  But if I run it from my more complex vi that controls the entire experiment, the necessary delay is at least 2 seconds.  

Why should that be?

Bob

[smercurio_fc]

Let me guess: the complex VI is in the same library as the "srs_filter_setparams" VI, right? If so, what happens if you remove the complex VI from the library?

Side notes:

• Do not wire a value to the N terminal and autoindex - do one or the other. In your case, simply autoindex your array of strings.
• You should be using VISA for new code, rather than the old GPIB functions.
• I would strongly recommend either using the "Time Delay" VI or write a simple wrapper around the "Wait (ms)" function with an error in and error out so you can elimate that sequence structure you have in the code.

[rmshelby]

You are correct, they were both in the same .lvlib.  So, I removed them both from the library, restarted labview, but I still have the same problem behavior.  I can load the srs_filter_setparms and it runs fine.  I load the complex vi, it runs fine.  As soon as I insert the icon for the srs_filter_setparms into the block diagram of the complex vi, then run srs_filter_setparms from its front panel, it exhibits the problem of pegging the cpu. 

Thanks for your other comments as well.  Will rewriting this using the VISA api do anything to avoid the problem I'm having?

Thanks,

Bob 

[rmshelby]

So I tried recoding it with VISA, and it improved matters.  It still pegs the cpu sometimes, but maybe only 1 out of 5 times instead of every single time.

Does this point to anything further I could look at?

Thanks for any ideas.

Bob

[Mr.F]

I notice that you don’t have complete error handling in your program. Can you add a simple error handler to the output of the shift register on the for loop (or an error in control and an error out indicator)? That can help you determine what is going wrong in the program. Also, the “bad behavior” that you mention, does the subvi return the correct values? Default values for the indicators?

[rmshelby]

The subvi does return correct values, as long as the timeout is long enough for it to finish.  There are no errors returned, with the exception of timeout.

Bob