Cura Support

[cfelicio]

Cura seems to be improving a lot faster than S3D in terms of features (adaptive layers, tree support, etc), but they still do not support single nozzle / dual extrusion :(

I asked the devs if there are any plans, and they said the next release (3.3) should support single nozzle. I also tried the beta, and I see now there is an option to inject custom g-code at each extruder start / end.

Question: How hard would it be to get filaswitch working with Cura 3.X?

[spegelius]

I'll need to check how the gcode looks. If Cura saves the print settings to the gcode as comments, that will help a lot. If all settings can be parsed and custom g-code can be injected, it shouldn't be to hard.

[cfelicio]

yup, I think another problem was the old version was hard because it was all absolute gcode, now it can do relative gcode as well.

[spegelius]

I had a look at the gcode lastest Cura Beta produces:

• TOOL CHANGE gcode is in wrong position, the actual Tn gocde is before the comment. Not a big problem, the TOOL CHANGE comment isn't mandatory and could be removed, but still it needs bit of work to verify it works properly
• no settings saved in the gcode. There's a kind of encoded piece at the end of the file, but extracting values from it would need to be implemented. Also the piece probably isn't the full list of settings. This is a blocker at the moment; alternative way to tell filaswitch the settings would need to be implemented before Cura gcode can be processed.
• relative extrusion needs to be turned on by user, not a biggie, same thing needs to be done in S3D depending on the printer profile

[cfelicio]

Thanks for looking into this! :)

I can try to submit a enhancement request to the Cura team and see how they feel about it. Let me know if that's ok!

Thanks!

[spegelius]

No problem. I'm ok with submitting an enhancement request, kinda interested to see how Cura fares against other slicers.

[cfelicio]

Done :)

Cross referencing: https://github.com/Ultimaker/Cura/issues/3667

[Ghostkeeper]

I'm a developer for Cura. Could you help me out with what's needed exactly for the first two things that Spegelius mentioned?

I could easily add a comment before all T# commands, so we can add that for Cura 3.4. We currently don't have such a comment at all. But what sort of comment would you need there? Is it just ; TOOL CHANGE? Because it seems like this comment doesn't add any information that isn't already in the g-code itself. It's literally what T# means. There also seems to be the code ; START SCRIPT START and ; START SCRIPT END which can be added in Cura by editing the start g-code, or we could hard-code it in the engine.

Currently we put the settings that the user has overridden at the end of the g-code. It's intended to have a quick way of knowing from the g-code what the user has changed if they send the g-code over to Ultimaker's support team. So indeed it's not all settings by far (but we know what the rest of them are by looking at Cura's defaults for the most part). It sounds like Filaswitch needs to know certain specific settings in order to switch properly. What settings would you need there? Maybe we could add them to the end g-code.

[spegelius]

The TOOL CHANGE comment is a remnant from the beginning of filaswitch development and isn't necessary, I'll probably remove handling for in from code anyways. In other slicers (S3D, Slic3r and KISSlicer), that comment is added to the custom g-code section and it is positioned just before the actual T-command. I tried to do this in Cura in Machine Settings -> Extruder x -> Start G-code, but the comment was positioned only after the actual T-command, which doesn't work:

T1 M82 ;absolute extrusion mode ; TOOL CHANGE

Anyhow, not a necessity as I can do without it and in general I hope to do without slicers needing filaswitch specific changes.

About print settings: filaswitch needs quite a lot of info about what the print settings are to make the tool change g-code additions integrate seamlessly to the print. The preferred way to obtain that info is to have the settings in the g-code files because there's no need to parse the g-code and do deductions, which could be wrong. S3D, Slic3r and KISSlicer do this already (they store all print settings) so there's code implemented for reading required settings from the comments. Alternatives for this:

• make user configure the settings. Not good if the print settings change in Cura, so user needs to update the settings to another sw
• parse the g-code. Doable, but as mentioned before, results are deductions and might be error-prone. Also would require some development effort from me and I've got quite a lot of other stuff to implement so not very high on my to-do list

List of settings (at least these are needed):

