run inverse kinematics calcs prior to runtime?

Hi everyone

As we know, GCODE is output from a slicer in cartesian coordinates, then if using a non cartesian machine inverse kinematics algorithms run in real time on the MCU in the case of Marlin and I know there are projects that do it on a host computer

My question is could we just replace the cartesian values in the GCODE with the translated values prior to runtime. It would require that G02 and G03 are not used and arcs are broken up into small lines by the slicer.

The host-PC /slicer could deal with real motion data if it has an exact model of the printer. But homing distance and bed levelling are 'live' values most of the time.
Also the Gcode is kept general to slice a part for different printers.

For non-Cartesian printers, the slicer would have to break up not just arcs into short segments, but even straight lines (like found in the infill) would have to be broken up into segments. For some models this would blow up the size of the G-code by more than an order of magnitude.

Edited 1 time(s). Last edit at 09/11/2018 12:47AM by LoboCNC.

Arches are already broken into segments in stl. So when slicer deals with arch it already deals with a Cartesian model of arch broken into straight lines. At this point, there will be a need for approximation of straight lines into arches.

Your idea isn't really compatible with the purpose of g-code.

You need to know the absolute coordinates of the toolpath in order to calculate the inverse kinematics, but a g-code file does not have that information. It doesn't know where the homing switches are until they are found, and doesn't know the shape of the bed until it has been probed.

Complete g-code is closer to a programming language than a list of xyz coordinates, the full specification includes arbitrary coordinate offsets and rotations, along with variables, loops, and macros. Controllers are also expected to support a number of features such as feedrate overrides which require knowledge of the kinematics of the machine.

Thank you for the insightful and informative answers, i'm properly dissuaded

Correct me if I'm wrong but aren't you describing klipper? Yes I know it technically calculates the inverse kinematics on the fly at run time-ish with a bit of a buffer, but as far as the micro controller running the machine is concerned, the inverse kinematics have been done prior to run time.

I don't know if the raspi classifies as a "host computer" like you mentioned in the OP. I personally don't think of it that way when it stays permanently connected to the MCU and it's only function is to run klipper. I just see it as another part of the printer's electronics at that point.

Edited 1 time(s). Last edit at 09/16/2018 10:25PM by Trakyan.

I think the idea here is, the arduino is too slow to run the delta computations, so instead a delta printer for example can receive gcode in it's native coordinate system rather than transforming it on the fly.

Now... what would be really interesting is if the gcode could compensate out other factors like wobble, resonance (very difficult), non-linearity, axis mis alignments. Maybe it already can do this? If so, I am not sure how it calibrates, but once these parameters are known, it could adjust the gcode again to compensate for it without adding overhead to the controller.