LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

architecture for data processing application

Hi all,

 

I made a small data processing application with Labview.

 

It imports curves from csv format (with a file dialog pop up), then displays them on an XY graph, allows the user to change the scale, allows to set it to lin/log via the front panel, and allows the user to delete curves if necessary, also via the front panel. Finally I use the "Advanced Plotting Toolkit" to display nice ("Origin like") curves.

 

There is no realtime acquisition (data come from csv), nor complex data processing that would require asynchronism between user interface and processing.

 

For the moment, I use stacked sequence with a boolean to trigger the related sequence (I know it may be not good).

 

I was advised to use queues instead, but I'am bit lost. Can you tell me what would be a better structure for such an application ?

 

 

0 Kudos
Message 1 of 14
(2,721 Views)

@haha1234 wrote:

 

For the moment, I use stacked sequence with a boolean to trigger the related sequence (I know it may be not good). 


So, you have multiple stacked sequences, one for each task? 😮

 

I have no idea why you even need sequences. Typical dataflow alone determines execution order just fine (... unless you tear up all data dependencies by overusing local variables) There is no need for queues because there is nothing time critical. All your various processing tasks are standalone. . (I am assuming that none of the processing steps take longer than a few hundred milliseconds).

 

All you need is a simple state machine while keeping the relevant data in a shift register and triggering the various actions as a function of user input.

 

We typically don't trust incomplete descriptions, because there are millions of ways your post can be interpreted. Just show us your VI and we'll give more targeted advice.

 

Message 2 of 14
(2,713 Views)

Depending on what you want to do, a Simple State Machine, or a slightly more complex design, the Queued Message Handler, might be much more suitable than a Stacked Frame (which is rarely used these days due to its clumsy architecture).

 

If you start up LabVIEW, you should see "Create Project" from the initial Getting Started window.  When you do this, among the first choices that appear in the Right-hand pane are "Simple State Machine" and "Queued Message Handler".  Choose "Simple State Machine".  Examine the code, read the Documentation, think how it could fit your Application.

 

If you are sufficiently adventurous, close the Project, and open another Project, this time choosing Queued Message Handler.  Again, examine, study, read, think.

 

Before actually choosing a design and starting to code, at least make a list of the States (or Messages) you want to handle to accomplish the (typically sequential) sub-Tasks that your Program requires.

 

Bob Schor

Message 3 of 14
(2,681 Views)

thank you for your two messages! Smiley Happy

 

with your information, I've started to look at the "simple state machine" template and it seems to be corresponding to my needs.

 

If I understand good, the difference between the state machine and the queued message handler is that the queued message handler can handle some tasks in parallels right ?

 

If so, at first sight, it may not be necessary for me.

0 Kudos
Message 4 of 14
(2,672 Views)

Based purely on your description, I'm not even seeing a need for a state machine.  A simple While Loop with an Event Structure will probably do the job.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 5 of 14
(2,655 Views)

OK,

 

So if my application is only composed of pure events that trigger always the same action, the while loop with an event structure is sufficient ?

 

but if the behavior is that an event triggers different successive actions, then the state machine will be required ?

0 Kudos
Message 6 of 14
(2,641 Views)

In my book, "A simple While Loop with an Event Structure will probably do the job." is still a (very, very simple) "state machine". Each event being a state and waiting for events being the "idle state".

 


@haha1234 wrote:

 

but if the behavior is that an event triggers different successive actions, then the state machine will be required ?


... unless these successive actions can all be placed in the event frame. It would be much easier if you could attach some simple code demonstrating what you need to do. For example if after each event a common logging action should occur, it could be placed after the event structure or in the timeout event case, while keeping the timeout in a shift register. Each suitable event would set the timeout to zero, while the timeout event would set the timeout back to -1 (infinite). There are many ways to do things!

Message 7 of 14
(2,628 Views)

Thank you again for all your valuable contributions.

 

Here is a simple example of what I want (all features have not being migrated yet). I tried to do it with a state machine.

The external ugly while loop is there just to show the values of the hovered curve. I don't know where to put it... It should run only while waiting for the user to press a button. There is also a problem with the plot legend (it seems not to be updated with the graph).

 

 

0 Kudos
Message 8 of 14
(2,606 Views)

Looks much better. One ugly point is that the lower loop runs all the time and cannot be stopped. (SImple solution: put the "exit" button terminal in the lower loop and wire to the termination condition. No other changes needed!) Try to work with "mouse enter", "mouse move", and "mouse leave" events for the graph instead to trigger the overlay only on demand.

0 Kudos
Message 9 of 14
(2,600 Views)

Yes ! Cat Mad The simple solution works perfectly 😉

 

However, is it a good solution in terms of CPU resources / controllability of the two loop? I tried to create a new event on mouse move on the graph, is it better? 

0 Kudos
Message 10 of 14
(2,593 Views)