[Feature] Cura support

[tillig]

Just installed this and the SlicerSettingsTab, cool stuff. However, I noticed using Cura as the slicer you don't get settings in the format

key1=value1
key2=value2

Instead you get a block of comments at the bottom of the gcode that looks like this:

;End of Gcode
;SETTING_3 {"global_quality": "[general]\\nversion = 4\\nname = Fine #2\\ndefini
;SETTING_3 tion = fdmprinter\\n\\n[metadata]\\nquality_type = normal\\ntype = qu
;SETTING_3 ality_changes\\nsetting_version = 5\\n\\n[values]\\nadhesion_type = b
;SETTING_3 rim\\nsupport_enable = True\\n\\n", "extruder_quality": ["[general]\\
;SETTING_3 nversion = 4\\nname = Fine #2\\ndefinition = fdmprinter\\n\\n[metadat
;SETTING_3 a]\\nquality_type = normal\\nposition = 0\\ntype = quality_changes\\n
;SETTING_3 setting_version = 5\\n\\n[values]\\ninfill_pattern = tetrahedral\\nin
;SETTING_3 fill_sparse_density = 50\\n\\n"]}

Cleaned up a bit, you get some interesting JSON with nested INI-looking settings

{
  "global_quality": "[general]\\nversion = 4\\nname = Fine #2\\ndefinition = fdmprinter\\n\\n[metadata]\\nquality_type = normal\\ntype = quality_changes\\nsetting_version = 5\\n\\n[values]\\nadhesion_type = brim\\nsupport_enable = True\\n\\n",
  "extruder_quality": [
    "[general]\\nversion = 4\\nname = Fine #2\\ndefinition = fdmprinter\\n\\n[metadata]\\nquality_type = normal\\nposition = 0\\ntype = quality_changes\\nsetting_version = 5\\n\\n[values]\\ninfill_pattern = tetrahedral\\ninfill_sparse_density = 50\\n\\n"
  ]
}

Or, in not-really-JSON expanded format...

{
  "global_quality": "[general]
version = 4
name = Fine #2
definition = fdmprinter

[metadata]
quality_type = normal
type = quality_changes
setting_version = 5

[values]
adhesion_type = brim
support_enable = True

",
  "extruder_quality": [
    "[general]
version = 4
name = Fine #2
definition = fdmprinter

[metadata]
quality_type = normal
position = 0
type = quality_changes
setting_version = 5

[values]
infill_pattern = tetrahedral
infill_sparse_density = 50

"
  ]
}

Are you aware of a plugin that parses this format, or is there any plan to enhance this plugin to support that? Thanks!

[tjjfvi]

Interesting; when I tested Cura, I didn't see any settings injection, and so I naturally didn't try to support it. My plugin doesn't strictly require the key=value format, rather it uses sed to convert different formats into it. However, that JSON-INI-merge couldn't easily be parsed by sed (to my knowledge), but I'll look into supporting that.

[tjjfvi]

Weird, I still don't see the settings; I see the ;End of Gcode but not the rest.

What version of Cura were you using? Did you have to change a setting to get that?

[tjjfvi]

FWIW, I have only tested Slic3r PE; I have no idea any other slicer will work.

[tillig]

I'm using Cura 3.6.0. I didn't do anything to intentionally turn this on, it just seems to magically be there. I just went and sliced a new thing to see if it always generates it; it seems to. I changed some settings and re-sliced; the settings get updated, so it's not some fixed block of stuff, it's Cura doing it.

A quick search shows that people have requested that Cura include all settings but it apparently only includes settings that are changes from the factory defaults. They say they do that to save on gcode size. If you reset the profile you're using in Cura to all defaults, it actually doesn't include settings.

I reset the profile to all defaults, re-sliced, and the block wasn't there. Here's what Cura looks like in the settings if you don't change anything:

However, I changed one setting (layer height) and Cura shows a little star to indicate something is non-default:

After doing that, I did get the extra settings at the end:

