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.  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

[ColeTrain]

Hello Bob and welcome to the forums,

From your complex VI, are you doing any other writes or reads?  Can you run the complex Vi without the GPIB writes and reads? What does it do then?

This sounds like it could be a race condition or perhaps a use of a shared resource.  I will also recommend posting this issue in the LabVIEW forum asthat board gets a larger number of views and you might find more advice from over there.  

[rmshelby]

Thanks for the reply. 

There are two other instruments on the gpib, and they're both working ok with the big vi.  The strange thing is that the complex vi does not need to be running, only loaded into memory to make the sr640 vi hang, so there shouldn't be and competition for resources, true?

Bob

ps will post in the LabView forum as you suggest.  I'm new to the forums and haven't explored very much yet.

[ColeTrain]

Hello Bob,

You are absolutly right that it shoudn't hang with the VI only loaded into memory.  That does sound like odd behavior, and I hope the LabVIEW side of things is able to help you out.  Could you post either your code or some screen shots of your code of both the large and small VIs so that we can take a look on this forum?  Perhaps we will be able to offer you some insights here.

[rmshelby]

Cole,

The folks in the LabView forum have offered some suggestions, but so far nothing has helped resolve this.  

OK, so here's the vi: srs_filter_setparms.vi

A simple vi that runs the filter vi in the same way that my big program does: test_sr640.vi

and a couple screenshots of the big vi.

Thanks for the attention.   At this point the relatively simple work-around is to remove this filter vi from the big vi and just run it separately.  This will take care of most of my needs.

Bob

[rmshelby]

The front panel:

[Mathan]

---

rmshelby wrote:

ps will post in the LabView forum as you suggest. 

---

Here it is for reference