Curaengine: Dual Extrusion Temperature Control Broken on Smoothieware

[ghost]

On smoothieware M104 TN Sxxx causes tool N to be selected which makes the idle tool temperature changes activate the tool and begins printing with it. I checked on the smoothieware irc channel and the developers indicated that there is no clear specification and potentially CNC gcode relies on M104 TN switching the tool. The fix is simply to reactivate the active tool after setting the idle tool temperature.

This makes dual extrusion fail when using Cura 2.x master as the tool switches whenever a preheat or cooldown is injected.

Attached are the original gcode and my munged gcode (sed -e 's/M104 T0(.)/M104 T0\1\nT1\n/' -e 's/M104 T1(.)/M104 T1\1\nT0\n/') in case they are useful in any way.

WSDMP_squirtle_dual_body.gcode.txt

squirtle_fixed.gcode.txt

[BagelOrb]

You could write a post processing script which does exactly that.
You can write those pretty easily.
Go to Cura/plugins/postprocessingplugin and add a script.

I don't think we will do this for all gcode cura generates, because it
might be the case that the UM3 moves to the switching bay on that T0
command.
I therefore don't agree with the smoothieboard developers.

I will also accept pull requests which only change the CuraEngine behaviour
for smoothie firmware.

[ghost]

I will do a survey of current 3d printer and cnc firmwares and if it makes sense attempt to make the case for changing behavior to the smoothie developers. If not, I'll submit a PR to add a smoothie variant of gcode to generate the tool changes to avoid affecting printers with other firmwares.

[ghost]

Ahoy,

I am pretty convinced now that the consensus behavior is not to switch tools when Tn is an argument to another command. Marlin has supported it that way since ancient history (Nov 2012, commit 06b58a9c4f6c9b01a36a17e264652891850a85eb, where Marlin_main.cpp first appeared. I didn't bother checking further back ...). With a few days of using my sed hack, I realized the workaround also has the undesirable side effect of causing the planner to decelerate to zero on every tool change causing stuttering whenever the temperature is changed.

I'm now fairly certain it's just a bug in the smoothieware g-code parser -- the tool change code just checks if the line contains Tn anywhere and performs the switch without checking if it's a command or argument. It looks like it will take a bit of hacking to make smoothieware support commands to inactive tools, but the solution doesn't really lie in cura after all so I am closing this.

[BagelOrb]

Good work and good luck getting smoothieware to work!

[trgtylcnky]

Hi, @unknownlamer
I wonder what is your current situation at this problem? Are we expecting any change in Smoothieware?

[ghost]

I talked to the smoothie developers on irc and they will not be changing the behavior since technically this is a violation of the NIST gcode spec (there are no arguments, just commands, so M104 S... Tn is equvialent to issuing a tool change at the same time as the temperature command).

They suggested using subcodes for each temperature control (M104.1, M104.2, etc) and indicated they might implement that, but it never happened. I'll try to revisit it soon and see if I can adapt my hacky patches (https://git.hcoop.net/?p=clinton/Smoothieware.git;a=shortlog;h=refs/heads/m104_hack) to be mergeable upstream (it has two parts -- needs to recognize the subcode, and optionally not wait for the planner queue to fully empty before issuing the temp command because it makes things stuttery, but not sure if they will agree with me that M104 should be an immediate command).

Their other suggestion was to use the config file to define separate M codes for each temperature control... the subcode method seems cleaner to me.

[Ghostkeeper]

If we need to allow for M104 sub-codes or G10 for temperatures, we can introduce a new g-code flavour for Smoothieware.

[boilerbots]

There was another issue for this problem but I can’t find it. In the ticket I believe the suggested solution is to add an config option to Cura for the modal T behavior support (like smoothie) then issue the T before temp commands and internally track the temperature for each extruder.

I started working on this but had so many other printer issues with my smoothie board that I dropped working on it.

[grk3010]

As suggested above, a successful workaround for this issue is to add 2 search and replace post processing scripts to Cura.
I'm using this workaround currently with Cura 4.4.1 and a custom large format FDM printer using a Panucatt Azteeg X5 GT controller board.

It would be nice to have a dedicated smoothieware firmware flavor option though!

!
!