How can I get settings in postprocessing plugin script

[kerog 0]

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 April 15, 2018 by kerog
clarification

[BoostedGcode 2]

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")

[BoostedGcode 2]

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.

[kerog 0]

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.

 

 

[ahoeben 1,981]

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.
 

[rooiejoris 5]

1 hour ago, ahoeben said:

@rooiejoris recently complained to me

I didn't complain, I asked a question... : )

And I can imagine that a full proof script is difficult, but I think a partly working work around could be quite helpfull already

[ahoeben 1,981]

Perhaps @ctbeke can say something about controlling headless Cura from the commandline?

 

29 minutes ago, rooiejoris said:

I didn't complain, I asked a question... : )

 

Complained in the nicest way possible in the form of a question ;-)

[ctbeke 133]

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.

[BoostedGcode 2]

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...

[kerog 0]

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?