controls and event structure

[GerdW]

Hi krispiekream,

did you look at the attachment? There are examples in it. All my comments are in red!
But anyway, here's an example:



Message Edited by GerdW on 08-06-2008 10:27 PM

[krispiekream]

yeah. i have looked at the examples. they are really great.
thank you for taking your time and yeah. its enough for today.
i am having a problem making subvi for my block diagram to make it smaller. i dont like to use REFERENCES?
is it good LABVIEW Practice to create subvi with references?



Message Edited by krispiekream on 08-06-2008 04:22 PM

[GerdW]

Hi krispiekream,

references are created when you have terminals/locals inside the part making the subvi. Move them outside of your subvi part to avoid references...
By removing all (unneeded) locals you also avoid to create references

References aren't bad (or good) - they are a way of programming. They have their advantages as well as disadvantages...
"Good practice": there are situations when you need the reference, i.e. manipulating a graph display from a subvi.
But in your case I think it's different due to overuse of locals, so making references "bad practice".


Message Edited by GerdW on 08-07-2008 08:13 AM

[krispiekream]

great advices.
after llooking at my code. what do you recommend me to do with the PRESURE/PRESSURE 2 local variables? i have to have them in order to display in the front panel.
do you have any suggestion to get rid of them?

[johnsold · Accepted solution]

Those are easy. Once you get reorganized to a state machine architecture then the Pressure and most other indicators can be managed via the big cluster you are passing around.

I spent some time (way too much time, actually) revising your program to illustrate some of the things that several of us have been suggesting to you.

Your diagram was over 15000 pixels wide! I reduced it to much less than that , although it is still much too wide. The goal is to fit it on one screen.

It is partially converted to a state machine. The Call Module case structure you have is actually a simple state machine. By combining it with what I have shown at the left side of the outer while loop, you can build something that may work well. I added comments at various points in the code - background colored with some obnoxious shade so you can find them.

I set it up so that when the buttons on the panel are pressed, the event loop sends a command via a queue to the main loop. The commands are a typedef enum.

What I sent will not work. It is incomplete and I do not know what much of your program was intended to do. Because I did not have most of the subVIs, it will complain and ask you to help find them when you first open it.

I think you will be able to eliminate almost all of the locals and probably most of the globals.

Lynn

[krispiekream]

wowwwwwwwwwwwwwwww, that is some nice sh*t.
i have never worked with something this good so i don't know if i can get it to work.
thank you for taking the time to do this. i never had better teachers then you guys.

but actually, you helped me modified the Controls and events subvi which is part of the program.
and the PROGRAM.VI is the whole program.
but i'll see if i can pull it off.
its a great start for me.


Message Edited by krispiekream on 08-07-2008 01:54 PM

[krispiekream]

maybe you can see if i am heading to the right direction?

[johnsold]

I only had a few minutes to look.

I think you are getting some of the ideas, but it is hard to tell for sure because the program is so big.

One concern: In the event structure you do not want any code which is time consuming. For example the Timeout case has the Simple Error Handler.vi. If an error occurs this will pop up a dialog and lock up that case until the user responds. While this may not be all bad for errors, generally you do not want any code in an event case which takes more time to run than the minimum possible time between events. This means: No dialogs. No file I/O. No hardware I/O. No FFTs. No nodes with time delays, waits, or timeouts. No printing. This is why I put the enqueue functions in most of the cases. All the event structure does is detect user events and tell some other part of the program what to do about it. The actual "doing" is done elsewhere.

The initialization, temperature cycling, pressure cycling, graphing, and shutdown at the end of the program can all be in one loop. Each will represent one or more states in the state machine.

Lynn

[krispiekream]

no printing? hmmm, what do you suggest? should i have another while loop like that one you have in parallel with the one that have the PRINTING?
so it would be 3 while loops.
i'll continue working on it.
but i dont really understand why i am doing his.
so once the BOOLEAN IS PRESSED IN YOUR STRUCTURE OF PROGRAM. it VALUE changed.
and it will release the queue to the CASE for it?

[krispiekream]

alright, i am lost now. i have 2 while loops.
one for temperature cycling, the other is for pressure cycling.
i dont know if what i am doing will be like what i had.