How many is too many cases for an event structure?

[JPrevost]

I currently have 12 and am adding more. Is this "safe" and within good programming priniciple or am I bloating already?

Having such a large program (over a meg now) is starting to really tax my concentration. Everywhere I look there is something else I need to do or test out. I'm not even adding features! Things like proper file handling (currently have 2 read, 1 create/replace/append, 1 read/write, 1 create) are really taking their toll. Because for each file there are different cases. Eg; If the user doesn't select a bin file I have to disable the learning function and disable/grey some of the tabs. If they press cancel I have special considerations like to close a file only after the user has either selected a new file or cancelled out. Thank God for error handling or I'd be one grumpy dude. Back to the event's, should I start a 2nd event structure for other events? Things that aren't directly controlled by UI? For example, if a file doesn't exist or the user cancels out of a file selection, I set a flag that indicates if there is a good file to execute code on or not. There is a case for this flag which then runs my code but at this pace I'm afraid the event structure might get flaky with so many cases. I can't remember where I read it but I believe 1 event structure is all you want in a VI. This is correct yes/no?

[Michael Aivaliotis]

Well, If you haven't already read this, here is an article I wrote for NI's website a while back:

Changing the Face of Design Patterns with LabVIEW 7 Express Event Structure

Most of it is a list of design patterns but pay attention to the Event Structure With State Machine. This should be the direction of your program. This is probably a lot of work to transform your program to this design but worth it in the long run.

You say your code is 1MB. This is actually pretty normal size. The number of cases is not important and you shouldn't worry about this. It is important to abstract certain functionality into sub-vi's. I cannot stress the importance of sub-vi usage. This will make your Main vi lighter and your overall code easier to manage.

As far as multiple event structures. I've done this before and it works but there really is no benefit. Is this to split up code? Why? There is no reason not to put ALL your events in one event structure. You say the "event structure might get flaky" define flaky. There is no logic behind this assumption. Is there something else specific that you are worried about?

[JPrevost]

Thanks for the reply and the direction. I'm working on always improving this code. It is my first large application and it will be my best!

As for the code size. I shouldn't have said 1mb. That's just the exe after building. As you know I've been battling the graphical side of LabView. That's my biggest hang-up because when I time the VI's they're all running with great efficiency. I've converted a lot of my "make the wiring diaghram smaller vi's" to subvi execution, this doesn't seem to register any measurable gains but I'm sure it's there if I look hard enough. I've got a bunch of local variables but I use them sparingly. Next step is getting the config file to a seperate vi where I'm going to use your example as a template. Other than that I'm moving a lot of my code into the event structure. The problem with this is sharing data between other parallel loops. The only means possible is through use of locals . I'm going to try and get you a copy of my code asap. I just spent the weekend pounding out a new beta release that fixed some of the complaints so I should have some time to give you a better picture.

BTW, what I think you're doing is awesome. I can't thank you enough... maybe I'll fly out to one of these NI gatherings. Not anytime soon but eventually

[i2dx]

It is my first large application and it will be my best!

that's a missbelief!

software will never be perfect in the developers eyes. it may be ok, or sometimes even pretty good and in some extraordinal cases you will really like some parts of your software (i LOVE this rs232 driver for the XYZ-Device ...). But you will find always find something to improve.

that's why there are project managers, who put the pistol on your chest and say "deliver or die" (or in bad cases: "cool, it compiles, let's deliver ...")

[PJM_labview]

...Other than that I'm moving a lot of my code into the event structure. The problem with this is sharing data between other parallel loops. The only means possible is through use of locals .

It is usually a good practice not do any work in the event structure. Event structure are used to catch events and then through some mechanism, the job to do in response to that event is selected.

The major advantages is that instead of beeing tightly coupled to the event, the job to do can be very easily recalled by anything at anytime.

In the image below the job is passed to the case structure through a shift register. You could also use a queue to pass job and data to another loop.

You might want to investigate queue, as you will see they are a lot more efficient to pass data between parrallel loop than locals.

PJM

[JPrevost]

It is usually a good practice not do any work in the event structure. Event structure are used to catch events and then through some mechanism, the job to do in response to that event is selected.

The major advantages is that instead of beeing tightly coupled to the event, the job to do can be very easily recalled by anything at anytime.

In the image below the job is passed to the case structure through a shift register. You could also use a queue to pass job and data to another loop.

You might want to investigate queue, as you will see they are a lot more efficient to pass data between parrallel loop than locals.

PJM

I'm looking at using queue's soon. I like how the loops wait until there is something in a queue. This is by far the best part about them.

I'm using a queue to take data from either the serial port or a file, if the data is checksumed as OK it goes into the queue, if not, empty case .

Thanks for that suggestion about using queues to pass work around. Right now I've only got it passing data between 2 loops, the "producer consumer" architecture only the producer isn't an event structure.... yet!

[Mike Ashe]

Thanks for the reply and the direction. I'm working on always improving this code. It is my first large application and it will be my best!

Hopefully you're wrong on both accounts, but thats very forgiveable! It is actually probably your first medium sized application and if you keep working with LabVIEW it surely should not be your best. It is amazing how one's definition of "large application" and "best coding practices" change with experience. The first time I was involved in a LabVIEW app that exceeded 1000 VIs I thought we'd coded the biggest thing in the world. Then I found out about one that exceeded 8000...

