Hey @jlauer . Wanted to bounce an idea off you. Have been working on some probing hardware and looking at your probing widget. Hope to get some good testing done this week. Will follow that up with a post.
I saw in your video covering the widget and its use that you said identifying the gcode correction values was difficult and that you used raycasters to get the job done. I have not looked at the code but am guessing you also may be doing some interpolation between probed regions to generate these values? I have been wondering if using the underlying gcode to generate a probing job might be a more direct / efficient approach. To describe it crudely, probe along your gcode paths to generate a surface profile and generate offsets for the program on that piece of material.
Are you suggesting in essence probing the tool path every few mm? Or probing on the fly? Probing on the fly would be difficult without an external probe precisely set to the tool tip. Unless you could connect the probe pin to a bearing inside the spindle perhaps.
You could possibly probe at each xy point in your Gcode to make the z offset super easy to specify (rather than interpolation like i do), but that would take so long for most gcode that i think it’s not practical. If you’re milling a PCB, you have probably 20,000 xy points to probe then whereas with the Auto-Level widget you end up with say 100 points.
@jlauer would that work? Imagine you were at 0,0,-0.1 and the next line of code was G0 X10 Y10 Z-0.1. That would mean you had no height readings between 0,0 and 10,10.
I’m imagining you’d do the probing of all points first, and then go back and mill everything. So you’d just take the XY values and ignore the Z values during the probing stage. When you probe to get your new Z you just compare the offset and modify the Gcode.
I don’t think probing as you mill is practical as the electrical connectivity to the end mill is hard to switch on/off because you’d have to do some kind of automatic alligator clip and the dust could cover the material so you lose electrical that way.
i would worry that you might not get much granularity if you were milling the xy of a gcode line and had some long toolpaths. I guess it depends on the job.
Oh, I see. Well, actually, that is a problem today with the current Auto-Level. It only modifies the end points and does not insert mid points on long lines. That was always something I wanted to add but never got around to it.
Ah. I see. So the better solution over all would be to make sure that no gcode path is over the hypotenuse of a probed square. So we’d need to parse each movement and insert waypoints.
Correct. There is a way to do this where you take the parsed Three.js lines which already exist in the 3D viewer and you can ask Three.js to just give you a new xy point that is say 2mm along the line. If it’s a 10mm move then you’d end up with 5 points along the line. Then you would insert a new G1 line in the Gcode for each point and raycast an intersection into the Auto-Level grid plane that was already generated. That new Z is your effective Z zero at that point.
Not even sure if you’d need to do it via 3d. Easy enough to do in the eagle board widget or in the gcode list widget. Just calculate the distance between two consecutive g1/0 commands and insert interstitial way points. A little harder for arcs. But not much. Just some vector math plus trig.
1.) Maybe it is enough to still use interpolation and use a subset of all
points. Every x points. But long runs pose a problem. Maybe you only
generate waypoints if two probe points are y units apart. X and Y are
settings. I don’t think you need to follow tool path explicitly.
2.) Also, it is perhaps possible to change gcode generation to something
more probe friendly. Something that generates more evenly spaced points.
That would be tool dependent.
Well, if you mouse over any line in the Gcode widget, you’ll see it knows the absolute XYZ value for that line for it’s start and end. The way it knows this is it asks the 3D viewer to tell it that data. The 3D viewer knows this because it parses each line of Gcode. So you have all of the data at your fingertips. Three.js has all sort of utility functions to do the math for you, that’s why I was saying just use it as a tool to figure out your waypoints and let it tell you the new xy value. Yes, you could do this on your own with the pythagorean theorem as well, but Three.js makes it even easier.
For G2/G3 those are a bit harder, but the Auto-Level widget does modify Z values in those lines today, but to generates waypoints along a G2/G3 is tougher because you have to splice the arc into sub-arcs.
Arcs are a little harder yes. But you have start and end points and IJK values. So getting the angle of travel for a given distance is trivial. And the equations for working out the x and y of a position on a circle after a given movement of xx degrees are first order. This should be an easy enhancement. I wonder how useful it is in practice though (although some boards i received recently were more than 0.2mm off in thickness side to side and had a slight warp)…
I goal of this approach is simplicity, speed & efficiency. Am not sure if you actually get that from this approach. I was thinking for jobs ranging in size larger than pc boards. I think the gcode path approach might help with large engraving jobs. But complex, dense tool path patterns probably benefit from the grid / interpolation approach.