M104 with inactive tool puts heater in standby mode

dc42

@rglory said in M104 with inactive tool puts heater in standby mode:

So if I have Tool 0 active and issue command:

M104 T1 S100

This sets standby temperature for T1 and puts T1 in standby mode. This is explicitly painfull when I have T0 and T1 attached to the same heater. I understand that M104 changes standby temperature when inactive tool is used but it should not modify that tool state. I think only T command should change state active/standby.

Or at least is it possible to make M104 not to modify heater state when active T and tool in parameter of M104 use the same heater?

Firmware Version: 2.02(RTOS) (2018-12-24b1)

Thanks,
Slava

This is intentional behaviour, to handle slicers that try to preheat the tool on standby shortly before switching to it. It looks like your slicer assumes that tools 0 and 1 have separate heaters and it is trying to set different temperatures for them. You need to tell your slicer that this isn't the case.

rGlory

@deckingman

Where is the M104 coming from? Is it slicer generated?

Yes, it is generated by Cura. And of course it generated worse possible way - after custom G-Code for tool change is already generated.

If it is, you might be kind of stuck.

Sorry I do not understand. Is firmware here written in stone?

M104 is deprecated and ideally, you should use G10. So G10 Pn Rn Sn will set both the active and standby temperatures.

Unfortunately I do not control Cura developers. As much as I know there is no way to change that. I found a workaround - disable temperature control completely, but that is a terrible workaround.

So M104 T1 S100 followed by T1 should make it active.

I think M104 should not make tool active/standby but Tn should. But this is a different story. At least it should not change it's state when heater shared with active tool.

TBH, I'm not sure what it is you are trying to do. If you have multiple tools using the same heater, then you can't have different active and standby temperatures.

I am trying to use pretty simple setup - 2 extruders and one hotend with Y-joiner. Slic3r does not work well with multicolor yet. Cura with duet3d together screw me up I cannot prevent it to put hotend into standby mode. I had to disable temperature control and move it to printer setup G-Code which is terrible solution. So I am asking this issue was reported multiple times why not to put solution in firmware when it is so simple?

rGlory

@dc42 said in M104 with inactive tool puts heater in standby mode:

This is intentional behaviour, to handle slicers that try to preheat the tool on standby shortly before switching to it.

So this is a workaround? Maybe it should be reworked? I looked through and this "feature" seems to screw pretty many people already. I saw a request on this forum to remove "standby" state completely and I think because of this issue. Anyway for firmware not to do it is pretty simpe - that information is right there.

It looks like your slicer assumes that tools 0 and 1 have separate heaters and it is trying to set different temperatures for them. You need to tell your slicer that this isn't the case.

Why slicer should care? Firmware has hardware configuration and it says right there: T0 and T1 share the same heater. Do not change the state through T1 when T0 is active and vice versa. I think it is very simple and should not break any other printers that have separate hotends.

deckingman

@rglory I say again, if you have a single heater, why are you trying to set a different standby temperature?

What you are trying to do won't work and it isn't the fault of the firmware or even the slicer for that matter. Either T0 or T1 is active when printing and as they have the same heater then it follows that both must be active. You can't set a lower standby temperature because you only have one heater for both tools.

I use 5 extruders and a Diamond mixing hot end so I have at least 6 tools defined and they all use the same heater. I've told you how to set it up using G10 Pn Snn Rnn. Do that in you start gcode and disable anything else you are trying to do with the slicer apart from change tools. And stop blaming the firmware because that isn't the problem.

rGlory

@deckingman said in M104 with inactive tool puts heater in standby mode:

if you have a single heater, why are you trying to set a different standby temperature?

I do not, Cura does and there is no way to stop it (as much as I know) unless you disable temperature control completely.

Either T0 or T1 is active when printing and as they have the same heater then it follows that both must be active.

T0 and T1 cannot be active at the same time (using Tn command), as they have separate extruders. They use the same heater but there is no way to let Cura know that. Duet firmware already knows that from config but it does not care and puts heater in standby mode when M104 T1 Snnn issued after T0 activated and vice versa.

You can't set a lower standby temperature because you only have one heater for both tools.

I do not want to set lower standby temperature and I do not want to use standby mode at all. But I do not have a choice, no matter what I do Cura issues M104 command after tool change and after custom code generated (otherwise I could reactive heater in that code) so putting it into standby mode.

I've told you how to set it up using G10 Pn Snn Rnn.

I do not control Cura that way, I can choose temperature in boxes. If there is way to tell Cura to issue G10 instead of M104 please let me know - issue solved.

