Cura Script

[ghost]

You should include a folder here that allows users to easily import your script into their favorite slicer. The console app by itself needs a wrapper essentially to interface with cura for example. Here is something I wrote and which is working for me. I don't know to how to parallelize it however, so that is something someone with better python knowledge can do. ArcWelder.zip

[FormerLurker]

very interesting! I wasn't sure if it would work by reading in the data one layer at a time, so i will have to test this a bit before I include it. I will do this once I finish what I'm working on.

[FormerLurker]

@yysh12,

If the the layer by layer doesn’t work you can just modify it to write it all into a single temporary file and then process it in one go.

That would be a last resort due to the potential for running multiple processes. I will definitely try that out. Exciting :)

[ghost]

Sounds good! I look forward to it!

[fieldOfView]

It would be great if PyArcWelder could add a method to convert and return a string of gcode commands, instead of having to go the route of writing and reading back files.

[FormerLurker]

I will give it a go, but I fear It would negate much of the speed benefit of using c++. I'll have to try it but I know it takes a lot of time to unpack them according to my previous tests, but since I may be able to process many layers at the same time maybe it will end up being faster. Writing the individual lines from python to a file can't be very fast either though...

[fieldOfView]

Alternatively, I can create a plugin that - instead of saving the gcode to a temp file layer-by-layer - assembles the full gcode file and hands it to your postprocessor in one go. I just want to make it run after all other gcode postprocessing has been done, because other postprocessors might rely on the data being available layer-by-layer which it won't after your postprocessor is done.

[ghost]

Oh my god. It's the legendary fieldofview! You've written almost every plug-in I use in Cura. I tip my hat off to you kind sir! Your plugins are what actually make Cura usable and user friendly.

Also correct me if I'm wrong, but if formerlurker modifies his code to directly return the processed gcode via python like you asked, you could easily make the plug-in multiprocess the layers within Cura, right? Or should he implement the multiprocess himself?

If he implements it himself then the one shot process step from cura could still work because his program can then just break it back into layers if you just add like a comment line or something after each layer. That way he can keep using c instead of python if that is what he prefers.

[fieldOfView]

Oh my god. It's the legendary fieldofview!

Blush. I find @FormerLurker's work quite legendary myself...

you could easily make the plug-in multiprocess the layers within Cura, right?

I'm not quite sure; the Global Interpreter Lock in python might complicate things. I'll have to give it a try.

[FormerLurker]

@fieldOfView,

I'm not quite sure; the Global Interpreter Lock in python might complicate things. I'll have to give it a try.

The dreaded GIL.... Worst thing in python. I've been looking into using multiple processes. It will be tricky, but worth it.

So, here's what I'm thinking. It would be best to supply cura with the list of layers as it expects. This gives us the opportunity for parallelism and would allow cura to show the resulting gcode. This obviously won't work well with cura's visualizer, but I'm hoping that would provide some incentive to fix the visualization of G2/G3 commands.

This won't be an easy task, but worth it in the long run. I'm finishing up some major changes to the plugin, and will start trying out some different strategies:

1. Adjust the library to accept and return a list of strings, then adjust the cura preprocessing script to call this function for each layer.
2. Attempt to use python multiproc to process several layers at once with parallel calls to the result of step 1.
3. Accept a list of lists for processing gcode (from your suggestion) and test the resulting speed.
4. Use internal c++ threading to process each layer (from step 3). This will require a bunch of scary changes to the c++ code, but I'm up for the challenge.

Give me a couple weeks and we can start figuring out how best to integrate this as either a separate plugin, with the Cura Octoprint plugin, or both.

Love this discussion and cooperation! Just so much fun.

[fieldOfView]

This obviously won't work well with cura's visualizer, but I'm hoping that would provide some incentive to fix the visualization of G2/G3 commands.

To mitigate this for the time being, the normal preview after slicing does not actually show gcode, but specially formed layer data. Postprocessing does not happen until the gcode gets saved, sent or printed. So after slicing, Cura will just display its non-arced G0/G1 data.

It is when loading a gcode file back in that Cura actually parses gcode, and then G2/G3 will become an issue. An issue that can be fixed, but an issue nevertheless.

[FormerLurker]

