We could use this configuration:
This is done in Ground Control, not in the firmware. This really should be done
in the firmware for compatibility with grbl if nothing else.
When ‘Home’ is moved. GroundControl shifts the on-screen representation of the cut paths and alters the parameters of the gcode lines based on that change. In this way, the screen represents the workarea limits and the sled without change, and the location of the lines to be cut are moved to the desired position on that representation.
How would the G38.2 gcode affect those relationships? Would the end result of doing both X and Y passes through G38.2 be the same as using the ‘Home’ button, with the screen re-drawn by GC for the new location? Is this transposition delayed until both X and Y are successfully detected?
The current ‘set home’ in ground control re-writes all coordinates in the gcode
as it sends it to the firmware. so if you are cutting the same thing in
different places on the workpiece, and you get different results, it could be
because you are executing different gcode in each place.
G38.2/G92/G54/etc make no changes to the G-code at all.
Instead what they do is define where 0 is (in various ways) in the firmware.
G38.2 is a way to move in a specific direction to detect where something is, and
when detected, that becomes 0 for that axis.
G54 and company let you set multiple places to be 0,0,0 and select one of them
for the particular cut. This is especially useful when you are cutting multiple
copies of one design (you can have one set of g-code to cut, and then execute it
in multiple places where the appropriate material is clamped in place, swap out
the raw material and repeat accurately)
How would the result of the G38.2 be represented on the screen?
I’m not sure it would show up. If you have a grid showing the coordinate system,
the result would be the grid snapping into place to line up with where the bit
for example, if you are at x5,y5 and did a G38.2 in the +X direction (and
immediately hit the stop), at the end you would be at X0 Y5.
It would take some thought about how to indicate that on the screen.
In the mean time, moving ‘Home’ is probably the way to handle it. The firmware would tell GC the new coordinates from G38.2 X and Y in the same way the ‘Move Here’ does, and GC would re-read the file and offset the X and Y parameters.
doing this in GC rather than in the firmware means that we are avoiding being
compatible with grbl and locking ourselves into only being able to use GC.
Why shouldn’t this be done once in the firmware?
I guess I can’t see how to get it done without breaking GC, and not breaking GC is more important.
I don’t see how it would break GC
As far as cutting goes, at most, you would delete all the code that implements
the home and replace it with a simple G54 (or similar) code to redefine home.
As far as the display goes, the work to implement g54 and similar are simpler
than re-writing the g-code (it’s just setting a fixed offset for any future
If you can find a way to do it PRs are always welcome, but I think the big issue is going to be that most XY machines just define a new zero position which they can do because the movements are linear. We always have to keep track of our true XY position. We could add an offset in the firmware and on the GC side, but I’m not sure how that would be functionally different
on this evolving topic, my only point would be to encourage the adoption of the widest definition of ‘standard implementations’ with regard to Work Offsets (or any other) G Code (and M Code) definitions.
Crossing over into the parallel conversation about Firmware Standards/Documentation/Implementations, I encourage the same approach: Casting the widest available net into Open Sourced, Profesisonal, and or Industry standards.
This approach will always fall short, somewhere, but I want to continue to vocally encourage all attempts to sustain those goals. I maintain that they will continue to pay large dividends over time.
it’s not very different if you only look at one alernate home location (which is
all GC supports today), except that it’s much clearer how you go back to the
But supporting the G54 family of codes (which would also make it possible to
support the G38.2 codes) supports having up to 6 home positions (IIRC) , and
switch between them, including programatically.
This also is what is needed to support ‘standard’ g-code sending tools. No other
equivalent of GC handles moving home by re-writing the g-code on the fly, they
all use the gcodes to manage the alternate homes.
Again, late to the party…
LinuxCNC uses absolute and workspace machine coordinates, and tracks both. I’d guess that grbl does something similar since you can switch workspaces on the fly. Without having actually read the code my mental picture is a matrix of offsets from absolute indexed by axis and selected workspace, and a single addition (or subtraction) to convert from the current workspace to absolute. The coffee hasn’t quite kicked in yet or I’d remember how a non-workspace absolute position mode is handled, but workspace 0 (or -1) could be a row of all zeros (yes, that adds the potential for a subtle bug) to eliminate constant testing in or out of WS mode.
Left Squeakie in the care of her parents and motored south for two days (forgot what 100+F feels like) to SW FL to search for a winter Maslow shop. Mrs Moose is having trouble understanding the house doesn’t matter, it’s the shop
While I thought it was obvious it probably isn’t, this all takes place while all the coordinates are cartesian, before being converted into polar (chain length and angle) mode. Hmm, does that make them more appropriate for mooseland?
Somewhat OT, but we’ve discussed a grbl style planner, or even porting to actual grbl, several times. Perhaps a random thought, but doesn’t the use of corner mounted motors and chains make acceleration radically different than grbl’s model? I don’t agree with chamnit’s comment that our lower speeds make it irrelevant; while our speeds are lower we’re dealing with moving a much heavier mass than the smallish machines with low spindle masses than the typical grbl devices.
Somewhat OT, but we’ve discussed a grbl style planner, or even porting to
actual grbl, several times. Perhaps a random thought, but doesn’t the use of
corner mounted motors and chains make acceleration radically different than
the grbl model is figuring the acceleration in how the vectors match, not in how
the motors have to accelerate/decelerate, so the same acceleration planner will
work for us
I don’t agree with chamnit’s comment that our lower speeds make
it irrelevant; while our speeds are lower we’re dealing with moving a much
heavier mass than the smallish machines with low spindle masses than the
typical grbl devices.
we have proof that it matters, when we enable the ‘machine cannot keep up’
logic, it triggers a LOT as the sled starts moving, so much so that we have it
disabled as we would have to set it’s threshold high enough to make it’w worth
This is proof that even with our slow speeds, we need to take acceleration
planning into account.
Where is acceleration planning normally handled? Is it in the gcode sender or in the controller? I see in grbl that there are “firmware keys” associated with maximum acceleration for each axis, which makes me think its handled in the controller, but I don’t know.
Would I be correct in stating that its technically possible to generate gcode that includes feed rate changes when needed?
When there is a speed control connected to the spindle it can have speed commands to change the speed for each line. So it depends on the controller. Otherwise you can pass the speed but it has no effect on controllers not connected to a spindle.
Normally a PMW signal is used to add speed control.
i hope that helps.
I think you’re referring to the rotational speed of the router bit, correct? I’m asking about the feed rate of the x, y, and z axes… i.e., changing the feed rate to avoid overshooting corners and such.
The firmware honors a feed rate that is found in a line of gcode, but won’t go above the maximum feedrate setting. If there is a Z movement in the gcode line the feedrate is evaluated against the z axis maximum rpm and distance per rotation as well. So each line could have a feedrate. As well, a gcode file could include “$15=newMaxFeedrate” values to set the speed limit on the fly, though it’s hard to see why that would be useful…