Communication error at the start of a new 3D-print

[GeertVc]

I've activated the serial logging right now and once I'm in that situation again, I'll give you all the info you need (full logs of octoprint as well as serial) + also the G-code I've used to start the printing.

Thanks for your support too!

Best,
--Geert

[GeertVc]

Hi,

I wanted to add lots of information to this reply, including all the necessary info asked. However, I got this silly message, forcing me to give my information in bits and pieces.

Sorry for that...

Pls. find all the requested info in the next 6-7 replies (this is silly...).

Best,
--Geert

[GeertVc]

Hi,

I've had the time again to start printing 3D stuff and I could also reproduce the problem.

Below are screenshots of the printing process:

1. Before the error happened: both bed and nozzle are at required temperature:

Then the nozzle is moved in Z- position to its starting point. That takes some 15-20 seconds (maybe a bit more, don't know exactly...).

See next reply for the sequel.

Best,
--Geert

[GeertVc]

Hi,

2. At the moment of the error. Connection is lost and both bed as well as nozzle temperature are dropping immediately:

See next reply for the sequel.

Best,
--Geert

[GeertVc]

Hi,

3. In the mean time, the Z-position is more or less OK and I reconnected to the printer + activated the print action again. You can see the wanted bed temperature is set again:

See next reply for the sequel,

Best,
--Geert

[GeertVc]

Hi,

4. After the bed has its temperature reached, the nozzle temperature is set too:

See next reply for the sequel.

Best,
--Geert

[GeertVc]

Hi,

I've also attached the serial log file:

serial.log (238.1 KB)

Pls. have a look from line 44 onwards (20201121): this is the start of the serial communication for this print batch.
At line 368, the bed has reached its required temperature (55°C).
At line 372, the nozzle get its wanted temperature (200°C)
At line 482, the nozzle has reached its temperature (or almost...)
At line 497, the error occurs.

Pls. see next reply for the sequel.

Best,
--Geert

[GeertVc]

Hi,

I've also attached the octoprint log file:

octoprint.log (8.7 KB)

See the next reply for the sequel.

Best,
--Geert

[GeertVc]

Hi,

And finally, if it would be of interest, I've also attached the G-code of the object I wanted to print:

B3DPT_Connector_TOLERANT.gcode (55.1 KB)

I hope all is present to give me some clues as to why this is error is happening.

Best,
--Geert

[b-morgan]

Before I look at the files I want to say thanks, @GeertVc, for your efforts in delivering the information. If it's any consolation, your post count may now be high enough that you have graduated from new user status

[b-morgan]

First, in the serial.log the following line appears:

2020-11-21 13:11:15,300 - Send: N10 G28 Z0*104
2020-11-21 13:11:55,363 - No response from printer after 6 consecutive communication timeouts, considering it dead. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.

I think we have established that this happens regularly on specific commands so let's do what it says.

1. Click on the wrench at the top of the screen
2. Click on Serial Connection
3. Click on Intervals and timeouts (Your printer's firmware doesn't appear to support the busy protocol)
4. Change the Communication timeout busy protocol not detected to 60 or
5. Click on Advanced options (the image doesn't show these next steps)
6. Change Max. consecutive timeouts while printing and Max. consecutive timeouts during long running commands to 10 (and leave the timeout busy protocol not detected at 30).
7. Click Save at the bottom

Let's check one more thing.

1. Click on Firmware & protocol
2. Click on Advanced options at the bottom under Protocol fine tuning
3. In the Long running commands text block, verify that G28 is in the list. If not, add it following the instructions below the text block.
4. Click Save at the bottom (if you changed anything)
5. If your printer is connected to OctoPrint, disconnect and reconnect so these changes take effect.

Before we try the experiment again, Your start gcode has the following commands in it:

G1 Z15.0  ;move the platform down 15mm
G1 F{travel_speed}

Remove the F{travel_speed} part (remove the second command completely). The slicer is supposed to replace this with the value of travel_speed. You appear to be using Cura 3.4.1 so the syntax is correct but travel_speed isn't defined. Alternatively, you could substitute 3600 for {travel_speed} as that speed appears within the gcode generated for the actual part.

Either edit the gcode you have already or slice your part again. Send it to OctoPrint and print it. Hopefully, we have fixed the problem but if not, you can examine the serial.log and verify that either the timestamps or the ...after 6... reflects the changes you made. Change the Max. consecutive to 20 if 10 didn't work and try again.

[b-morgan]

We should work on your end gcode as well but let`s solve one problem at a time

[GeertVc]

Hi Brad,

First off, thanks for your extensive explanation and the time you've put in preparing the answer for me. Much appreciated!!!

But no, I'm still not graduated to a higher level. I can still post only one embedded media at a time in a post. So, here we go again with my bits and pieces. Sorry again for that...

Best,
--Geert

[GeertVc]

Hi,

Next, if I understand you correctly, for the first section I should execute steps 3 and 4 OR steps 5 and 6. But not both (otherwise, two changes in one go...). Am I correct with my assumption?
If so, then I've executed steps 3 and 4 first. I already found the location for steps 5 and 6 too, but didn't change anything in that section so far. As you mentioned, one step at a time...

About the Long running commands section, I can confirm G28 is already part of the commands list. See image below:

See next reply for the sequel.

Best,
--Geert

[Charlie_Powell]

Get to trust level 1 by…

• Entering at least 5 topics
• Reading at least 30 posts
• Spend a total of 10 minutes reading posts

Edit Looks to me like you are pretty close, maybe there is a slightly different threshold from the default

[GeertVc]

Hi,

Regarding the start code, pls. see the image below. It shows both start and end code generated by Cura as of this writing:

I've also pasted the start and end code below:

• Start code

;Sliced at: {day} {date} {time}
;Basic settings: Layer height: {layer_height} Walls: {wall_thickness} Fill: {fill_density}
;Print time: {print_time}
;Filament used: {filament_amount}m {filament_weight}g
;Filament cost: {filament_cost}
;M190 S{print_bed_temperature} ;Uncomment to add your own bed temperature line
;M109 S{print_temperature} ;Uncomment to add your own temperature line
G21        ;metric values
G90        ;absolute positioning
M82        ;set extruder to absolute mode
M107       ;start with the fan off
G28 X0 Y0  ;move X/Y to min endstops
G28 Z0     ;move Z to min endstops
G1 Z15.0 F{travel_speed} ;move the platform down 15mm
G92 E0                  ;zero the extruded length
G1 F140 E30              ;extrude 3mm of feed stock
G1 X20 Y0 F140 E30
G92 E0                  ;zero the extruded length again
G1 F{travel_speed}
;Put printing message on LCD screen
M117 Printing...

• End code:

M104 S0                     ;extruder heater off
M140 S0                     ;heated bed heater off (if you have it)
G91                                    ;relative positioning
G1 E-1 F300                            ;retract the filament a bit before lifting the nozzle, to release some of the pressure
G1 Z+0.5 E-5 X-20 Y-20 F{travel_speed} ;move Z up a bit and retract filament even more
;Added by GVC to prevent steppermotor X-direction to hit the right side of the printer
;G28 X0 Y0
G90
G1 Z160                                 ;move X/Y to min endstops, so the head is out of the way
;Added by GVC
;G1 Z15
;End added by GVC
M84                         ;steppers off
G90                         ;absolute positioning
;{profile_string}

I can see the command you mentioned in the start code, but then in one line, not two lines.

G1 Z15.0 F{travel_speed} ;move the platform down 15mm

Is this similar to what you mentioned (except that it's written in one line iso 2...)?

Next to this, I already had to change the end code too (see the comments with the trigram "GVC") because the motor was hitting the right side each and every time a 3D printing was finished. With that change, it doesn't happen anymore...

This was the code causing the issue (but now commented out):

;G28 X0 Y0

PS: luckily, only 2 separate replies this time...

Best,
--Geert

[GeertVc]

Hi Charlie,

This is my "earning state" so far:

I'm even already the proud owner of "Earned 'First Emoji'"!!!

Let's see when I will be able to post more than one embedded media at a time...

Best,
--Geert

[b-morgan]

{travel_speed} appears twice in your start gcode, line 14 and again on line 19.

Here's the beginning of my Ultimaker Cura 4.8.0 start code for my LulzBot TAZ 6:

;This G-Code has been generated for the LulzBot TAZ 6 with standard extruder
M107 ; Sliced at: {day} {date} {time}
M107 ; Nozzle Size: {machine_nozzle_size}
M107 ; Layer height: {layer_height}
M107 ; Walls: {wall_thickness}
M107 ; Fill: {infill_sparse_density}
M107 ; Estimated Print time: {print_time}
M107 ; Filament used: {filament_amount}m {filament_weight}g
M107 ; Travel speed: {travel_speed}

and here is the gcode output from slicing a 5x5x5 cube:

;FLAVOR:Marlin
;TIME:108
;Filament used: 0.0207119m
;Layer height: 0.2
;MINX:132.3
;MINY:132.3
;MINZ:0.3
;MAXX:147.7
;MAXY:147.7
;MAXZ:4.9
;Generated with Cura_SteamEngine 4.8.0
M82 ;absolute extrusion mode
;This G-Code has been generated for the LulzBot TAZ 6 with standard extruder
M107 ; Sliced at: Sat 21-11-2020 09:03:06
M107 ; Nozzle Size: 0.4
M107 ; Layer height: 0.2
M107 ; Walls: 0.8
M107 ; Fill: 20
M107 ; Estimated Print time: 00:01:49
M107 ; Filament used: [0.02]m [0.1638406951904297]g
M107 ; Travel speed: 120

As you can see, {travel_speed} appears to be defined in 4.8.0. It comes from:

Perhaps it isn't defined in your version of Cura. Are you using Ultimaker Cura or someone's packaged (old version)? I see: ;Generated with Cura_SteamEngine 3.4.1 in your gcode output.

BTW, I'm using M107 so I can output some additional text as comments (after the ;). I probably don't need to do that anymore, but at the time I put it in, I had a reason. I just can't remember that reason anymore (of all the things I've lost, I miss my mind the most).

[GeertVc]

@b-morgan

Are you using Ultimaker Cura or someone's packaged (old version)?

Yes, I'm using version Ultimaker Cura 3.4.1:

Here's some more details:

I realise now this is an old version but that is the version that was packed with my printer (which I bought 1 1/2 months ago).
I don't know why they added such an old version to the package, but I didn't want to change since I thought that version of Cura would have been fine-tuned for that specific printer.

As I said before, I just recently stepped into the 3D printer world, still a long way to go...

PS: I'll try the new settings ASAP (printing is now ongoing and will still take several hours before finish) so might be for somewhere tomorrow....

Best,
--Geert

[b-morgan]

Many smaller 3D printer manufacturers don't have large enough operations to do their own slicing software or to even keep applying their changes to someone else's slicing software so once they have something working, they leave it alone.

Ultimaker Cura 4.8.0 appears to have support for your (comparable) printer so at some point in the future, you might want to give it a try. You may have to manually move some of the specific printer settings across (you can start with the comparable or create a custom) but after doing that, you get the benefit of all of the improvements Ultimaker has added to Cura.