M104 with inactive tool puts heater in standby mode

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?

rGlory

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

It's not a bug.

Sorry, but I clearly see a bug here - tool is already in standby mode and put it in standby mode again. It is clearly a bug with improperly maintaining state in the firmware. For example if I have tool 0 active and execute T0 will it put it into active state again and switch from T0 to T0? Executing T0 deactivation and T0 activation code? No I do not think so. Because state of tool needs to be maintained. Putting aside proper or improper Cura behavior - M104 Tn Snnn rexecutes standby transition for inactive tool when it is already in standby state. This is clearly a bug or improper state management. If that bug is fixed then it will eliminate problem with Cura - win win situation.

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?

I am not asking here not to obey M104 command, taht is not necessary. It should change standby temperature as it does now. I only ask to fix state management that it would not standby tool that is already in standby state. Then Cura problem will disappear or fix would be easy and obvious. And it should not affect 2 nozzle users.

dc42

As I understand it, in the situation that is causing you a problem, Cura is sending a M104 command with a T parameter referring to the tool that is already on standby in order to change its temperature. RRF implements that by calling StandbyTool on it. Granted, if the tool is already in standby, it could do it by setting the tool temperature directly instead. But that wouldn't solve your problem, would it? What you seem to be asking RRF to do is to ignore Cura's attempt to change the temperature of the standby tool - which would break the behaviour for users with dual-nozzle printers.

I'd really like to hear what @burtoogle has to say, he is the Cura expert round here.

rGlory

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

Granted, if the tool is already in standby, it could do it by setting the tool temperature directly instead.

Not quite. There is no instead here - M104 or M109 handling changes standby temperature already and I do not ask to touch or change it. This is existing functionality. I only ask not to standby tool that is already in standby state.

But that wouldn't solve your problem, would it?

The point is it actually would. Problem is this:

 // code here
T1 ; new tool activated, now T0 is in standby
// some more code
M104 T0 S123 ; cura sets standby temperature for T0 and RRF screws T1 state by reapplying standby to T0

So T0 is already in standby state here when M104 executed. For multiple hottend people it will change standby temperature heater for T0 and stanby temperature would be used. For shared hotend if M104 does not put T0 into standby again standby temperature for T0 would be updated but it will not affect heater as it will keep active state from T1. I hope I explained it clearly. So properly maintaining state here should not break functionality for multiple hotend and would fix for shared one.

What you seem to be asking RRF to do is to ignore Cura's attempt to change the temperature of the standby tool - which would break the behaviour for users with dual-nozzle printers.

No I do not. I am only asking to maintain state and do not standby tool that is already in standby mode. Everything else should be as it is.

deckingman

@rglory One last shot.........

Given that you only have one heater, you can only have one temperature for both tools at any given time. So you can't use a lower standby temperature. 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. Cura can send M104 Tn Snn and it won't change anything because Snn is equal to the active temperature. With a shared heater, active and standby temperatures will be the same in the physical world so why not simply configure them to be the same?

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. If the heater drops to standby temperature, then the active tool will also be at standby temperature. Conversely, if the heater is at active temperature, then the tool which is on standby will also be at that active temperature.

rGlory

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

deckingman

@rglory Your arguments don't make any sense at all, so I finally give up.

rGlory

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

Your arguments don't make any sense at all

If that arguments not good enough for you lets put it this way: almost every new user using Duet and Cura for shared hotend with multiple extruders is going to hit this issue and it takes quite long time and frustration to identify the cause and find solution. Either task is not simple. Yes we can blame Cura for that and give up, but there is a bug in firmware and fixing that will help those new users. Good enough for you now?

Thanks,
Slava

dc42

I am sorry, you most definitely are asking for RRF to ignore Cura's attempt to change the current temperature of the tool that is on standby. Cura asks to do that when it expects to switch to that tool in the near future.

The problem is that Cura seems to be assuming that the tool on standby doesn't use the same heater(s) as the current tool. Are you certain that there isn't an option in Cura to leave the temperatures of tools alone when they are not active?

rGlory

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

I am sorry, you most definitely are asking for RRF to ignore Cura's attempt to change the current temperature of the tool that is on standby. Cura asks to do that when it expects to switch to that tool in the near future.

I am not sure we are on the same page here. I am referring to the current situation with RRF as represented in github on your branch and what Cura does. So M104 Tn Sxxx sets standby temperature for inactive tool first. Am I correct here? Setting standby temperature would affect temperature of heaters associated with that tool if they also in standby mode. And it works for multiple nozzles ie separate heaters. But if a heater is shared it would be in active state (deactivating one tool puts it in standby and activating another brings it back to active if I am not mistaken here). So changing standby temperature on inactive tool would not affect shared heater if not this bug that reapplies standby mode to that tool again which puts heater into standby mode.

The problem is that Cura seems to be assuming that the tool on standby doesn't use the same heater(s) as the current tool.

I think Cura is correct assuming that the tool in in standby. Problem is that M104 handling code in RRF blindly reapplies standby mode to the tool again which applies standby mode to all heaters associated with it and that breaks the logic - shared heater loosing active state from active tool. So making M104 to check if that tool already in standby and not to do that again (standby temperature applied before and would be handled properly if heater is in standby mode) would fix this issue for shared heater and should not break anything for not shared one.

Are you certain that there isn't an option in Cura to leave the temperatures of tools alone when they are not active?

Only option I found is to disable temperature control completely. And it is not simple - you have to create a json file defining your printer and disable temperature control completely. That what I have right now and I inject temperature commands into g-code but for me this is not a very good solution. And I spent long time and many prints cancelled to find cause and this solution.

deckingman

@rglory Your arguments don't make sense for te following reasons.

You say that the standby temperature needs to be maintained as part of the material properties in Cura. That's all well and good. Then you say you need to change it for each extruder. Why? If it's set in materials properties why do you need to make changes for each extruder?

Then you say, if you have another printer you need to remember not to do that? Again why? For this printer, you can't have separate active and standby temperatures - they have to be the same because you have a shared heater for each tool. If you have another printer with separate nozzles, which allows you to use different active and standby temperatures then you'll have to do things differently in any case. No matter how or where the active and standby temperatures are set they will be different. What's to stop you creating filaments such as "PLAsingleHeater" and "PLAseparateHeaters" It doesn't matter how or where you set the active and standby temperature. If you have different machines with different temperature requirements, then you can't use the same filament temperature profile for both machines.

Then you say that if you want to adjust the temperature on the fly through the web interface, you won't be able to do it. Of course you will. Why on earth do you think you won't be able to? Hundreds if not thousands of us do that so why do you think it won't work for you?