It is when loading a gcode file back in that Cura actually parses gcode, and then G2/G3 will become an issue. An issue that can be fixed, but an issue nevertheless.

What do you think the odds of getting the visualization fixed are? I think it would be great if Cura updated the visualization to show the G2/G3 codes just like it does with other preprocessing scripts.

[fieldOfView]

If someone (like me) implements it, the odds that it gets merged are fairly high. If we ask Ultimaker devs to spend time on it, the odds are slim to zero. Let me get a plugin working first, and worry about the visualisation later.

Order of things to do:

• get initial plugin working with temp files and get it on the Marketplace
• fix visualisation in Cura
• work on getting your arc-fitting code integrated into CuraEngine properly

[f1vefour]

Thank you yysh22 for raising this enhancement idea, it definitely would be nice to have this functionality.

[fieldOfView]

It is early days, but here's the start of a plugin: https://github.com/fieldOfView/Cura-ArcWelderPlugin

All layers are assembled into a single file, processed by ArcWelderConsole and split into layers again.

My Linux virtual machine ate itself, so the binary for ArcWelderConsole for Linux is missing.

Edit: Linux binary for ArcWelderConsole added to the repo.

[fieldOfView]

An easy to install development snapshot can be downloaded here: Cura-ArcWelderPlugin You can install it by dropping the file onto the Cura buildplate as if you were opening a 3d model.

The plugin adds settings to the "Special Modes" category. You can easily find these settings by typing Arc Welder in the search field on top of the Custom settings panel.

[ghost]

Very nice!

[FormerLurker]

Cool, will try it out asap!

[FormerLurker]

Oh, I just added a new option to the console application in the devel branch, -z or --allow-z-axis-changes which will produce arcs across all 3 axes (for spiral vase mode). It's NOT supported by all firmware, and is experimental, but might be a nice addition as long as it includes some warning. Here's the notes from the console app:

(experimental) - If supplied, z-axis changes will be allowed within arcs (supports spiral vase mode). Default Value: false

[fieldOfView]

I'll add an option for that the next time I get to update the binaries. I can detect if the spiral vase mode is used, and only allow setting the Arcwelder option then.

[ETE-Design]

@fieldOfView Is the "easy to install development snapshot" always newest version when downloading?

[fieldOfView]

Actually, no it isn't. Here's the latest development snapshot. I'm fairly close to an official release to the Cura Marketplace.

[golfromeo-fr]

I have tested AW with octoprint and it is interesting but I am putting my files on SD card to print so if I had a script to create the *.aw.gcode from PrusaSlicer.

note: rounded models gets "compressed" a lot but as expected "square" models/layers are not "compressed" at all

[ETE-Design]

@fieldOfView How is it going, is it in the markedplace yet, or do you have a newer version than the latest you linked to?

[fieldOfView]

Sorry, I forgot to mention here that the plugin was accepted for the marketplace (yesterday).

[ghost]

Woo! Congrats! Should we close this issue or would @fieldOfView and @FormerLurker prefer to leave it open for dialogue?

[FormerLurker]

@fieldOfView, you may want to check out the new artifacts. I've been getting reports of issues in cases where Cura produces gcode that extrudes over the same path multiple times. Not sure if that's a bug in the slicer (seems like it is all coming from 4.7 gcode), or just settings related (overlap percentage very high), but in any case the new artifacts have some advanced error detection that seems to have put this issue to bed once and for all. As an added bonus, you can increase the path tolerance percent to an extremely high value (I used 10,000% in my tests) and not experience any bad arcs. That setting is still useful, but now is not required to produce working gcode, at least in my testing. I'm pushing out a development rc for the OctoPrint plugin, so perhaps it is best to wait a bit before adding these to an official build.

[ETE-Design]

@FormerLurker Is Marlin's Standard settings still the best to use to get the best result? Or do you have some settings you recommend?

[FormerLurker]

@ETE-Design, the defaults for Marlin 2+ should produce excellent results as long as arcs are enabled. Just make sure you are installing Marlin 2.0.6+

[FormerLurker]

@yysh12, did you intend to reopen this?

[ghost]

Oh sorry! I must’ve hit it without noticing. I’ll close again.