Possible to port this to a slicer

[benjjyman]

Hi I read about the preprocessing Times a raspberry pi would take to apply all offsets and I wondered if this program could be made as an plugin to cura or similar slicer so the heavy lifting is done by the main pc/ mac.
I really don't have the coding skills to embark on such a project, I only dable in python and arduino / pi. It's been over 20 years since I programmed c# or pascal or even visual basic.
Its just an idea, I don't know if it would make it more difficult for the end user having to send the offsets back through octopi, to a plugin attached to a slicer or even a standalone app?

[Willmac16]

From what I know (I don't use Cura), Cura and its plugins are python based, so the code could probably be ported to Cura. You could make it a standalone app since all that this plugin does is take in a gcode file and manipulate it using some number and some somewhat fancy math (I also added the option to probe a grid with version 0.4.0, but you could copy the points from the octoprint config.yaml file). I'd be happy to help you get things working with cura, but I don't really have the desire to do that development myself since that is a whole new environment to develop for that I don't personally use.

One other thing to note, is that I plan to rewrite the actual processing in C++ to be faster and less blocking of octoprint (my TranslateModel plugin was a practice run at this sort of coding).

[Willmac16]

From what I know (I don't use Cura), Cura and its plugins are python based, so the code could probably be ported to Cura. You could make it a standalone app since all that this plugin does is take in a gcode file and manipulate it using some number and some somewhat fancy math (I also added the option to probe a grid with version 0.4.0, but you could copy the points from the octoprint config.yaml file). I'd be happy to help you get things working with cura, but I don't really have the desire to do that development myself since that is a whole new environment to develop for that I don't personally use.

One other thing to note, is that I plan to rewrite the actual processing in C++ to be faster and less blocking of octoprint (my TranslateModel plugin was a practice run at this sort of coding).

@benjjyman I realized that my previous reply may have not pinged you, so here is a ping. One thing I didn't add earlier is that it should be easier to run the code standalone with how I plan to write the C++ processing. Let me know if you have any more questions.