Event Structure... mouse down or value change case

[Robi56]

Just for a different approach... I needed a jog for 2 axis and wanted continuous motion with the button down.

Any of the buttons = True- performs motion, all false- stops. Timeout of 100ms gives a reasonably fast response time for this machine.

[altenbach]

---

@Robi56 wrote:

Just for a different approach... I needed a jog for 2 axis and wanted continuous motion with the button down.

---

This was a 8 year old thread and showing a flat code picture does not help at all. You are not even showing the event case for the mouse or boolean! Attach your code and explain in detail why your approach is "better"?

Why are there so. many. local. variables??????

I would recommend to start a new thread, post your code, and we'll show you how to do it correctly.

[altenbach]

---

@Robi56 wrote:

Just for a different approach... I needed a jog for 2 axis and wanted continuous motion with the button down..

---

Here's one possible solution that does not need any local variables or high Aztec pyramids of case structures.

See if it can give you some ideas how to adapt your code.

[Robi56]

Thanks,

I didn't mean to imply better. Just different. You did shame me into modifying my code. I wasn't pleased with the Aztec approach at the time...

The point was that during timeout if a button is held own 1 case is triggered, all buttons released another case (stop) is triggered. That might have been all that was required.

[altenbach]

Glad to help.  Maybe it will help more than one person. 😄

Well, we only had a small picture of your code and there was no way to tell much from it. (We can't see the code in all these other cases, code in other events, mechanical action settings, front panel look, locations of the terminals for all these local variables, etc. It is not even clear why you have an event structure if you are polling the bulk of the code 10x per second forever, even when nothing needs to be done.)

So, my program is a completely fresh approach, starting with a blank diagram.

It is a general and simple solution that can equally well be applied to the original one-axis problem. The loop only spins when something needs to be done and is waiting patiently otherwise. Place an indicator for the iteration terminal and you'll see the difference with your code. A mechanical action of "switch until released" will generate two events, one on press and one on release and my code guarantees that the action is seen. If you instead poll such a switch, you can easily miss a user interaction unless you happen to read the terminal in just the right moment, e.g. if the button is pressed for 80ms, there is a nonzero chance that the code misses the TRUE.

I am sure things could be improved further....