Very large retraction on print completion - V19.03.1

[RetromanIE]

What it does is at the very end of the print (once completed) it does a large retract. Its happened 3 or 4 times in the last day or two(since installing the firmware). The first retract was about 130-150mm, and the last one a few mins ago retracted all the way out of the bowden to the feeder. The head doesn't move away from the print while doing the retract and so far it hasn't actually had any impact on the printed objects.

I did the factory reset once I'd installed the firmware and my retraction settings are the standard 4.5mm @ 25mm/s and 20mm as the end retract(all firmware defaults).

I'm using the latest firmware (Tinker V19.03.1) on my Ultimaker 2+ Extended.
On my test ultimaker robot gcode it happens every print. But i can slice another model and it might or might not happen on that one. Weird!

[gr5]

This happens to me also if I go into the TUNE menu and up the flow to a value > 100%.

Did you do that?

And if I set the flow to < 100% then at the end of the print it does the opposite - it extrudes a huge blob onto the print.

[RetromanIE]

I've not done that in the menu. In S3D my PLA flow is 100% but my PETG is 108%. Its happening on both PLA and PETG prints. It's a weird one!

[RetromanIE]

Been testing this all evening. Adding retract gcode at the end of the files etc. still the same. It really is a pity as the features are so useful on this firmware, but i might have to go back to official if i can't sort this out.

[fredlime]

Hi
I also have this problem of retraction. Randomly more or less at the end of printing.
I had to install thinker V16.03.1 to no longer have this bug.
Fred

PS: Sorry if there are errors in translation, I am French

[UM2Moriis]

I've been installing Tinkergnome 17.10.1 on my Ultimaker 2+ for a long time. So far no problems. I print the same object for weeks. Now, at once, the printer executes the mentioned retraction of 20-30cm after each print.

Since I have not changed anything and always print the same parts, I assume that it is due to Simplify3d. I updated this to version 4.1.2 last week.

I can find there in the settings but so far nothing and just test a gcode file from the previous S3D version.

Maybe someone has an idea, if it may be due to S3D?

Edit: I have now tested with 3 different versions of Simplify3D. In the latest version, the filament is pulled out at the end 20cm, with the older Simplify3D versions only about 2cm.

That's not what it's all about, but why is my UM2 + doing that recently?

The only thing that comes to my mind is that I have always printed with Simplify3D and a few days ago 2 files via SD card with the latest version of Cura.

Can it be that the Crúra gcode has changed something in the printer settings?

[RetromanIE]

Here's the last bit of gcode for an Ultimaker Robot print that is having the retract issue. It was sliced in latest S3D.

G1 X108.640 Y107.232 E0.0401
G1 X108.771 Y107.219 E0.0417
G1 X108.902 Y107.232 E0.0434
G1 X109.027 Y107.270 E0.0450
G1 X109.145 Y107.332 E0.0467
G1 X109.249 Y107.416 E0.0484
G1 X109.337 Y107.523 E0.0501
G1 X109.399 Y107.641 E0.0518
G1 X109.438 Y107.768 E0.0535
G92 E0.0000
G1 X109.450 Y107.901 E-0.2776 F720
G1 X109.437 Y108.034 E-0.5557
G1 X109.398 Y108.161 E-0.8339
G1 X109.334 Y108.279 E-1.1125
G1 X109.292 Y108.330 E-1.2500
G1 E-6.5000 F1500
; layer end
G28 X0 ; home the X-axis
M104 S0 ; turn off heaters
M140 S0 ; turn off bed
M84 ; disable motors
; Build Summary
; Build time: 0 hours 35 minutes
; Filament length: 593.6 mm (0.59 m)
; Plastic volume: 3786.62 mm^3 (3.79 cc)
; Plastic weight: 4.73 g (0.01 lb)
; Material cost: 0.12

[RetromanIE]

And here's the actual full printable gcode file. This is sliced for an Ultimaker 2+ Extended in S3D.
UltimakerRobot.zip

[UM2Moriis]

@RetromanIE please add M83 in your Endscript in Simplify3d an test again:

G28 X0 ; home the X-axis
M104 S0 ; turn off heaters
M83
M140 S0 ; turn off bed
M84 ; disable motors

[plywak]

Hi guys,
I am observing simmilar issues with 19.03.1 on my UM2+
Previously I was using tinkergnome 18 without any troubles, and now, the retraction at the end of the print is one of the problems.

I have to admit, that problems with retraction at the end happened mostly when I changed the flow value in tune menu.
What is more, sometimes I see that while printing, in random points where retraction is needed to be done, it stops, retracts around 15cm, than extrudes 15cm and is printing again.
The biggest problem however is, that printer randomly throws up an ERROR message, and stops printing at all.

I have not tested it more deeply, but all that troubles I have observed this week, with one 20h print job. The file is 65MB, 20 simple models on buildplate. I was printing it 5times, and 2 of them were successful, the other 2 ended with error message, and one was ended by me, when I spotted that whole material was extruded from bowden tube.

