VISA Locking up Labview NI Spy results

[Earl.Bell]

I have a vi that is sending commands to a HP35670A Digital signal analyzer and every once in a while Labview locks up during execution.

The vi sends commands for each trace in a while loop.  Each trace is read during the same loop iteration but not sequentially.

I managed to finally get it to lock up (only happens intermittently) while NI Spy is running but I don't understand the log output.

Can someone decipher the log for me and tell me what has happened so I can fix the problem?

The crash happens in the last few lines.  As you can see from the log it should just keep repeating the same cycle but I get this viWaitonEvent that seems to come out of nowhere then the program locks up.


Any help would be greatly appreciated.

(i'm working on creating an example of my vi.  Its rather complicated and I'm still kinda new to this)




Message Edited by Earl.Bell on 01-22-2008 01:52 PM

Message Edited by Earl.Bell on 01-22-2008 01:53 PM

[Earl.Bell]

Here is the VI that i call in a while loop.  I actually have four of these in the same while loop being read "at the same time" (ie non sequential).
This VI does the communicating with the DSA.

[Ted_H]

Hi Earl,

I took a look at your NI-Spy capture, however i don't see any errors being reported by your device or the driver, so I can't say with confidence what is causing your application to freeze.  Looking at your code, there are somethings missing that may be the cause of your errors.

First, include VISA session open and close functions, this will correctly open a VISA session to you instrument.  Also, can you explain how you are iterating your code, are you just hitting run repeatedly? I would recommend using a while loop.  A good resource for instrument control are the shipping examples included in LabVIEW.  Check out GPIB VISA and LabVIEW GPIB examples in the Hardware Input and Output>>GPIB folder.  Try  using your commands with these examples.

Lastly, there is an instrument driver available for your device on the instrument driver network at ni.com, here is the link.  This driver will give you access to you devices functionallity through LabVIEW.  If you have any additional questions, please feel free to post back.

Cheers,

Ted

[Earl.Bell]

Hi Ted,

I am calling that VI within a while loop.  I'm actually calling the same VI 4 times in the while loop. 

I took your suggestion and included an open and close in the VI and still get the same problem.

I have downloaded those drivers already, but I had a difficult time finding ones that would do what I need.  Seeing as I already knew the string commands to send the DSA the VISA writes seemed easier to implement.

Thx for your response,

Earl Bell

[Dennis_Knutson]

You are calling the same subVI 4 times in parallel? That's going to cause some problems with GPIB communications.unless you are doing some locking. The GPIB bus does not support parallel operations. One instance of the subVI might be sending a write for channel x, then another instance might send a write for channel y, while a third instance is expecting a read from channel z. You should look at using the VISA Lock/Unlock. There's a shipping example that should help. You want to make sure that each subVI starts and finishes sending the commands and queries before another call starts.

p.s. You should wire up the error in/error out connections!

Message Edited by Dennis Knutson on 01-23-2008 08:34 PM

[Earl.Bell]

I was under the impression that even though they are being called in parallel, LV only runs one subVI at a time.  That it halts execution in the calling program until the subVI is finished.  Your saying that this is not the case?

I'm still a novice with LV so I don't really understand its execution order for these kinda things.

I have added an open and close at the beginning of the subVI and changed the number of bytes read.

Since changing the number of bytes being read I have not had a crash.  I was previously reading 1000 bytes as I couldn't find anywhere in the DSA manual to tell me what the outputs were size wise for each command.  I finally just used LV to view the actual ouput and count the characters.  This seems to work. For now 😛

I've also wired up the error lines for the VISA controls, thanks for the suggestion Dennis.

Here's a copy of my updated VI.

[Ted_H]

Hi Earl,

So LabVIEW uses data flow to control order of executions.  A VI node (or subVI) will execute once all the inputs to that node have been received.  Consequently, when two vi nodes receive all the inputs simultaneously, they will execute in parallel. Turn on highligt execution (click the lightbulb on your block diagram tool bar) to see how your code executes.  Also, here is a link to an article that explains data flow in greater detail. 

I'm glad you were able to get your application up and running.  Like Dennis said, I would also recommend using the GPIB communication shipping examples as a starting point for your application.

Ted

[Dennis_Knutson]

Putting the VISA Open and Close inside the VI is not the best way to do things. You should only need to do it once, in the main. Also, Changing the number of bytes expected should not have any affect. The standard for GPIB instruments is that EOI is asserted when the data is complete and a VISA Read will terminate as soon as EOI is detected. Therefore, if for example an instrument returns 100 bytes, it should not make any difference whether you specify 100, 1000, 10000, or any other number. I still think the best way for you to get maiximum performance and reliability is to use the VISA Lock mechanism.