G-Code Interpolated Printer; stop recipe proliferation

Let Pathio determine how to best present your known g-code output.

We all have different printers and they all have some language. There is a basic core group and then there is the printer specific stuff that must be worked out. Why not simply let the slicer software determine a starting point to dial in your specific printer profile? When characterizing your printer, it can query the user to clarify an interpretation. Most printers come with optimized sample prints which is more than sufficient to interpolate 99% of the slicer settings needed to generate a starting point g-code file for any printer. This feature alone could revolutionize your pathio slicer by taking advantage of unique printer features, whether added in later F/W, or are simply unique to that printer. This could even open up some previously closed printers.

The actual slicer engine could not care less about the g-code. It just generates the positions and has input on flow rates and travel velocities within a geometric bounds. If you give the g-code generator a hind of what to provide, it will be able to interpolate the data such that it responds to format and values of a known print. This really is AI at work and functions best when allowed to query the user interactively.

Of course this thought could use refinement, but I believe it is a game-changer if this could be part of this development or follow on (or other party). Consider this concept as new and unique for our industry. An asset that will prove itself over time as it has in other industries not too far from our realm. The basis is already well published under the heading “recognition”.

Some of this sound interesting about automatic setup of printer and then clarification from user. But you lost me at

I am not quite sure what you mean. Should you load a piece of premade gcode from the manufacturer, and then have an AI/ machine learning algorithm to analyse it and learn it’s structure?

Can you be a little more specific on what precisely you have in mind? Maybe provide an example. It sounds interesting.

You have it right, CC. There are always two layers of interpretation when setting up a recipe. One for the user and one for the machine. Things get lost in translation. So why not let the machine talk to the machine by examining the way the data is presented and how the motion and feed relate to specific functions. A known good file from the prospective printer which Pathio wishes to be a host for would provide slkcer input for a 95% or so complete profile with the benefit of a common format native to that printer if it applies (or even a solid Cura recipe you are use to). My example is the Cubify line of printers from DDD. Once decrIpted, these are dead simple files but the recipes are highly refined and therefore worth exploring. AI recognition would go a long way to automating an otherwise daunting task. All the 3D data supporting the feed and speed aspects is also there making analysis data complete. What cannot be gleaned by AI is special functions. There machine learning technology would take this to the next level yet again.