Jogging of Z-axis should not allow going negative or beyond table height

[mrandt]

Currently I can crash the nozzle into the table when jogging down and also the Z-axis into the machine when going up. We should apply safe limits here - similar to X and Y axis.

[thethereza]

ensure you have set the limit switches as limiting in the configuration for z

[mrandt]

Limit switches are fine. Probably "crash" was not a good verb to use because nothing really breaks at the speeds I am operating the Z-axis at.

However, after I homed Z-axis (set upmost position to zero) and calibrate needle height, there is no point to allow jogging beyond those limits.

Currently I can move needle so far up or down that limit switch trips, resetting the TinyG. See screenshots below:

Notice how I could jog Z-axis beyond needle length until it hit the table and eventually tripped limit switch?

Same is possible moving Z-axis up - so the Z-coordinate will be negative in that case.

[thethereza]

Yes it can happen in that mode. Like doctors say, don't do it if it hurts.

On Jul 16, 2015, at 8:30 AM, mrandt notifications@github.com wrote:

Limit switches are fine. Probably "crash" was not a good verb to use because nothing really breaks at the speeds I am operating the Z-axis at.

However, after I homed Z-axis (set upmost position to zero) and calibrate needle height, there is no point to allow jogging beyond those limits.

Currently I can move needle so far up or down that limit switch trips, resetting the TinyG. See screenshots below:

Notice how I could jog Z-axis beyond needle length until it hit the table and eventually tripped limit switch?

Same is possible moving Z-axis up - so the Z-coordinate will be negative in that case.

—
Reply to this email directly or view it on GitHub.

[mrandt]

Cannot deny the truth in that 😁

As users are prevented from going negative or beyond maximum size when jogging X and Y axis, applying the same precautions to Z would probably make sense.

[thethereza]

When in that mode, the limit switches are bypasses with The assumption that the user has control over jogging up and down. Typically movements are very small so I don't see people slamming the head into the table very frequently. In order to make that work, you would have to guarantee homing before the action is taken and keep track of limits which adds complexity to the code without, what I feel, is a pressing need.

On Jul 16, 2015, at 9:55 AM, mrandt notifications@github.com wrote:

Cannot deny the truth in that

As users are prevented from going negative or beyond maximum size when jogging X and Y axis, applying the same precautions to Z would probably make sense.

—
Reply to this email directly or view it on GitHub.

[mrandt]

What do you mean by "that mode"? I believe user may hit F-keys (or maybe manual control buttons if we added those) any time?

The user also has control over jogging left and right or forward and backward. Still we prevent the machine going outside "safe limits" - so why not for the Z-axis?

Regarding your comment about guarantee homing: I do feel a pressing need for that. See my feature request recorded as issue #8 - I think the machine should not be allowed to move at all (neither jogging nor automatic moves) unless it has been homed correctly.

If there was a use case to move before homing, we should make that an "expert mode" or use a "you might break things, are you really sure?" confirmation dialog.

Whatever users can do wrong they certainly will at some point... And I am not as arrogant as to exclude myself from that assumption.

[thethereza]

I personally would hate requiring it to be homed every time. It would waste
a lot of my time as I restart the app often and the tinyg knows where it
is.

On Thursday, July 16, 2015, mrandt notifications@github.com wrote:

What do you mean by "that mode"? I believe user may hit F-keys (or maybe
manual control buttons if we added those) any time?

The user also has control over jogging left and right or forward and
backward. Still we prevent the machine going outside "safe limits" - so why
not for the Z-axis?

Regarding your comment about guarantee homing: I do feel a pressing need
for that. See my feature request recorded as issue #8
#8 - I think the
machine should not be allowed to move at all (neither jogging nor automatic
moves) unless it has been homed correctly.

If there was a use case to move before homing, we should make that an
"expert mode" or use a "you might break things, are you really sure?"
confirmation dialog.

Whatever users can do wrong they certainly will at some point... And I am
not as arrogant as to exclude myself from that assumption.

—
Reply to this email directly or view it on GitHub
#3 (comment)
.

-Reza

[mrandt]

Why would you restart the app but leave TinyG on - besides during development? Never occured to me, unless the application crashed or I wanted to switch releases.

I want my system to run automated and unattended as much as possible. IMHO the simpler from user point of view and the less error sources, the better.

I do see the benefit of reducing the likelihood of a user error (clicking Test X and see machine banging into the opposite frame) which might even result in hardware damage by enforcing home and managing home state and positional confidence - but I also see we might have different opinion about this, fair enough.

I suggest that - as a compromise - we could include configuration options to disable safe limit checks per axis and also enable or disable "enforce homing".

I will keep this issue open as a feature request - @jkuusama could mark it accordingly once he's back from vacation.

[thethereza]

I leave the machine on most of the time. To power cycle I have to move to the next table so I leave it on. I also don't pay for electricity in my office. If you home and quit the all it should move to home so that it's already homes when you restart the app.

On Jul 17, 2015, at 2:45 AM, mrandt notifications@github.com wrote:

Why would you restart the app but leave TinyG on - besides during development? Never occured to me, unless the application crashed or I wanted to switch releases.

I want my system to run automated and unattended as much as possible. IMHO the simpler from user point of view and the less error sources, the better.

I do see the benefit of reducing the likelihood of a user error (clicking Test X and see machine banging into the opposite frame) which might even result in hardware damage by enforcing home and managing home state and positional confidence - but I also see we might have different opinion about this, fair enough.

I suggest that - as a compromise - we could include configuration options to disable safe limit checks per axis and also enable or disable "enforce homing".

I will keep this issue open as a feature request - @jkuusama could mark it accordingly once he's back from vacation.

—
Reply to this email directly or view it on GitHub.