And stop blaming the firmware because that isn't the problem.

That problem exists:

https://community.ultimaker.com/topic/25233-auto-inserted-m104-t0-s0-during-print-with-dual-extrusion/

https://github.com/Ultimaker/Cura/issues/4204

As a workaround I always need to run a post script to remove the cura adding M109 Sxxx gcode... but this remove also the first M109 Sxxx that I need to be there then I need to edit the file and activate manually the first M109...

https://github.com/Ultimaker/Cura/issues/5155

I also had the problem with printing from the second extruder of a GeeeTech A10M where the nozzle would not heat up. I came up with a fix which seems to be supported by the printer firmware.

And I am not blaming firmware, I am just saying it is easier and more logical to fix it in firmware, because firmware already has that information handy - if heater shared or not. Slicer needs to be configured at least or even worse post processing needs to be added.

mtmello2003 created this issue in Ultimaker/Cura

closed Cura add temperature update gcode when tool change, without need it. #4204

szerwi created this issue in Ultimaker/Cura

closed Cura 3.6 disables heating while printing dual extruder #5155

Phaedrux

I went through similar problem with Cura when trying to set it up for use with the Pallette 2. Perhaps the solution they provide would also work for you.

https://support.mosaicmfg.com/hc/en-us/articles/115003212274-Cura-and-Chroma-Setup

In addition to setting printing temp and standby temp to be the same...

For more recent versions of Cura (3.4 and later), we've seen issues with temperature changes in the GCode that causes the extruder to pause over prints, causing blobbing and quality issues. This is due to Cura adding a number of M109 commands that causes the extruder to pause as it heats and cools. To eliminate this issue, please follow these steps:

On your computer, find the path C:\Users%user%\AppData\Roaming\cura\3.3\definition_changes\ “your printer”_settings.inst.cfg
Add “machine_nozzle_temp_enabled = False” to the [values] section. This disables Cura from overriding any temperatures changes in the GCode.
Add “M109 S200” to the startup GCode.

In other cases, we've seen that additional lines are included in the GCode that can cause issues with the nozzle temperature. If you're using Cura 3.6 of newer, we would suggest using a program such as Notepad++ to Find and Replace lines that contain 'M104 T0 S0'. You'll need to delete these lines or they will cause your nozzle to cool to 0 degrees. You can also check that the last color to print is assigned to the first extruder, helping to avoid this issue in the GCode.

rGlory

@phaedrux said in M104 with inactive tool puts heater in standby mode:

Perhaps the solution they provide would also work for you.

This solution is exactly what I mentioned - I have to disable temperature control and put custom g-code into printer startup. This works but is a terrible solution - it requires to change startup g-code every time material changed and you cannot fine control temperature anymore (for example different one for the first layer and so on). You actually
can by injecting it manually but that is a pain.

On another side it is a pretty easy fix on firmware level:

1 That information is already in config
2 It should not affect existing multi-extruder printers. Single extruder ones are screwed by this problem anyway.

deckingman

@rglory Seems like the problem is with Cura.

But I say yet again, there is no need to use temperature control of the hot end in the slicer. Disable it and do as I said with the G10 commands in the start gcode. Then all the slicer has to do is issue Tn commands without any other parameters.

DC42 has already pointed out that other slicers try to pre-heat the tool on standby and that is why the firmware works the way it does. So if he changes the firmware to suit you and the way you choose to use your slicer, then it'll upset all the other users who use a different slicer.

rGlory

@deckingman said in M104 with inactive tool puts heater in standby mode:

Seems like the problem is with Cura.

I do not disagree with that. But I doubt the issue will be fixed soon there, as ultimaker printers do not have such config if I am not wrong. So having this solution in duet would be another reason to use it with Cura and good improvement.

But I say yet again, there is no need to use temperature control of the hot end in the slicer. Disable it and do as I said with the G10 commands in the start gcode.

It is really a bad way to do it - changing temperature in g-code instead of properly modify it in slicer settings. Then you loose properties of different materials that slicer maintains, you need to do that manually. Also you cannot control temperature for the first layer vs the rest, which sometimes is handy.

DC42 has already pointed out that other slicers try to pre-heat the tool on standby and that is why the firmware works the way it does. So if he changes the firmware to suit you and the way you choose to use your slicer, then it'll upset all the other users who use a different slicer.

Preheat only makes sense for printers/users with separate nozzle ie separate heaters. For shared heaters preheat does not work anyway and this change will not break anything and it is very easy to differentiate separate heater/shared one in firmware.

deckingman

