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: Ultimaker/Cura#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: Ultimaker/Cura#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 ***@***.***> 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 <#43 (comment)>, 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

[paukstelis]

Great. I'll check it out this evening and hopefully try some prints.

Random 0,0 moves are a Cura problem. I don't see filaswitch needing to take care of it on its own. I just use Cura post-processing with search/replace (X0.0 -> ; X0.0) which works well enough until there is a real Cura fix.

[paukstelis]

I'm trying to use the initial retracts as 'ramming' which is followed by long retracts. I've found a couple of things. First, not all initial retract moves are included in the wipe. I have 12 moves, only the first few are actually used. Second, the long retracts with wipe don't seem to be outputting any extruder moves.

Here is what I am using in the hardware config:

## Converted to RAMMING
rapid.retract.initial[0].length: -0.2816
rapid.retract.initial[0].speed: 1756
rapid.retract.initial[1].length: -0.3051
rapid.retract.initial[1].speed: 1902
rapid.retract.initial[2].length: -0.3453
rapid.retract.initial[2].speed: 2153
rapid.retract.initial[3].length: -0.3990
rapid.retract.initial[3].speed: 2487
rapid.retract.initial[4].length: -0.4761
rapid.retract.initial[4].speed: 2487
rapid.retract.initial[5].length: -0.4467
rapid.retract.initial[5].speed: 2487
rapid.retract.initial[6].length: -0.1301
rapid.retract.initial[6].speed: 2487
rapid.retract.initial[7].length: -0.6773
rapid.retract.initial[7].speed: 2487
rapid.retract.initial[8].length: -0.7644
rapid.retract.initial[8].speed: 2487
rapid.retract.initial[9].length: -0.6821
rapid.retract.initial[9].speed: 2487
rapid.retract.initial[10].length: -0.1426
rapid.retract.initial[10].speed: 2487
rapid.retract.initial[11].length: -0.8483
rapid.retract.initial[11].speed: 2487
rapid.retract.wipe: True
rapid.retract.pause: 0
rapid.retract.long[0].length: 15
rapid.retract.long[0].speed: 6000
rapid.retract.long[1].length: 24
rapid.retract.long[1].speed: 1200
rapid.retract.long[2].length: 7
rapid.retract.long[2].speed: 600
rapid.retract.long[3].length: 3
rapid.retract.long[3].speed: 360

And here is what gets output:

; TOWER START
G1 Z1.4500 F720; z-hop
G1 X149.973 Y91.716 F7200; move to purge zone
G1 Z0.9500 F720; move z close
G91; relative positioning
G1 E0.8000 F2100; tower prime
G1 X-10.000 Y0 E-1.0000 F350; pre-retract with wipe
G1 X-50.000 Y0 F6600000; pre-retract initial pause wipe
G1 X60.000 Y0 F6600000; pre-retract initial pause wipe
G1 E1.0000 F540; prepurge initial prime
G1 X-60.000 Y0 E5.4000 F6000; purge trail
G1 X0 Y-1.467 F3000; Y shift
G1 X60.000 Y0 E5.4000 F6000; purge trail
G1 X0 Y-1.467 F3000; Y shift
G1 X-8.000 Y0 E0.2816 F1756; rapid retract with wipe
G1 X-8.000 Y0 E0.3051 F1902; rapid retract with wipe
G1 X-8.000 Y0 E0.3453 F2153; rapid retract with wipe
G1 X-8.000 Y0 E0.3990 F2487; rapid retract with wipe
G1 X-8.000 Y0 E0.4761 F2487; rapid retract with wipe
G1 X-8.000 Y0 E0.4467 F2487; rapid retract with wipe
G1 X-8.000 Y0 E0.1301 F2487; rapid retract with wipe
G1 X-4.000 Y0 F7200; wipe
G1 X0 Y-0.467 F3000; pre-purge jitter
G1 X0.500 Y0 F7200; pre-purge x adjust
G1 X15.000 Y0 F6000; long retract with wipe
G1 X15.000 Y0 F1200; long retract with wipe
G1 X15.000 Y0 F600; long retract with wipe
G1 X15.000 Y0 F360; long retract with wipe
G1 X-60.000 Y0 E20.0000 F346; cooling
G1 X60.000 Y0 E-20.0000 F230; cooling
T0; change tool

Actually, a third thing I found was that prepurge.initial.retract must be defined or an error gets thrown.

[Ghostkeeper]

Random 0,0 moves are a Cura problem. I don't see filaswitch needing to take care of it on its own. I just use Cura post-processing with search/replace (X0.0 -> ; X0.0) which works well enough until there is a real Cura fix.

