Jump to content
Ultimaker Community of 3D Printing Experts
kerog

How can I get settings in postprocessing plugin script

Recommended Posts

Hi,

 

I'm trying to update some of my old Cura 1 postprocessing plugins for the new Cura.  One of them is a color change at height for dual extrusion printers.  As part of the plugin I'd like to access some of the existing parameters, like rest temperature or extruder start/end gcode.   Can anyone tell me how to do that?

 

Also, is there any documentation anywhere on the plugin and/or postprocessing script API?  All I have had to go on so far are examples...

Edited by kerog
clarification

Share this post


Link to post
Share on other sites

from UM.Application import Application

(I believe "machine_start_gcode" is the parameter you're looking for which I looked up by looking at Cura/resources/definitions/printrbot_simple.def.json)

then anywhere in your script you can get a property by calling:Application.getInstance().getGlobalContainerStack().getProperty("machine_start_gcode", "value")

Share this post


Link to post
Share on other sites

This is something I wanted to add to my PostProcessingPlugin Script as well so I looked at it a bit more.

 

In my case I wanted to retrieve retraction_amount and while I'm getting a value it is not returning the value for the latest slicing but what is set for the machine profile.

 

Note: I've tweaked the parameters so now I have a custom tab.

So I guess there are multiple settings for the same parameter and you have to grab the correct container stack to get what really is in use.

Share this post


Link to post
Share on other sites

When I try to run my postprocessing script, I get an error at this line:

 

 output_line += Application.getInstance().getGlobalContainerStack().getProperty('machine_extruder_start_code','value');
 

TypeError: Can't convert 'NoneType' object to str implicitly
 

The implication to me would be that this is not working, but I don't know precisely what about it is not working.  How does one go about debugging something like this?  So far it's been

 

(1) modify the python

(2) quit Cura

(3) restart Cura

(4) reload the model

(5) reconfigure the postprocessing script

(6) save the gcode

(7) check it, and check log for errors

 

Kind of cumbersome.  I imagine there's a more efficient workflow, and would like to know what other people are doing.

 

 

Share this post


Link to post
Share on other sites

Cura has multiple "stacks" containing settings; a global stack that has all the settings that are properties of the printer (such as machine_start_gcode, build plate dimensions, but also those settings in the sidebar that have a "link" icon), and one or more extruder stacks for settings that can be different for each extruder. The machine_extruder_start_code setting is an extruder setting, and you are asking Cura for a value from the global stack. That results in a None value.

 

You can get at the extruder stacks using ExtruderManager.getInstance().getActiveExtruderStacks() (you have to import ExtruderManager from cura.Settings.ExtruderManager). Cura 3.2 has a similar function.

 

13 hours ago, kerog said:

How does one go about debugging something like this?  So far it's been

 

(1) (2) (3) (4) (5) (6) (7)

 

I imagine there's a more efficient workflow, and would like to know what other people are doing.

 

Basically that's how its done. You can save yourself some RSI by loading Cura from the commandline and specifying a model to load.  Cura 3.3 will remember your PostProcessing configuration between settings, that also helps.

 

I run Cura from source, so I get the logs output to the console. It should be possible to get the same when running cura.exe --debug model.stl, but the --debug option seems broken for me.

 

@rooiejoris recently complained to me that there is no easy way to run postprocessing-scripts outside Cura anymore. It would be nice to be able to run the script on a pre-sliced gcode from the commandline. I have been giving that some thought, and could write a python script to do that, but currently that is in the "too much to do in too little time" bin.
 

  • Like 1

Share this post


Link to post
Share on other sites

Well, you can run Cura headless by using the --headless command line argument, but you'd still need a way to connect to Cura to make it do things. For example make a plugin that exposes Cura functionality over DBus or ComServer. We don't have any real samples on this yet because it's an experimental feature, and the one working implementation we have is closed source for now.

Share this post


Link to post
Share on other sites

Very helpful information! Below code did the trick for me:

from cura.Settings.ExtruderManager import ExtruderManager

retraction_distance_from_config = ExtruderManager.getInstance().getActiveExtruderStacks()[0].getProperty("retraction_amount", "value")

 

I just hard coded to use the first extruder - works in my case.

 

Regarding development cycle I'm doing exactly what you are right now.

Briefly looked at how hard it would be to modify PostProcessingPlugin.py to load the scripts dynamically upon adding them and unload it if you remove the script but seemed more than just a change here and there... 

OTOH what I did was for the actually post processing algorithm development is to extract the actual processing out into a separate .py file that I could run independently from Cura and feed the input from a file.

But I know this is not that useful when you're fiddling with how you can get the right settings carried over into your script...

Share this post


Link to post
Share on other sites

OK, I've got a couple postprocessing plugins working pretty well.  One copies the skirt to every layer (otherwise known as a draft shield).  The other does the equivalent of a filament change for a dual extruder system.  At a particular height it swaps from one extruder to the other.  Now, there are a bunch of different ways one could implement this feature.  I'll describe my approach, and am interested in suggestions for improvement.

 

(1) At start, set second extruder to rest temperature

(2) When specified height has been reached, (a) Execute specified g-code move (e.g. G0 X0 Y0), M104 current extruder to rest temperature, M109 new extruder to print temperature, and then select the new extruder.

 

The G-code move allows the user to select a location that will involve a minimum of oozing over the part during the move.  I use this in combination with the skirt on every layer so that the skirt primes the new extruder.

 

I looked at using the extruder start and end code, but interestingly enough found that the [<setting>] syntax didn't get translated when I polled the setting as described in the previous post.  BTW, what do people use those for, anyway?

 

Once these plugins are decently finalized, where does one submit them these days?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Announcements

  • Our picks

    • Architect Design Contest | Vehicles.
      We're open for entries! - Design and submit your 3D designs of architectural entourage - vehicles - for a chance to win a large filament pack. Presenting an idea, an architectural design or something as big as an urban project isn't easy. A scaled model can really help to get your idea across.
        • Like
      • 24 replies
    • What The DfAM?
      I'm Steve Cox, an experienced engineer familiar with 3D printing. I wanted to share some DfAM guidelines with this community to help and make stronger parts.
      I'm also an Autodesk Certified Instructor for Fusion 360, so many of the images in ...
        • Thanks
        • Like
      • 22 replies
×

Important Information

Welcome to the Ultimaker Community of 3D printing experts. Visit the following links to read more about our Terms of Use or our Privacy Policy. Thank you!