;SETTING_3 {"extruder_quality": ["[general]\\nversion = 4\\nname = Draft #2\\nde
;SETTING_3 finition = fdmprinter\\n\\n[metadata]\\nposition = 0\\ntype = quality
;SETTING_3 _changes\\nquality_type = draft\\nsetting_version = 5\\n\\n[values]\\
;SETTING_3 n\\n"], "global_quality": "[general]\\nversion = 4\\nname = Draft #2\
;SETTING_3 \ndefinition = fdmprinter\\n\\n[metadata]\\ntype = quality_changes\\n
;SETTING_3 quality_type = draft\\nsetting_version = 5\\n\\n[values]\\nlayer_heig
;SETTING_3 ht = 0.15\\n\\n"}

So... it's apparently not always there, and when it's there, it's there because it's the custom stuff you changed.

[tjjfvi]

Oh, interesting; thanks!

[tjjfvi]

I think the best way to resolve this would be a Cura plugin/package/extension/post-processing-script/whatever-else-they-call-it that just dumps the settings in a ; key = value format at the end or whatever, as I don't think supporting Cura's weird JSON-INI-merge-dump thing is worthwhile. Sure, it adds maybe a few seconds of save-time and maybe 1kb of extra data, but anyone who has looked at a gcode file knows that makes a minimal difference.

[tjjfvi]

@tillig, do you normally use Cura and thus this issue prevents you from using this plugin, or was this just something you noticed?

[tillig]

I only use Cura. Only reason I even know about settings in gcode was from this plugin announcement showering up in Octoprint. I don't know if Cura has an extension like you've mentioned. I'll have to search.

[tjjfvi]

I'm probably missing something obvious, but do you know of a way I can find post-processing-script documentation/examples?

[tillig]

I have to admit I'm learning as I go here. I'm actually fairly new to the 3D printing community getting my first printer in September 2018. I'm a software dev and a fairly fast learner, but you may have a leg up on me in some cases.

Looking in the Cura menus under "Marketplace" I see there are only roughly 20 plugins available. I don't know off the top of my head how to create a plugin, but I have high Google-fu, sooooo...

• Cura has a really small page about plugins that supposedly lists all available plugins but doesn't. However, it does link to...
• This plugin repository which has an imperial-to-metric conversion plugin written in Python.
• Cura has a plugins folder installed under it, like C:\Program Files\Ultimaker Cura 3.6\plugins that has a ton of Python scripts. It appears there is one folder per logical plugin, though there are a lot of folders and I don't actually have that many plugins installed. I am guessing much of Cura's functionality is implemented via plugin.
• Inside Cura under the Extensions menu there's a Post-Processing plugin that's apparently there by default. It has several examples that come with it. I also see a C:\Program Files\Ultimaker Cura 3.6\plugins\PostProcessingPlugin\scripts folder that has individual Python scripts that... do stuff. Browsing the source of them I can see what's happening but the object model they use isn't documented in there so I don't know what's available.
• I did find the line in their PostProcessingPlugin that executes scripts (yeah, spelunking now!) and it appears it only passes the active set of gcode, at least that's how I read it. I also found what I believe to be the base script class definition and while it appears you can access your own settings, it doesn't look like you get the current slicer settings.

Based on all that, I gather the most likely way you can do this in Cura itself is to write an actual plugin rather than a post-processing script. How to actually write a plugin... would be something to glean from the existing plugins?

That's about as far as I can get at the moment. I guess that's a long way of saying, no, there's not really much in the way of documentation or official examples. 😄

[tillig]

I did just find in the forums that the Z Offset plugin here is a good example of a Cura plugin that post-processes gcode on its own, not using the PostProcessingPlugin. Maybe that will help?

[tjjfvi]

Thanks! Too bad though that your Google-fu didn’t reveal perfect documentation 🙂; I was hoping I missed something. I didn’t see the Z Offset plugin, though; I’ll look into this more later.

[tjjfvi]

@tillig, I have to defer working on this issue, but I appreciate your assistance and will gladly receive PRs, Cura plugins. etc. to help fix this issue.

[tillig]

No worries. If I get a chance I'll see what I can do. I have a few other projects in the works at the moment.

[talldonkey]

Hey, check out the first post here

FormerLurker/Octolapse#142 (comment)

I don't think a plugin is needed - I think it's easier to specify start (or end) gcode in Cura to specify what slicer settings that you want dumped out to the gcode.

The format also looks like it will work with the regex approach you are using. Therefore with some configuration on both the start gcode side, declaring a convention for Cura settings output, identifying the setting variable names, and the right Regex (which honestly I've never been able to get good at) - this should be able to work with the current release

[tillig]

Interesting. To keep it current you'd have to write something that parses the giant JSON file of all properties and dump the thing you paste into the gcode start block. I'd want all the settings visible, not just a subset.

[talldonkey]

I'm not sure what your use case is, but mine is to work towards automating the usage of Octolapse.

Currently we have to manually copy settings from cura to the Octolapse plugin.

https://github.com/FormerLurker/Octolapse/wiki/Printer-Profiles---Cura-Settings

The Octolapse plugin needs a few (15) key speed settings to work at the best quality and not interfere and cause artifacts in your print. It's a pain in the butt esp if you have different settings for different materials, filaments, models, etc.

Therefore manually cobbling together a list of those 15 properties, manually putting it in my start/end gcode somewhere and manually keeping up to date with property changes (should be minimal for those specific properties) is enough for MVP for my specific use case

[tillig]

I was more hoping to be able to view the complete list of slicer settings from the SlicerSettingsTab plugin, companion to this one. I'd want all the settings rather than just a few.

[tjjfvi]

@tillig, @talldonkey: Solved. Add this gist to your start/end gcode; it should work for all the settings. I removed start & end gcode, as that is where the settings will go, but you can reinsert those if desired by removing a semicolon from the beginning of the line (if there are two).

[FormerLurker]

@tjjfvi,

I tried your gist code, and it works nearly 100%! There are a few settings that aren't being replaced, but I am one version behind, so perhaps this is the reason. The only settings that give me substantial issues are the start/end gcode tokens. If I put either of those codes there, gcode will be added to the file in a runnable format (will be sent to printer). Perhaps there exists an encoded variant of those two tokens? Additionally the settings tokens are re-added. For the time being I suggest leaving those two out until a workaround can be created.

[tjjfvi]

@FormerLurker: Oops! I’ve removed those.

[tjjfvi]

Added info to README; closing.

[tjjfvi]

@tillig, this will now always get you the most up-to-date version.

[FormerLurker]

@tjjfvi, the new version works great, thanks! By the way, how did you find documentation about the settings replacement tokens you used in your gist?

[tjjfvi]

@FormerLurker: I used the JSON file linked in @talldonkey’s Octolapse issue linked in @talldonkey’s first comment in this issue.

[FormerLurker]

Wow, I guess I didn't really understand what taildonkey was posting at the time! This whole time it was right under my nose.

[tillig]

Verified in Cura 3.6.0.

For future folks, if you go to Settings -> Printer -> Manage Printers, select your printer, and click "Machine Settings" - that's where the start/end gcode can be added. I put it in the end gcode and the SlicerSettingsTab plugin displays it with no problem in Octoprint.

Super nice! Thanks for doing this and providing these plugins!

[johny-mnemonic]

@tjjfvi Thanks for this great find!
I just tried it and it works.
There are quite a few fields however, that are missing from your gist, while they are in the json you are parsing. For example "Initial Layer Print Speed".
Looks to me as if they are missing in case they are nested too deep in that json. Your gist seems to only contain first two levels from that json. Anything nested deeper is missing.

From short inspection it looks like they do have at least four levels of nesting, not just categories and their children as you call it here.
Looks like simple fix, but my programming skills are still too lame to send you PR :-(

[tjjfvi]

@johny-mnemonic: Thanks for letting me know; I’ll look into it.

[tjjfvi]

It seems like things can have children even if it its type is not category; I’ll fix this tomorrow.

[tjjfvi]

@johny-mnemonic: Fixed!

[johny-mnemonic]

@tjjfvi Thanks! It looks complete now.

[FormerLurker]

Hey, I know this has been closed for a while, but I have been implementing multi-extruder/multi-material support for my plugin and made a cura discovery that you might be interested in.

For settings that have "settable_per_extruder": true inside of the fdmprinter.def.json file, you can request the per extruder settings via the following replacement token pattern (using retraction speed as an example):

; retraction_speed_0 = {retraction_speed, 0} 
; retraction_speed_1 = {retraction_speed, 1}
; retraction_speed_2 = {retraction_speed, 2}
; retraction_speed_3 = {retraction_speed, 3}
; retraction_speed_4 = {retraction_speed, 4}
... etc

There are a few other tricks that can be done, such as extracting the support extruder material temperature and such. See this merged pull request for more info. Enjoy :)

[FormerLurker]

One more thing, I noticed that if you try to extract settings for an extruder that doesn't exist in the machine definition, it just spits out ALL of the replacement tokens in json format. Yuck.. This is definitely a bug somewhere in this file. I don't have time at the moment to figure out what is going on, but it's definitely a Cura bug with very unfortunate results.

[FormerLurker]

One final update - The bug that I mentioned in my last post has been resolved. Multi-extruder extraction looks like it will work as expected in the next Cura release! Thanks!