stopping a vi.

[exo]

If the stop button stops the vi in Untitled, why doesn't do the same in Project 1640 7.

Thanks

[Dennis_Knutson]

There are so many things in your program that can be submitted to the Rube Goldberg thread that I don't quite know where to start. All of the hidden Booleans should be deleted and your use of local variables and event structures is quite strange in many places. For example, the code in the first image below can be simplified to what is in the second. I can't run your VI because of several missing subVIs but I think your whole problem is because of those two outlying while loops with their own event structures. Try writing you program without those or just include them in the single event structure in the main while loop. Read the help about caveats and recomendations about using event structures.

Message Edited by Dennis Knutson on 10-10-2007 10:12 AM

[exo]

I take the Rube Goldberg comment as a compliment. Two things: I read that you have to read a control in order for the event to execute ( although some of my recent experience indicates that this isn't true). Second, I tried with my Untitled example to duplicate the condition in my vi. i.e. Event structures inside while loops. What could I have done in my program to make it not stop?

[exo]

Don't see the event structures that where supposed to be in Untitled. Will try again

[exo]

Beginning to see.
Thanks

[RavensFan]

Getting into the Rube Goldberg thread isn't really a compliment.  You just become an example for others as what NOT to do.  It is a very bad idea to have event structures embedded in event structures.  I think that would often cause erratic behavior.  Also, you've been told in numerous other threads that writing to an indicator and the local variable of the indicator is a wasted action.  Before posting any more code, please clean up any unnecessary local variables.  It will only take a few minutes.     I still don't understand what your thought process would have been to start writing the program that way. 

The event (such as a value change) gets captured before the control is actually read.  And having 2 object value change events embedded one inside the other is serious.  Because the outer event will fire, then the inner event will not fire because the other event will have already stripped it off the event queue.  Thus I think the code will freeze until you change the object a second time.  But often, events will lock the front panel controls until complete, which means you won't be able to change the object again to cause it to fire.  You need to completely eliminate that inner event.

For the inner default case on the outer object value change event, you can greatly simplify the string functions.  First, you can take a single index array function and stretch it down.  Wire a 3 to the top value.  All other outputs below that will be in sequence 3, 4, .......  You should also look at the array to spreadsheet string function (perhaps along with Get array subset since you are starting with element #3).  It will format a string array into a string where you can define the format codes as you see fit.  It will eliminate a lot of the concatenation.  In case -1, instead of bundling empty strings and feeding them into star parameters,  right click on star parameters and select create constant.  Then you can edit the cluster constant to have empty strings, thus eliminating the bundle function.

I recommend:

1.  Take the online tutorials.

2.  Take Labview Basics 1 and 2 courses when you get the chance.

3.  Keep reading the forums to learn.

4.  Take the advice you are given on the forums and follow it.

Good luck!

Message Edited by Ravens Fan on 10-10-2007 01:26 PM

[exo]

I am not a LabView programer by any means and have years of experience writing regular code. It's easier and, I think, quicker for me to start writing and fix and learn things as I go than to go through the tutorial. Sometimes, as I write some things do not get cleaned up or are more complicated than they need to be but I just need it to work not be pretty. I also don't mean to abuse your help, but it is often far easier to ask than go through the books or help files.



More importantly, I can't begin to tell you, how helpful you guys have all been and that I couldn't do it without you. Again, let me show my graditude by offering you tickets to the American Museum on Natural History if you are ever in NYC. When we get the instrument to Mt. Palomar, I would also be glad to show you around if any of you are the San Diego area.

Doug

[Dennis_Knutson]

Everyone here is glad to help but you have to remember that the majority of us are unpaid volunteers. To hear someone say that they would rather ask the forum how to do something instead of reading the on-line help or taking a brief amount of time to take a tutorial, is not, imho, a very welcome statement. Seeing previous advice ignored, is even less welcome.

[exo]

Dennis,

It is not a question of ignoring advice. It's a bunch of guys racing like mad to finish a multi million state of the art instrument on time. And you are part of that bunch. I hope you forgive me my trespasses and my less than perfect working habits and continue to help out.

P.S. I understand about Rube Goldberg but I'm proud of the fact that I made what I work one way or aanother

[Dennis_Knutson]

I think you'll find that you will continue to get help but please, please do some clean-up on your program. It's really difficult for anyone to understand what is wrong when the programming style is so obtuse. You also need to understand that because each subVI is a separate file, when you attach your main VI, that only your main VI gets posted and none of the subVIs. You have to attach them separately or create an application distribution. Including all of your code makes it much easier to see what might be wrong.