Stop button does not reset after each start of program

[rr1024]

---

@RavensFan wrote:

No. It does not have the same effect.  They are completely different actions.  If they were the same, then NI would have never created the second one.  I have never seen a practical use for "Until Released".  Read the help files on the mechanical actions to see the difference.  It is a real tricky, subtle difference.  But it is a difference.

If you clean up the boolean logic, and put the start button in the event structure.  It runs just fine.  See attached.

---

I  see, but I don't under stand the start button you created because it basically goes no where. Is that because the event structure only needs to kick off on the change. If that is the case why does it have to have a wire at all?

[RavensFan]

Dataflow.  It just makes sure that the while loop doesn't execute until after the event structure has executed.

But actually, that wire can be eliminated because the wire coming from the Log File Control through the file open path is doing the same thing.

I didn't create the start button.  It is the same one you had.  I just moved it into the event structure so that it gets read and reset when the event structure fires.  Also, part of the convoluted boolean logic yoiu had before actually sent a False through the event structure into the while loop because the Start button was read when the VI started and passed that False value through the event structure once the start button's value changed.  Of course that start button would stay true because it never got read again, and when you reran your program, it would pass through a true value (it's value when the program started) and send a true through the event structure into the while loop.  Thus making the convoluted boolean logic that much more unpredictable.

When you have a problem with code, figure it out and fix it.  Throwing more code at it (the NANDS, feedback node, the strip/build path) doesn't actually fix anything.  It just makes things more complicated and maybe covers up the symptoms of the problematic code.

[Gregory]

Often times when a boolean is used to trigger an event it is not wired, but it must be put in the event case to ensure that it gets read and set back to its original value. Then you use the event case to perform some action, or send out some data or state information.

One case where it might look like "nothing is happening" is in a pop-up window. You may want to wait for the user to press a button before closing the window, but once they do there is nothing to perform except to complete the running of the VI so it will close.

[rr1024]

---

@RavensFan wrote:

---

@GerdW wrote:

There is one more big failure: because the event structure is not in a loop your VI becomes unresponsive when you click the start button two or more times… 😞

---

That is true also.

But the OP has been told about this a few times before in previous threads and has failed to fix that problem.  In the modifided VI I attached, I fixed that be turning off the front panel lock for that event.

---

Telling someone a solution is wrong does not necessarily help someone learn how to fix it, Especially when the answer is to put it in the structure and when I do so it freezed my UI, little did I know I had to diconnect it from the stop latch.

[rr1024]

---

@RavensFan wrote:

Dataflow.  It just makes sure that the while loop doesn't execute until after the event structure has executed.

But actually, that wire can be eliminated because the wire coming from the Log File Control through the file open path is doing the same thing.

I didn't create the start button.  It is the same one you had.  I just moved it into the event structure so that it gets read and reset when the event structure fires.  Also, part of the convoluted boolean logic yoiu had before actually sent a False through the event structure into the while loop because the Start button was read when the VI started and passed that False value through the event structure once the start button's value changed.  Of course that start button would stay true because it never got read again, and when you reran your program, it would pass through a true value (it's value when the program started) and send a true through the event structure into the while loop.  Thus making the convoluted boolean logic that much more unpredictable.

When you have a problem with code, figure it out and fix it.  Throwing more code at it (the NANDS, feedback node, the strip/build path) doesn't actually fix anything.  It just makes things more complicated and maybe covers up the symptoms of the problematic code.

---

Totally agree and thanks, that is very helpful to my future understanding of labview.  Yes I understand throwing more code at is is probably not good but usually a necessary evil when learning a new language 

[RavensFan]

---

@rr1024 wrote:

Telling someone a solution is wrong does not necessarily help someone learn how to fix it, Especially when the answer is to put it in the structure and when I do so it freezed my UI, little did I know I had to diconnect it from the stop latch.

---

What the heck are you talking about?

When I tell someone that they'll have a problem because the event structure is set to freeze the front panel, isn't that telling them how to fix it?  I never set put it in another structure.  And what this has to do with "disconnect from the stop latch" is absolutely nothing.

EDIT:  Maybe you were responding to Gerd's message rather than the one I gave you last week.  Which was actually more directed at RTSVLU who gave a faulty message.  here http://forums.ni.com/t5/LabVIEW/How-to-create-a-start-button/m-p/3316931#M971719

[rr1024]

---

@RavensFan wrote:

---

@rr1024 wrote:

Telling someone a solution is wrong does not necessarily help someone learn how to fix it, Especially when the answer is to put it in the structure and when I do so it freezed my UI, little did I know I had to diconnect it from the stop latch.

---

What the heck are you talking about?

When I tell someone that they'll have a problem because the event structure is set to freeze the front panel, isn't that telling them how to fix it?  I never set put it in another structure.  And what this has to do with "disconnect from the stop latch" is absolutely nothing.

EDIT:  Maybe you were responding to Gerd's message rather than the one I gave you last week.  Which was actually more directed at RTSVLU who gave a faulty message.  here http://forums.ni.com/t5/LabVIEW/How-to-create-a-start-button/m-p/3316931#M971719

---

I think so but thanks for your help, I may have a dim light bulb in undestanding labview 

[GerdW]

Hi rr,

Because I was tying ot get it to work properly 

So it didn't work, but you sticked with wrong code?

Because the UI seems to freeze when I put the start button inside the event structure and we don't want that to happen do we? If you have a better why please show me

I told you here… This behaviour is explained in the example VIs coming with LabVIEW. You surely played with them to understand how to use the event structure!?

Because I want the user to be to stop and start the program, with one button or two but I couldn't get one button solution to work. If you have a better why please show me

I usually start with defining an algorithm. Something like this pseudocode: "WHILE not(Stop button) WEND" - helps a lot in understanding/defining what a program should do…

Because without the strip path in place I have to provide a static file name an I want the user to type the file name in when they click the file icon. If you have a better why please show me

Right now the user simply uses the file path control - it makes no difference to put the Strip-/BuildPath combo inside. Doing something more complicated than it should be is called Rube-Goldberg…

I can go back at check to see if that works

LabVIEW provides these options because they work…

because I need a specific format of the data for import into another program and I couldn't get formainto string to output it in the format  I needed but I could give that a try again

Should result in the same string array as before:

and yours is not? what is your point

My signature shows the LabVIEW versions I use right now, so others can attach VI in a suitable LabVIEW version. I only change this, when I install a new LabVIEW version.

Your signature shows the same "joke" again and again wasting screen space without providing any useful information for us…

But to end this part of the discussion: it's your signature and you can write whatever you like to in your signature!