whats the chance you could post this config file for the x y swap thanks so much
1 Like
Here you go! I am linking to over where I just now posted my config.yaml code with swapped X and Y.
The graphic in this post may help also:
So recently there was some discussion about Bart Dring and FluidNC wiki, etc discouraging use of G92, which has been commonly used to, for example, set XY to 0,0 in probing scripts, etc. I had read the FluidNC wiki about this, but still did not understand, so I asked Bart about it in the Discord, and this was his reply:
It [G92] is left over from the hand coding days. If you hand code a bunch of gcode for a part and want to cut a second part off to the side you can use the gcode to make the first part, then use G92 to offset over to the side and start a second part with the exact same gcode. You still need to use a G54 (etc) offset on the first part. Otherwise everything is lost after power off. If you are using G92 without using G10 before it you are suffering a bad case of RepRap poisoning.
Modern CAM does everything for you. If you want 2 parts, just copy the part in CAM.
Granted I am still very green on all of this, but that logic doesnāt make sense to me. I donāt see anything wrong with printing the same part twice from the same gcode. I donāt care if it doesnāt store those positions after powering it off. When I turn it back on, I might be swapping plywood and Iām going to re-home it anyway. Sure I could duplicate it in CAM, and I would if I was doing a bunch, but if Iām doing just 2 of something, Iām probably going to just use the same gcode twice.
1 Like
@jeyeager
Based on my limited understanding so far, regarding Bartās position, he would not have a problem with it being used that way, as thatās what itās āintendedā for per his explanation. I think the problem stems from the fact that apparently much of how it is used, is not as intended. I still donāt understand what āunintendedā use he is eyeing, and why itās problematic, but his repeated statements in a variety of contexts both discourage its use, and imply it does not do what most think it does. I donāt know enough to know what I think it does. 
1 Like
I thinks itās just about tool offsets. So basically G92 sets coordinates to zero whereas G54-(is it G59?) simply offset the machine but doesnāt change the coordinates.
My understanding is the issue comes into play when you need to slice the code. If you use continuous G92ās itāll be near impossible to correctly reposition the machine without running through all of the gcode again. For example
g28
Part1
ā¦router gcodeā¦
G92 laser offset
ā¦laser gcodeā¦
G0 *Part2
G92 *zero
ā¦router gcodeā¦
G92 laser offset
ā¦laser gcodeā¦
Etc, etc,etc
So if you have an issue at/before part 2 there isnāt a reliable way to reset the machine to that point, where as g54 uses current positioning so you only need to find original zero.
Most cams donāt let you do this anymore so those that are are doing it by hand. This is of course coming from a person that doesnāt have any first hand experience of this so I may have it wrong but from my under of how the code works this would be my guess
Both of these indicate what Iām talking about.
Did you mean to post this here?
For right now, all the instructions are written with g92 in mind. Using the other method requires another step by the user each time they use the machine. I am not convinced I should change the instructions.
Today I spent some time dialoguing with Bart Dring, getting advice and help for a G-code script for probing with the Jackpot board on my LowRider v3 CNC. Hereās the resulting script, and I really like it:
G21 (MSG G21: Metric mode)
G94 (MSG G94: Feed = per minute)
M0 (MSG Attach probe)
G10 L20 P0 X0 Y0 (MSG G10: Setting current XY position as workspace origin 0,0)
G38.2 G91 Z-124.9 F400 (MSG G38.2: Fast probing to material)
G1 Z5 F400 (MSG G1 move Z up by 5mm, speed 400)
G38.2 G91 Z-6 F100 P0.34 (MSG G38.2: Slow probing to material. Plate thickness: 0.34)
G90 (MSG G90: Switching to absolute positioning)
G1 Z30 F900 (MSG G1: go to Z30, speed 900)
M0 (MSG Remove probe)
M62 P1 (If used start spindle pin27)
Notes:
In FluidNC, anything after a semicolon is treated as a comment ignored by the machine, and anything inside parenthesis is treated as a comment as well, but putting "MSG " (note the space after the G) inside the parenthesis causes the message after that to be reflected in the feedback section of the command interface.
In my own use of the code, I have some of the lines commented out so they donāt run, but as shown above, all of them are active, as for most users, they should all be run.
; M0 (MSG Attach probe)
ā¦would cause a pause and require me to press a continue button, and whereas I typically always have my probe attached before I ever tap the probe macro button, the pause is merely an inconvenience to me.
The same goes for the second M0 command:
; M0 (MSG Remove probe)
I should mention, I donāt include probe code in my cut jobs, as I always probe separately beforehand. So for me, Iām not separated from a cut job by the automated pause. If you have probe code built into every job in the start code, then this is a safety thing you probably should keep in.
And finallyā¦
; M62 P1 (If used start spindle pin27 )
Iām using a Kobalt router as opposed to a spindle, so Iām a manual start rather than a code based start, so I"m not using this command.
So the same as before just not using g92?
1 Like
For most users it is a safety feature so both your hands are nowhere near a machine that can tun on at any moment.
Iāve had to accidentally race the machine(accidental play button hit) to get the probe off and start the spindle before it hit the boardā¦
It wasnāt fun
I did start with your docs here as a base, and I know two differences are no G92, and it probes twice (once a little quicker, and a second, slower one for more accuracy).
I should mention, I donāt include probe code in my cut jobs, and always probe separately beforehand. So for me, Iām not separated from a cut job by the automated pause!
I added a note above to the effect that it probably should be kept in for safety for those who include probe code at the start of their jobs!
2 Likes
Is this correct? The offset isnāt permanently stored? What I read made it seem like the g54 commands could be permanently set.
It is permanently stored that is the extra step. Home is no longer home. So now instead of starting each job from home, now you will be starting it from whatever your last workspace was defined at. So the extra step is homing and resetting your workspace to your new project.
This is fine after you have run some jobs and understand the machine.
Currently, I am not changing anything about G92. Workspaces are great and have always been available. They unfortunately are not beginner-friendly in my opinion.
1 Like
So you run a starting gcode, then run a separate job gcode instead of using a pause?
Definitely agree with this
So workspace values are kept after restart? That is both helpful and not. I guess it removes some latency if something goes wrong. But Iām not sure the learning curve is worth it to some.
No pressure from me. Here is my thought process.
- Iām treating this thread as a focused type of build log about my implementation of Jackpot, so trying to keep it updated.
- I really like having hard limits and soft limits enabled, and when they are enabled, I found that use of G92 made probing not work. [Updated later to add: that was apparently due to some other reason.] I continually got alarms instantly when the code line for probing was reached. Paraphrased: āAlarm 2, travel outside of soft limits is not permitted.ā Switching away from G92 allowed me to do probing while still having soft limits enabled. [Updated later to add: it seems it was some other edit that allowed success.] I have tested and confirmed that the hard limits and soft limits are working on all axes, including Z axis both before and after probing. Once homed, I can no longer accidentally drive the LowRider either too low or too high, so no longer able to accidentally cause that frustrating crash.
1 Like
I am not understanding this yet. What additional step is required?
EDITED TO ADD: I remember now that you are likely referring to the workspace offset being saved and surviving reboots. However, that was regarding the pendant. This probe code is not related to that, and does not cause an offset that survives a reboot.
1 Like
I totally get that.
I do want to point out that there may be some mixing of two conversations here. This G10 in the probe code is not [behaving] the same as the āzero (axis) buttonā code in the pendant. Whatever the pendant āzero axis buttonā is doing is surviving reboots. This code is not. The workspace XY of this probe script does not result in an offset that survives a reboot. I just tested to be sure. This is āG10 L20ā not āG10 L2.ā