Multiplatform Support

[clsergent]

Following @ITmaze suggestion, I open this discussion. Per his own words:

I'm raising this as an issue, but really it's a place to have a discussion. The prompt was a log entry in FreeCAD during PostProcessing: "Command ignored: G83", which turned out to be a drilling operation which was most of the job at hand. I understand that SnapMaker (and Marlin) G-Code does not support G83 and that's fine, but it raised this issue.

I was using my A350 in CNC "mode", but I also want to be able to post process Laser and 3D printing from within FreeCAD.

I understand that each mode has specific requirements and I wondered if there is value in creating three separate post processing modules, one for each mode. Perhaps it should be per module, differentiating between the 1600 mW and 10 W laser and the Single vs Dual-Extruder, perhaps take into account the 4th axis rotary module, etc.

The point being that making a single Post Processor that handles all this seems less than ideal.

In addition, there is no reason that I can think that a G-Code like G83 can't be replaced by a few lines of G-Code and thus adding G83 support to the hardware. Note that G83 is just an example. You're alreading replacing unsupported tool changes with a pause, so this idea is already happening.

I understand that this is a non-trivial process. I'm a 40-year software development professional, but my journey into SnapMaker and G-Code is still very young.

I realise that "patches welcome" is a perfectly valid response, but I'm hoping to learn if this is worthwhile before digging in too deep.

Kind regards, Onno

[ITmaze]

I'm acutely aware that creating this issue represents more work for the project and as the instigator of this issue, I'm happy to assist.

When I raised the issue, I started thinking that this might represent three different post processors, one for CNC, one for Laser and one for 3D extrusion. As I started thinking deeper about this, I suspect that given the modular nature of the SnapMaker platform, it would be useful to manage this at a more granular level, especially if the post-processor is going to implement variations of G-Code depending on the level of support.

For example, the "Dual Extrusion 3D printing module" might support swapping filament, but the announced "J1 HighSpeed IDEX 3D Printer" supports two separate extruders, a subtle but significant distinction. This points to different underlying hardware in the form of devices as well as different modules - which is why I renamed the post processor on my workstation to SnapMaker_A350_CNC_post.py.

Given the modular nature of Python, it seems appropriate to design a way to facilitate this ecosystem, rather than hard-code one post-processor for one specific example. Note that I'm leaving the actual implementation of such a module as a separate process, since it seems logical that there are users who might want to extend the code base to include newer modules.

I could also imagine a translation layer wrapped around a module to incorporate the current rotary module, since it implements a 4th axis.

[clsergent]

Once again I will take into account your advice, and rename the current postprocessor to Snapmaker_2_CNC_post.

Here is the justification:

• Snapmaker is written the same way the company writes it, with a leading capital.

• 2 refers to the machine generation. 2.0 is used by the Snapmaker company, but it is not allowed by the Path Workbench. This number is used over Axxx, because even if I only tested the postprocessor on my A350, all "Snapmaker 2" machines share the same controller, and the postprocessor does nothing specific to the A350.

• CNC obviously refers to the function of machine the postprocessor serves. Other values could be for instance "Laser" or "FDM".

[ITmaze]

Noted with the following observation:

The various "Snapmaker 2" machines have different dimensions, even though they share the same modules and controller. This means that a boundary check warning is specific to a model, even if they use the same dialect. I realise that a boundary check is an extra "feature", but it highlights the example of modularising the code.

I also understand that I keep hammering that point, but having written software for 40 years, old habits die hard :-)

[clsergent]

You are absolutely right about the boundary check, which could add a safety net.

However I think that it is not trivial... Indeed, the origin is not absolute and may be placed wherever you want within the build area. As a consequence, boundaries vary accordingly...

Two alternative mechanisms could be implemented:

• set the origin early (center, top/left, top/right, etc.): a boundary check can be done but will be valid only if the origin is accurately set on the machine. It also constrains the placement of the material on the build plate
• check distance between max coordinates along the three axis: the check will only be valid if the toolhead origin coincides with the origin set in FreeCAD

Theses mechanisms cannot always prevent from crossing physical boundaries and may give the user a wrong feeling of security. Thus I prefer to rely on the machine mechanisms.

However, I may have missed another implementation, so the discussion remains open!

[ITmaze]

Boundary checking is never trivial :-)

My very first pass of this is to keep track of movements and warn if the total sum of the movement in any axis exceeds the maximum travel of a device. This does not take into account any origin, but as you point out, that could be anywhere. For example, I'm working on a modular mounting system where the origin is the same for all my models, but not in a standard location.

The challenge with keeping track of movements is switching between absolute and relative movements, which will cause all manner of "fun". At the moment I'm thinking that the implementation might track min_x, max_x, etc. and update as required. The error might be something like: "Warning: G-code appears to exceed Snapmaker dimensions in the x-axis."

The boundary dimensions could be a command line option, but I favour entering these boundaries into a wrapper for each device. It also means that people who used the Z-axis extension for Snapmaker 1 might also benefit from this post-processor.

I also note that this thread might become a generator of feature requests. Do you want these to show up in this thread, or would you like to track them as separate issues?

o

[clsergent]

A simple boundary check can indeed be implemented using axis extrema. They may have to be calculated though, notably if arcs and Bézier splines are used(did not check if the latter has been implemented in Snapmaker firmware).

[clsergent]

As the thread is a place to discuss, it is indeed a generator of feature requests. To keep things clean, it would be better to track each request as a separate issue.

[ITmaze]

Created Issue #6 to deal with boundary checking and added some thoughts on things to consider. It's likely incomplete.

I wonder if there's a G-Code "stress test" where every G-Code is sent to the Snapmaker to test if it exists and actually works. I realise that some of this could be achieved by looking at the firmware source code, but it seems that people are recompiling current versions of Marlin firmware to suit the Snapmaker and enable extra features.