good evening everyone,
I tinkered around with the postprocessor for a few (slightly frustrating) weeks now and could finally get FreeCAD motivated to hand me over a G-code, which is already converted by the processor provided by Snapmaker.
For testing purposes, I compiled two easy workjobs each for the outlines of a few simple shapes: 1x FreeCAD, 1x Luban. They seem to match very roughly, but there are some significant differences. [My interpretation of Snapmakers G-code dialect may be partially wrong due to a sufficient documentation.]
I have noticed the following:
- The commands occurring in every initial sequence of Luban-generated G-code are different.
– Luban uses G90 (set absolute positioning) followed by some G0 (rapid linear movements) to positioning the tool near the work origin. Afterwards it’s turning the spindle with a predefined turning speed, set by a value for power in percentage between 50 and 100. [The values for the feedrate are a bit odd and far from rapid, but won’t affect the practicability]
– The postprocessed FreeCAD G-code spares the setting for the positioning mode. The following approach to the work origin affects only the Z axis. There is an additional G21, which i couldn’t find in Snaps dialect (neither in the few sentences documentation, nor through the controllers command line). The following M3 sets the Power value with a variable named S instead of P. I tried that command seperatly in the controllers command line and it turned the spindle as well. Hard for me to estimate, if that matters or what this difference might affect also.
The needed movements of the tool is generated way different. Luban only uses linear movements (G0 / G1), even to display curved shapes in an approximation. FreeCADs code includes some G2 in addition, with values which meanings i couldn’t guess yet. The few lines doc published on github states, G2 and G3 are arc moves, which should be converted to linear ones for the Snap. Because.
Luban generates G-code which sets the work origin as reference level. Thus, the dip into the workpiece is translates by negative values on the Z axis. The FreeCAD postprocessor instead sets the bottom of the workpeace as reference level. A 0.5 mm dip into a 10mm workpiece for example is compiled at Z9.50 instead of Z-0.50. As the result, the FreeCAD G-code makes the Snapmaker milling in the air above my workpeace, exactly the thickness of my workpeace away from the intended place. I didn’t find a setting to change that yet. A possible workaround could be constructing the model in FreeCAD “in reverse”, but I didn’t try that yet according to the needed changes in my workflow.
I didn’t analyze the footer yet.
I’ll had a deeper look into the provided postprocessor afterwards. It seems, the Snapmaker one is a modified copy of the linuxcnc postprocessor originally provided with FreeCAD.
- There is the python specific header found first. As long as I don’t find a need to import any additional librarys, I won’t touch that part.
- There are some parts, which are simply hardcoded as Preamble / Header / Footer / and so on. These simply hand over their payload to the G-code file line by line and are therefore the parts, where necessary adjustments are easy to do.
- But there are the more important parts, where functions change structure and syntax from the generated fictional G-code FreeCAD generates to the dialect understood by Snapmakers controller. Sadly, this might be the part, where the difference in the reference level is originated.
As I’m not able to switch to Fusion360 and as long as Luban is just capable of milling simple pictures into flat surfaces, I fear, I have to customize the postprocessor until I get any satisfying output. But my spare time is limited and I don’t speak python fluently enough for easy results: Anyone interested and willing to help?