We could use this configuration:
1 Like
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?
1 Like
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
is
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.
1 Like
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.
1 Like
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
plotting)
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
1 Like
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.
1 Like
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
ârealâ home.
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.
3 Likes
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
3 Likes
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.
1 Like
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?
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
questionable.
This is proof that even with our slow speeds, we need to take acceleration
planning into account.
David Lang
1 Like
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?
Yes,
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.
Thank you
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âŚ