Manual mill knob emulation

[Meliusja]

I have tried multiple ways of fine positioning with grbl and grblhal such as keypads, mouse, playstation controllers and they all are slow and too easy to make a mistake and slam into the work piece, table or fixture. There is nothing as simple as a graduated knob on the screw.

I would like to modify the encoder plug in to work as follows:

2 encoded push button inputs - Axis X - 0,1 Axis Y 1,0 Axis Z 1,1
2 encoder inputs

When one of the three buttons is pushed the plugin will capture the encoder counts. Then start moving that axis relative to the number of counts moved on the encoder. Would need a scale factor parameter for encoder counts to distance. When the pushbutton is released the axis will stop following the encoder. While the button is pushed it should feel like the ball screw is attached to the encoder wheel, It seems something like this was started but I couldn't see any axis selection method. My question is are any significant problems anticipated with this approach?

An enhancement would be to add one more input that is a fine or coarse selector switch that selects a different scale factor between counts and distance.

Jeff

[terjeio]

Keypad step jogging can be made pretty precicse by can be slow to use.

2 encoded push button inputs - Axis X - 0,1 Axis Y 1,0 Axis Z 1,1

Per axis? The plugin can claim auxilary inputs and even subscibe to pin change (click) events. So can be done if the driver provides enough inputs.

2 encoder inputs

Implementation of the physical interface is at the driver level - events are posted via the hal.encoder.on_event function pointer - here is one example. Events from multiple encoders is supported.

Then start moving that axis relative to the number of counts moved on the encoder. Would need a scale factor parameter for encoder counts to distance.

If you want to generate steps directly (bypass the planner) then this can be done by calling hal.stepper.pulse_start and syncing the position after each step. Upscaling the number of steps to generate for each encoder tick is not easy?

For my MPG & DRO I send jog commands based on sampling the encoder on regular intervals, it is not easy to get right and encoders with detents causes jerky movements at slow feedrates. Precise positioning is not hard to achive as the target position is displayed (in a different color) while jogging. I have a 600PPR encoder without detents that I want to try with this approach - this should get rid of the jerky movements. One turn of the encoder translates to either 1 or 10mm motion so it mimics a handwheel.

My question is are any significant problems anticipated with this approach?

One may be enough available pins on the controller MCU, sending pulses if upscaling is needed another.

[terjeio]

This is what you want (video)?

[Meliusja]

Yes that video is similar to what i am looking for. To be more specific, I am using a T41U5XBB board. The board has the 4 aux inputs as you know. I want to wire 3 buttons and the encoder using these 4 aux inputs. The buttons would probably be read periodically and while a button is pressed to enable the associated axis the motion would follow the handwheel as in the video. 1mm and 10mm per rev sounds about perfect. It sounds like what you have is very close to what I want.