@rglory If you want to use different temperatures for different materials, just set them in the G10 commands for each tool. You don't need to set them in the slicer. This is getting too much like banging my head against a wall so I'm out of here............

dc42

Why slicer should care? Firmware has hardware configuration and it says right there: T0 and T1 share the same heater. Do not change the state through T1 when T0 is active and vice versa. I think it is very simple and should not break any other printers that have separate hotends.

Because slicers don't ask the firmware what sort of tools have been configured, and require you to tell them. Some slicers don't understand mixing tools at all.

The M104 and M109 commands were never designed to handle the flexible tool configuration that RepRapFirmware provides. That's why RepRapFirmware provides G10 for setting temperatures too.

rGlory

@deckingman said in M104 with inactive tool puts heater in standby mode:

If you want to use different temperatures for different materials

You do not understand as you probably not using Cura. It maintains library of different materials with their properties (for different makers, color etc). So if you define material and set temperature for it, it will be updated when you switch btw materials. But if you need to put it manually into g-code you are on your own. That is especially a problem when you have more than one printer and in some of them temperature controlled properly, but some of them require g-code change. Do you get it?

rGlory

@dc42 said in M104 with inactive tool puts heater in standby mode:

Because slicers don't ask the firmware what sort of tools have been configured, and require you to tell them. Some slicers don't understand mixing tools at all.

The thing is if firmware would handle it (have different behavior if heater shared or not) then I do not need to tell slicer if my heater is shared or not and slicer can produce generic code that would work on both printers with shared nozzle or not.

Is that not the target and we have setting in firmware to change tools and so on? We can put that all into slicer and not bother. But make them unified is better imho.

The M104 and M109 commands were never designed to handle the flexible tool configuration that RepRapFirmware provides. That's why RepRapFirmware provides G10 for setting temperatures too.

I cannot enforce Cura developers to use G10 instead of M104/M109, I can leave with manual temperature control. What I am trying to say - this will solve many people issue and should not affect existing users. And on top of that I think that is easy to implement feature. So this is feedback from a user of duet3d card and pretty long time spent of fixing this problem and frustration with that and I think this feature will improve mine and other people experience. If it is too hard to do or you think it will break existing users or just would not want to bother so be it.

deckingman

@rglory said in M104 with inactive tool puts heater in standby mode:

@deckingman said in M104 with inactive tool puts heater in standby mode:

If you want to use different temperatures for different materials

You do not understand as you probably not using Cura. It maintains library of different materials with their properties (for different makers, color etc). So if you define material and set temperature for it, it will be updated when you switch btw materials. But if you need to put it manually into g-code you are on your own. That is especially a problem when you have more than one printer and in some of them temperature controlled properly, but some of them require g-code change. Do you get it?

Yes, I get it entirely. Because I have been printing multi materials using 3 input, and 5 input hot ends with 0.5mm and 0.9mm nozzle sizes which I switch between on a regular basis and I've been doing that for years. So I do know what I'm talking about.

I learnt long ago that if I used the slicer to set temperatures for materials, then every time I want to print the same part using different materials, I had to re-load the STL, select the material in the slicer, re-slice it, and upload it. Now I can do the same thing simply by editing one line of the start gcode file.

But I'm not going to try to help you any more because you clearly don't want to listen.

rGlory

@deckingman said in M104 with inactive tool puts heater in standby mode:

But I'm not going to try to help you any more because you clearly don't want to listen.

I got your message, but I am afraid we understand little bit differently what "help" means. I just want to point - the way I want to do it does not conflict with your way and does not enforce you to change. But your help here from the beginning is to force me going particular way because you think it is better. And instead of explaining why this way is better you just saying it should be this way and if I try to explain why I want my way (and I am not telling you how to do that, just trying to say that my way could be also useful sometimes) you say I do not listen, you are tired and so on.

I do see benefit of controlling temperature from slicer (and many other people do, otherwise they would not put that there) and I think it is very easy to fix this issue in firmware so I came here to ask - is it possible? What I got back? "Where is the M104 coming from? Is it slicer generated? If it is, you might be kind of stuck." That's it? Sounds like I am too small to listen and if cannot be solved without changing firmware nobody cares. And I cannot try to express my opinion without hurting your fillings. Sorry.

gregspruce

@rglory For what it's worth, I would also like to see M104 not affect both active and inactive tools. It would be nice if the slicers would use G10, but since thats RRF and not most other firmwares, it's a low priority for those devs.

I'm currently stuck manually editing every gcode to remove the M104 that gets put in by both cura and slic3r after custom tool change and/or layer change g-code.

