Backlash Compensation Feature Request

[mediaplateau]

Description

I would like to see some basic backlash compensation in Cncjs. Unless someone is motivated to to implement it, I'd be willing to take a stab at it, although I'm not sure my programming skills are up to the task.

Basically all machines have some amount of backlash. Whenever the machine changes its direction there is a certain amount of play (number of steps required) before the machine will start to move in the opposing direction. I think implementation could be as simple as adding a few steps upon a positive direction change, and subtracting a few steps upon a negative direction change. These steps would need to be speed controlled. These additional steps should not change the Work Position / Machine Position.

Of course, some new configuration values would have to be added for the amount of backlash for each axis.

Example of Backlash Compensation in Mach3
https://www.youtube.com/watch?v=A27nOkTFYDY

Versions

• CNCjs: 1.9.12

How Do You Install CNCjs?

• NPM

CNC Controller

• Grbl

Hardware

• Raspberry Pi

Operating System

• Not Applicable

[MitchBradley]

I don't think CNCjs is the right place to do this. CNCjs is a user interface for machine control software such as GRBL, TinyG, Smoothieware, etc. The machine control software in turn runs on an embedded board, typically an Arduino. The machine control software has enough knowledge of the low level machine state - and sufficient real-time capabilities - to do backlash compensation, whereas CNCjs does not. CNCjs doesn't know about the machine parameters - steps-per-mm and speeds and such things.

Another way of looking at the division of labor is that CNCjs is responsible for sending GCode commands to the controller, and the controller is responsible for interpreting those GCode commands to move the machine. Backlash compensation is at the "move the machine" level.

Mach3 includes the machine control function and the user interface function in the same software package. Its backlash compensation is almost certainly done in the machine control portion of the code; the portion that is analogous to GRBL or TinyG.

While it is certainly possible for CNCjs to "edit the GCode on the fly" in hopes of fixing backlash, that adds a level of complexity that I personally think is a not a good idea. Getting it right, and keeping it working in the face of all the different machine types that CNCjs supports, would be very difficult.

Backlash compensation is not as simple as just fiddling the GCode coordinates. For circles/arcs, the direction can change multiple times on different axes during a single G2 or G3 command. There are other complications too. If you change a coordinate in a G1 move that is followed by a G2 arc, you can mess up the starting point of the arc and invalidate the radius.

Now, having said that the machine control software is the "right place" to do backlash compensation, you might ask about the status of that feature in current machine control software. It turns out that neither GRBL, TinyG, Marlin, or Smoothieware support it, despite numerous proposals. The consensus among those developers is that it is likely to cause more problems than it solves, even in the context of the low-level firmware that has detailed knowledge of the real-time motion state.

[cheton]

For G2/G3 arcs, it needs to implement a pre-processor to expand an arc to multiple G1 lines to avoid splitting up arcs. Backlash compensation is beyond the scope of the current development plan, I will back to check this when it's added in Universal G-code Sender (UGS).

winder/Universal-G-Code-Sender#132