Stop Button Not Working

[vindsan]

I have uploaded a program which I am doing. It is the code to back up data by sending files over network using tcp. It is divided into 4 cases. But the problem is my whole program is kept inside a while loop and stop button is used to stop the program. But unfortunately the stop button is not working. I dont know why is that. Can someone please help me by saying why is the stop button not working and what should be done to make it work. Thanking You in advance. 

[James.M]

LabVIEW programming is based entirely on dataflow and parallelism. This is incredibly powerful and has lead to its success over the years (coupled with the graphical programming), but is usually one of the first things that new developers stumble over. Here's a simple resource to become more familiar with how it works. The Highlight Execution feature is a great way to watch how your application utilizes dataflow.

Your Stop button is being read after every iteration of your loop, but your program is running and not looping while doing other things. You have waaaay too many event structures. Your code sits and waits at every single one of them until the button you want is pressed. You should only have one event structure that handles all of your user events. You even have events with different structures that will compete with each other in different cases of your case structure.

You need to rebuild your application from scratch with a better architecture. This will never work the way you have it and it would just be faster to re-do.

The Simple State Machine template that ships with LabVIEW is really the best way for new developers to get familiar with LabVIEW while utilizing a semi-scalable architecture.

Here's a broad example of how a state machine works:

• States: Init, Idle, Exit, DoThing1, DoThing2, DoThing3
• Each state contains code that might take some time. Ideally, not too long because that's how long your code could be unresponsive.
• The Idle state contains an event structure for all user interaction.
• The front panel has a button that says "Do Thing 1".

1. Loop Iteration 0: Application begins, first state is Init. The Init state does some initialization stuff and tells the application to go to the Idle state when finished.
2. Loop Iteration 1: Application goes to Idle state. It sits there, waiting at the event structure.
3. Time goes by, then user presses button "Do Thing 1". There is no code, or minimal code, within this event case. The output of this event state tells the application to go to the DoThing1 state.
4. Loop Iteration 3: Application goes to DoThing1 state. There is code here that does some stuff. The output of DoThing1 state tells the application to go back to the Idle state.
5. Loop Iteration 4: Application goes to Idle state where it waits at the event structure again.

• Each of the states can tell the application to go to any state they want. Want to reinitialize? Go to the Init state again. Want to end the program? Go to the Exit state. Want each state to trigger another (like a sequence)? Have DoThing1 output DoThing2, which outputs DoThing3,  which outputs Idle.

[altenbach]

---

@vindsan wrote:

 But unfortunately the stop button is not working. I dont know why is that.  

---

I think nothing is working right and you already got a few good tips how to correctly architect your application.

You have multiple hard event structures in the same cases and even in different cases. Even the ones that are in the "other case" will queue up events, but will never be able to service them. They lock the front panel until the event completes, but the event cannot complete because it is not in the dataflow. Deadlock!

A case with multiple timeout-free event structure can only complete once all event structures have been triggered.

Then you have serious race conditions that make the outcome completely unpredictable. Most of it is cause by mindless overuse of local variables.

Let's have a look at the following code section:

 

Once the event triggers, the listbox output is read and pushed into an array indicator (A). In parallel, the array indicator gets read via a local variable (B). Since there is no data dependency both things occur in parallel and most likely the local variable gets read before the indicator gets updated with the new listbox values and you are processing values from a stale state. Eliminate the local variable and simply branch the wire form the listbox. You can even delete the "array" indicator once you are done debugging, it is not doing anything useful.

 Never use exotic mechanical actions such as "switch until released". They have their use, but 99% of all boolean controls are typically either "switch when released" or "latch when released". Don't try to micromanage such details without plenty of thinking. Typically you should use value events instead of mouse events.

You need to learn about the basics of dataflow. Then look at the common design patterns that ship with LabVIEW I am sure there is something that fits.