rGlory

Actually I looked into source code in github and the fix probably would not be as straightforward as I thought first, the problem is that the tool supports multiple heaters. That can be solved by comparing all heaters in both active and selected tools and if any of them shared prevent it to switch state.

But I came with more interesting conclusion reading the source:

https://github.com/dc42/RepRapFirmware/blob/dev/src/GCodes/GCodes2.cpp line 1306

	// New behaviour from 1.20beta12:
	// M109 Snnn
	// - If no tools are active, set Tool 0 to active
	// - Set active tool's active and standby temperatures to Snnn
	//
	// M109 Tnnn Snnn
	// - If no tools are active, set Tnnn to active
	// - If another tool is active but Tnnn is off, set Tnnn to standby
	// - Set Tnnn's active and standby temperatures to Snnn
	// M104 does the same but doesn't ever select a tool

So according to this "If another tool is active but Tnnn is off, set Tnnn to standby" what we discussed here is a bug, not intended behavior, because from source and observed behavior it sets Tnnn to standby no matter if it is off or not. If it would work as described here the fix would be easy if necessary at all - activate another tool at the begining of code and it would not go into standby mode.

If this is a bug indeed fix is oneliner:

https://github.com/dc42/RepRapFirmware/blob/d9f051b6c658fa278b22535a8bd03d124bcf8fad/src/GCodes/GCodes2.cpp#L1388

instead of:

 reprap.StandbyTool(applicableTool->Number(), simulationMode != 0);

it should be:

 if( applicableTool->GetState() == ToolState::off ) 
    reprap.StandbyTool(applicableTool->Number(), simulationMode != 0);

dc42

@rglory said in M104 with inactive tool puts heater in standby mode:

If this is a bug indeed fix is oneliner:

https://github.com/dc42/RepRapFirmware/blob/d9f051b6c658fa278b22535a8bd03d124bcf8fad/src/GCodes/GCodes2.cpp#L1388

instead of:
 reprap.StandbyTool(applicableTool->Number(), simulationMode != 0);
it should be:
 if( applicableTool->GetState() == ToolState::off ) 
    reprap.StandbyTool(applicableTool->Number(), simulationMode != 0);

That will break the functionality for existing users. The code is the way it is precisely because in a 2-nozzle system, Cura preheats the tool that is on standby shortly before switching to it.

Isn't there a switch in Cura to tell it that you have a mixing nozzle, so you don't want it to mess around trying to set 2 different heater temperatures?

rGlory

@dc42 said in M104 with inactive tool puts heater in standby mode:

That will break the functionality for existing users.

If existing users rely on bugs, it should be fixed anyway or at least documented. But how about:

if( applicableTool->GetState() != ToolState::standby ) 
          reprap.StandbyTool(applicableTool->Number(), simulationMode != 0);

Because currently code "puts" tool into standby mode even if it is already in standby mode. Can at least this be considered as a bug and fixed? Because that what actually screw it in this situation - tool already in standby by T command, but M104 puts it in "standby" mode blindly again, without even checking if it is not already there.

Isn't there a switch in Cura to tell it that you have a mixing nozzle, so you don't want it to mess around trying to set 2 different heater temperatures?

I do not think so, I spent long hours try to identify the reason and trying to fix it. And I suggest to put this fix as I am afraid every new client using duet3d and mixing dual extruder with Cura will hit this problem immediately. And it is not very easy to find the reason, it cost me quite long time and frustration. If you do not care about one nozzle people and 2 nozzle ones are first class citizens and you do not want to touch erronous behaviour if it may affect them, it is ok, would be good to know.

dc42

@rglory said in M104 with inactive tool puts heater in standby mode:

If existing users rely on bugs, it should be fixed anyway or at least documented. But how about:

It's not a bug. Or rather, the bug (if there is one) is in Cura. Cura is deliberately telling the machine to change the temperature of the tool that is on standby. This makes sense for a machine with 2 separate nozzles. It doesn't make sense for a machine with a single nozzle.

Perhaps user @burtoogle can comment, he knows Cura much better than I do. Maybe there is a way of turning off the feature to change the temperatures of tools on standby.

if Cura doesn't provide that facility, then the question is: to what extent should RRF put up with slicer bugs and try to work around them? Could we identify exactly when we should obey a M104 command that refers to a standby tool, when when to ignore it? In this particular case, we could say that M104 commands that refers to a tool that is on standby and has a heater shared with the active tool should be ignored; but will that always have the "correct" effect? What if each tool has multiple heaters, and only some of them are shared?