LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

serial VIs in while loops

I have written a program that has two while loops. One loop has two serial VIs controlling two instruments and other loop uses one variable from the previous loop. I am using queue for controlling the variable passing. Things are fine till here.
My problem is, after i run the program for 24 hours, my computer slows down. it seems like it's getting processor intensive.
Both the serial VIs are getting initialized at first. The loop that runs serial VIs execute at 200ms. Is it that the serial VI is filling some buffer and making memory intensive.
After 24 hrs, the execution of any function, even the windows explorer takes half a minute to display. After I reboot the computer, things become normal and fast.
Any idea where I am consuming more memory and keep on doing it?

many thanks
0 Kudos
Message 1 of 7
(3,940 Views)
The serial VIs should not be taking up your memory.
Are you sure it's this part of the code that's causing the problem (you disabled it and the problem stopped)?
If so, you may be filling the queue faster than you're emptying it, which will eat your memory if the queue has an unlimited size. There is a VI which allows you to check how many elements there are in the queue.
If the problem isn't in this part of the code, I suggest you post code, with some more details.

___________________
Try to take over the world!
Message 2 of 7
(3,931 Views)
I have seen a similar issue with Win-XP using a PCI-serial multi-port card (to add 4 more ports).
However, I am using CVI. Nevertheless, the problem resided with the OS and the way it processes interrupt services. We implemented a workaround. Apparently a solution is available with SP2.

What OS are you using? And which version of LV?

Serial communication should not have much of an impact on CPU performance, especially with newer PC's.
However, some OS (Win-XP for instance), may have performance issues of their own.
I'm obviously not a fan of xp...

JLV
Message 3 of 7
(3,916 Views)
Here is a llb file with Visa being used inside for loops. It isn't a continuous running loop, but it should help. We really need to see a sample of your code.
Message 4 of 7
(3,904 Views)
thanks to all for very valuable inputs. I isolated the serial part of the code and I nailed it down to one serial VI which talks to temperature chamber and gets the temp data.
I noticed that when I execute this code, the MEM usage in the task manager goes up by 4KB. So if i run all day, the VI becomes really processor intensive.
I tried to work around it, but didn't help. This VI has 'open VISA' and close VISA- VISA based serial communication. Any other ways- configuring serial ports etc. does not work.
I have posted the code..any help would be really appreciated.
0 Kudos
Message 5 of 7
(3,888 Views)
"So if i run all day"

After looking at your VI I read this as indicating that you are using the continuous run button OR you are calling this VI repeatedly from another VI.

If either are the case the slow down in performance is indeed the memory and the increase in memory useage of 4k per call all amkes sense.

The VI you are calling opens and closes a VISA refernce.

LV is really like a good assistant taking notes and taking care of all of the deatils for you so you go off an think your higher thoughts. One of the things it does is make sure that any scrap of paper that you left lying around is not lost. Even if you just put a dot on it. One of those scraps of papers shows up as a block of memory everytime you open a reference in LV. If you close it, LV or VISA etc will decrement the access count to that widget but the scrap of paper is still there. The scraps of paper and burned any time you tell LV you are done thinking. This happens when you exit LV. Then and only then does all of the memory allocated for all of the scraps of paper cleaned up.

To fix your poblem take a very close look at what Unclebump posted. He demostrates how to open a resource, use it and then only after he is done does he close it up.

You will also find that your code may run faster because your are not breaking out a new scrap of paper everytime you want to say something.

Ben

PS Thank you for psoting the code. It saves us doing a lot of guessing!

Message Edited by Ben on 05-17-2005 08:39 PM

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 6 of 7
(3,868 Views)
Well worded Ben.

I like your description.

😄
0 Kudos
Message 7 of 7
(3,853 Views)