Set temperature failed with klipper via WEB Ui
Hello!
I'm using Repetier Server Pro 1.2.0 with klipper on a Voron printer.
There is one behavior which is strange:
If the printer is fresh started I adjust the temperatures (bed and hotend) from my desktop via Repetier-Server Web UI. Works!
When temperatures are reached I start the print from the web interface either. Works!
After print is finished, I remove the parts. If I want to adjust the temperatures now again from the WebUI, this does not work. It seems that klipper is not accepting any temperture value from the WebUI or the new values will not be send. Even if I do a firmware restart remotely, Repetier-Server is not able to adjust the temp settings again.
If I start a new print via WebUI (without pre-heating of the printer) the heatup takes place as given in GCode and print starts after reaching setup temperatures. Strange...
Any chance to reveal this issue?
Regards
Stefan
Comments
Strange I can't reproduce it on my system.
Which Klipper version do you use? Could you tell me the exact process to reproduce your issue?
Meanwhile you could try to update the Server to 1.3.0 and give some informations from the log to see what happens.
Nothing special there...
Can someone reproduce that behaivior? Which logfile could help here?
Regards
Are you connected using the api connection as well? Installations from server side would create and call klipper with proper commandline. That way we can still see that e.g. heaters were turned off also you hid them in a command we can not inter pret (PRINT_END). Otherwise we might still think heaters are on. Also I think we have no test to not send the command. So main question at this stage is do we not send the command or does klipper not execute it as expected.
In klipper if you have set a name some functions will use the official klipper command SET_HEATER_TEMPERATURE instead of M104/M140
Same behavior on Touchscreen and Web Interface.
Haven't tested it on klipper printer for now and due to time it has to wait a bit. But I wonder that no one else is having the problem as well. Especially since these functions are identical to all firmwares.
With that start gcod ein klipper server even would not need to set temperatures jsut calling PRINT_START and it should be set even if we would not do it.
There is one reason why server would stop sending M104/M140 and that is firmware says it is unsupported. Then it would strip all these commands from being send later until it is reconnected. In case of klipper this happens if we receive:
Sorry for troubling you, but I think it is a bug in RS:
Entering after a finished print in console:
switches the extruder on, in the terminal I see a acknowledgement of the command, the menu item for extruder turns red:
So big question is where do you differ? When you enabled command in console, did you see the M104 was send? I ask because you did not answer the question if it was marked as unknown command before so server would filter it. In my case it was not marked so it was send and executed as supposed by klipper.
// Unknown command:"M104"
during the print also I do not have an idea why it should do so.
Did you log a first print and search for // Unknown command: to see if there was something explaining this?
Unknown command:"M140 110"
Unknown command:"M140 110"
Unknown command:"M104 240"
server assumes M104 is unknown so it prevents resending it. It does not know klipper in reality means wrong parameter for command as it states it is unknown and resending unknown commands is a waste of resources which is why we do it, also for other firmwares it really means M104 is unknown. So guess I remove the definition for klipper so it does not do unexpected things just due to a type error.
You can do it as well removing