Message box stops other things happening?

[SteveL]

I am relativley new to Labview and I'm having a problem with a message box in LV8.

The task seemed simple: LV is controlling a relay that starts a motor. There is a front panel switch that starts & stops the motor. The motor moves a small metal table from left to right or right to left. There is a limit switch at each end of the table traverse. If the user attempts to drive the table too far in either direction it will trigger a limit switch. The program monitors the switches and if either one is activated it switches off the power to the motor. All of that bit is working.

Then I thought it would be sensible to tell the user that it had happened, and which switch had been hit.

A message box, I thought! Well, no, not that easy.

To keep things simple I decided to use two CASE structures: one for each switch. ( I am sure there is a much better way but I am still learning). Each CASE structure has a Property Node of the Front Panel motor on/off switch within it that turns the motor off. If I put a message box within either structure, the program ignores the On/Off Property node until the user clicks OK on the message. This means that the motor continues to run!

Any help would be appreciated.

Steve Lawson.

[Chris Davis]

I am relativley new to Labview and I'm having a problem with a message box in LV8.

The task seemed simple: LV is controlling a relay that starts a motor. There is a front panel switch that starts & stops the motor. The motor moves a small metal table from left to right or right to left. There is a limit switch at each end of the table traverse. If the user attempts to drive the table too far in either direction it will trigger a limit switch. The program monitors the switches and if either one is activated it switches off the power to the motor. All of that bit is working.

Then I thought it would be sensible to tell the user that it had happened, and which switch had been hit.

A message box, I thought! Well, no, not that easy.

To keep things simple I decided to use two CASE structures: one for each switch. ( I am sure there is a much better way but I am still learning). Each CASE structure has a Property Node of the Front Panel motor on/off switch within it that turns the motor off. If I put a message box within either structure, the program ignores the On/Off Property node until the user clicks OK on the message. This means that the motor continues to run!

Any help would be appreciated.

Steve Lawson.

Sounds like you are running into dataflow issues. Message boxes are modal, which means that they stop execution until the OK button is pressed. The easiest way to solve your problem is by using a sequence structure, to ensure that the property node is executed before the message box is displayed. Look at the sequence structure example that ships with labview called Time to Match.vi. I found it by searching for structure in the NI Example Finder.

[Louis Manfredi]

Hi Steve:

Welcome to LAVA...

might be easier to help if you included your code, but I think I can make some suggestions without seeing exactly what you have done.

The message box ties up the thread that it is in until the user acknowledges it. If the message box comes up before the motor is shut off, then (as you've found out) the motor keeps running...

Since you're a beginner, probably don't want to get into discussions of putting the motor control in a separate thread.... :!: Although if there are risks of damage to life or property involved in failure to properly control the motor it's control should definitely be in a separate thread-- indeed, in separate non-windows-os computer, such as a LV realtime system. :!:

So, assuming the consequeces of a crash are not drastic, and working with a single thread, what you need to do is shut the motor off before telling the user why it shut off.

At least three ways of doing this:

1. Rather than have a dialog box, have a boolean indicator on the front panel show the state of the limit switches. (Similar to the reporting means I use for a project I'm working on now with motor control.)

2. Within each of your two case structures, insert a sequence structure. Shut the motor off in the first frame, then post the message in the second. (Quick & dirty, simple mod to the program you've already got.)

3. Rewrite your program as a state machine, go first to the shutdown motor state, then to the post message state. (Quite a lot of learning for a beginner, but a very good programming architecture model, well suited to LabView & for that matter many other programming languages. Overkill for your current project, but a good investment in your knowledge for future programs -- even perhaps future versions of your current program--- which might be more complex. If you've got the time, search this forum on "state machine," there is a lot of traffic.

Even if you fix the dialog box problem, there is a risk that Windows will wander off to do some general housekeeping while the motor is running (leaving the pot on the stove?) so if there's a risk to life or property if your motor drive crashes its limit switches, hard wire them or get a real-time motor controller.

Best Regards, Louis

[ned]

This is exactly the expected behavior. The Dialog Box vi does not terminate until the user clicks the button, and that's important - there are times when you might want to wait for the user to acknowledge the message before continuing (that's why there's an output from the Dialog Box vi). A structure (case statement, while loop, etc) can't complete until every VI inside of it has terminated, so your VI waits in the case structure until you click OK.

Second, the code is not ignoring the effect of the property node until after you click the button - in fact, you may see that the motor button does change positions on the front panel while the message box is still visible - but that's not enough to turn off your motor. Somewhere in your code you must be reading the value of that button and writing that value to a relay, and your motor isn't turning off because the message box is preventing that read from occurring.

One easy solution is to write directly to the relay inside your case statement (but also update the property node so you don't turn the motor back on again after the user acknowledges the message). Another is to put your message box in a separate loop, and use a notifier to tell that loop to show the message box. If you post your code, I'm sure someone will be able to suggest a good solution for you.

[SteveL]

OK, I just answered my own question:

The solution was simple. I took the message box outside the case structure. Now, this on it's own doesn't fix the problem but I also added a compound 3 input AND gate.

The inputs to this were from Limit Switch 1, the On/Off switch, and the switch that reverses the motor direction (sorry, I didn't mention that last one). I then added more code that changes the Forward/Reverse front panel switch to the opposite of where it was.

Now, these inputs will only give an output when a/ the motor has stopped, b/ the Forward/Reverse switch is in the correct direction for that Limit switch, and b/ that Limit Swtch has been activated. All of this is only TRUE when the CASE structure has already done it's bit and finished. Therefore the message box doesn't interfere with anything.

Steve.

Thanks to everyone that answered:

I composed my solution reply and sent it before I realized that you had all taken the trouble to answer, sorry.

Now, I did try putting a sequence inside the case statement but it isisted on the last sequence (the message one) being finished before it would do what was in the first two boxes in the sequence.

I checked the NI site and there was an article there that said something about all things being completed in a sequence before it would carry out the instructions in the whole thing? I thought this was odd!

Until 2 weeks ago I had never used Labview (I was brought up on BASIC ,VB, and Delphi).

Programing with pictures has been a struggle but I'm getting the hang of it.

Right, I must read about threads and state machines :-)

I am sure that in a few months time I will look back at this first program and wonder how I managed to write it so badly: That's programming.

I am also sure I will be asking some more questions, and this time I'll check for answers before sending my own replies!

Have a good weekend.

Steve Lawson

York University

Physics Department.

[Ton Plomp]

Now, I did try putting a sequence inside the case statement but it isisted on the last sequence (the message one) being finished before it would do what was in the first two boxes in the sequence.

I checked the NI site and there was an article there that said something about all things being completed in a sequence before it would carry out the instructions in the whole thing? I thought this was odd!

Programing with pictures has been a struggle but I'm getting the hang of it.

Programming in pictures aouch.....

But what sequence structure have you used?

have a look at Darren's nuggets on flat sequence

Ton

[i2dx]

Programing with pictures has been a struggle but I'm getting the hang of it.

Right, I must read about threads and state machines :-)

I thinks wether you like graphical programming or not is a question how your brain is structured. I, e.g. can't remember street names, names of persons and dates but I can remember exactly on the LabVIEW code, I wrote 3 years ago. If my customer calls me "Hi, we have a problem with xyz" I take a quick look on the code (and I know which VI I have to look at) and can answer his question within minutes ...

I was really happy with Labview, because I found out that I will never have to search a missing semicolon again or a typo in a long variable name ... that's great