• bed size (for determining min and max coords)
• bed origin
• printer type (delta, cartesian)
• print speeds (perimeter, 1st layer speeds, default speed, travel speed, z-speed...)
• extruder count
• extruder tool ids
• extruder temperature settings (layer setpoints if any)
• nozzle size
• path width (usually perimeter if multiple values)
• extrusion multiplier (per extruder if possible)
• retraction length
• retraction speed
• brim on/off, size
• raft on/off, height
• z-offset
• coasting

In general, I'd just dump all the settings, in my opinion it's good to have a store of old print settings that one can go back if needed. KISS actually allows users to read the print settings from old gcode, if there's need to recover settings.

[Ghostkeeper]

If you put the ;TOOL_CHANGE comment in the extruder's end g-code it seems to work properly, being put right before the T# command.

I don't think it's feasible to parse the g-code. It'll be impossible to disambiguate the extrusion multiplier and path width for instance, and it'll be very hard to detect the brim, raft, z-offset and coasting.

Cura currently puts the settings at the end of the g-code just like S3D, Slic3r and KISS, all the way in the bottom of the file. And you can import a .gcode file as profile to get the settings from it back. However it only puts settings there that the user has overwritten from the default profiles. In theory you could fill the rest in by the defaults in Cura but that would be a pain because you'd have to maintain multiple sets of default settings in Filaswitch for each version of Cura or something.

We decided to put only the user-changed settings in there so that it'd be a bit more human-readable. I don't think we'll change that part. I was hoping we might want to put a few more things in the g-code headers but that is a lot of settings there! I'll sleep a bit over it I guess.

There's a few problems with the settings that you need in Cura in general:

• Cura currently has no information about the gantry system of the printer (delta/cartesian/etc). It's been irrelevant to us so far. A machine setting could be added but not for 3.4 any more. I'm very slow to react, sorry.
• We have no tool IDs other than numbering from 0 to N.
• Cura has quite a powerful temperature control system so that the temperature is not always the same across a layer for one extruder. In particular, it tends to start printing from a slightly colder temperature, then heat up during the printing of the layer, then cool down slightly towards the end of the layer. This is to reduce oozing while switching nozzles. We could ignore these (the temperature differences are little: ~5-10 degrees).

[spegelius]

I'll re-check the tool change comment positioning; I tried it on some beta-vserion of Cura. Also might've configured it wrong, can't remember the details anymore.

• Gantry system: filaswitch checks for bed limits when checking if purge tower fits the bed so that information is needed.
• tool numbering from 0 to N is ok. S3D has a more advanced (and confusing) system where one can assign ids for the heaters so Filaswitch supports separate extruder id and heater/tool id. But I think on most systems the extruder id/number and tool id/number is the same
• I don't think the temperature variance is a problem. But Filaswitch does change the tool temperature during tool change if printing materials that require different temperatures. But for that, Filaswitch needs to know the temperature setpoints for each tool, thus needs the settings available in the gcode file.

[paukstelis]

I'm going to have a look at this again. I'm pretty disappointed with the latest S3D update, and Slic3rPE still forces models to be on the build plate, which makes printing some things very challenging.

[Ghostkeeper]

Here's a new section of documentation about the temperature regulation in CuraEngine that will be relevant to you: https://github.com/Ultimaker/CuraEngine/blob/master/docs/inserts.md#pre-heating-and-pre-cooling It indicates the places where you'll find temperature commands within a layer, and for different materials you'll need to adjust these temperature commands or remove them.

[paukstelis]

Thanks, @Ghostkeeper. Correct me if I am wrong, but Cura does send all settings to CuraEngine to slice, right? Perhaps a setting flag that would tell CuraEngine to dump all the settings to a file that could be parsed by filaswitch for the relevant stuff would be one way to go.

[spegelius]

I'm actually working on a gcode parser that doesn't need the settings in the gcode file, got fed up after Slic3r did some things that broke the Slic3r layer parser... it does read Cura gcode already, but it's in early stages still, many things to implement. Also I'll be writing some unit test so it'll take a while.

[paukstelis]

Cool. Let me know if you need help testing and whatnot.

[spegelius]

Roger. Current WIP code is in genericparser-branch, not usable yet but has the basics for parsing the gcode. About Cura: installed the latest version, having problems with changing retraction length for other extruders than 0, where's the per extruder settings?

[Ghostkeeper]

Correct me if I am wrong, but Cura does send all settings to CuraEngine to slice, right? Perhaps a setting flag that would tell CuraEngine to dump all the settings to a file that could be parsed by filaswitch for the relevant stuff would be one way to go.

