Hi, I’m using the beta version 3.52 and I’m trying to print a file generated with PrusaSlicer.
Despite extruder temperature and homing set in the GCode file, GCodePrintr only waits for the bed temperature and then immediately tries to start printing with a cold hotend.
The beginning of the GCode file:
; generated by PrusaSlicer 2.3.3+linux-x64 on 2022-08-15 at 21:44:29 UTC
;
; external perimeters extrusion width = 0.45mm
; perimeters extrusion width = 0.45mm
; infill extrusion width = 0.45mm
; solid infill extrusion width = 0.45mm
; top infill extrusion width = 0.40mm
; support material extrusion width = 0.35mm
; first layer extrusion width = 0.42mm
M107
M190 S65 ; set bed temperature and wait for it to be reached
M104 S235 ; set temperature
;TYPE:Custom
G28 ; home all axes
G1 Z5 F5000 ; lift nozzle
M109 S235 ; set temperature and wait for it to be reached
G21 ; set units to millimeters
G90 ; use absolute coordinates
M82 ; use absolute distances for extrusion
G92 E0
; Filament gcode
;LAYER_CHANGE
;Z:0.27
;HEIGHT:0.27
G1 Z0.270 F6000.000
G1 E-1.00000 F2220.000
G92 E0
G1 X60.675 Y60.031 F6000.000
G1 E1.00000 F2220.000
;TYPE:Skirt
;WIDTH:0.42
Additionally, how do I avoid the sample file being loaded at startup?
It’s larger than my print size, so I always get an annoying warning at start.
This does seem to be the correct command. Therefore, it would seem to be a problem with how it is being interpreted. That happens at the controller, so it is likely firmware setting. This may be a simple setting, or possibly a firmware bug.
Maybe you should go into the firmware console and type M503 to list all current settings.
I’ve investigated things further and this might be the fault of my printer’s firmware (A Qidi Tech X-One) behaving in non-standard ways.
People using Octoprint ran into issues with Qidi printers as well and this plugin was created: Fix CBD Firmware.
According to that Qidi and some other printers have these following quirks:
It doesn’t support an N parameter on the line number command M110 that OctoPrint utilizes during handshake for maximum compatibility and will react with a non descriptive error to its presence, stalling communication.
It doesn’t support X, Y and probably also not Z parameters on the homing command G28 and will react with non descriptive errors to their presence, stalling communication.
It doesn’t support X, Y, Z or E parameters on the stepper commands M18 and M84 and will react with non descriptive errors to their presence, stalling communication.
It uses wait (which should signal that the printer is waiting for new commands to be sent to it) to signal that it’s busy and can’t currently receive new commands (a situation for which there is actually an established busy response).
I can see Wait lines in GocdePrintr’s log. That those get interpreted as “send new commands” instead of “I’m busy” would explain why it doesn’t wait for the temperature to reach its target and instead starts printing.
This sounds like a firmware bug.
GCodePrintr will send each line to the printer and wait for an “OK” response before it continues to send the next line.
During heat-up, the firmware should report the temperature (e.g. T:180.3 /210.0 B:60.0 /60.0) until the temperature is reached, only then it should send “OK”.
If the printer is busy processing other commands it would send echo:busy to indicate that it is not ready to receive new commands (GCodePrintr will wait for OK anyway and does not need the echo:busy response).
The “wait” response means that the printer is waiting for new commands and this leads GCodePrintr to continue even if no “ok” has been received. The printer firmware should send “wait” only if its ready with processing the previous cmd.
/** From Repetier FW:#define WAITING_IDENTIFIER wait : Communication errors can swollow part of the ok, which tells the host software to send the next command. Not receiving it will cause your printer to stop. Sending this string every|second, if our queue is empty should prevent this. Comment it, if you don’t wan’t this feature. */|