Best posts made by 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

@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.

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 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.

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

Therefore, if you can't physically have a lower standby temperature (because both tools share the same heater), then why don't you simply set the standby temperature to be the same as the active temperature? Then it won't matter what tool is in what state.

In theory yes, in practice this is very error prone method. First - Cura maintains that standby temperature as material property. So if I update material I need to remember to go to each extruder and fix that. Plus if I have another printer with separate nozzles I need to remember not to do that or to revert that back. Plus if I want to adjust temperature in fly trhough web interface in Duet to tune my printing this also will be screwed by incorrect state transition. On another side if firmware would fix state maintenance that would work for both variants of printers - shared nozzles or not, or even one that has both shared and not shared in the same hadrware uniformly without any issue.

I think it is pretty clear that state maintenance has a bug here there should be no transition from standby to standby mode. Otherwise logically we should have transition for active tool from active to active again. That would fix the issue as well, but I do not think that is necessary.

As I said before, I don't understand why you are trying to use a low standby temperature for two tools which share the same heater.

I am not trying to use standby temperature, I do not have a choice. Cura injects that code no matter what AND the worst possible way. I know that IT is Cura's problem, but why not to fix bug here and on a side effect it would eliminate this issue with Cura?

To repeat again I do not get confirmation yet but I think it is pretty clear that transition from standby to standby is a bug and fixing it should not break functionality for existing users and improve other people experience at the same time.