Labview Program will hang between 33% and 50% of the time.

[Yamaeda · Accepted solution]

Maybe i misunderstood, but from the picture it's several different 6517-functions called. Did you refer to 3 loops, or this 3rd function?

Either way, you need to open and run it in Highlight and Retain-modes to see what's actually wrong the 3rd time, and my guess is some serial setting showing up on the 3rd time, or possibly some dirt character which needs flushing before sending command and reading result.

/Y

[SaintsFan]

Yes there are I believe a total of three 6517 sub vi's that are called. Also, there are sub vi's for 237, and the arduino.

It's not really a loop per say. What I mean is I click the run program button and the entire thing runs and then stops by itself. On the third time running it hangs. The location where it stops at is the vi after 6517 config block. I think it's called Read or single read.

I'll be able to check it tomorrow when I go to the lab.

[Yamaeda]

---

@SaintsFan wrote:

Yes there are I believe a total of three 6517 sub vi's that are called. Also, there are sub vi's for 237, and the arduino.

It's not really a loop per say. What I mean is I click the run program button and the entire thing runs and then stops by itself. On the third time running it hangs. The location where it stops at is the vi after 6517 config block. I think it's called Read or single read.

I'll be able to check it tomorrow when I go to the lab.

---

So, how do you start and stop the program, and do you reserve/free resources in a good manner? Stopping with Abort, e.g. can leave the com ports open, preventing further use until you restart LV.

/Y

[SaintsXLIV]

I use the run button to start the program. The abort button is only used when the program hangs. If the program hangs, I push the abort button and manually switch the current source into standby. Following that, the program can run to completion twice before the third run hangs again.

When the program starts, it sends the command to set a pin on the microcontroller to high. Next it initializes the current source, sets it to operate, and then triggers. Then, the volt meter is initialized, and the command to take a measurement is sent after that.

Reserve/free resources: I'm using the vi's acquired from the Find Instrument Drivers under the Labview help menu. These vi's do all the reserving and freeing of resources unless there was some mistake built into them.

When the LV hangs, I do not have to close all of LV itself, so there's shouldn't be any problems with the ports. If it hangs I use the abort button only. The program successfully runs twice again after that.

[AKA_TG]

Im sorry if I jmissing something already mentioned  but usually when using I/O to a device (any device on any bus using Visa calls)

I always (if at all possible)  flush my buffer before asking the device to transmit characters to me. It takes extra time no doubt but can

help make something more reliable.

If your device is somehow waiting for a special termination character from the last handshake f if your program somehow gives the device an extra character it does not understand, then it will definately hang and never send anything back.

.

[SaintsFan]

By visa calls do you mean where I am writing to the arduino? If this is what you are talking about, how would I flush the buffer? From what I can tell the program hangs at 6517 Read.vi on the third run of the entire program which is from the labview instrument driver downloaded package.

Any idea of how to clear whatever buffers there are for the instrument drivers.

[Yamaeda]

Check the Visa palette, there's a Flush buffer. Insert it before the Read.vi and see if it helps. 

/Y

[SaintsFan]

Just an update on the situation with the program hanging. After following your instructions for running with highlight on and retain values, I've identified the exact location where the program get stuck. As expected it was the 6517 Single Read.vi that was called within the program. Inside the program it hangs inside the case structure shown in the picture at a Wait for GPIB RQS block. There is a zero constant wired to the timeout ms input.

Timeout ms input specifies the time, in milliseconds, that the function waits before timing out. To disable timeouts, set timeout ms to 0. The operation aborts if it does not complete within timeout ms.

Since a 0 was wired to the input, the operation aborts if it did not complete immediately. I changed the zero to 500 ms and ran the program many times without any more hanging issues. 

I have run a few test measurements and have discovered a problem with the accuracy of the readings and will create another thread to address this so that another accepted solution may be earned on that one as well.

Thank you all for the help and I look forward to your assistance with working out the bugs in the next problem.

Attached is a picture highlighted where the problem was inside the Single Read.vi

[altenbach]

Now all you need to do is get rid of that annoying stacked sequence. Start here.... 😄

[SaintsFan]

Thanks, fortunately it's not my stacked sequence. It's the vi written by Keithley folks for this instrument driver package. I believe I will have to contact them regarding their Single Read.vi retrieving incorrect measurements from the 6517. The measurement is off by an entire decimal place plus a few millivolts off the value.