Multiple poll case structures to event help

[Uke88]

Hello all,

I need some help with how to structure my code.  When I first started writing the code, I had no concept of how Labview worked.  I knew basic data flow and everything else I had to Google to figure out.  The main chuck of my code uses a case structure inside of a while loop.  The case structure is controlled by 20 Boolean variables (built array and converted to number).  Inside this case case structure is another case structure controlled by 6 Boolean variables (array to num).  Attached is a quick drawing of what I'm trying to explain with 4 variable controlling each case structure.  

The 20 Boolean is sectioned into 3 parts - run as normal, save data (10 Boolean), load data (10 Boolean).  When no Boolean is pressed, the code runs as normal.  Inside the "run as normal" section has the next 6 Boolean variables - when 1 is pressed, it controls 1 of 3 H-bridges.  The 20 save/load Booleans are "Latched when released" and the 6 H bridge Boolean are "switch when pressed".

I am planning on adding more functionality to my code, which would increase the 20 Boolean count.  I am thinking of switching the 20 Boolean variables to an event loop instead of a case loop.  That being said, it's going to take some time (a lot of my code can't be condensed because I have a lot of variables everywhere... poor design but its what I got...).  I guess I'm looking for what would be a benefit of switching my code to event loop instead of the Boolean array?  I tried doing an event loop with my 6 Boolean variables and it seemed to slow everything down (I couldn't figure out how to keep the loop going until the Boolean H-bridge control was released via event handles).  My guess is that the event handles can't work off of "if this is pressed do this".  My main concern is that switching my code to events would slow it down, which would be bad.  

I've come across this and am trying to understand what is good and bad coding with event loops.  I can use some guidance and advice on what my next step should be.

Thanks,

Matt

[crossrulz]

You definately should be using an event structure.  What you probably missed was the timeout input in the top left of the structure.  If unwired, the timeout is -1 (never timeout).  You can put your code that needs executed repeatedly into the timeout case.

A better way would probably to put your code that must continually run into another loop.  You can then communicate with that loop using a Notifier or Queue.

Since it sounds like you are new to LabVIEW, you might want to check out a couple of NI's online tutorials.

LabVIEW Basics
LabVIEW 101 

[aputman]

Event structure is definitely the way to go.  Check out JKI state machine. 

[johnsold]

Matt,

Done properly a program with an event structure should be as fast or perhaps faster than what you are doing now.  Look at the Producer/Consumer Design Pattern which comes with all recent versions of LabVIEW.

With 26 booleans you have theoretically 2^26 or more than 67 million possible combinations.  Your case structures are going to get messy!

It may be worth spending some time thinking about your User Interface and your program architecture before doing any modifications.  For example your Run Normal, Save, and Load might be better controlled by a ring or enumerated control rather than multiple booleans.  Similarly, the 10 booleans for Save data - what do they do? If they are channel selectors, you may not need a case for each boolean.

I like to think of the User Interface (front panel) as a source of commands to the program.  Then I consider that the program performs tasks related to the commands (and possibly to the data or errors as well). The design process (which has nothing to do with LV at this stage) consists of identifying the Commands and Tasks and creating a mapping between them. After the design is complete, developing the code follows from the design.

Lynn

[Yamaeda]

What an excellent opportunity to start over! Start over, do it right, do events!

It'll be alot more managable and scalable, it might even be well worth looking at the Producer/consumer-structure. It's a little more complex but a very good and general design.

Also, 20 boolean buttons for save sounds like you need a UI design, yet another reason to start over. 🙂 I'm guessing it's several channels with the same functionality? Either make a channel selector and 1 save button, or an array of clusters with the needed buttons and information.

/Y

[Uke88]

Thank you all for your responses.  I got a lot a lot to digest right about now :D.

