Authorize: Timer that sets the duration of an "Authorize" action is not working.

[tedh-shopbot]

You should be able to set how long and AUTHORIZE input persists.

[kyle-kingsbury]

For clarity, is this what you are talking about?

[kyle-kingsbury]

Currently this setting controls how long the "authorize" popup remains on the screen. If it is set to 0 then the popup never appears. If it is set to 5, then after 5 seconds the popup disappears. If the timeout is exceeded the program does not run

From what you have said, this setting is supposed to authorize the machine for the designated time, and this functionality did work at one point.

[tedh-shopbot]

Yes. That is the setting that sets the duration of "Authorize" that is not working (at least for me).

[RobMackie]

I'm curious - It seems odd to me that you would authorize the tool for a period of time. It seems like any type it stops, a new auhtorization should be required before it moves again. I can see how a timed pause that is short enough not to pop a dialogue could be treated like a "dwell" - meaning that from the users perspective the planner never stopped planning and they aren't interacting with it to restart it. Any time there is a dialog on the screen that could start the tool, it seems like the perons at the tool would want to have to push the button if they have activated the authorization required feature.

Another exception I could see to having to push the authorize button (other than timed pauses that don't pop a dialog) would be during the any time period between the user starting a file and the first actual motion command being sent to g2. So if there were a bunch of "pause with message" dialogs, they could move through those and only need to push the authorize button once fabmo is ready to send its first motion command to g2, and then of course any other time motion is "stopped in a way that the user can restart" would then require authorizatiton.

We probably need to decide what the correct behavior is so we can implement the right thing.

[tedh-shopbot]

@RobMackie ... anytime in a file there is a stop, particularly a feedhold, that should require re-authorization. I certainly agree!

However, the the "authorize" request is generated in a number of situations where is not really about a file being underway, because anything that activates a runtime basically triggers authorize. There are, for example, housekeeping functions like moving the tool around a bit to get ready to run a file. Opening the keypad generates a request -- as it should. However, if you close the keypad, make an adjustment and reopen it, another authorize is required. This can get very awkward when you are just trying to make a few moves.

There is also the case of the Sb4 Command line, where one frequently sends a command to change a speed or make a small move -- usually by way of getting the tool set up. Again, it gets awkward to work with the frequent authorize requirement on each submitted command.

And, (not supported yet) there are in-file triggers for authorize in macros that can cause a homing or a tool change to need several authorizes. We should have a way for a programmatic override of the authorize by the file developer for cases where there is no need.

All this is by way of not discouraging people from making regular use of a safety function.

Our earlier release of FabMo on Handibots was unfortunate because of software failures. These are almost exclusively related to the instability of Edisons on Wifi networks and the unreliability of earlier versions of G2. In general, we had worked through most of the features of that version of FabMo and were pretty happy with them for a starting point. The usefulness of say a 30s window of authorization was something that seemed to work well.

[RobMackie]

We need a full definition of what the correct behavior is to make it a useful and safe feature before we do work coding.

[RobMackie]

check that exiting keypad unauthorizes motion