I use a Keithley MUX and a DVM to measure different values in my system, including 4 wire resistance. My project runs for several hours without any problem, but last night I have got an error after approx. 8 hours runtime. My error out in the main vi shows the following error:
GPIB Write in A_4Wire_resMUX_2!1,2!3,2!5_new.vi Error code 6.
I have attached this subvi, as you can see, I have put a while loop in the subvi, to give enough time for the 4Wire measurement to be done. But of course maybe another GPIB write function crashes in the subvi, not the one after the while loop.
I have 2 questions:
1. what is the best way to do error handling in GPIB comm., so I could see on my final error out what element caused the problem in this certain subvi?
2. Can someone show me what I could do better in this subvi, to avoid possible GPIB errors?
Its just guessing, but I think the error comes from that I may not give enough time to the GPIB device to perform an action, so the next GPIB write crashes?
plus info: WindowsXP, LabView 2010 Full version
Thanks very much for advice and help!
Solved! Go to Solution.
Now that you have a modern version of LabVIEW why are you not taking advantage of the instrument driver network? VISA is wonderful and the raw 488.2 primitives should be considered "obsolete".
Since you did not use the specific instrument driver vi's we can't tell which write to what device generates the error you are seeing.
So to specifically answer Q1. Use the Driver's found on the instrument driver network- they are tested and structured in ways that assist in debugging your application and take advantage of powerful features in VISA..
And 2) (see #1) and change the stacked sequence into a state machine
Just a note, I have put a 10ms wait timing in the while loop what asks weather the Keithley is ready or not with measurement, and my VI is running now without errors for several days...
But of course next time I will use VISA drivers...