stop events structure

[FakStory]

Hi all!


Here I am! I'm using a events case in a while loop. The problem is that I should press twice on the stop button to stop the while loop...WHY!!! That my question...I set Switch when release for my stop button...(I must use a local variable of it...) Now, I can't stop my VI it seems that the value of my Stop booleen must be read before the while loop begin...then, when I press once my Stop booleen, then, it stay at true value, end it seems that the while loop start an other time...So, I press the control again, and the Vi stop correctly...( By closing, I send a false value to the stop booleen, to recover a ready to use control Like a latch mechanical action...)

Now there is the problem...To figure out where is the problem,  I highlight this...and now,  I got no problem! each time it is highlight, my VI stop correctly, but in normal mode, I should push twice on the control to stop it...Is it common? Do you know something weird with event case? By the way, I need to have an event case with no time out, because I use some shift registry each time I make an event action... An other weird tings, is when I recreate the "same" thing in an other VI, Or even I copy paste the inner part of my VI in a brand new VI, it working...
In addition, I can't send you an example, because it is a part of a very huge program...(So I should send you too many subVI and special driver...So...)
Nevertheless, I took a picture

Thanks for help this...

Fakstory

[mikeporter]

The reason for the code working with execution highlighting turned on is simple (to name at least): Can you say , "Race Condition"? The problem is that somewhere in your code you have something happening that only works when you slow-down execution by turning on execution highlighting. I'm not sure where it might be, but the code you posted looks OK. You mention a local variable, what is that for?

For this stop button to work all you have to do is remove any local variables you have for the stop button, give it a nice mechanical action so it will reset itself when read by LV (I forget what its called but I like the middle one on the bottom row of mechanical actions) and move the terminal into the event case handling the value change event. The terminal doesn't have to be wired to anything.

Mike...

[altenbach]

Please attach the real VI instead of a picture.

SInce you wire a boolean TRUE out of the stop event, the loop should stop no matter if the button goed on or off.

I see several problems and inconsistencies. For example:

• it seems that this entire event structure is inside a big case structure. This means that it is possible that the event structure is not even in the dataflow.
• What's up with the lowest shift register? Since you don't use the shifted value you can delete the entire shift register and nothing will change.

To troubleshoot the problem, we need to see the entire VI.

[FakStory]

Thanks Mike for your tips...But I need to stop several while loop in different place...so, I need to use local variable...( I have like five or six local variable...) Maybe this is not the best way to do, but this is the only one I found...

Then, Altenbach...Did you see Noobs under my name? Your two tips is maybe the first thing to check, but be sure that it is not the problem... Like you said, "you can delete the entire shift register and nothing will change"...So is that help me?!? any way, thanks to take the time...

Ok fine, I'm now looking for a way to remove all my local variable, but it seems that it's impossible...for the moment...(any suggestion?)..Again, I can't post the VI, you will not be able to run it anyway...WHY I SHOULD PRESS TWICE ON THE STOP BOOLEEN TO STOP IT? In all my other while loop or case structure I the stop control works fine! But not in this events cases...It seems that the case structure only works with when control is release...But when I Highlight, I saw the true value pass to the while loop stop...

I understand that it is possible that when I slow down the execution, "somethings make it works". But my post here are to figure it out...I tought that someone had already get my problem...it seems that not...I try to put a delay with the wait, but...nothing...any way, I forget this for the moment, but if you thing at something...let me know

Fakstory

[GerdW]

Hi FakStory,

no need to attack Altenbach - you just show a small portion of your vi and we should guess what's wrong

So please attach your vi anyway - even when it's broken we can look for problems and may give better advice...

[FakStory]

You got right GerdW.
My apologies Altenbach. It was not against you particularly... I just don't post things for that kind of problem... So, it is the kind of answer I hate... it is for me lowering the asker with some noobs detail without helping at all...You know what I mean...? I'm just borring about that...
Again, If you ALREADY get this problem...Tell me...(I thing the description is clear enough...)

FakStory

[jrpe]

One of the things about asking people to help you debug code is that chances are none of them have had exactly the same problem, unless it is a 'noob' problem. The easiest way for anyone to debug a program is to actually SEE the program. No one has the same problem because it probably isnt a bug, it is probably a subtle mistake somewhere in the code, so the only way for people to help you is to actually see the vi. If you had posted the vi in your first post, this would almost definately have been solved by now. We understand what the problem is, the description was clear enough, we just can't help you solve it if we dont have your code to debug. I can't just say something like "oh in your case structure that wasn't in the picture, you have a race condition that is causing this." So if you want the problem fixed...post your vi, unless its proprietary code or something, even then, you can isolate the section that gives you difficulty.

Anyway, just my 2 cents.

[GerdW]

Hi FakStory,

as others said too: it's much easier to find the problem when seeing the code entirely!

Yes, I got the same problem 10 years ago. No I hadn't this problem since then
From your description it's a race condition. So please (again) post some code...

Have a nice weekend - here it's Friday, 5.30pm


Message Edited by GerdW on 11-09-2007 05:25 PM

[altenbach]

Look, if you only attach a picture, we can only comment on what we see! 😄

The main diagnosis ("race condition"!) has already been mentioned. The point about the event structure inside a case structure is serious and could possibly cause problems like you observe, but it is not possible to tell from the picture for sure. Your picture shows very little, but what it shows does not make sense. I just pointed out the two most glaring observations. Since you say yourself that you are a noob, such comments can help. A program that is clear and does not contain unecessary things is much easier to debug.

Typically, the quality of the answer cannot be better than the quality of the question. You don't provide enough details and the image you posted is useless to pinpoint the problem.

Analogy:
You don't bring a picture of your motor to the mechanic and ask why the car does not start. Unless the picture show that the motor is missing or on fire, nonbody will be able to tell what's wrong. 🙂

All we can say for sure so far is that have a race condition. Provide some code (even broken) and we can give a more detailed analysis.

[FakStory]

Thanks to all again...

As you say Jrpe : "post your vi, unless its proprietary code or something, even then, you can isolate the section that gives you difficulty." and then I tried to isolate the problem and it disapeared, so thanks Altenbach, it is probably a race condition... I'm now looking in this way...(http://forums.ni.com/ni/board/message?board.id=4170&message.id=5422&query.id=8782#M5422)
That is the kind of tips I wanted!

Have a good week-end!

To GerdW:  Here it is 13h40...