Strange delay at the beginning of the print  

Re: Strange delay at the beginning of the print

Christophe

I don't have that issue, but then again, I don't use Slic3r... I am running the latest drivers and firmware though.

My start GCode:

M201 X1000 Y1000 E600 ; set default acceleration
G21 ; [mm] mode
G90 ; absolute mode
M140 S<BED+5> ; Heat the bed + 5 degrees for Mk2
M109 S<TEMP> ; Warm it up, and wait till it's warm
G28 ; Home all (inc. calibration)

Followed by Extruder select:

T<EXT+0> ; Select new extruder
M109 S<TEMP> ; Warm it up, and wait till it's warm - redundant
G1 Z5 F1000 ; move the extruder to 5 mm
G1 X5 Y5 Z.0.23 F9000 ; move the extruder to print initial line
G1 Y80.0 E9.0 F1000 ; print a short line to prime extruder
G1 Z5 F1000 ; move the extruder to 5 mm
G92 E0.0 ; Zero extruder
M83 ; Relative

Peter

Re: Strange delay at the beginning of the print

I too have the same driver and firmware that you are running, however, I use simplify3d for the slicer. I do not have the delay. Could it be the slicer?

Re: Strange delay at the beginning of the print

1.7.3. + FW 3.0.3 + Slic3r - no delay here

Re: Strange delay at the beginning of the print

Hi Roman,

could you please show the first line of the gcode you are using ? it's very strange and it happens every print.

Re: Strange delay at the beginning of the print

Here it is. You can try whole g-code (attached below). Its Hodor doorstop (PLA 210/60) :-).

; generated by Slic3r 1.30.0.25-prusa3d-release_candidate_1_3-win64 on 2016-06-22 at 20:10:12

; 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

M107
M83 ; extruder relative mode
M104 S210 ; set extruder temp
M140 S60 ; set bed temp
M190 S60 ; wait for bed temp
M109 S210 ; wait for extruder temp
G28 W ; home all without mesh bed level
G80 ; mesh bed leveling
G1 Y-3.0 F1000.0 ; go outside pritn area
G1 X60.0 E9.0 F1000.0 ; intro line
G1 X100.0 E12.5 F1000.0 ; intro line
G21 ; set units to millimeters
G90 ; use absolute coordinates
M83 ; use relative distances for extrusion
G1 E-0.80000 F2100.00000
G1 Z0.150 F7200.000
G1 X54.763 Y87.093 F7200.000
G1 E0.80000 F2100.00000
.....

Re: Strange delay at the beginning of the print

Thanks Roman.

Do you use OctoPrint ?

The difference I could see here is that OctoPrint is sending M105 requests each seconds to make a temperature graph...

Re: Strange delay at the beginning of the print

I have Raspberry Pi with Octoprint, but I usually use SD card. I have 4 printers and only 2x Raspberry Pi :-).

I will try Octoprint. Do you copy g-code file through web interface or directly from Slic3r?

Re: Strange delay at the beginning of the print

I push it directly from Slic3r, but I'm pretty sure that it does not modify the gcode content.

I will do some test printing from SD as well. It's not preventing me to print, but I do not like when I do not understand 🙂

Re: Strange delay at the beginning of the print

I just catched this on Facebook 🙂 (MK2 user)
Looks like Octoprint is waiting for some response.

Any reason the new start/stop gcodes would have my printer stop for nearly a minute after calibration when printing from octoprint? It doesn't do it with the calibration gcode, just my new loads from slic3r.

Re: Strange delay at the beginning of the print

I also have this delay issue. FW 3.03, Drivers 1.7.3. Using Slic3r to export gcode and sending it to the printer via OctoPi 1.2.13. I didn't have this issue with 3.02/1.7.2. Unfortunately I upgraded both together so I don't know specifically which update started the delay. Looking at the terminal in OctoPi it's definitely waiting for something and then has a communication timeout.

It happens after the mesh bed leveling but before the intro line, somewhere between these lines in the Start G-Code?

G80 ; mesh bed leveling
G1 Y-3.0 F1000.0 ; go outside pritn area [SIC]
G1 X60.0 E9.0 F1000.0 ; intro line

Re: Strange delay at the beginning of the print

Ahhh

I think there is a huge clue there.

I remember seeing somewhere that OctoPrint could be set to wait longer for certain GCode commands. Or am I making this up? I can't seem to find out where that setting is..

Peter

Re: Strange delay at the beginning of the print

Just found it...

Octoprint/Settings/Serial connection/Advanced Options/Long Running Commands

Peter

Re: Strange delay at the beginning of the print

Yes, it seems like an issue after the G80 code. Will check the terminal dialog during this phase.

The Terminal show this during the initial phase during the delay:

Send: N6 G28 W*98
Recv: ok
Send: N7 G80*22
Recv: 80:ok
Recv: echo:endstops hit: Z:0.22
Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Send: N8 M105*47
Recv: ok T:240.0 /240.0 B:109.7 /110.0 T0:240.0 /240.0 @:66 B@:125
Send: N9 M105*46
Recv: ok T:240.0 /240.0 B:109.7 /110.0 T0:240.0 /240.0 @:66 B@:125
Send: N10 G1 Y-3.0 F1000.0*25
Recv: ok

Not sure this is a timeout, I assume the code "80:ok" is not well interpreted by OctoPrint.

Re: Strange delay at the beginning of the print

Ok, I think I found it, the G80 code does not answer by ok.

Using the "Fake acknowledgment" button on Terminal in OctoPrint bypass the wait for the ack and the print continue as expected.

I had a look at the firmware sources, but I'm not very confortable to find if an ack is suposed to happen. Josef ? Anyone from PR ?

Re: Strange delay at the beginning of the print

Christophe

Remove the G80 code and amend the G28 line to a simple G28 in the start GCode area of the slicer.

Problem gone...

Peter