While-loop stops unexpectedly

[kper]

Hi Paul,

I agree that structuring the program in Sub_VI would make it look way better.

Initially I did connect the terminating clause of the loops to the error of the queues. So that if I stop the first loop, all the others will stop as the queues are being deinitialised. I put the consteant values there to check why the loops terminate/get stuck.

Now what I mean with terminate is, that if I put a probe on any location in the loop that terminated, it will say "Is not performed" (or whatever it says in the english version).  Correct me if I am wrong, but as the queue will not wait for an element, but perform an empty iteration if there is no element in it,

a probe that is located e.g. after the "unequal to zero" should always be delivering values if the loop is still running? Or do I misinterpret my code there?

greetings and thx for the help

kper

[PaulieQ]

As johnsold said you can use timeout to check if a queue is empty or not. see the attachment.

check more in detail what happens in the sub-vi contained by the while loops. i don't think that the problem is directly related to the queue. at least for the second loop.

could it be that the loops that get stuck are using the same vi or resources and the problem is common for all of them.

[kper]

Hi,

I think you might be right here.

If the while-loop was stuck in one of the Sub_VI that would explain why the probes all say that nothing is being performed in the loop.

Still the Sub_VI (only thing they're doing is calling a C-Node) are all working fine in a different version of the program.

So if there would be a fatal error in the c-code I would have probably known that a long time ago.

Additionally I just realsied, that the exact same program had been running fine yersterday. So I don't think, that the error is because of the implementation.

The only reason I see why the program would get stuck in LabView I can see, is that it is waitiung for data. However I can't see a reason why the data shouldn't be there as I have checked the corresponding producer loops and they were working fine. If data doesn't arrive in the .c-code it would probably throw an error, wouldn't it?

I will be  checking my c-code for errors anyways.

Thx

[WayneS1324]

---

@kper wrote:

Correct me if I am wrong, but as the queue will not wait for an element, but perform an empty iteration if there is no element in it, 

---

If I interpret your statement correctly...

The dequeue will wait forever for an element unless you set a timeout. A timeout of -1 means wait forever. -1 is its default value.

Wire a constant to the timeout terminal indicating the number of milliseconds to wait.

[kper]

I had hoped to archieve the same effect by cheking wether there is an element in the queue and only do the remove if there is.

And as there are constantly elements beiing added to the queue, it should not have to wait forever....

However I probably won't lose anything if I give it a constant timeout, so I'll try that!

Thanks a lot!

[Mark_Yedinak]

---

@kper wrote:

Hi,

that's 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.

---

I don't mean to be nasty but I would strongly recommend you rewrite this application. If you are doing this as part of the requirement to obtain your degree this code is nowhere ready to be considered professional work. Which after all you are trying to demonstrate you are capable of when getting your degree. I didn't even want to try and understand what was going on. So little of your code is visible on the screen it is near impossible to scroll around and keep track of the logic. Any performance issues you were running into were most likely due to poor programming and convoluted logic. You should review the style guide and consider more use of subVIs in your code.

[Mark_Yedinak]

---

@PaulieQ wrote:

As far as I know there is no real multi-threading in LabView.

Paul

---

I am not sure why you think this but this simply is not true. LabVIEW is multithreaded and can not only take advantage of multiple threads but it can take advantage of multiple cores as well. The compiler is quite sophisticated and breaks the code up into executable nodes which it will execute in parallel in separate threads.

[kper]

Hi,

thanks to all of you who commented and helped. In the end, putting timeouts to the queues solved the problem.

If I had the possibility to rewrite my code now, I would most certainly do quite a bit a lot different.

However, as this is the first LabView - Program (or overall Program) I have written in my life, it does of course lack style.

So again thanks a lot to all who still put in the effort and helped!

Greetings

kper

[kper]

Hi,

thanks to all of you who commented and helped. In the end, putting timeouts to the queues solved the problem.

If I had the possibility to rewrite my code now, I would most certainly do quite a bit a lot different.

However, as this is the first LabView - Program (or overall Program) I have written in my life, it does of course lack style.

So again thanks a lot to all who still put in the effort and helped!

Greetings

kper

[PaulieQ]

---

@Mark Yedinak wrote:

---

@PaulieQ wrote:

As far as I know there is no real multi-threading in LabView.

Paul

---

I am not sure why you think this but this simply is not true. LabVIEW is multithreaded and can not only take advantage of multiple threads but it can take advantage of multiple cores as well. The compiler is quite sophisticated and breaks the code up into executable nodes which it will execute in parallel in separate threads.

---

Mark, by "multithread" I mean the same multithread which is available in Visual C for example. Where one can define the priorities, cores and so on. LabView is multitreaded but you have no direct control on individual threads.

The multithreading in LabView means creating parallel loops and letting LabView to deal with them. Correct me if I'm wrong.