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

[SaintsFan]

I have a problem with a Labview program I made. I have two programs that do the same thing. One is in flat sequence form and the other is in state machine form.

As explained in the link below, I would like to make use of a microcontroller to make wiring connections for automating a measurement process. A separate current source and volt meter will be used.

https://forums.ni.com/t5/LabVIEW/Sequence-a-good-idea/td-p/2601333

I have since made some simple test programs which I have attached. The problem is when executing, the labview program will hang, but not every time the program is execute.

For example: Hall 1.2.vi will work properly twice with the third time it is executed it will hang. If you abort and try again, it will again run twice with no problems with the third hanging. This one is in flat sequence format (was in a flat sequence, but merged the windows because I thought that was the cause). From what I can tell, the program will hang when calling Keithley 6517 Single Read.vi. Both connected Keithley devices are connected to the computer via GPIB at 16 and 27. The way I verified if it was this vi causing it or contributing to it was that I removed it and the program never hung. I find it very strange that it will hang exactly on the third attempt every time.

Hall 1.3 simple.vi will work the first time and hang the second time. So it works 50% of the time. This one is in State Machine format. This one will hang at the case titled "Measure 1" which contains the Keithley 6517 Single Read.vi.

I've used the highlight execution button and watched the program run. Oddly, it doesn't hang when using this button. So I tried adding delays/wait in different places to no avail.

What could be causing this? As a side note, I say the program hangs for two reason. The main one is the program doesn't finish running so the run arrow is still black. The second thing is that if you notice at the end of the labview program, I have a block there that turns the current source off which doesn't happen when it hangs. I have to manually turn it off and then hit the abort program button to stop labview.

[altenbach]

What is the point of the seqeunce structure in Hall1.2? Seems purely decorative, because it does not have any useful function. (the delay runs in parallel to the rest of the code).

