subvi does not stop from the mainVi immediately when the stop button pressed in the mainVi

[vahid_blaster]

Hi guys,

I have a mainVi which has a subVi inside. I want to have a kind of emeregency stop button in my mainVi.

when I pressed the button, the program does not stop instantly. it does one loop and then stops.

please help me to solve this problem.

Attached you can find the Main and SubVI

[johnsold]

This is basic dataflow. Any code is available to run as soon as data is present on all its inputs. No data is present at its outputs until all the code inside has completed.

What this means in your case is that the stop button will likely be read almost instantly when the while loop starts an iteration. It will not be read again until the start of the next iteration. This is why it will usually take an extra iteration to stop. You can either force it to read the stop button after the other code inside the loop completes or use a Producer/Consumer (events) architecture where the stop button will be read in a parallel loop containing an event structure.

It also means that the Move_MINI subVI has no means of responding to any external events (such as the stop button being pressed) after it has started running. All the other subVIs are missing so it is hard to tell what is going on. From the control labels and VI names I suspect that this may be some kind of motion control system. If so it probably takes 100s of milliseconds to seconds or longer to complete a move. To allow an external event to modify the behavior of such a VI, you need a means of communication between the event (stop button) and the VI. A notifier may be an appropriate choice. The VI also needs to be configured in such a manner that it never goes more than about 100 ms without an opportunity to stop. Without knowing more about the subVIs, I cannot say how this might work.

Lynn

[vahid_blaster]

Thanks Lynn. What do you need to know exactly about the SubVI?

As you mentioned, the program is running a servo motor.

I still dont know what to do!

[koushik_Shetty]

The design is not proper for your applications. there is lot of things you need to consider before going into this.

1) have states in your design(state machine).

2) have queues(queued message handler).

3) have event structure.

if you know these 3 you can have better design for this application. there are examples for the above 3 so "Google It". #2 has #1 in it. so learn about #2 and #3

[vahid_blaster]

Actually I did not design all the SubVIs myself. The codes was given by the controller manufacturer. I only combined them partially to create my required control for moving the motors.
I believe this problem should be solved much simpler than this. there should be a way to read the stop button control immediately and stop the program.
Besides, I tested the LavVIEW stop button to stop the program. even that does not stop the motor immediately. the program stucks somewhere in a loop or.....?!

[GerdW]

Hi Vahid,

I believe this problem should be solved much simpler than this. there should be a way to read the stop button control immediately and stop the program.

Well, your MainVI looks ok to me: you read the stop button and end the loop depending on its state.

BUT: THINK DATAFLOW! The loop itself can only stop once all the subVIs have finished…

(And please remove that RubeGoldberg after the STOP button. Either use a simple NOT function here or switch the STOP button from ActiveHigh to ActiveLow…)

Besides, I tested the LavVIEW stop button to stop the program. even that does not stop the motor immediately. the program stucks somewhere in a loop or.....?!

It seems that one of your subVIs is calling an external function (maybe a DLL) which needs quite some time to execute. Please look for yourself as we cannot do this due to missing subVIs…

[johnsold]

You have been given some good advice.

The problem stopping is most likely due to the way the subVIs provided with the controller operate. You CANNOT stop the program until those subVIs stop if they are already running when the stop button is pressed. (And, as I stated in my earlier post, it may require one complete additional iteration of the for loop).

If you need to stop the system in less time than the time it takes for those subVIs to complete one call, then you have only two choices: Write new subVIs which can be stopped faster, or Create a hardware stop that interrupts power to the motor without waiting for the software.

We cannot tell you what you might be able to do with the subVIs without knowing what is in them. 

Another thing to try: Ask the controller manufacturer how to stop their software within your time limits (such as <=100 ms).

Lynn

[vahid_blaster]

Hi GerdW,

Thanks for your comment I will remove that part for sure 😉

Here I provide all the subVIs that I have.

I have tried to find the problem but I could not. I have heard from some one that using Property Node for stop button may solve the problem. What do you think?

Cheers,

Vahid

[RavensFan]

A property node could work.

Looking at the hierarchy, it seems like the long waits may be occurring in the WaitReady.vi.  If you check the property node of the stop button there (but you'd have to pass a reference to it all the way down the hierarchy), it could more quickly detect that you've pressed the stop button.

I think a better architecture would be to use a separate loop in your top level VI that monitors the status of the stop button.  (Perhaps use an event structure to detect the change.)  Update a functional global variable with that information.  Wherever you need to stop a loop early, read the functional global variable and OR that with whatever other stop conditions you have for those loops.

Like any situation, you need to be careful of race condtions.  Make sure you only write values to a functional global variable, a  local variable, or a global variable in only one location, and only perform read operations in the other locations where you need that information.

[johnsold]

That driver looks like it was written very long ago.  The serial port VIs have been replaced by VISA Vis and functions in newer versions of LV. 

The driver VIs are not written in such a way as to be easily modified for the stop you want.  WaitReady.vi could wait as long as 5 minutes if the remote device continues to communicate but never sends an "R" in the correct spot in the string to stop it.

You might be better off re-writing the drivers using VISA and designing the revised versions to never stay in a subVI longer than ~100 ms without checking for the stop button.  I thnk it would be easier (and you would likely get better results) to start over and do it right than by trying to force a modification into the existing driver VIs.

Lynn