-
Notifications
You must be signed in to change notification settings - Fork 3
Development Path and Future Needs
This page is intended to be a central place where grbl future development path of features are listed. Feel free to discuss and place any insightful comments into the 'Issues' messaging board.
Development finished. Only bug fixes will be applied to this branch.
- Run-time execution: Done.
- Feed hold and resume: Done.
- System abort: Done.
- Program stops: Done.
- Real-time status report / DRO: Done.
- Updated user settings: Done.
- Run-time settings: Done.
- Work coordinate systems: Done.
- Runtime Command Pins: Done.
- XON/XOFF software flow control: Done. But only possible on Arduinos with FTDI USB chips.
-
Axis acceleration independence: Currently, grbl has one acceleration limit parameter, but in most machines the acceleration limits are not equal for all three axes. More often than not, they are much different, i.e. CNC router table movements or mill Z-axis spindle vertical movement. The planner will need to be re-written to account for these, but it's difficult to say how much of a cycle budget there will be when v0.8 is finished. So for now it's placed into v0.9 as a future development.
-
Real-time adjustable feedrates: On Haas CNCs, there is a feature with 5%, 25%, 50%, and 100% real-time feedrate adjustments. This is primarily for testing and proofing g-code programs and to adjust feedrates live, if a cutting tool is chattering and needs to be slightly sped up or down. The main issue is how to react to these de/ac-celeration changes real-time without skipping steps under an uncontrolled change. This may be difficult to do with the current code structure, but as Jens Geisler suggests, "An external interface could break every move into small segments and feed them just ahead of time into grbl's move buffer, so when the user requests to change the feedrate, it take a maximum of one full buffer worth of short moves before the new speed can take effect. To keep the free spirit of grbl, the feeder should be implemented maybe in java using rxtx for serial communication." There's much to be debated on this one.
-
Backlash compensation: There are many ways of handling backlash, which all have different levels of complexity and drawbacks. The main problem is how to ensure that the CNC keeps moving smoothly as possible through the backlash without compromising accuracy. Although it seems like the easiest thing to do is to just insert a line motion in the direction of backlash, but this has significant problems. For example, if one is plotting a circle at a high feedrate, at the end of each quadrant, the CNC must compensate for backlash. Since the backlash line motion is perpendicular to the arc, the machine must come to nearly a complete stop, adjust for backlash, and resume so that the acceleration limits of the motors are not exceeded. So do you have some type of line fit instead with an acceptable amount of path deviation error? Should there be multiple types of backlash methods available for users to select depending on the type of machine? Many many questions to be answered. However, a placeholder for backlash is already in the code for users to add their own.
-
Tool Offset Support: Tool offsets are still in high use by certain CNC setups and machinist workflow preferences. It can be simpler to adjust the tool offsets directly in the g-code program rather than re-generating the entire g-code from CAM software. Or, this feature maybe integrated into an independent grbl GUI/interface for a true headless system. Still up in the air, since it does not apply to all CNC machines, only mills and lathes.
-
Probing: The use of a probe to locate a part or tool in machine coordinates. Up to debate.
-
Jogging: This is planned as a separate program to be run independent of grbl's planner and stepper programs. This is mainly for trying to keep things simple. In production CNC machines, this is the same behavior, where a program run locks out the ability to jog until the program is canceled or complete.
- More hardware support: At v1.0, the code should be stabilized enough to begin officially inserting more hardware support into the grbl codebase. A lot of this work is already going on by some great people, but from a development standpoint, it's difficult to write new code when multiple hardware systems need to be supported for each minute iteration. As this moves forward, the hard work people have already put in will be directly integrated when the time comes.
- SD-card support: This may be an important feature in upcoming versions. Having on-board storage will free up the serial port for real-time commands and status reports from no longer having a constant stream of gcode to grbl. This also allows for more true headless CNC setup. May be integrated as a compile-time configuration option.
- 4th axis capability: Not high on the priority list, since no one has a 4th axis yet to test it on.
- Lathe branch: Not to difficult to port to a lathe, since they are only two axis. Just time and effort needed for this.
- Synchronized spindle: Synchronizing the spindle with axes movement would be a great challenge. This is commonly used for mill threading and for advanced machining of complex lathe parts. The main issue here is ensuring that the axes stepper motors do not exceed their acceleration limits, because if they do, steps and location will be lost. Typically a motor encoder is used to detect spindle rotation (steppers don't have enough torque or speed for driving spindles), and sychronizing the spindle motor encoder and axis stepper motor can be difficult to do robustly and universally for varying setups and would require a special motion mode that doesn't use Grbl's acceleration planner. This feature is usually more successful on an adhoc basis, where motions are tuned for each machine.