Yes, Cura's front-end sends all settings via Protobuf messages over a local socket to CuraEngine. If Cura is packaged in debug mode, these settings are output to the log as well. Cura's beta releases are always packaged in debug mode, so you can see there how it looks. Alternatively, you could run CuraEngine using verbose mode (-vvv) and it will tell you too. To run CuraEngine in verbose mode, you'd need to edit the command in the CuraEngineBackend plug-in of Cura (under CuraEngineBackend::getEngineCommand(), just remove the if that checks for debug mode).

To make CuraEngine dump all settings to a file is not something we would implement in the mainstream Cura branch for just this filaswitch application. So you'd need to distribute your own version of Cura to get that or manage somehow to read it from the log.

[spegelius]

Branch generic-parser has now code that seems to process Cura-sliced files ok. I haven't printed any of the files yet, but I'll try one tonight/tomorrow. Also only Cura works ATM. And temperature handling is disabled so make sure to tune Cura temps properly for all extruders. Writing a generic gcode parser is a real PITA and don't know if I have the time or motivation to perfect it. There's just so much ambiquity that on has to try to overcome with clever tricks. Also one thing I hate is that different slicers output bit different format of commands. All are valid, but makes a truly general solution a pipe dream. Also why on earth latest Cura does retract with G1 F1200 E-2? I mean why the speed and length are swapped? Do every fw out there even support that? * excessive rant deleted *. Gotta find some motivation from somewhere.

[spegelius]

Ok more rant: why does Cura add unnecessary tool change to the beginning of a file? I sliced a model that uses T1 and T2, but Cura still adds T0 to the beginning:

`;FLAVOR:Marlin

;TIME:4833 ;Filament used: 0.134141m, 0.956529m, 2.96662m, 0m ;Layer height: 0.2

;Generated with Cura_SteamEngine 3.6.0 T0 M82 ;absolute extrusion mode`

[paukstelis]

There are quite a lot of things like this that are sort of annoying about Cura. I've seen unexplained movements to X0 Y0 after the first use of each tool.

[spegelius]

Haven't noticed that, at least yet.But some odd movements now and then, head moving to areas where it shouldn't be and messing up the print with blobs of wrong colors. But I got a 4 color print done. Not very pretty, some uneven extrusion and stringin, partly because had some bad stringing in the splitter part, which eventually caused a jam, but that's not related to Cura. The stringing part is; Cura does the head moves to new positions with G1 command that has also the Z coordinate, which makes the move very slow when head is on the tower area. So i need to fix the head move after tool change.

pic1 pic2

[paukstelis]

Good progress! I'll try to do some tests starting next month. I've been busy working on a carousel-based tool changer I'm taking to MRRF at the end of the month (hence the use of the Cura prime tower) and various improvements for my Octoprint plugin.

[Ghostkeeper]

I've seen unexplained movements to X0 Y0 after the first use of each tool.

This was a bug in Cura (and also considered by the developers to be a bug) that should be fixed now.

[spegelius]

@paukstelis : sounds interesting, I've also been thinking about how to go about implementing tool changing. Nothing concrete, too much other projects going on...

I've seen unexplained movements to X0 Y0 after the first use of each tool.

This was a bug in Cura (and also considered by the developers to be a bug) that should be fixed now.

Well that movement to X0 Y0 happened a couple of times for me. I'm using Cura 3.6.0. These movements were after tool change. Example line: G0 F5400 X0.00 Y0.00 Z0.5. Only a couple of such lines, maybe related to tool change being the last for that tool?

Progress so far:

• fixed the head moves from tower to print
• retractions/primes before and after tower look good when looking at the gcode, but having severe under extrusion after tool changes (see pics below). Need to comb the gcode through more, but so far can't find the reason

Todo:

• temperature handling, need to parse the temps from the gcode
• remove temperature commands that set the temp to 0. These seem happen when extruder isn't needed for a while or ever during the print. With single nozzle setup these kill the print
• add check that the relative extrusion is on
• also remove the unnecessary absolute extrusion commands that Cura seems to add after the tool change, luckily there's also the relative extrusion command so this is no biggie ATM. Wonder if this messes Duet somehow...
• probably other things that I can't remember right now, seems there's all kinds of small oddities now and then...

