Set temperature failed with klipper via WEB Ui

repman

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

Repetier_Support

Hello Stefan,
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.

repman

Thanks repetier,

I will update to 1.3.0 soon and come back with a detailed description if the issue persists.

repman

Coming back to this issue as it is still there.

I did end of last year a complete new setup with all the settings as advised in the RS-Doku. I took an image for the raspberry pi as suggested, so everything is up-to-date and in the right place.

If the printer (Voron 2.4 with klipper) was off and I started heating from the webGUI (Heatup Extruder and heating bed) this works the first time after the printer is switched on (heaters turn on and the target temperature turn red). The heating takes place. Than I start the print and this works.

After the print finishes and I want to setup heaters again, this does not work from the WEB-Gui. If I select the items in the menu they do not turn red and the heaters stay off. If I start the print from the GUI, the heaters turn on and the target temperatures turn red again. But only in case of starting the print, not seperately before.

So short story: The first time it works, after that not anymore, until I switch the printer completely on and off.

Here is my PRINT_END macro wich is executed at the end of the print:

###### Print End #######
[gcode_macro PRINT_END]
# Use PRINT_END for the slicer ending script - please customise for your slicer of choice
gcode:
M400 ; wait for buffer to clear
G92 E0 ; zero the extruder
G1 E-1.0 F3600 ; retract filament
G91 ; relative positioning
G0 Z1.00 X20.0 Y20.0 F20000 ; move nozzle to remove stringing
TURN_OFF_HEATERS
M107 ; turn off fan
G1 Z2 F3000 ; move nozzle up 2mm
G90 ; absolute positioning
G0 X50 Y200 F3600 ; park nozzle at rear
{% if printer.toolhead.position.z < (printer.toolhead.axis_maximum.z - 80) %}
G91
G0 Z30.00 F2000 ; move up 50 mm (relative Mode)
G90
{% endif %}
M84 ; disable motors
BED_MESH_CLEAR
SET_NOZZLE_LEDS_OFF
STATUS_OFF

Nothing special there...
Can someone reproduce that behaivior? Which logfile could help here?Regards

repman

Just tried one thing which could be a workaround:

Restarting klipper from the WebGUI helps! After that the temperatures can be adjusted again. But why not before...

Repetier

You should check console tab in server and enable commands. See what commands get send and if klipper sends an error back or if it was wrong command.

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.

repman

I checked that in the console. I switched on Commands and ACK.

If I try to switch the temperatures to predefined values nothing happens. RS does not send any command.

If I write some value in the menu for the corresponding heating source (eg. 100°C in heatbed pop up or use the ring indicator to adjust temperature), the value in the menu changes to red for a short time, than back to black. In the console there is no command written.

I think RS does not send this changes.

Any ideas?

repman

Just to be sure:

After a klipper restart it looks like this:

If I set temperature by menu to predefined ABS:

Exec:10:26:21.518: @getip

Send:10:26:21.521: N19 M117 192.168.1.64:3344

Recv:10:26:21.522: ok (N19)

Send:10:26:21.573: N20 M140 S110

This works more than one times (switching on and off) if no print is started....

Repetier

Which interface are you using? Just tried touch and regular for extruder and bed and both did send the gcode expected.

In klipper if you have set a name some functions will use the official klipper command SET_HEATER_TEMPERATURE instead of M104/M140

repman

Repetier wrote
Which interface are you using? Just tried touch and regular for extruder and bed and both did send the gcode expected.

Do you have printed something and tried it afterwards again? At first try it works here too, but not after printing.
Same behavior on Touchscreen and Web Interface.
<blockquote class="Quote">In klipper if you have set a name some functions will use the official klipper command SET_HEATER_TEMPERATURE instead of M104/M140

Means, I should use SET_HEATER_TEMPERATURE instead of M104/M140??

I did not use SET_HEATER_TEMPERATURE in my klipper.cfg.

But in my Slicer-Start-GCode I have the following:

<blockquote class="Quote">; The next two lines to avoid, that PrusaSlicer adds automatic wait for temperature G-Codes
M104 [first_layer_temperature]
M140 [first_layer_bed_temperature]

; Now the klipper start codes
PRINT_START EXTRUDER_TEMP=[first_layer_temperature] BED_TEMP=[first_layer_bed_temperature]

and the PRINT_START Macro:

<blockquote class=" Quote">###### Print Start #######
[gcode_macro PRINT_START]
# Use PRINT_START for the slicer starting script - please customise for your slicer of choice
gcode:
CLEAR_PAUSE
{% set BED_TEMP = params.BED_TEMP|default(60)|float %}
{% set EXTRUDER_TEMP = params.EXTRUDER_TEMP|default(190)|float %}
# Button LEDs red
SET_LED LED=fysetc_mini12864 RED=1 GREEN=0 BLUE=0 INDEX=2 TRANSMIT=1 SYNC=0
SET_LED LED=fysetc_mini12864 RED=1 GREEN=0 BLUE=0 INDEX=3 TRANSMIT=1 SYNC=0
# Printer Caselight ON
LIGHTON
# Nevermore Filter Fan ON
{% if BED_TEMP > 90 %} ; STK
NEVERMOREON
{% endif %}
M117 Heating Bed ...
M190 S{BED_TEMP}
# Start Heating the Extruder and proceed without waiting
M104 S{EXTRUDER_TEMP}
# Home the printer and quad_gantry_level
M117 Homing ...
G32 ; home all axes