If you see this happen with the current stable release of Cura (4.0), I'd like to have a project file so that I can reproduce it and maybe fix it or point out what settings are causing it.

Edit: Nevermind. We've linked before to a topic that links to a topic where reproduce steps are located.

[paukstelis]

The issue with no extruder movements on long retract wipe is just that the extruder is not defined in the method gen_movement call. Just needs the extruder=old_e

EDIT: Also figured out that wipe distance, rr_wipe_length was hard coded at 8. How about: rr_wipe_length = self.width/(len(rr_lengths)+1) This seems to ensure that all movements are accounted for.

[paukstelis]

Managed to do some testing and working on a first print. There will certainly need to be some modifications to make it nicer, but it does work and I was getting OK, though not great filament tips with the settings I had. One of the other problems I ran across is that tower raft does not seem to work in the genericparser branch. It throws this error:

  File "/home/paul/filaswitch2/filaswitch/src/filaswitch.py", line 584, in <module>
    main()
  File "/home/paul/filaswitch2/filaswitch/src/filaswitch.py", line 567, in main
    result_file = pf.process(args.file)
  File "/home/paul/filaswitch2/filaswitch/src/slicer_cura.py", line 30, in process
    self.add_tool_change_gcode()
  File "/home/paul/filaswitch2/filaswitch/src/gcode_file.py", line 441, in add_tool_change_gcode
    for line in self.switch_tower.get_tower_lines(current_z, z_pos, self.e_pos, self.active_e, new_e):
  File "/home/paul/filaswitch2/filaswitch/src/switch_tower.py", line 1033, in get_tower_lines
    gap, purge_multiplier, lines = self._calculate_purge_values(layer_h, new_e)
  File "/home/paul/filaswitch2/filaswitch/src/switch_tower.py", line 915, in _calculate_purge_values
    lines = purge_e / (utils.extrusion_feed_rate(self.purge_line_width, layer_h, 1.75) * self.purge_length * 2)
ZeroDivisionError: float division by zero

I've always found the rafts help a lot when the tower is not very large.

[paukstelis]

I've also discovered the cause of the z_hop error, though not the explanation. It looks like having movements in the starting gcode really messes things up. For example, if I have this line in my starting gcode script:

;go outside print area
G1 Y-3.0 F1000.0

It fails and throws a z_hop error. Removing that line and filaswitch works just fine.

[spegelius]

Ok I'll try to look at these problems during weekend. The wipes need more work because filaswitch isn't meant for one printer only -> the moves need to be fitted to work with different settings.

…

On Thu, May 9, 2019 at 4:18 AM paukstelis ***@***.***> wrote: I've also discovered the cause of the z_hop error, though not the explanation. It looks like having negative positions in the starting gcode really messes things up. For example, if I have this line in my starting gcode script: ;go outside print area G1 Y-3.0 F1000.0 It fails and throws a z_hop error. Removing that line and filaswitch works just fine. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#43 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABQU7WFE3ZZBZKEP3G77HPTPUN3XPANCNFSM4EZ4OWEQ> .

[paukstelis]

I've done one print with Cura+Filaswitch+Prusa MMU2S and it was successful! I had no user interventions to fix load/unloads on the MMU2 (something I haven't done with Slic3rPE), so it seems that the tip quality even in this unoptimized state is pretty good.

One other thing to consider would be to ease up on where the slicer identification takes place. If I recall correctly, right now it looks for the 'generated by Cura SteamEngine' comment at line 5 or something, but newer versions of Cura (including the git master branch) write some extra stuff so its no longer at that position and needs to be manually changed. Maybe if it appears in the first 30-40 lines?

[Ghostkeeper]

If the Griffin g-code flavour is used, the text ;GENERATOR.NAME:Cura_SteamEngine always appears on line 4 of the g-code.

Otherwise it puts a header before the generator which, if I've counted correctly, causes the ;Generated with Cura_SteamEngine <version> line to appear on line 12 at the latest. You might want to scan the first 15 lines or so just to be sure and more robust towards future versions.

[spegelius]

Fixed some bugs: raft should work now, gcode inside START_GCODE comments shouldn't affect the parsing, Slic3r PE tuning and S3D should be also supported now.
Not tested in any way, I'll do some test prints next week

[paukstelis]

Raft still doesn't work for me. I've also found that if I get lots of division by zero errors, depending on how many lines I manually define (running from command line in most cases). Last file I worked with it would throw an error until I manually got to 8 lines. Let me know if you want to see that file to test.

[spegelius]

Ok, send me the file, easier to debug. pe 10. toukok. 2019 klo 2.50 ip. paukstelis <notifications@github.com> kirjoitti:

…

