While-loop stops unexpectedly

[kper]

Hi,

I have a problem with while-loops in one of my programs.

I am using a consumer/producer architecture with several while-loops. The problem is, that 2 of them will just sudddenly stop.

Originally I had the terminating clause connected to the error of the queue that connects the loops. However there was no reason for an error there.

So I tried connecting the terminating clause to a boolean constant. The result is, that they work fine for about 5 minutes and then again just suddenly stop (as before).

Does anyone have an idea how this could happen? Is there anything except for the terminating clause that will stop a while-loop?

I'm looking forward to your answers

Greetings

[NitzZ]

Hi,

Can you post your code? 

Regards,

Nitzz

[kper]

Sure I can.

As it does need to connect to several gadgets it will probably not work on your computer but maybe it'll still help.

The loops that will terminate are the 2nd, 3rd and 6th from the top.

I know the program is not very well or nicely written. But since it is my first one ever and pretty complicated I am still kind of proud that (at least for the first 5 minutes)

it does what it should.

So if there are suggestions to improve the style, I'll be glad. Just please keep in mind that I am kind of new to LabView.

The green Sub-VIs all just call .dll files, others are pretty hughe as well. However all of them are working fine, asI have tested them with a different version of "Hauptprogramm" and it all worked fine.

Greetings

[kper]

Sure I can.

As it does need to connect to several gadgets it will probably not work on your computer but maybe it'll still help.

The loops that will terminate are the 2nd, 3rd and 6th from the top.

I know the program is not very well or nicely written. But since it is my first one ever and pretty complicated I am still kind of proud that (at least for the first 5 minutes)

it does what it should.

So if there are suggestions to improve the style, I'll be glad. Just please keep in mind that I am kind of new to LabView.

The green Sub-VIs all just call .dll files, others are pretty hughe as well. However all of them are working fine, asI have tested them with a different version of "Hauptprogramm" and it all worked fine.

Greetings

[PaulieQ]

What you did is not huge is enormous.

You can do 99.99% from all the LabView programs with 2 while loops - like in attachment.

I recommend you start everything from the beginning using: - only two while loops, cluster to organize data, making sub-vis,  etc. If you continue with this VI you will lose a lot of time when you have to debug or modify something.

[WayneS1324]

Are you sure the loop is stopping and a dequeue isnt just waiting for data?

I looked at the code for a minute but got tired of scrolling around the screen.

But my first program was a monster too.

[NitzZ]

Hi,

Even I would recommend what PaulieQ has said. 

Regards,

Nitzz

(Kudos are always Welcome;))

[kper]

Hi,

thats exactly the kind of comments I expected!

And I know that you are right, however I am doing this for my Bachelor and am slowly running out of time, so starting all ovger again is really not the solution I had hoped to get.

Considering the comment, that everything in LabView can be done in 2 while-loops: Thats what I started with, however it had worked out, that the program got to slow, as I need to do quite a lot of evaluating of pretty big pictures with 90 frames. The limiting factor here are the 2nd and 3rd loops, which will only manage to run about 80 times a second, which is e.g why I needed 2 of them. I found that the more while-loops I used, the more cores my computer uses to calculate and the faster the program got. So now I wonder: Is there a better/other way to get LabView multithreading than using a bunch of while-loops?

I have just checked, and it is actually the while loop that will close. However the actions performed after that while-loop aren't performed, e.g. deinitialising the queues.

I have also found, that if I make the program evaluate even more data, it will stop more quickly.

Could it be that there is some sort of a memory overflow that will terminate certain parts of a program?

I can totally understand that nobody wants to read the code, so I'll put my question a bit different: Has anyone of you ever experienced a while-loop terminating when there was a constant value on the terminating clause that told it to gon on?

Thx

kper

[PaulieQ]

kper,

What do you mean with loops terminate?? They get stuck - constant index value (i from the loop) or do you get an error.

If you get no error, and the while loop(s) gets stuck you should search for the VI that stops the execution. You can use probes to view to "i" for each loop and break points. 

Another hint. The practice with [F] at Stop When True is very unhealthy. You create several Queues and allocate memory for each one of them. You can stop your program only by pressing the Stop button from the Front Panel menu. This will interrupt the program without closing and releasing the queue memory. The Release Queue VIs are NEVER REACHED.

As far as I know there is no real multi-threading in LabView. What you could do is to create subVI from every Loop and to load each loop in a different SubPanel (UnterPanel). The execution time is the same (as using while loops) but in this case everything is much more compact and organized.

Paul

[johnsold]

I looked at your program.  The style guides recommend that no panel or block diagram be larger than one screen.

None of your loops will ever stop! You have false constants wired to the termination terminals.  The only way your program can be stopped is by using the Abort button on the tool bar.  This is not its intended usage.  It is to allow the programmer to force a program under development to stop when the program has an error which prevents it from stopping in an orderly manner.  As someone on this Forum has stated: "Stopping a VI by using the Abort button is like stopping a car by hitting a tree.  It works but it often has undesirable consequences."

Most likely one or more of your loops are stalling waiting for something to happen.  Most of the loops have Dequeue Element functions with no timeouts. Some of your queue functions have the error wires connected via shift registers and others do not and you do not appear to check the errors.  I did not attempt to follow all your queue references on their epic journeys to see whether anything obvious was occurring. Rather than the Queue Status followed by # elements Not Equal to Zero, you could just use the Dequeue Element with a timeout equal to the value in the false cases.  It the Timed Out output is true, do nothing, otherwise process your data.  In some loops you do not use the dequeued data element.  If the data does not mean anything, there may be better ways to do whatever it is that you are trying to do.

Lynn