Number of elements in the FP affecting the performance of my application ?

[Giovani]

I developed a simple application which consists of aquiring a signal through a channel of a PXI 5102 module and commanding some relays of a SCXI 1161 module.

This application has the following features :

-The user can, at any time, change the configuration of the PXI 5102 module.
-The signal acquired can be saved to a file whenever the user wants.
-Instead of showing the signal acquired through the PXI 5102 channel, the user can load a given file which contains a saved signal.
-The user can increase or decrease the pressure on a line through a VI that commands SCXI 1161 relays.
As you can see, it is a fairly simple application but the problem is that it have been running for a time the fron
t panel crashes. Is it because the high number of elements I have in the front panel ?

To give you more information I tell you that the processes of saving, loading, decreasing and increasing the pressure on the line are event cases of an event structure.
The front panel consists of a tab structure, 20 controls and indicators and a cluster consisting of 9 controls.

[RossC]

Giovani,

Could you further describe the crash? Does an error come up when the program crashes? If so, what error is it? (Error code and associated message would help)

The number of front panel objects you have is well within the maximum that LabVIEW can handle. I suppose if there was a large number of graphic-intensive controls (such as graphs and 3D plots), that could cause a problem. If you do have a large number of graphs and you tab between them using the tab control, you could set up a case structure based on the tab control value and only send data to the "active" graph(s). This could help reduce the graphical intensity of the front panel.

Please post here with the info requested above and we can discuss the problem further.

Sincerely,

Ross C

Applications Engineer
National Instruments

[Giovani]

No error take place. By crashing I mean that after a period of time the frontpanel control´s response to inputs of the user become so slow that after a short time there´s no response at all.

The problem is that I´ve been dealing with this problem in this aplication for quite a while and although I´ve optimized, I think, its execution time and the way it deals with memory usage this problem persists.

Since most of the operations performed by it depends on inputs by the user I´ve decided to use an event structure to manage them and decided to load the VIs related to them dynamically into memory to somewoh optimize memory usage.

In order to make things more clear to you I´m sending you a zipped file containing pics that completely describe the frontpane
l ad the block diagram of the appliction.

Any help you can give will be deeply appreciated.

PS : I´ve tried to sent the zipped file but awindow appeared notifying me that Developer Exchange is down for maintenance. If you need any more information to clarify what I mean please let me know.

Sincerely,

Giovani Marcelino Nesi
DRV Desenvolvimento e Representação Virtual Ltda.

[RossC]

Giovani,

If the application does not have a graphic intensive front panel, and you are using an event structure to handle the user inputs, then we still have not identified the source of the problem.

One thing to check would be how fast we are acquiring data from the 5102 and how the data is being stored. If we are acquiring at a high speed and the samples are being accumulated constantly in memory (perhaps with a shift register), this could cause a problem since the memory could be filling up. Is this the case in the application? The described symptoms sound like a memory issue, though it is possible something else could cause this behavior.

Sincerely,

Ross C
Applications Engineer
National Instruments

[Giovani]

RossC,

In order to clarify the way I´m acquiring data through the 5102 I´ve included in this reply a jpg file containing the whole block diagram of the VI which implements the data acquisition.

As you´ll see, in this VI I used a for structure to acquire data N times and, after the acquisition, divided the sum of the N data by N to obtain a filtered signal.

I decided to use the method above to clear the signal of any noise because it´s a characteristic of this signal.

Thanks again,

Giovani Marcelino Nesi
Design Engineer
DRV Desenvolvimento e Representação Virtual Ltda.

[RossC]

Giovani,

One suggestion I have is to close the references to the controls for which you have property nodes after using them. This ensures that the references are not causing a memory leak by keeping multiple references open in memory. Also, just as a quick programming suggestion, it looks like pane 0 of the sequence structure basically just does a scope acquisiton to return an array and then reinitializes the array to all zeros. You could just initialize an array using the scope parameters to determine the array size and eliminate the need to do a whole acquisition just for this purpose (if this indeed what you are doing). However, I do not believe from looking at the pictures that your array initialization method is causing th
e freeze.

If making these changes does not help the situation, this may be a better question for our LabVIEW section. Let me know it goes!

Sincerely,

Ross C
Applications Engineer
National Instruments