configurable acceleration for handwheel/jog movements

[chris2560]

I'm currently finding some severe jerking whatever I try on my handwheel control algorithm.
I'm taking the clicks from a mouse scrollwheel event, detected from tkinter in python. (my handwheel is an old mouse board with 200step/rev cnc handwheel soldered instead of the scrollwheel encoder)
I've tried 4 ways:

1. send a jog segment whenever the mouse scroll event is detected $J=G1 G91 X0.1 F600 (or using G53) and monitoring the planner buffer state, to avoid filling too far and causing a long overshoot when I stop winding. Result is jerky and unreliable running at low speed, and notable overshoot when I stop winding.
2. same as attempt 1 but with a feedrate determined by the time interval between scroll events. Result is more jerky
3. send a jog event whenever the scroll event occurs and I've recieved the 'OK' from the last jog event, and poll to see when the handwheel stops being wound. The trouble here is that when the handwheel stops being wound, I have to send \x85 and G4 P0 and then a ? and repeatedly check the serial input buffer until the status returns to idle before I can send any more jog commands. Somehow I get recursion errors
4. put the handwheel step events onto a buffer, and when I poll the serial input (every 100ms), if the jog buffer has anything in it, I send this until GRBLHal has more than 0.4 seconds of lookahead. When the user stops winding the handwheel, (triggered by a timed tkinter intrrupt after 200ms from the last handwheel click), I simply clear the jog output buffer, but leave GRBLHal to finish the 0.4 seconds of jog segments it has. This is the smoothest algoritm I've managed to make, but less than 0.4 seconds in the GRBLHal planner buffer will stutter, and even at 0.4 seconds it's constantly accelerating/decelerating. (I also keep getting Error36, I suspect the usb chip on my MKS DLC32 is struggling)

I have found, that if I set the x axis acceleration fairly low (20mm/s/s) not the default (40mm/s/s) then it jerks far less, but I want the faster acceleration when I run on auto mode, and don't want to constantly be altering the GRBLHal parameters. I'd prefer an inertia feel to a jerky feel, particularly as the inertia only comes when I wind the handwheel too fast for the usb communication to keep up with. I presume Fanuc and Haas manage it by having closed loop motors and seriously fast axis topspeed and no usb overheads?

Equally, if someone else has successfully implemented a non jerky handwheel then how does the logic work?

[terjeio]

The OpenPNP plugin has M-codes for adjusting acceleration (and jerk if enabled - untested for now).

I have made two attempts at jogging in the encoder plugin, this for handwheels connected to the controller.
My MPG implementation has code for handwheel support that sends gcode commands. It works fairly well with my lathe, the ones in the encoder plugin - I really do not know because I have not tinkered with that code in a long time.

Other Grbl MPG pendant implementations may have solved the issue of generating smooth movements - there are a few floating around.

[chris2560]

Is the OpenPNP plugin available for ESP32 yet?

[terjeio]

Added now.

[dresco]

I've got a couple of jogging implementations in my Control Panel plugin. I've tried to smooth out the acceleration for keypad jogging, but haven't felt the need for the encoder.

When you say jerky, are you referring to unstable/wavering acceleration, rather than the initial jerk as it starts moving? If the former, in my experience this happened when my individual jog commands were either too small a distance, or too fast a feed rate, for the interval they were delivered at..

My understanding is that for a planned movement, grblHAL will have a trapezoidal ramp up and down at the start and end. I think the trick for jogging is to send the requests at a rate that prevents it from getting to this deceleration phase before the next movement is added to the planner? That might not technically be a very good explanation, but is the way I visualise it - keeping some future moves fed to the planner - so that movement just continues at the requested speed.

My implementation sends jog requests at 100ms intervals by default, and I have plugin settings for jog speed & distance, so that the keypad jogging can be tuned to match machine performance. As I say, I never felt the need to do this for the encoder jog, but that might just be down to my usage, where I tend to use the keypad for coarse control, and the encoder just for fine positioning..

Btw, you can send a CMD_JOG_CANCEL when the encoder stops turning, that would help your overrun?

[chris2560]

Certainly a game of just-in-time jog segment delivery, yes by jerky I do mean unstable/wavering acceleration

Makes sense to use the steady jog for major movements particularly as I'm normally just using manual movement for setup (need to implement a nice speed configurable all axis jog function to my python computer based control panel then),
but I'm wary or faster button controlled continuous jogging particularly after an apprentice at work crashed (and completely destroyed) a Haimer 3D taster by accidentally rapid feeding down in Z, whereas the handwheel would likely have given the apprentice time to react and stop going the wrong way, saying that none of my home machines rapid so fast as that Fanuc at work can.

Guess I'm probably also having some trouble with usb overheads, particularly as I'm only getting updates 10 times a second, so currently only outputting from the handwheel buffer 10 times a second, maybe I could use some predictive logic here (based on achieved feedrate and elapsed time) and output segments 30 or 40 times a second for faster jog rates, thereby keeping the segment length low but the planner buffer fuller.

Would rather not call the jog cancel if avoidable, it was causing many headaches and recursion errors and syncing errors for some reason

(Notably when running on 1mm per click, Haas machines have a visable slow-deceration overrun as you stop winding, I assume they're also ignoring steps if you wind too fast on that mode).

Update 1/march:
Finally got around to trying again to solve this riddle. Can't seem to improve it any more, trouble is I was trying to achieve Fanuc like smooth movement up to max axis speeds, whereas a Fanuc seems capable or 2500mm/min on handwheel with 0.1mm/click, but then 2500mm/min is snails pace for a Fanuc.
I seem to remember seeing somewhere in the machine paremeters that the axis acceleration on the Fanuc was 500 (mm/s/s??) though this is bell curve.
When I actually think about this, that means at 2400mm/min (40mm/sec), and 500mm/s/s acceleration, it can accelerate to that in less than 0.1 seconds, so the equivalent of max speed for my machine would be 4mm/second with only 40mm/sec acceleration.

As I say, I never felt the need to do this for the encoder jog, but that might just be down to my usage, where I tend to use the keypad for coarse control, and the encoder just for fine positioning.

I guess that's where I'm getting it wrong, I shouldn't be expecting low end chinese steppers and stepper drivers to achieve anything comparable to the expensive Fanuc machines at work.

Thank you all for the help and pointers, I simply hadn't understood the physics of what I was asking.