Other than that I'm moving a lot of my code into the event structure. The problem with this is sharing data between other parallel loops. The only means possible is through use of locals

Perhaps I shouldn't tell you this, but there are actually about a half a dozen ways to move data between loops, so just file that datum away for now and concentrate on the event stuff Michael Aivaliotis pointed you too and the gueues PJM expounded on. Queues remain my favorite.

It is usually a good practice not do any work in the event structure. Event structure are used to catch events and then through some mechanism, the job to do in response to that event is selected.

Amen to that. A pretty reasonable way to look at the Event Structure is that it is an interrupt handler, software interrupts rather than hardware. No, it's not exactly that, but the analogy holds. An Interrupt Handler, properly used always does the absolute minimum with the data and takes as little time as possible. It catches the interrupt, verifies what type, performs any _must do_ data massaging and then passes the work off to another routine, usually queued, and goes back to watching for the next interrupt.

Go, and do thou likewise ...

[JPrevost]

Hopefully you're wrong on both accounts, but thats very forgiveable! It is actually probably your first medium sized application and if you keep working with LabVIEW it surely should not be your best. It is amazing how one's definition of "large application" and "best coding practices" change with experience. The first time I was involved in a LabVIEW app that exceeded 1000 VIs I thought we'd coded the biggest thing in the world. Then I found out about one that exceeded 8000...

Perhaps I shouldn't tell you this, but there are actually about a half a dozen ways to move data between loops, so just file that datum away for now and concentrate on the event stuff Michael Aivaliotis pointed you too and the gueues PJM expounded on. Queues remain my favorite.

Amen to that. A pretty reasonable way to look at the Event Structure is that it is an interrupt handler, software interrupts rather than hardware. No, it's not exactly that, but the analogy holds. An Interrupt Handler, properly used always does the absolute minimum with the data and takes as little time as possible. It catches the interrupt, verifies what type, performs any _must do_ data massaging and then passes the work off to another routine, usually queued, and goes back to watching for the next interrupt.

Go, and do thou likewise ...

I'm wrong on one account. This probably won't be my best program but it is my first. Key word being my. The only other "program" I've written in LabView was some crap that did nothing more than subroutine, woops, subvi "work". My first intro to LabView was v6 back in 03 where I was in charge of setting up an enging dc electric engine dyno in the ME department of Ohio State University... I was a student on the FSAE team. Some student before me wrote a program that datalogged but it was poorely written. I didn't have any documentation and just started playing around with it after class every day for a couple months. After finally taking a NI class things started to click together in my brain and off I was running. Even then I didn't write a new program, I just modified the existing one.

I too can think of a few ways to move data between loops but the local variables seem the best when they're called in multiple places at different times without any order (user input/interrupts). I like Queues and I think they are the best. Nothing lost and very flexible except I'm not at the level of using them to pass jobs between loops. Eventually, I hope.

I totally understand what you guys are saying about the event structure. That's what I was trying to say only I didn't do a good job with it. The less work the event structure has to do the better and so I can have a LOT of cases, just don't add a lot of code .

[nudalakasim]

It is amazing how one's definition of "large application" and "best coding practices" change with experience.

Well said Michael :thumbup: ,

I usually re-look into my old codes, and each time, believe me, I feel "WoW I've improved a lot" and have "learned new things". And I believe that this will be the case for the years to come...

nudalAKasim

[Rolf Kalbermatter]

You say your code is 1MB. This is actually pretty normal size. The number of cases is not important and you shouldn't worry about this. It is important to abstract certain functionality into sub-vi's. I cannot stress the importance of sub-vi usage. This will make your Main vi lighter and your overall code easier to manage.

1MB for a single VI is IMO a little at the large side but it can happen for more complex VIs. It is probably a good candidate to check for common routines that can be delegated into subVIs.

The number of cases is not that important but there can be a "to much". I once inherited a program that implemented a robot sequencer. It was written in a single VI with one huge loop containing a sequence structure with one case structure in each sequence, operating all on the same global state variable and one or two case structures in there containing all the possible sequence steps and substeps of the process logic. Of course no shift registers used at all but just globals all over the place.

This program was in LabVIEW 6.1, the main VI weighted in at around 8MB, the two huge case structures had more than 200 cases each and every single edit operation on the VI took several seconds or so on a medium speed PC for LabVIEW to verify its internal graphs for syntax checks. Breaking the VI made editing luckily faster. Completely rewriting the application was no real option since the whole sequence logic was nowhere documented other than in the diagram.

I finally managed to modify the VI in such a way that the main sequence logic was broken into the UI handler logic in the main VI, three logical processes that the sequencer only could process exclusively anyhow put into their own subVIs, replacing much of the globals with shift registers and intelligent functional globals and some optimizations in the sequence steps itself, resulting in around 4 VIs with 1MB each, some extra helper subVIs, and no cases structure with more than 70 or so cases.

The result was an application that could be again edited without any noticable delay, worked noticably smoother with less CPU load, and fixed a few bugs by the way. Besides having to select a specific case during development in the popup list when there are 100 or more cases is a major pain in the a** (and in earlier LabVIEW versions you would not be able to scroll in that list if it did not fit on the screen ;-)

Rolf Kalbermatter