LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabView Program Error

HI!
I get a spradically error while executing my LabVIEW VI. I couldn't really figure out on what it depends. I'm using 6.1 with Win 2000 Prof. Furthermore, I'm using Keithley GPIB Hardware (2400, 7002). Cold this error have anything to do with the drivers for the Keithley software? Or could it be a problem regarding windows? Or could it be a problem in my prgraming?
In my main VI I call various number and order of subVIs dynamically. Maybe that causes Problems. I'm getting a Error message as attached and then a Error Log (DrWatson) is created. I'll attach this log file, too. Does anybody knwo how to analyze the log file? Are there hints what could be the cause of the error?
Thanks.
ANDY
0 Kudos
Message 1 of 11
(4,205 Views)
When you get these errors, are you also seeing errors pop up on the screen of the keithley? And what drivers are you using for the Keithley? I've noticed that if you get errors internal to Keithley unit, and you are using the IVI drivers, Labview will shut down the IVI session and you will see errors in LabVIEW. If you can give me more details I will try to give you more feedback.
0 Kudos
Message 2 of 11
(4,179 Views)
Thanks for your answer!

I'm using the latest software drivers as you can download them on the keithley webpage:
2400: 24xx-850cv2[1].0.exe (24xx Family VXIPnP/VISA-based Driver for VB, C/C++, LabVIEW5.1 or higher and LabWindowsCVI(v5.5)(17Mb))
7002: kei7002.llb

As far as I have discovered, there are no error displayed on the periphery when the window error message pops up and LabVIEW is shut down.

I'm not a 100% sure but it seem to me as it happens more often that LabVIEW will be shut down if I first use the device as a voltage source and then as a current source or the other way round. But it definitely works sometimes. So I'm not sure if the parameter to initialize the 2400 and the parameters set to change the source mode are involved in this problem.

ANDY
0 Kudos
Message 3 of 11
(4,158 Views)
What versions of NI-488.2 and NI-VISA are you using? It is usually best to try the latest versions when experiencing problems like this.

Shawn B.
National Instruments
Use NI products on Linux? Come join the NI Linux Users Community
0 Kudos
Message 4 of 11
(4,128 Views)


@Shawn B. wrote:
What versions of NI-488.2 and NI-VISA are you using? It is usually best to try the latest versions when experiencing problems like this.

Shawn B.
National Instruments


HI Shawn,

so far I don't think that this had something to do with the drivers. As I already pointed out, I have a main program from where I dynamically called different sub vi's in a from the user randomly chosen order or number. I appears that the "call by reference" caused the trouble, so LabView messed something up in the memory and exited.
I had already this thought in my fist post, but now I actually replaced the dynamic calling of the sub for every VI and it seems to work fine. Therefore I won't recommend using the "call by reference" for several different Sub VIs.
What do you think what the actual problem could be?
Best Regards
ANDY
0 Kudos
Message 5 of 11
(4,123 Views)
HI Shawn,

I checked out the versions I'm using:
NI VISA 2.6.0f7
NI VISA Server 1.0.0.f4
NI 488.2 1.70
NI IVI Engine 1.83

what are the latest versions that are available?
ANDY
0 Kudos
Message 6 of 11
(4,107 Views)

Andy,

The Call By Reference Node uses ActiveX to dynamically call the sub VI. So it is possible this is an ActiveX issue. Also were you closing your reference after the Call by Reference Node? Check out the "Dynamic Load Example.vi" in the LabVIEW examples to see the Call by Reference Node in use. Maybe this will help.

There are newer versions of the drivers available. They can be found here. You should verify the newest version of the driver that can be used with your GPIB board first. 

Shawn B.
National Instruments

Use NI products on Linux? Come join the NI Linux Users Community
0 Kudos
Message 7 of 11
(4,098 Views)
Shawn,

"Dynamic Load Example.vi" with my vi they are identically in the way they are programmed. I did close the reference after the call by reference.
At the moment I'm using my version of the main VI without any dynamic calls. This seems to work fine, but I'll try to get the other version to run, too. I downloaded the newest Version of the GPIB driver (2.3) and the VISA driver (3.2) I couldn't find anything regarding the VISA Server.
Regarding the IVI Engine 1.83 it is very unclear if there are updates or not or if they could be used or not. Is there an update? I only read that some newer stuff is not compatiple to that 1.83 Verion.
Any other driver should not be a concern regarding this problem?

ANDY
0 Kudos
Message 8 of 11
(4,088 Views)
Andy,

There are newer versions of the IVI Engine, but I do not think that they will fix your problem. You can try turning off multithreading, to see if this fixes the problem as well. In LabVIEW go to Tools >> Options >> Performance and Disk, and uncheck Run with Multiple Threads.

Is there a specific reason why you are trying to use the Call by Reference Node?

Shawn B.
National Instruments
Use NI products on Linux? Come join the NI Linux Users Community
0 Kudos
Message 9 of 11
(4,063 Views)
Hi Shawn,

There was no specific reason why I was trying to use the "Call by Reference" Node. It seemed to me to be a very elegant way to call sub VIs and have only that VIs in the memory that are currently running.
Besides that it appeared to be very helpful that the I was able to work on the SubVIs even while the Main VI was running. Now that I'm working with the static calls I realize that that this was very very comfortable. I do have to exit the running Main for every change on every single SubVI.

A big problem with the "Call by Reference" as far as I encountered it is to create a .exe as you have to add all your dynamic files and subVIs beloning to the dynamic files by hand and file by file.
0 Kudos
Message 10 of 11
(4,053 Views)