LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

user event usage

I use User event and I have couple questions.

1. What is reason to use User event instead fo create additional control or indicator with making event by Value(Signaling) property? As I see:

- User event pros: Front panel doesn't have additional control or indicator. It is possible to transfer data.

- Control or Indicator event pros: Block diagram is much simpler. There is not needs to create, register, unregister, and destroy event.

 

2. Does User event queue remove data when Loop B process User event?

I have application where I transfer data through User event. Loop A generates User event with data. Loop B has Event structure which catch the User event, processes User event data, and updates plots and add data into local array based in Loop B Shift registers. Each time when new measurement starts the plots and the local array are clean. But I see that the application uses more and more memory.

I assume that plots and the local array don't use additional meory. I assume that maybe User event queue doesn't clean memory when data was read. (I am thinking to try LabVIEW Queue.)

Also I assume LabIVEW engine doesn't return memory when array is replaced by bigger array.

 

Any help?

0 Kudos
Message 1 of 5
(2,845 Views)

User Events are more flexible because you can register and unregister them.  Handling a user event does not require a context switch to the User Interface thread, whereas a Value (signaling) property node does cause a context switch which is less efficient.  You can generate a user event in a subVI (admittedly you could also pass a reference to a front panel item, but it is inefficient to access front panel controls through references).  Alternatively you can handle a user event inside a subVI more easily than you can handle an event on a front-panel control within a subVI.

 

Handling a user event will remove data from the event queue.  In your case, you said that you are adding data to a local array and to a plot.  Each time you add new data to either of these items it will consume additional memory, of course.

 

Why are you using a user event to transfer data between two event structures, though?  If the only thing that loop B is doing is receiving data, a queue would be a better choice.

0 Kudos
Message 2 of 5
(2,837 Views)

 


nathand wrote: 

Handling a user event will remove data from the event queue.  In your case, you said that you are adding data to a local array and to a plot.  Each time you add new data to either of these items it will consume additional memory, of course.

Why are you using a user event to transfer data between two event structures, though?  If the only thing that loop B is doing is receiving data, a queue would be a better choice.


nathand, thank you very much!

Of course, memory usage increase when my program adds data during measurement. But I talk about another issue. For example, LabVIEW starts, project is loaded

1.1. vi is opened. LavVIEW uses 150 MB memory.

1.2. vi starts. LabVIEW uses 170 MB memory

1.3.measurement starts (170 MB) and stops later. LabVIEW uses 200 MB memory.

1.4 measurement starts again. I see that LabVIEW memory usage drops but instead of 170 MB it drops to 190 MB (???) 
1.5 neasurement stops. vi stop. I see that LabVIEW memory usage drops but instead of 150 MB it drops to 160 MB (???)

 

Why and where does LabVIEW eat memory?

I transfer data between loop A without event structure. Loop B has event structure and handles a lot of event of controls and User events.

0 Kudos
Message 3 of 5
(2,830 Views)

Your memory usage is not being negatively affected by events.

 

LV handles its memory allocations in a compley way based on how the programs were running.  It doesn't free up all memory immediately.  But this has nothing to do with events.

 

Shane.

0 Kudos
Message 4 of 5
(2,827 Views)

Vasilich2004 wrote:

Why and where does LabVIEW eat memory?


Without seeing your code, I can't make any useful guesses.  You might take a look at the VI profiler (Tools -> Profile -> Performance and Memory) and see if you can find a VI that's using an increasing amount of memory.  Your code will run somewhat slower while the profiler is running.  If you have an uninitialized shift register to which you add data constantly, that can cause the appearance of a memory leak.  Another common cause is carelessness with references - for example every instance of Obtain Queue gets a new reference, even if the queue is named, so every queue reference must be disposed of individually.

0 Kudos
Message 5 of 5
(2,825 Views)