I’m super used to running a syntax checker on automated test procedures that I write before I ever run them.
Since the yaml seems to be picky, why not have a strict syntax checker? Better to know. (Better still to have FluidNC spit out good error messages, but that’s an aside.)
3 Likes
I could argue that for config, JSON is overkill, and annoying in its own ways. Especially if you end up dealing with a mix of strict and permissive JSON parsers… I will grant that for inter-process communication, JSON is 100% better than XML, even if you don’t end up with fancy, polite documents lite DTDs and the like…
1 Like
Any markdown is going to get hate. I was just trying to point out that it wasn’t FluidNCs fault (but I am in camp yaml).
There are online yaml checkers. There are very strict linters too. The trouble is making sure the checker is up to date with the code. And if you have the wrong whitespace, that can sometimes lead to valid, but logically incorrect yaml. Like putting a parameter for a motor in the next scope. A generic yaml tool won’t be able to help with that. A fluidnc specific tool will be expensive to upkeep.
There isn’t a perfect solution and at the current scale having volunteers debug issues for the people that have them is close to the best solution. But I just want more notice to people that they have a problem. Double checking that the tmc settings were accepted is a start. Making sure the current setting was set would be nice to have. Maybe some automatic double checking like: You set this driver type to TMC2209, but you haven’t set a current limit (because the yaml is wrong and the current is in the wrong section).
2 Likes
Please forgive the double post. This seems to belong here as well as the thread on the case itself.
I laser engraved the lid, using a 100W CO2 laser, at 300 mm/sec, with 45% power.
When cleaning away the debris, avoid use of astringents, etc (including avoiding alcohol and WD-40 or the like) as it will cause micro-fracture cracks in the edges of your engraving. I made this mistake (alcohol), but then was able to correct it with careful use of a heat gun. Be careful with a heat gun, as you can overheat it and cause bubbles and ripples and ruin the appearance. I did not make the latter mistake this time, but I had made that mistake before on another project. (Open sharing of mistakes will hopefully prevent someone else from making the same ones.)
3 Likes
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?