Pull Request Guidelines

Guidelines for creating pull requests.

Issue

Please create an issue for general discuss regarding the changes in the pull request. Ideally this is done before the pull request is submitted. Pull requests are always welcome and encouraged, but coordinating efforts saves time for everyone. Discussion via Discord is also acceptable. Put a link to the discussion in the PR description.

Branches

Please target the devt branch with your pull requests. All new changes and features are staged in the devt branch before merging to the mainbranch.

For experimental features, it is also acceptible to target other, non main, branches.

Build Date

Any time changes affect the compiled firmware, change the build date in grbl.h to the date of of the pull request. $define GRBL_VERSION_BUILD "YYYYMMDD" ... Example: #define GRBL_VERSION_BUILD "20190517".

Note: This date may be changed if other changes, with later dates are merged first.

File names

If files need to be renamed from standard grbl file names due to conflicts with libraries, etc, please prefix the old filename with "grbl_". Example: limits.h has a conflict, so limits.h and limits.cpp were renamed to grbl_limits.h and grbl_limits.cpp

Code Style

See this doc for our coding style

Important Code Guidelines.

• ISRs: The ISRs have to be very fast. They block all processing, including RTOS tasks. The ESP32 has a floating point bug related to ISRs and the FPU. Do not use floats in ISRs or anything that could be called by an ISR. Doubles can be used. They bypass the FPU, but require a lot of time to process.

The Wiki

There is no good way to issue pull requests against the wiki. If you have a suggested change to the wiki, please create a new issue. Issues are formatted with markdown, just like the wiki. Put your changes and any images in that issue. We will edit the wiki with those changes.