Repetier

It does not really matter if you use M104/M140 or SET_HEATER_TEMPERATURE when klipper works as supposed. SET_HEATER_TEMPERATURE is needed if you have multiple beds or chambers which is why it is included now and preferred if name is known.

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:

// Unknown command:"M104..."

You could try instead deactivate printer and activate in server. That flushes the list if it existed but does not restart klipper. If it persists it is more klipper if it is gone it might come from unknown command.

repman

<blockquote class="Quote">It does not really matter if you use M104/M140 or SET_HEATER_TEMPERATURE when klipper works as supposed.

Sorry for troubling you, but I think it is a bug in RS:Entering after a finished print in console:

SET_HEATER_TEMPERATURE HEATER=extruder TARGET=190

switches the extruder on, in the terminal I see a acknowledgement of the command, the menu item for extruder turns red:

Send:18:09:23.344: SET_HEATER_TEMPERATURE HEATER=extruder TARGET=190Recv:18:09:23.345: ok

If I do the same (again after a print) with

M104 S190

nothing happens (no heating, no acknowledgement, nothing turns red inspite "my personal HEAD").

In the klipper logs the first command appears, the seconds one not!

I assume you send M104 if I use the menu item in the GUI, right? This command is not send to klipper after a print, who knows why....

<blockquote class="Quote">But I wonder that no one else is having the problem as well.

I would agree that it is klipper related or related to my personal misconfiguration if klipper would show any reaction in log files. As klipper and the RS terminal do not show anything I suppose the commands M104 / M140 are not send anymore if a print has ended.

I can reproduce this behavior on two different machines with two different repetier-Server versions and different klipper versions.

I can not imagine that this only appears on my personal setups as they follow mostly the standard suggestions....

<blockquote class=" Quote">With that start gcod ein klipper server even would not need to set temperatures jsut calling PRINT_START

You are right with this, but I like the bed and the chamber to be heated equally before I start a print. And fortunately RS has menu items to switch bed and extruder on without starting a print immediately. Unfortunately these entries do not work anymore after a finished print!

Has someone else here a printer with klipper and can test it?

Regards

Repetier

Ok, today I printed 2 Objects in a row using Klipper printer and it worked. Afterwards I changed temperature with server temperature control which did send M104 and it worked. So on server side this looks good in my case.

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.

repman

<blockquote class="Quote">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.

In Console I switched Commands:ON, ACK: ON, Pause Log:OFF, Filter M105: ON

Than I entered GCode M104 S200

Result:

Nothing to see in console window, temperature stays.

Than I entered Macro GCode: SET_EXTRUDER_TEMPERATURE 200 (absichtlich falsch!)

Result:

Send:10:27:23.562: SET_EXTRUDER_TEMPERTURE 200

Recv:10:27:23.569: // Unknown command:"SET_EXTRUDER_TEMPERTURE200"

Recv:10:27:23.570: ok

Than I entered the right GCode: SET_HEATER_TEMPERATURE HEATER=extruder TARGET=200

Result:

Send:10:30:17.320: SET_HEATER_TEMPERATURE HEATER=extruder TARGET=200

Recv:10:30:17.321: ok

Temperature of extruder rises to 200 °C, Menu entry turns red!

Than entered menu entry to switch extruder temperature OFF

Result:

Nothing happens, no console acknoledgement.

As you tried it on your machine and it works it must be something in my settings to prevent sending the M104 / M140 commands. I will go through all my settings and changes I've made during setup and come up with mere questions than.

Repetier

Since it worked at the start I and now M104 does not appear any more I think klipper did send
// 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?

repman

Going more into deep could sometimes help :-)

Checking the klippy_log file I found in the nearly endless lines of mcu stats some Unknown command lines:

Unknown command:"T0"

Unknown command:"M104 240"
Unknown command:"M140 110"

These just at the beginning of my start script.

During the print roundabout every layer:

Unknown command:"EXCLUDE_OBJECT_START"

....

Unknown command:"EXCLUDE_OBJECT_END"

At the moment I'm looking from where the M104/M140 are coming. I suppose it is from the Slicer custome GCode, where I have included this:

<blockquote class="Quote">; The next two lines to avoid, that PrusaSlicer adds automatic wait for temperature G-Codes
M104 [first_layer_temperature]
M140 [first_layer_bed_temperature]

I removed these now even if I can not imagine why setting a temperature with commonly used GCode should not be executed.

AND YEAH!

Now as I'm writing this, I think I have found the error:

M140 [first_layer_bed_temperature] is faulty!!!

It must be:

M140 S[first_layer_bed_temperature]

Checking that now....

repman

Success!

Now the logfile entries

Unknown command:"M104 240"
Unknown command:"M140 110"

are gone and temperature changing after print does work again.

But why on earth RepetierServer does not send the M104 S200 command again if I send a wrong M140 or M104?

You can test that easy in console:

Send M104 200

and after that no M104 S200 will work again. Even the acknowledgement is not send anymore.

Same with M140!

Repetier

Everything is fine on server side. As I said when we get
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

<response type="unknownCommand" string="true">// Unknown command:\"(.\d+)</response>

from Klipper.xml in installFolder/firmwares

repman

yeah, I thought something like this, especially as this command changes temperatures, which could be a security risk if performed uncontrolled..

But you must concede: This was not that obvious that it catches immediatly in someones eye.

Thanks for your time and efforts repetier!