Event Structure... mouse down or value change case

[AsstToRegionalMgr]

I get the feeling this is a simple problem, but I can't seem to figure out a solution.

I have a VI that is supposed to communicate with a stepper motor drive.  I am working on placing boolean buttons on the front panel (acting as momentary switches) that will jog the motor CW or CCW as long as the button is pressed.  Once the user releases the button, the motor should stop jogging.

I have tried to use both the mouse down and value change event cases.  Using mouse down, for some reason the timeout occurs almost immediately even while holding the mouse down on the button.  This results in what appears to be nothing happening.  Although the motor is recieving all the commands it needs to run, it recieves the stop command immediately after.

Using the value change case, the procedure works and the motor spins, but when releasing the button (another value change), all the jog commands are resent to the motor followed by the stop command.  Sometimes the motor continues to spin after the stop command has been sent, and I think this could be occuring because it recieves all the jog commands (again) and the stop command at once.

Is there any way to cnage my event case to run the way I want it to... Send commands on button click... Send different command on button release.

Thanks.

[LV_Pro]

There are a number of issues with how you have written it. When you press one of the buttons you get essentially two events, button down (timeout -1, never timeout) and button released (timeout 10 milliSec). The timeout input is in milliseconds. If you encase the action in the up or down button in a case statement, and just pass the timeout wire through on the false this will help. Then have the timeout set in the "timeout" state back to -1.

Also, move the open, configure and close out of the loop, so that it happens before you enter the loop, and closes upon exiting the loop. Leave the actual writes in the their respective event cases. Create an exit or stop button and an "exit button event", and wire that to the stop, with the other cases having a false wired out to it. You shouldn't stop your vi's with the stop button on the tool bar.

[AsstToRegionalMgr]

Thanks a lot for the help...

I'm having trouble understanding what you mean by "encase the action in the up or down button".  Should I keep the layout roughly the same as it is now, but change what value gets sent to the timeout using a case structure rather than the select function?

Ultimately, will this solve the issue I am having with sending the same commands on button click and button release?

[aputman]

Here is one way.  I'm sure there are more elegant ways of doing it.  Just replace the Random number generator with your VISA code...taking into account what was already said about moving the Open/Init/Close routines outside the loop.

[AsstToRegionalMgr]

Thanks for the suggestion...

I was able to solve the issue I was having.  Previously, I was attempting to chage the timeout from -1 to some value greater than 0 to initiate the timeout event on a button release.  To solve the issue, I simply removed all the code that was changing the timeout value, and left the default timeout at -1.  I also removed all the code in the timout case.  Then I created a new mouse up event case that is triggered by releasing either of the buttons, and copied in the code that used to be in the timeout case.

Now the VI works exactly as I need it to... where one event happens on a mouse click of a button and a different event happes when the button is released.

Very simple solution, however I have only been working in LV for about a week and I didn't even see the mouse up event when I was scrolling through the event options.

[johnsold]

You may also need to deal with Mouse Leave.  If the button is pressed and the cursor moves off the button before the Mouse Up, no event is generated.

Sophisticated User Interfaces can be tough.  Explore the menus. Try things.

Lynn

[AsstToRegionalMgr]

That's a good point.  I wonder if there is a way to force the pointer to stay within the limits of the button when it is pressed.  Since LV knows when the cursor passes over the button, it's not a stretch to think you could force the cursor to stay there.  I've seen this type of operation on CNC machines where the cursor is forsted to stay over the STOP or ABORT button while the machine is running.

I suppose it would also be a sneaky way to play a trick on someone by placing such code in a mouse over event with no timeout and no other event case.

[johnsold]

I am not sure that it would be a good idea to constrain the motion of the cursor. While CNC users may get used to that behavior, computer users really expect to be able to move the mouse anywhere.  Frustrating users without a clear benefit to those users is usually a start down the path to joblessness.

Look at Mouse Enter and Mouse Leave events also.

Maybe what you want is the Value Changed event with the button Mechanical Action set to Switch Until Released (equivalent to a momentary action switch).  That generates an event when the button is pressed and (the same) event when it is released.  That way LabVIEW and the OS handle all the issues about where the cursor is relative to the button boundaries and everything tends to work the way users expect.  You could use code similar to aputman's snippet except that you would need to select one of two messages depending on the value of the switch (Start or Stop).

Lynn

[paulc314]

I had an identical problem. I was using the event structure, and encountered a problem since event structures will unlatch latched boolean variables (ie: mechanical action)

How I dealt with the proble is as follows, using a control "jog" set to "mechanical action -> switch when released"

-set event for "jog" to value change

-use a case structure for jog = true to enable your drive. Set up your task to run the drive indefinitely

-using same case structure, when jog = false, disable drive by clearing task.

worked for me. 

[RavensFan]

---

@paulc314 wrote:

I had an identical problem. I was using the event structure, and encountered a problem since event structures will unlatch latched boolean variables (ie: mechanical action)

---

Actually event structures do not unlatch the latched booleans.  The reading of the control's terminal is what unlatches the button.  Generally. you do want the terminal in the event case for that boolean so that the terminal will be read and pop the button back up when the event is handled.

The key thing is using the correct mechanical action depending on what you want the button to do.  For a 1 press 1 action, do something like start or stop, then pop back up, you generally want Latch when released, and put the terminal in the event case.

For a state that where you push a button in and you want it to stay there until you push it back up, then you want Switch until released.  (Like a single button Power On/Off button.)

For something where you want the button to only stay in while pressed, but immediately pop back out when you let go, so that you have a continuously maintained True as long as you hold the button in (like a spring action jog button), you want Switch until Released.

I have yet to find a practical use for Latch until Released, (the button stays in until either you let go or the terminal gets read.)

Switch when Pressed and Latch when Pressed are similar to the "Until Released" version of the Switch when Latch, but the difference is the action happens when you press in on the button as opposed to waiting until let the mouse click back up.  These might have a use in a user interface where you rely on timing of the user interaction, but go against the behavior of most buttons in other Windows applications.  The Until Released versions allow you to drag the mouse off the button before you let back up on the click allowing you to undo your interaction with that button in case you make a mistake and act like you never pressed it.