- Incremented from v0.9e to v0.9f due to the new g-codes, velocity
reporting option, decimal printing refactoring, grbl-sim updates, and
G0/G1 bug fix.
- Settings version was also incremented since settings.decimal_places
is now gone.
- Denoted bit_true_atomic only for sys.execute bit settings. All other
bit_true type calls are for local variables only and don’t need atomic
access. Still looking into other ways of setting these flags without
requiring atomic access, but this is a patch for now.
- Minor bug fix that caused G92.1 not to work. The mantissa of G92.1
was not computed correctly due to floating point round-off errors and
the use of trunc(). Fixed it by changing the computation with round().
- Installed tool length offsets with G43.1 and G49! True tool length
offsets via G43 are not supported, because these require us to store
tool data that we don’t have space for. But we’ve come up with a good
solution for users that need this. Instead we are strictly using the
dynamic version G43.1 via linuxcnc.org. Visit their website for more
details on the command.
- G43.1 operates by requiring an axis word and value to offset the
configured tool length axis, which can be configured for any axis
(default Z-axis) in config.h. For example, ```G43.1 Z0.5``` will offset
the work coordinates from Z0.0 to Z-0.5.
- G49 will cancel the last tool length offset value and reset it to
zero.
- Tweaked the ‘$#’ parameters report. `Probe` is now `PRB` and a new
value `TLO` states the tool length offset value.
- Pushed this uncompleted code to merge a conflicting pull request.
- New G43.1 and G49 g-codes to be installed. The beginnings of it are
in place. These g-codes are intended to be used in conjunction with
probing and allow GUIs to set tool length offsets without Grbl needing
to store a tool table.
- G43.1 is defined as a dynamic tool length offset that is not stored
in memory. Rather, when commanded, these are applied to the work
coordinates until a reset or disabled by G49. This works much like G92.
- Added a new optional compile-time feature for ‘realtime’ (within
50ms) feed rate reporting. When querying for a status report, a new
data value will state the current operating rate. It’s only beta at the
moment and has some kinks to work out.
- Updated the code for printing floating point values to N decimal
places. Generalized the main floating point print code to accept a new
decimal places value and created a set of handler functions to print
certain floating point value types used in Grbl, like position, rates,
coordinate offsets, etc. All of these have different decimal
requirements and change when printed in mm or inches mode.
- Number of decimal places for the different value types can be
re-defined in config.h, but there shouldn’t be a need for this, as
these are physically limited.
- Removed the decimal places settings, as this was now obsoleted by the
new decimal places code.
- The new decimal places code also saves almost 300kB in flash space,
as it’s more efficient.
- Although stated as invalid in the NIST g-code standard, most g-code
parsers, including linuxcnc, allow G0 and G1 to be commanded without
axis words present. For example, something like ‘G1 F100.0’ to preset
the motion mode and feed rate without a motion commanded. Older CNC
controllers actually required this for feed rate settings. This update
should now allow this type of behavior.
- Line number tracking was getting truncated at 255, since it was using
wrong variable type. Fixed it with a trunc().
- Increased the max number line allowed by Grbl to 9999999 from the
g-code standard 99999. The latter seems to be an arbitrary number, so
we are allowing larger ones for at least one known use case scenario.
- Created a new test directory to contain some testing g-code to proof
the firmware. Only got started with one test case so far. More will be
inserted as needed.
- Some other commenting updates to clarify certain aspects of the code.
- Updated offset-mode arc error-checking to EMC2’s version: The old
NIST definition required the radii to the current location and target
location to differ no more than 0.002mm. This proved to be problematic
and probably why LinuxCNC(EMC2) updated it to be 0.005mm AND 0.1%
radius OR 0.5mm.
- Updated the mantissa calculation that checks for non-integer values
and GXX.X commands that aren’t supported. There was a potential uint8
overflow issue.
- Fixed g-code parser bug related to not using the correct modal
struct. G10 P0 not selecting the current coordinate system when a
G55-59 is issued in the same line.
- Fixed g-code parser bug related to not using the correct modal
struct. Target position locations were not computed correctly when
G90/91 distance modes were changed in the same line. It was using the
previous state, rather than the current block.
- Completely overhauled the g-code parser. It’s now 100%* compliant. (*
may have some bugs). Being compliant, here are some of the major
differences.
- SMALLER and JUST AS FAST! A number of optimizations were found that
sped things up and allowed for the more thorough error-checking to be
installed without a speed hit. Trimmed a lot of ‘fat’ in the parser and
still was able to make it significantly smaller than it was.
- No default feed rate setting! Removed completely! This doesn’t exist
in the g-code standard. So, it now errors out whenever it’s undefined
for motions that require it (G1/2/3/38.2).
- Any g-code parser error expunges the ENTIRE block. This means all
information is lost and not passed on to the running state. Before some
of the states would remain, which could have led to some problems.
- If the g-code block passes all of the error-checks, the g-code state
is updated and all motions are executed according to the order of
execution.
- Changes in spindle speed, when already running, will update the
output pin accordingly. This fixes a bug, where it wouldn’t update the
speed.
- Update g-code parser error reporting. Errors now return detailed
information of what exact went wrong. The most common errors return a
short text description. For less common errors, the parser reports
‘Invalid gcode ID:20’, where 20 is a error ID. A list of error code IDs
and their descriptions will be documented for user reference elsewhere
to save flash space.
- Other notable changes:
- Added a print integer routine for uint8 variables. This saved
significant flash space by switching from a heavier universal print
integer routine.
- Saved some flash space with our own short hypotenuse calculation
- Some arc computation flash and memory optimizations.
- G38.2 straight probe now supported. Rough draft. May be tweaked more
as testing ramps up.
- G38.2 requires at least one axis word. Multiple axis words work too.
When commanded, the probe cycle will move at the last ‘F’ feed rate
specified in a straight line.
- During a probe cycle: If the probe pin goes low (normal high), Grbl
will record that immediate position and engage a feed hold. Meaning
that the CNC machine will move a little past the probe switch point, so
keep federates low to stop sooner. Once stopped, Grbl will issue a move
to go back to the recorded probe trigger point.
- During a probe cycle: If the probe switch does not engage by the time
the machine has traveled to its target coordinates, Grbl will issue an
ALARM and the user will be forced to reset Grbl. (Currently G38.3 probe
without error isn’t supported, but would be easy to implement later.)
- After a successful probe, Grbl will send a feedback message
containing the recorded probe coordinates in the machine coordinate
system. This is as the g-code standard on probe parameters specifies.
- The recorded probe parameters are retained in Grbl memory and can be
viewed with the ‘$#’ print parameters command. Upon a power-cycle, not
a soft-reset, Grbl will re-zero these values.
- Moved ‘$#’ command to require IDLE or ALARM mode, because it accesses
EEPROM to fetch the coordinate system offsets.
- Updated the Grbl version to v0.9d.
- The probe cycle is subject to change upon testing or user-feedback.
- Updated some of the ifdefs when disabling line numbers feature.
Getting messy with this compile-time option. This will likely get
cleaned up later.
- This is just a push to get the new probing code to compile. Testing
and optimization of the code will soon follow and be pushed next.
- Added a grbl planner simulation tool that was written in Matlab and
Python. It was used to visualize the inner workings of the planner as a
program is streamed to it. The simulation assumes that the planner
buffer is empty, then filled, and kept filled. This is mainly for users
to see how the planner works.
- Updated some of the compile-time ifdefs when enabling line numbers.
The leaving the un-used line numbers in the function calls eats a
non-neglible amount of flash memory. So the new if-defs remove them.
- Changed line number integer types from unsigned to signed int32.
G-code mandates values cannot exceed 99999. Negative values can be used
to indicate certain modes.
- Homing cycle line number changed to -1, as an indicator.
- Fixed a reporting define for the spindle states that was broken by
the last merge.
WARNING: Bugs may still exist. This branch is a work in progress and
will be pushed to the edge branch when at beta stability. Use at your
own risk.
- Homing freezing issue fixed. Had to do with the cycle stop flag being
set incorrectly after the homing cycles and before the pull-off
maneuver. Now resets the stepper motors before this can happen.
- Fixed an issue with a rare feed hold failure. Had to do with feed
hold ending exactly at the end of a block. The runtime protocol now
sets the QUEUED and IDLE states appropriately when this occurs. Still
need to clean this code up however, as it’s patched rather than written
well.
- Updated version build via $I command.
- Forgot to comment on a new feature for the last commit. Since steps
are integers and millimeters traveled are floats, the old step segment
generator ignored the step fraction differences in generating the
segment velocities. Didn’t see like it would be much of a big deal, but
there were instances that this would be a problem, especially for very
slow feed rates. The stepper algorithm now micro-adjusts the segment
velocities based on the step fractions not executed from the previous
segment. This ensures that Grbl generates the velocity profiles EXACTLY
and noticeably improves overall acceleration performance.
