M104 T1 also changes tool

[trgtylcnky]

I am Using Cura 3.0.3 and I cannot print with dual extruder. I am using Smoothieware firmware. M104 T1 Snnn is considered a tool change command. I think Cura assumes this wouldn't change the tool but according to this (https://github.com/Smoothieware/Smoothieware/issues/760#issuecomment-154208693) post on Smoothieware repository, it is a NIST standart. For example, in the beginning of the Gcode, there are these lines:

M104 S260
M104 T1 S260
M109 S260
M109 T1 S260

After these lines, firmware selects the tool 1 but the rest of the Gcode is supposed to be executed with tool 0. This problem doesn't occur in the old version of Cura (15.x.x)

[fieldOfView]

I see two solutions:

• Put "T0" somewhere in your start gcode, so smoothieware switches back to your T0
• Put your own heatup sequence in your start gcode, making sure you include {material_print_temperature} somewhere in there. Cura will not insert its own heatup code before your start gcode if it sees your start gcode includes heatup commands.

[trgtylcnky]

Thank you, but I don't think it would work. Because there are other M104 Tn commands in the code, such as when selecting tool 1 and setting the tool 0 temperature to standby temperature.

[diegopradogesto]

Which GCode flavour are you using in 3.0.3 and which one did you use in 15.x.x?

[trgtylcnky]

I am using Marlin flavour and I was using RepRap (Marlin/Sprinter) in 15.x.x

[smartavionics]

FYI, I checked the current RepRap source code and for that firmware, M104 does not select the tool specified by the T param but M109 does.

[diegopradogesto]

Yes, that's what I was trying to find out. If you use the Marlin flavor but you have another different firmware in your printer, there could be few differences.

[trgtylcnky]

I see. But making this Smoothieware compatible won't break Marlin compatibility. Also, the closest choice to Smoothieware is Marlin so I need to use that.

Normally, I would say this is Smoothie's problem but they said it should be that way according to NIST standards.

[smartavionics]

Maybe we need to add a smoothieware flavor which can behave differently than Marlin in this respect.

[Ghostkeeper]

There is indeed a NIST standard for g-code, but it says nothing about M104 and only says something about T separately or in conjunction with M6 (Tool Change). I think the separate T# command was misinterpreted as if it also applies to the T parameter on other commands. On the other hand, the RepRap Wiki page about g-code says that T is indeed a parameter indicating which tool the command applies to. So I'd like to challenge that claim of Wolfmanjm there.

FYI, I checked the current RepRap source code and for that firmware, M104 does not select the tool specified by the T param but M109 does.

If this is the case, then changing the start g-code should be sufficient, right? We never output M109 T# in the engine because the only time we really need to wait for the temperature to be reached is when we are just about to print. Judging by that Smoothieware issue though, it seems to interpret M104 T# as being the same as T#\nM104. Looking at their code I'm not exactly sure what to think, but it seems that they don't use the tool number in the actual heating command (the tool is stored in the designator field). We only output M104 T# to pre-heat, so if it's not supported, then this g-code flavour should not pre-heat.

You can work around the problem by setting the heat-up speed to 999999 degrees per second. This effectively kills pre-heating and puts the M104 T# command right before a T# command, where it can't do harm. I'd welcome a PR that implements a machine setting to enable/disable pre-heating, but with that workaround it's probably not really necessary.

[nallath]

All m codes are considered to be machine specific if I remember correctly.

[ChrisTerBeke]

I've seen a lot of different behaviours for M codes, for starters the response to a M105 to get temperature data is quite different per machine.

[trgtylcnky]

You can work around the problem by setting the heat-up speed to 999999 degrees per second.

I will try. In case you will try to make a Smoothie flavor, the following statement instead of M104 T1 S200 would work, I think:

T1
M104 S200
T0 ; I am sure the engine knows which tool was active before so switch back to it

[boilerbots]

I am looking at this same issue with my Smoothie board. Just to be clear, when ever the Tx command is seen, the Smoothie firmware switches to that new tool until the next Tx command. It is modal just as NIST suggests, although 3D printers choose to not implement M6, so how this works is somewhat ambiguous.

Perhaps we need a Smoothie flavor? There is a second problem regarding Cura and Smoothie and that is related to G0 vs G1 speeds. Smoothie stores the last used feed rate for G0 and G1 in separate variables but Marlin/RepRap do not.

[Ghostkeeper]

I would prefer a setting to enable/disable individual features of the g-code flavours over adding new flavours. Eventually it should be possible to remove the flavour setting altogether. So I'd rather see a setting to enable/disable pre-heating or disable/enable commands on the not-currently-active nozzle.

[tarchive]

@Ghostkeeper

You can work around the problem by setting the heat-up speed to 999999 degrees per second.

I do not see a setting like this anywhere. Has it been removed or the name changed?

The only work around i found was to set the material standby temp the same as the default printing temp which effectively removes the M104.

I would prefer to use your work around for the many obvious benefits but i just cant seem to find any settings or google results describing this.

Edit: Okay i found the "Extrusion Cool Down Speed Modifier" setting which appears to also control the heat up time. The problem is that anything over a 2 degree C Per Second gives an error and slicing aborts. This is still not useful unless i can specify something much higher.

Is there a different setting or a way to override this limit where i can use 99999...

[Ghostkeeper]

I do not see a setting like this anywhere. Has it been removed or the name changed?

This is a machine setting. You can modify it only in the printer definition file (which is intended because you are then essentially writing a printer definition for a printer which is not normally supported by Cura) or by installing the Machine Settings plug-in by FieldOfView from the marketplace. That plug-in is probably recommended if you're just experimenting a bit.