You need to find out where it hangs. The reason is most likely in one of the driver VIs (that I don't have). Maybe you need small delays between calls. (You did not say how you added delays. Can you clarify what you tried?)

Hal 1.3 will never give you any useful output, because the exit case has the output tunnel for "measurements" unwired. That indicator belongs into the "Measure 1" case or you need to keep the measured data in a shift register.

[SaintsFan]

---

@altenbach wrote:

What is the point of the seqeunce structure in Hall1.2? Seems purely decorative, because it does not have any useful function. (the delay runs in parallel to the rest of the code).

You need to find out where it hangs. The reason is most likely in one of the driver VIs (that I don't have). Maybe you need small delays between calls. (You did not say how you added delays. Can you clarify what you tried?)

Hal 1.3 will never give you any useful output, because the exit case has the output tunnel for "measurements" unwired. That indicator belongs into the "Measure 1" case or you need to keep the measured data in a shift register.

---

Thanks for the reply. Currently the sequence in 1.2 is purely decorative. Previously the blocks were broken up similar to the state machine one in 1.3. I merged the windows in an attempt to figure out and hopefully fix what was causing it to hang. Eventually, it turned out to be a decorative sequence so that should just be ignored.

The same goes for the unwired output in hall 1.3. At this point, I'm just trying to figure out why it's hanging on a set interval. After I can figure out what is causing it and correcting it, I can move to finishing the program and actually worrying about outputs.

Also, I've tried placing wait/delays at various places with no improvement of the problem. My next thought is to just remove all the vi calls and have everything in one program.

[altenbach]

---

@SaintsFan wrote:

Also, I've tried placing wait/delays at various places with no improvement of the problem. My next thought is to just remove all the vi calls and have everything in one program.

---

How did you place the waits?

Why would placing everything in one program fix the problem. That makes no sense! What is your reasoning?

[SaintsFan]

---

@altenbach wrote:

---

@SaintsFan wrote:

Also, I've tried placing wait/delays at various places with no improvement of the problem. My next thought is to just remove all the vi calls and have everything in one program.

---

How did you place the waits?

Why would placing everything in one program fix the problem. That makes no sense! What is your reasoning?

---

In the case of hall1.3, I placed a wait in the Measurement cases and CS On cases and there was no affect. In the hall 1.2 when the blocks were broken up similar to the state machine cases where each sequence window was identical to the cases, I placed a wait or delay in each window with no effect on the hanging.

My reasoning for placing everything in one program is the same as my reasoning for figuring delays would help, since the time of execution would be altered. If the execution time is faster and if the timing is the problem then I figured that the problem would happen more frequently or even every time.

Somehow I get the feeling this is not the case. The reason being the interval in which it succeeds or hangs is constant. I believe somewhere, a value is getting set. The 6517 Read vi runs fine if I run this vi by itself no matter how many or how fast I run it. Also, the same goes for both 1.2 and 1.3 if I remove the 6517 read vi they run fine no matter how fast or how many times I run them. 

Somehow after the current source is set to operate and triggers labview will hang on a set interval when calling 6517 read vi.

Separately they work, together there is a problem. I tried placing a delay between these two by connecting the error out of the trigger vi to the error in of the delay block and the error out of the delay block to the error in terminal of the 6517 config block. I've also tried delays between other blocks connected the same way. From what I understand, a called vi can't execute until all inputs are present. Is this the correct way to wire the delays?

[altenbach]

If the code works under execution highlighting, it means you need delays. Maybe the delays are not long enough or they are not placed in the right location.

---

@SaintsFan wrote: I tried placing a delay between these two by connecting the error out of the trigger vi to the error in of the delay block and the error out of the delay block to the error in terminal of the 6517 config block. I've also tried delays between other blocks connected the same way. From what I understand, a called vi can't execute until all inputs are present. Is this the correct way to wire the delays?

---

A small picture would explain it much better that 1000 words ever could.

[SaintsFan]

I've attached an altered Hall 1.2.vi showing how I placed the delays before when I was trying to fix the issue. Please check this out while I go downstairs and re-verify that I can indeed run it in highlighted mode with no problems. It was late last night so my memory is a little fuzzy.

Hall 1.3 simple.vi also shows how I placed the delay in the measurement case.

[SaintsFan]

Alright, I've just checked again and it appears I was mistaken. Highlight mode on hangs on the third run of the program for Hall 1.2. I see the inputs arrive to the 6517 read vi shown in the attached picture. When it hangs there is no outputs that leave from this vi. On other runs I see the inputs enter and leave this vi, except every third time where it hangs there. Just to clarify, when I say hang, I mean that the inputs flow to the called vi, but nothing leaves the outputs in highlight mode. If it continued correctly it would eventually reach the vi that turns the current source off.

[Yamaeda]

It's not the same sub-vi's, so you need to open it and see what's happening inside, possibly it's missing or flush away the correct answer and then wait forever for it ...

It could also be a case of erroneous serial setup causing the 3rd command to be corrupt. Typically parity, flow control or stop bits can result in the 2nd or 3rd command being corrupt.

/Y

[SaintsXLIV]

---

@Yamaeda wrote:

It's not the same sub-vi's, so you need to open it and see what's happening inside, possibly it's missing or flush away the correct answer and then wait forever for it ...

It could also be a case of erroneous serial setup causing the 3rd command to be corrupt. Typically parity, flow control or stop bits can result in the 2nd or 3rd command being corrupt.

/Y

---

Could you please clarify? I don't understand what you mean by not being the same sub-vi's. I tried to run highlight mode for each of the sub vi's individually, but there are no problems of hanging. Also, as I mentioned before the program will hang every third run for Hall 1.2.vi. Only after removing the call for 6517 Read.vi will the program run without hanging on the third run. It ran 20/20 if I removed that vi, otherwise it will hang every third.

I'm unsure how the information could be flushed away or missing only some of the time not every time.

Here's one question I have though. If you notice in the program, there's a config vi for the 237 that executes first then the 237 vi is used to operate the current source. Likewise, the 6517 config vi is executed prior to the 6517 vi that controls the measurement. The necessity of these config vi's are obvious for initializing the equipment, however, is this needed for each run or only after the first time the equipment is turned on?

Your 2nd comment about erroneous serial setup sounds like something of interest. Could you elaborate? Also, this serial setup you speak of, is that GPIB?