I am using Cura 4.0.0, without any problems on any other Ultimaker. Any suggestions?

[gr5]

So when it retracts 15cm and then unretracts 15cm - this is a VERY common symptom of when the arduino gets errors reading the SD card (or errors through the USB cable if you print that way). You will also occasionally see it move in X or Y long distances outside the part and then move back and continue where it left off. This is because randomly a digit is changed. For example an X position of 11mm might change to 91mm due to 1 bad bit (plus coincidentally checksum changing to match).

The other common symptom is when it halts due to "printing out of area".

Try taking the SD Card circuit board out and cleaning it well. I was able to fix my issues by removing a tiny hair - like an eyelash - that was in among the contacts inside the printer. Also try moving the ribbon cables around a little bit. For me removing the hair changed the issue from 1 erratic move every 3 minutes to 1 erratic move every 4 hours. I also cleaned the contacts with isopropyl alcohol and a q-tip.

[plywak]

Thanks gr5!

However, the problem with retraction ang unretraction has never occured again.
All other problems remained the same. Anyway, I have cleaned all the eletronics. Than, I compiled firmware again in ArduinoIDE and after flashing all problems are gone. I will keep on testing

[plywak]

Hi again,
Unfornuatelly, the problem with retraction and unretraction occured couple of times more.
I have three UM2+s (two of them were orginally UM2s) and the problems are visible on each one of them.
Do you know how to fix those problems?

[gr5]

If you sit by the machine while it prints I'm pretty sure you will also notice it do the same thing in X and Y. But not Z. Best bet is to replace both PCBs if cleaning SD card slot did not help.

[plywak]

Nope, I did what you said. I put them on the desk near to mine, but it only retracts and unretracts the material, nothing else. During that operation print head remains still. I will try to record a movie while the problem occures.
I will try to flash one of them with stock 3.3.0 firmware. Let's see what happens

[gr5]

Try to measure (within 10 or 20%) how much it retracts. If it's a perfect even amount (10,20,30,40,50,60,70 ,80,90,100,200,300,400,500 etc) centimeters then it's most likely the problem I'm familiar with.

The head should move at the same time but it may be very tiny (less than 1mm) and slow.

Better to put this type of issue on the forum as I'm pretty sure it's a hardware issue and not a software issue. There may be other people there who have seen this. If you have two UM2 printers then I would swap the PCB with the SD card reader on it to see if the problem moves. Swap the ribbon cables also.

[gr5]

Actually I think it's more likely to be only one bad bit so probably it would move 10,20,40,80cm. Definitely not 15cm.

You said it happens when "retraction is supposed to happen". So does it: retract, move the head, unretract? does it always do that? If so then it's less random than I expected and my next question would be "did you change flow in TUNE menu?"

[plywak]

Thank you for the comment.
Yesterday, I have flashed one of the UM2 with stock 3.3.0 firmware. I did not touch the PCBs or SD cards. And so far I have not spotted problems yet. But I keep on testing. I am curious, because I started observing the problems right after I have installed tinkergnome 19.03.1. Previously I was using both, stock and 17.10 without any problems.

Regarding the head movements. I have not seen such a thing. If it was moveing, it had to be movement in micro scale.

[stefanrueger]

I also observe a large retraction after changing material in V19.03.1. Having inspected the source code it looks like the end_of_print_retraction variable is also used for the end of changing material procedure.

tinkergnome_init() from tinkergnome.cpp initialises this variable thus:

if (version > 4)
{
    // read end of print retraction length from eeprom
    end_of_print_retraction = GET_END_RETRACT();
}
else
{
    end_of_print_retraction = END_OF_PRINT_RETRACTION;
    SET_END_RETRACT(end_of_print_retraction);
}

As GET/SET_END_RETRACT() read/write to EEPROM, this suggests that the bug could be happening to those of us who change to V19.03.1 from "out of the blue" (say, from the original Ultimaker software or from a much older version of Marlin) where that EEPROM location is uninitialised.

I do not know whether EEPROM is kept or initialised after a firmware update. I suspect it's kept in my case. I do not know how to rectify this (Factory reset? Older version?), but changed to a V17.10.1 and all seems good.

It's unclear to me what the benefit of storing these values in EEPROM is unless there is a utility that allows me to manipulate EEPROM values. That of course could be some menu item in expert mode, in which case that might be another way of rectifying the observed problem, too.

Anyway, I hope my observations help.

Stefan

PS: Unrelated and not of great importance: I generally recommend the use of eeprom_update_...() functions instead of eeprom_write_...(). This avoids unnecessary eeprom writes.

[gr5]

If you are right, then doing a factory reset will fix this. It fixes those eeprom values.

Basically as long as you upgrade marlin from an older version to a newer version it knows how to translate the old eeprom values to the new. But if you do a downgrade to the firmware (or a cross-grade) it can get confused and some values can be somewhat random. factory reset sets all the eeprom values back to default. Things like steps/mm and current leveling position.