-
Notifications
You must be signed in to change notification settings - Fork 3k
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: Code and implementation structure completed. Allows for asynchronous command execution, such as feed hold(pause), cycle start(resume), system abort, status reports, etc. The code structure can allow a simple modification to externally use spare Arduino I/O pins to set these commands. This is up to debate whether or not to include this.
- Feed hold and resume: The feed hold and resume features are completed. The feed hold decelerates under control to ensure no loss of steps and the planner replans the entire buffer for the resume.
- System abort: Resets grbl without having to physically reset the Arduino. Machine position is retained and coordinate offsets are reset, per NIST RS274-NGC protocol. Looking into cases when machine position should not be retained, if there is a chance of lost steps, i.e. tripped limit switch, but a physical reset of the Arduino will always clear the machine position.
- Program stops: M0, M1, M2, and M30 have limited support. Optional stop toggle is in the works. Pallet shuttle will not be supported. These were enabled by the introduction of the resume and system abort run-time commands.
- Real-time status report / DRO: Bare-bones status reporting complete. Reports machine position (aka home) and work position (G92). Possibly needed: Line numbers, buffer status, g-code modes, feed rate, distance to go, mm/inch mode, etc. A binary mode for interface systems or other modes that can be set by the user in EEPROM. The form is still up to debate.
- Updated user settings: Many compile-time settings will be moved into the EEPROM flash memory for permanent storage, as an attempt to make grbl fully configurable as a single build. Will likely come in the form of an 'Advanced' settings module within the current '$' interface. However, depending on what needs to be placed in here, this could be moved to a v0.9 developmental feature.
- Run-time settings: Not the same as run-time execution. This will set some run-time grbl modes that are not required to be real-time, such as toggling block delete, setting machine(home) position, toggling auto-cycle start, etc. The updated user settings will store the user specified defaults.
- XON/XOFF software flow control: Toggle-able simple streaming option by using a common terminal program to send a g-code file to grbl with no fuss or special interface. However, run-time commands will not work in this mode.
- 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. Jogging will likely be the final feature added for v0.8.
-
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.
- 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 and synchronized spindle: Not to difficult to port to a lathe, since they are only two axis. However, synchronizing the spindle with axes movement would be a great challenge. This is commonly used for threading, but also for advanced machining of complex turned parts.