Raft still doesn't work for me. I've also found that if I get lots of division by zero errors, depending on how many lines I manually define (running from command line in most cases). Last file I worked with it would throw an error until I manually got to 8 lines. Let me know if you want to see that file to test. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#43 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABQU7WF3HJDDQ2VR5ZTIPULPUVOQPANCNFSM4EZ4OWEQ> .

[paukstelis]

Here you go. With hwcfg I am using.

OPI3M_P1-bonds-4.gcode.txt

PRUSAMMU2S.hwcfg.txt

[spegelius]

Found the reason for the missing raft and division by zero errors: second tower first layer was at 0.5, which caused the purge calculation try to print one very fat line. Fixed the tower z gap fill function so now each tower has same initial z so raft works and no more huge gaps (hopefully)

[paukstelis]

I've gotten back around to doing some more testing. Observations:

1. Cura does temperature differently (tool, then temp. e.g. M104 T1 S200) when it sets temps. I've noticed in some places this leads to strange behaviour on my MMU2S (chunks of g-code being skipped by the printer). For now I've taken to just doing a search/replace to get rid of the reference to the tool since it seems that setting 'use tool id' to false doesn't do anything in this case. I think it might be nice to have a command line flag (or hwcfg?) that would allow some settings like specific temps for load/unload on a per tool basis. This is useful with true multimaterial. In my case i'm using HIPS as an interface support layer for PLA.

2. Line 565/566 in switch_tower.py still needs to have the extruder=old_e stated, otherwise there is no extrusion.

3. My use of rapid retract moves for ramming and cooling moves for what has been called skinny-dipping (quick plunge to remove strings at tips) seems to work well. Its stutters a bit in the sense that it is doing all the ramming over one sweep length, so maybe working out how to split that over multiple sweep lengths might as be useful.

[spegelius]

1. Temperature handling is currently commented out so nothing is done for temperatures. I need to add temp parsing and layer indexing to genericparser for the logic to work.
2. Added
3. I'll need to test this to see how it works. I added the prepurge.initial settings which helped with Promtheus setup to get better tips, not perfect especially with PETG (but PETG seems to work very well for me even so).
   My settings:
   prepurge.initial.retract: 20
   prepurge.initial.retract.speed: 350
   prepurge.initial.pause: 2500
   But if the skinny-dipping improves the tip even further, great. Splitting the extruder moves to the sweeps is also something I was thinking about for the wipe movements.
   BTW I don't use the cooling movements, never seen any need for them. Maybe if the filament changes are very close to each other...

[spegelius]

Temperature handling should be now working in genericparser branch. No test prints done, but gcode seems ok. Also with Cura, make sure that the standby temperature is same as the printing temperature. With single nozzle setup the standby temperature is really unwelcome feature...

[Ghostkeeper]

We've had a pull request on Cura to ease the workflow in Cura of working with a printer with a mixing nozzle similar to this.

[spegelius]

@Ghostkeeper : great, that feature makes things easier.

Sliced a multi-model with Cura 4.1 and there seems to be few of those moves to 0 coordinates: G0 F5400 X0.00 Y10 Z0.5. At a guess, does this happen when extruder prints the last time during a print? The model uses 4 materials, 3 of them are on the first layer and 2 of those print only on first layer. Incidentally there are two moves.

[Ghostkeeper]

We haven't seen a bug with those moves recently. Perhaps the Layer Start X/Y is 0 or the machine_extruder_start_pos_x/y and machine_extruder_end_pos_x/y are set to 0?

A project file can help to debug.

[spegelius]

Here's the project file: https://www.dropbox.com/s/wicl3tvg448dtex/CFFFP_3DBenchy_-_Dualprint.3mf?dl=1.
No really sure what those settings are. Nozzle offsets for all extruders are set to 0. Printhead settings are 20,10,10,10.

Printed Benchy, tool changes seem to work quite nicely. I need to tune the general print settings, though, seems the retraction needs to be upped a bit and probably other stuff. Also I'm seeing the underextrusion still, again not sure what does that. Haven't tried removing the extra M82 commands that are after each tool change, could be that those are messing with the Duet pressure advance...

[paukstelis]

I have still been seeing the occasional X0.0 Y0.0 moves as well in 4.1

[spegelius]

Disabling pressure advance fixed the under-extrusion. Something in Cura gcode messes Duet PA with small areas it seems.
Need to retune retraction, with PA ~2mm retraction works quite well, without it 2.9 seems to be bit too low.
Benchy printed with 2.3mm retraction, the other model is with 2.9mm. Otherthan that filaswitching Cura gcode seems to be working quite well. Still need to test the temperature parsing, not quite sure if the temps are set in proper places...