search

FabMo / FabMo-Engine

The FabMo Engine - A software and apps ecosystem for digital fabrication.
http://gofabmo.org/
Apache License 2.0
55 stars 22 forks source link

Trying to abort a manual move with the keyboard has unexpected and ...bad results #911

Open obra opened 2 years ago

obra commented 2 years ago
image

I was at 23,16, entered "1" into the "X" text entry field and noticed that my z was a little low. I Immediately hit "Return" to try to abort the move. But since the cursor was focused in the X box containing a constantly updating value for the tool location, what happened was that the move completed and then returned to the position it was at when I hit return, since the UI saw me try to "move" to that location.

RobMackie commented 2 years ago

We need to define what the right way to stop such a motion from the operator console is (not from the pendant but from the web-browser.

Once we have that decided, it should be pretty implementable.

obra commented 2 years ago

A good couple issues I had today would have been solved by having focus jump to the "Stop" button if it was displayed. I think that hitting return, hitting escape, hitting space or clicking the stop button should all kill motion. If I'm trying to stop the spindle from moving, it's usually moderately urgent and the absolute highest priority thing going on.

kyle-kingsbury commented 2 years ago

In my mind, return is the accept button. I often hit it when I want the machine to move. Though I guess it would make sense that if the machine is already in motion that accept would stop motion. Never thought of it that way! What you describe seems dangerous and unexpected. Definitely needs to be fixed.

RobMackie commented 2 years ago

Have been thinking about this a lot. Jesse I think we need to send you a button to use as a "feedhold" button, unless you have a nice big momentary push button handy.

Why do I think a hardware button is the solution? FabMo is present on the control station as a web application in a browser. There is no assurance that the focus will even be on the browser, let alone on the right widget. I think we should work to make sure that if the focus is on the browser the right thing happens - so Jesse's comments stand, but I think that when something is going wrong, having one single purpose and completely reliable method of stopping things short of estop is a good idea. Our newer desktops will have that on a pendant.

What do you think Jesse? does a 3" or 4" button that stops all motion sound like a good idea to have at the tool?

Rob.

Rob.

On Fri, May 20, 2022 at 11:39 AM Kyle Kingsbury @.***> wrote:

In my mind, return is the accept button. I often hit it when I want the machine to move. Though I guess it would make sense that if the machine is already in motion that accept would stop motion. Never thought of it that way!

— Reply to this email directly, view it on GitHub https://github.com/FabMo/FabMo-Engine/issues/911#issuecomment-1133048327, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA3QBLU2TGIJVKIE4EGHKMLVK6W4RANCNFSM5WNXFBGQ . You are receiving this because you commented.Message ID: @.***>

obra commented 2 years ago

On Fri, May 20, 2022, at 10:19 PM, Rob Mackie wrote:

Have been thinking about this a lot. Jesse I think we need to send you a button to use as a "feedhold" button, unless you have a nice big momentary push button handy.

As it happens, my stock in trade is buttons and switches. They're typically a bit smaller than that, though. Depending on the right way to wire it up to the device, I can almost certainly hack something up. Are there existing docs or schematics?

Why do I think a hardware button is the solution? FabMo is present on the control station as a web application in a browser. There is no assurance that the focus will even be on the browser, let alone on the right widget.

Yup. There are limits on what the browser can do, but those limits are..broader than they used to be. Between the full screen API and https://developer.mozilla.org/en-US/docs/Web/API/Pointer_Lock_API, you can make something that's likely "as good" as SB3 even without the hardware.

I think we should work to make sure that if the focus is on the browser the right thing happens - so Jesse's comments stand, but I think that when something is going wrong, having one single purpose and completely reliable method of stopping things short of estop is a good idea. Our newer desktops will have that on a pendant.

Is the plan for the pendant to be part of the eventual retrofit kit? How are y'all implementing that? Is it wired to the G2 or to the fabmo? It occurs to me that one could do a very rough version of a pendant with a cheap USB 10key numeric entry pad and something listening for HID events on the pi.

What do you think Jesse? does a 3" or 4" button that stops all motion sound like a good idea to have at the tool?

I do think that having a big motion stop button is the right thing. I don't know that I need something custom ginned up for me, though. If it's something that you expect to ship to customers, I'm perfectly happy to test it out.

Best, jesse

tedh-shopbot commented 2 years ago

I agree with Jesse's first suggestion above. Whether an external button or not, the focus and cursor should go to the Stop button in when a "go to" in the keypad is in play. That way, an ENTER or a CLICK will both produce a Stop. (And, assigning a hardware stop also works fine.)

We chose using the browser knowing that there would be the issue that the client could be in another app -- the need for having a hardware button at the tool as a stop was pretty much a given since the client does not even need to continue running for FabMo to be cutting.