My method right now for the "normal" mode is a case structure with "normal" being cases "0,3,5-7,9-15....".  It works but not effeciently.  If I go down the event code, could I set the timeout to 0 and then bank on the waits that are in my subVI's to act as the time out?  It takes ~50msec for 1 run of the main block diagram due to subVI waiting and execution.  Sorry I'm bad with terminology, i just don't know what to call things.

I haven't looked into consumer/producer yet.  I plan on reading up on some basics because I think clusters and arrays will be a huge modification to my code.  This way I can shrink down large sections of my code to subVIs which I think would make upgrading the main code easier.  

As for the saves, its basically the same function where I open a file and save a value to a key.  Each Boolean save is for a specific section - 1st Boolean is save 1, 2nd Boolean is save 2, etc.  Same thing goes for loading.  Is there a better way to do this?  I think I can make an array to do this for me...?  My idea is to say when "save array" is changed, search for the changed button and then update that section information.  Same thing for laod.  Attached is the front panel for my save section.  The border around the Booleans is there for show and I think if I change that to a cluser, I can pull off the new save/load idea.  

Matt

[Uke88]

I got to reading about the Consumer/Producer loops from here.  I don't think that's what I'm looking for.  From my understanding, Consumer/Producer loops are broken down into 2 separate loops - Consumer and Producer.  The Producer creates a queue and the consumer takes the queue and processes it.  The queue works on shift registers.  To me, that means that each loop something has to be passed into the queue or the consumer won't know what to do.  

For my code, every loop LabVIEW sets/gets 5 data points to an Arduino.  2 servo pulse widths and 3 pot voltage values.  When a save/load button is pressed, LabVIEW takes that data and stores/loads it from a save file.  I think event structures would be better for me here.  The way I'm looking at things, once a Boolean changes, save/load.  Otherwise, keep chugging away at the data.

Matt

[camerond]

---

@Uke88 wrote:

I got to reading about the Consumer/Producer loops from here.  I don't think that's what I'm looking for.  From my understanding, Consumer/Producer loops are broken down into 2 separate loops - Consumer and Producer.  The Producer creates a queue and the consumer takes the queue and processes it.  The queue works on shift registers.  To me, that means that each loop something has to be passed into the queue or the consumer won't know what to do.  

---

No, that means that the consumer loop doesn't do anything at all until something is passed into the queue.

Why not use an event-driven Producer-Consumer design? Run the Producer loop off of events, and the consumer loop as usual. That's Point 4 (Important Notes - Synchronization) in the white paper you linked to.

Cameron

[Uke88]

Cameron,

I guess I dont understand the Producer/Consumer design.  Right now Im thinking that the only thing prducer does is get data and send it to the consumer where the consumer then takes the data and does stuff with it.  If that's the case, then why not just use event design?  (Producer being the event and conumer being the action)

Or should I look at it like this.  The consumer will run the set/get Arduino variables and thats what that loop focuses on.  Meanwhile, the Producer looks for user input.  When a save/load button is pressed, it saves/laods the values.  In the save aspect, thats not too bad of a problem.  However, loading stuff can take quite some time...  If thats the case, I could put a case structure to signal loading.  

Is my second idea what you had in mind, or am i still way off?

Matt

[camerond]

You would want to use an event-driven P-C design instead of a straight Event structure if your processing (Consumer loop) might take longer than the time between consecutive events. This way, you can catch all of the events (P-loop) and they will be processed as soon as the C-loop has a chance to get to them. Otherwise, you can miss an event if your single event-driven loop isn't ready to take one when it arrives. If you have a gazillion events coming quickly and they each take a long time to process, you may lose some, but we're talking a really big number. In practice, probably some events will not take as long as others to process, so you'll be better at catching up.

In my understanding, it's primarily insurance against losing data. With a P-C design, you've got it all waiting in line (even if it seems like that line which never moves at the DMV - where you get your driver's license), whereas with a straight event structure, when it's gone, it's gone, like when Lucy had a job wrapping candy.

Cameron