loop taking longer time at each iteration

[F.NIORT]

Hello, 

I'm doing data acquisition with a cDAQ and NI modules (-10/10V; -20/20mA; thermocouples: and digital I/O)

At the beging and for the first five minutes my loop is fast enough (about 0.8s and i need to be below 1s), but after time, the loop start taking about 2s, then more and more up to about 15s 2 hours in the test.

I tried to serach for the part taking more time and I identified that it was my acquisition VI, wich is strange because it's not one writing data onto a file or something as so.

Also, when stopping my VI, the loop stops, but my VI is still running and i can't stop it even with the button or the task manager, i need to restart my computer

Have a nice day !

PS: i can send screenshots if needed in addition to the VIs

[GerdW]

Hi F.,

---

@F.NIORT wrote:

At the beging and for the first five minutes my loop is fast enough (about 0.8s and i need to be below 1s), but after time, the loop start taking about 2s, then more and more up to about 15s 2 hours in the test.

Also, when stopping my VI, the loop stops, but my VI is still running and i can't stop it even with the button or the task manager, i need to restart my computer

---

Without looking at your code:

• You build up growing arrays in your code, which takes more and more time…
• When finishing the VI LabVIEW starts to cleanup your memory requests and is quite busy with doing so…

[Yamaeda]

Somewhere here is the problem 

The probable cause is that you open and close the result file with each write instead of opening the file outisde the loop and using the reference.

[santo_13]

You definitely need to rearchitect the code to be scalable and manageable,

Use a QSM or derivative to modularize your functionalities.

Based on my quick 5-min review of the code, unless required, you may be able to achieve the functionality with the Free edition of FlexLogger itself.

[F.NIORT]

Thanks for your response,

That was my first idea, but I already removed all shift register and tabs. Here is the only data in the while loop (the first screen is used 4 times in a flat sequence for each module), the data in the cluster is configuration data wich is just transfered to the acquisition VI below

There is also a file writing output on an excel but I tried without it and the same problem was there.

Same thing for the wavechart.

If you have any idea or want another screenshot I can send them to you !

Have a nice day !

Esteban

[F.NIORT]

Hello,

Thanks for your help, I need to use LabVIEW (I proposed FlexLogger but it got rejected).

I don't know why I didn't put all of that data outside of the loop, it allowed me to get a faster loop (about 0.1s), but my loop is still getting longer and longer with the iterations, so it's only moving the problem slightly later on.

If you have any idea or want another screenshot I can send them to you !

Have a nice day !

Esteban

[GerdW]

Hi Esteban,

---

@F.NIORT wrote:

---

You initialize a DAQmx task with each call, read some samples and then you STOP the task - but you don't CLEANUP the task!

Why do you even need to init/stop so often instead of just once?

Have you ever considered using arrays with autoindexing loops instead of duplicating all that code???

There is so much wrong with your code…

[Yamaeda]

---

@GerdW wrote:

Hi Esteban,

---

@F.NIORT wrote:

---

---

That's a Race condition if i ever saw one.

[stevem181]

Hi Esteban,

I can't look at your code, but I see from the images that you are using property nodes along with your acquisition code.

This can force all the code to run in the UI thread essentially making your CPU operate on a single core.

Try disabling the property nodes and see if that makes the code run without slowing down.

A workaround could be moving the property nodes to a separate loop via a queue.

steve

[rolfk]

---

@Yamaeda wrote:

---

@GerdW wrote:

Hi Esteban,

---

@F.NIORT wrote:

---

---

That's a Race condition if i ever saw one.

---

While it technically is a race condition it may not really be that relevant considering that it is a slow temperature logging and most likely it won't matter if a particular overlimit condition is in bin x or bin x+1.

It is however a but-ugly solution for something that is done 10 times exactly the same! This belongs into a loop that is executed 10 times and does the according operation once in each iteration, not 10 times in parallel. Soooner or later the boss comes and wants the condition changed or add an eleventh and twelfth channel. And then the OP can go and edit each instance of the code and hope to make it correct in each, or copy and paste yet another instance of that code and create an even greater nightmare when the inevitable change to logic is required from him later on anyways.