How do I correct a gradual slowdown of data being displayed?

[bmihura]

The problem happens even when there are no remote computers reading the data.

[rolfk]

Considereing that restarting LAbVIEW doesn't help you have to search it in external components to LabVIEW. First I would check for DAQ function by trying to isolate that out of the application (not executing those VIs should be enough).

Or could it be that your graphics display driver has a memory leak? LabVIEW makes use of some rather low level (but completely legal) functions in the GDI, some of which don't get as often called by other applications.

It used to be very common reason in Windows 3.1/95 days for slow computers and crashes, since display drivers were typically tested with Office applications and if they didn't crash there they were considered "good enough for sale"TM. That turned out to be almost always way not good enough for LabVIEW 😉

Rolf Kalbermatter

[shoneill]

OK, restarting  "the labview program" doesn't he, but I'm not entirely sure if you mean restarting LV totally (Closing all VIS, then closing LabVIEW itself and re-opening) fixes the slow-down or not.  If not, Rolf is correct, you need to look outside LV.

Are you displaying too much data?  Are you outputting the entire 15M to the screen?  If so, the down-scaling and sheer memory operations will slow your program down.

Hope this helps

Shane.

PS It would still be very useful to have a snapshot of your block diagram to help debug it. (No BMPs please, they're too big)

[rolfk]

---

@Shane wrote:

PS It would still be very useful to have a snapshot of your block diagram to help debug it. (No BMPs please, they're too big)

---

Eventhough there have been several requests for him that he actually lets see something about his app he hasn't done so. I assume he is either working for a top secret military agency or so sure that his VIs won't do anything wrong that he can't do that

Rolf Kalbermatter

[bmihura]

Here’s my code; the main VI is “!Drill Sreen.vi”:

http://www.lctechnology.com/files20.zip

Sorry if this is a double post, my last one didn't seem to work with my code attached.

You may be able to run this in simulation mode as follows:

1. Unzip the files into a directory.
2. In setup.txt, set “Floor Station Directory” to your directory.
3. The main VI is “!Drill Screen.vi”.

[bmihura]

Also, I'm not displaying too much data. There are about 20 numbers displayed a couple of times per second, but as you can see from that VI I attached, the front panel has gauges with canvasses overlapping them, so that a lot of graphics I suppose.

[rolfk]

This application is undebuggable.

- It doesn't run without some extra stuff installed (no I won't install an Active X control)
- Its main diagram covers about 10 screens width on my monitor
- It is impossible to understand what this program is doing without hours of research.

This last point will apply to you as well in a few months when you need to fix that tiny little bug someone has found. A redesign of the entire application with use of state machines, proper subVI modularization etc is IMO absolutely mandatory.

So where could be the problem: (in  order of chance)

You use an Active X control (or maybe even more) Try to eliminate that control in a simulation mode and see if it still keeps eating memory. Most probably it won't!!
You use lvOPC. This has also a chance of eating memory. There have been several memory leaks in lvOPC in the past.
You use globals all over the place. While this won't create memory leaks in LabVIEW it typically will slow down your application and it definitely makes an application very difficult to debug and maintain. I for myself have simply a hard time to manage more than a few globals in my head and I have decided that I won't try to understand a LabVIEW program which uses zillions.

Rolf Kalbermatter

Message Edited by rolfk on 07-06-2005 04:29 AM

[bmihura]

Thanks for the ideas. Yes, this is a huge application! I was reluctant to post it because of that.

As for the ActiveX control, I thought that was intrinsic to Windows; I downloaded it from an example on NI's web site.

I checked all my global variables. I don't like to use globals at all, but because of the nature of this program, most of them are necessary to pass data between VIs running in parallel.

I also suspect an OPC memory leak. With our current hardware, however, that's the only way to communicate with it. I'll explore that possibility.

[shoneill]

Havea  look at Queues for passing data between parallel VIs.  Globals are never the ONLY solution to a problem.

I haven't looked at your software (I assume you have LV 7.0 or above?).  I only have LV 6.1.

Good luck with your debugging, it sounds like you'll need it.

Shane.