Printed a benchy with 2 colors: benchy1 benchy2

Underextruding for some reason quite a lot.

On other note, I managed to optimize the filament prepurge routine: now there's first a 20 mm slowish retract, then 2.5s pause and after that I ram 29mm, followed by immediate long and fast retract. Cuts the ramming amount to half and the tips seem to be cleaner.

[paukstelis]

Not nearly the precision of the E3D tool changer, but it is somewhat novel. Looks like this:

Yes, the X0.0 Y0.0 movements are bugging a number of people: https://github.com/Ultimaker/Cura/issues/2433

I believe setting layer_start_x and layer_start_y to something else can at least minimize some bad things from happening for this bug.

I just looked at the cpp file for the M82/M83 commands it throws in there. I don't quite get why its even there. There isn't an option to mix relative and absolute extrusion for different extruders (if you check relative extrusion it applies to all extruders).

Based on that thread above, the post-processing replacement tag might be a simpler solution for the temperature parsing, just replace all the existing M109/104s with comments.

The unexplained movements over the model at the first tool changes are something that still bugs me and is probably related to the X0.0 Y0.0 bug.

[paukstelis]

So I have finally gotten around to testing this out without any luck. I pulled the latest and switched to genericparser. At this point, I have tried testing with gcode from Cura 3.6.0.

It looks like there are a number of things that aren't getting assigned to the extruders?:

2019-04-27 16:25:07,407 - filaswitch - ERROR - Gcode processing failed: 'NoneType' object has no attribute 'z_hop'
Traceback (most recent call last):
  File "/home/paul/filaswitch/src/filaswitch.py", line 214, in load_file
    self.result_file = pf.process(gcode_file)
  File "/home/paul/filaswitch/src/slicer_cura.py", line 32, in process
    self.add_tool_change_gcode()
  File "/home/paul/filaswitch/src/gcode_file.py", line 457, in add_tool_change_gcode
    for line in self.switch_tower.check_infill(cmd.data, z_pos, self.e_pos, self.active_e):
  File "/home/paul/filaswitch/src/switch_tower.py", line 1166, in check_infill
    for line in self.get_brim_lines(current_z, extruder):
  File "/home/paul/filaswitch/src/switch_tower.py", line 615, in get_brim_lines
    if extruder.z_hop:
AttributeError: 'NoneType' object has no attribute 'z_hop'

[spegelius]

Hmm strange, I'll check that once I get some time

[paukstelis]

I have gotten it to work with some profiles, but for other profiles it fails with this error.

I'm looking at using Cura for printing with Prusa MMU2S. It looks like there is mostly a new protocol in Slic3rPE for MMU2 (ramming, etc.). I think most of this can be adapted from existing methods in filaswitch, but it looks like the wipe during initial retract is not yet implemented in genericparser, so I'll see if I can work up a PR for that.

[spegelius]

I have some wipe movements implemented on master branch, just need to merge it to the genericparser. I'll try to work on it this week, I need to do it while I still remember what is what anyways... :)

On Mon, May 6, 2019 at 1:22 AM paukstelis [email protected] wrote:

I have gotten it to work with some profiles, but for other profiles it fails with this error.

I'm looking at using Cura for printing with Prusa MMU2S. It looks like there is mostly a new protocol in Slic3rPE for MMU2 (ramming, etc.). I think most of this can be adapted from existing methods in filaswitch, but it looks like the wipe during initial retract is not yet implemented in genericparser, so I'll see if I can work up a PR for that.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/spegelius/filaswitch/issues/43#issuecomment-489468702, or mute the thread https://github.com/notifications/unsubscribe-auth/ABQU7WHYMIJ5DJIT4UHAWSLPT5MZXANCNFSM4EZ4OWEQ .

[spegelius]

I merged master to genericparser so the new wipe movements should be available. See CubeFeeder4c_wipe hwcfg for turning them on. Also comments welcome about how they work, they might need some tuning. Tested some hwcfgs and couldn't get that crash happening. If it happens, send me the gcode you are trying so I can debug. Things open currently:

• temperature handling
• preprime primes all extruders with slicers other than Cura
• KISS support
• remove random moves to 0x0
• try to find out what causes the underextrusion with Cura gcode, is it happening on all machines or just mine