Build plate crash at end of print.

[gr5 2,167]

Oh - I see you sent me a direct message.  You could post that here as people will still need to ask permission to see it.

[Fernando_alp 0]

We seem to have run into this exact issue today, not sure if it will relate but here's our story:

• Ultimaker S5 Pro bundle, Firmware 7.1.0
• A job had been submitted through the local network and started (Tough PLA on core 1 and PVA on core 2)
• I submitted another job from the digital library (ABS on core 1 and PVA on core 2)
• When the first job finished, printer did what has been described here, extruder moved to the left, did a cold pull routine for the Tough PLA on core 1, then moved to the right with the plate raised and oozing or extruding PVA from core 2; extruder hit the print and pushed the glass plate out of position; then it completed the cold pull on core 2 and buildplate lowered.
• Teammate thought the second job had started, but the printer had actually just done the filament "parking" routine, for some reason the plate raised between cold-pulls causing the crash instead of lowering buildplate first.
• Digital factory showed print done and waiting for cleanup, after removing print and adjusting plate, teammate touched on the "Print removed" button on the touchscreen and second print started normally.

 

 

[Ultiflow 0]

Thank you very much for your investigation.

 

I am now quite confident that there is an issue when printing only with right core (except the skirt at the beginning)

 

At the end, it hits the front, but mainly it travels from right to left with the plate way to high.

 

My guess is that the new update that enables faster ends has an issue. The cores are travalling in the middle of the print if the build is at top. 

 

When there is purge on left core, the build lower just before going to purge right core. But this is the move when you really printed with both cores.

 

I force all my current prints to use both to prevent this issue to happen and further potentially damage the printer.

 

I came in the forum looking for a displaced build plate exactly like the first picture. I was surprised it was on the other side. If they fixed a bug on left to right, maybe there is still one from right to left.

 

II made more than 150 prints before this firmware. It's second time I report an issue using two cores (on Cura last time) and there was a bug last time and it has been fixed.

 

I did gave you the rights to the video, sorry for the delay.

 

And maybe I am doing wrong or that my machine is broken 😕

 

Cheers.

 

 

[Ultiflow 0]

1 hour ago, Fernando_alp said:

We seem to have run into this exact issue today, not sure if it will relate but here's our story:

• Ultimaker S5 Pro bundle, Firmware 7.1.0
• A job had been submitted through the local network and started (Tough PLA on core 1 and PVA on core 2)
• I submitted another job from the digital library (ABS on core 1 and PVA on core 2)
• When the first job finished, printer did what has been described here, extruder moved to the left, did a cold pull routine for the Tough PLA on core 1, then moved to the right with the plate raised and oozing or extruding PVA from core 2; extruder hit the print and pushed the glass plate out of position; then it completed the cold pull on core 2 and buildplate lowered.
• Teammate thought the second job had started, but the printer had actually just done the filament "parking" routine, for some reason the plate raised between cold-pulls causing the crash instead of lowering buildplate first.
• Digital factory showed print done and waiting for cleanup, after removing print and adjusting plate, teammate touched on the "Print removed" button on the touchscreen and second print started normally.

 

 

 

Okay, so in your case it's left to right and purge happened on core 1.

 

Did the height of core 1 (though PLA parts) were significantly higher than the the height of PLA ?

 

My guess is that the build plate adapts to the height of it's own material for the purge and not the max of two.

 

[gr5 2,167]

@CarloK - new firmware bug on latest firmware (see ultiflow posts above).  If you only use the right core, when the print is complete, it raises the right core and then proceeds to move to the front right corner hitting the part(s) on the print bed because the left core is now 0.7mm lower than the top of the print.  This can pull the glass bed off the bed TO THE LEFT.

 

@ultiflow - firmware bugs are harder to report.  In case Carlo doesn't report this somehow, please create a ticket.  So in the upper right corner of this page there are 9 dots.  Click that, then "support".  Then on the new page, just to the left of the 9 dots there is a button: "submit a request".  Follow the instructions.  Meanwhile I suggest you downgrade your firmware - or don't do "right core only prints" until this issue is fixed.

 

I saw the video, thanks.  If CarloK asks please give him access to the video also.  Why are you trying to keep the video private?  I didn't see any big secrets or anything.

 

 

 

 

 

[Ultiflow 0]

Just made an impression with using both cores, but got the issue.

 

It scratches this piece.

 

[Ultiflow 0]

@gr5 I made a report with both video and picture.

 

Thanks again !

[gr5 2,167]

And it *only* does this at the end?

 

So I know a guy who has several S5 pro bundles and he has been on the latest firmware since it came out and his printers work nonstop almost 24/7 and he said he just did lots of prints yesterday with only core 2 (right core) and there were no problems.  Of course he didn't watch what happened in the last few seconds.  Maybe he just didn't notice?

 

It's really hard to tell what's going on in your video.

 

Having the cores touch the top of your print like that is pretty common - overhangs can lift up on their leading edge.  Think the "bow of a boat" (benchy) - in that case, when printing Benchy, the tip of the bow sticks up above the print level and the nozzle will hit that part of your print repeatedly.  This happens on many many of my prints and is pretty normal.  It looks awful.  It sounds awful.  But 99% of the time the print comes out fine.  You can reduce it with more cooling which is why you always want 100% fan with PLA (but not with every material).

 

So I really can't tell if what you show in the video is normal or not.

 

Now in your photo you show the silicone rubber cover - your printer should have come with a spare.  You can get these cheap - I forget the price but around 5 covers for 5 or 10 dollars/euros.  So 1 or 2 euros/dollars each.

 

So in the video is it only the silicone cover that hits the print?

[Ultiflow 0]

I got three times the build plate totally displaced like in the picture. And always at the end of the print like others.

 

Was it the same as the core touching the piece, I can't tell. I made a reset on all settings and firmware too see.

 

Maybe making a skirt with both cores make this by setting up a bad altitude variable in the core. The purge is being done quite high in my oppinion.

 

From what I have seen, sometimes the build plate lower from something like 3 centimeters before going to the other side at the end, sometimes not.

 

Now that I made a full reboot, I will see if it happens again and inform here. Until then, thank you very much @gr5 for your orientation!

 

 

 

[gr5 2,167]

Purge is indeed done quite high.  That sounds normal.  Sometimes it doesn't stick to the glass and is carried over to the start of the skirt/brim.

[CarloK 203]

@gr5 I'm in the process of leaving Ultimaker. I forwarded this info to colleagues of the appropriate firmware team.

[CarloK 203]

We discovered one bug that could explain this behavior: at the end of a print we do a deprime. The calculation for a safe build plate height will be wrong when a paused print was aborted, this can happen for example by a user pause action, but also by an filament warning.

Key point is that when the printer in a paused-state is aborted, then from that moment on the printer will use a wrong Z-height in the deprime procedure in all following print jobs.
Introduced in v7.0.0

Work around:
1) Reboot the printer after an aborted pause action.
or
2) Pause a print and then resume. The resume action will reset the data stored at pause start.

[Ultiflow 0]

Thanks for the update

 

[Ultiflow 0]

Got it again. The print was finished but tye build plate pushed by the printing head.

 

[SimonGeorge 0]

 try a Digital Factory Reset, I had also confront by the same issues but now its working fine. 😶

[nmoreno 0]

Hi,

When I was finnishing a printing model with PLA, the build plate adhesion has been moved strongly out of the 3D printer.

I would like to know why this happened. I was using 2 colours but my model was printed only with 1 one of them and by default the support were generated with the other colour (Extruder). Is this happening due to the use of doble colour (Extrusion)?

 

In addition, I would like to know if this is related with the material station or with a bad setting of the 3D printer movement (Travel option, "Retraction").

 

[oneilloverland 0]

I’m experiencing this issue as well, and I just posted on another thread:

I stood and watched 2 prints finish and go through the “de-prime” phase. It was the de-prime phase that caused the collision. I was using the left print core only (Print Core 1) with Tough PLA. The print had good adhesion throughout the print, but it was (thankfully) dislodged when hit with the printer head.

The past two prints are the first times I’ve run into this. Here’s how they are different:
1. They have a taller profile than most of my prints (~40mm)
2. I was trying out the Visual - Fine Profile in Cura to generate the g-code.
 

The machine is on the latest firmware, and we have printed with Ultimaker PETG and Ultimaker Tough PLA. We also have the Material Station.

 

I’m guessing that the print bed has to move all the way up to the top to keep the purged filament from falling on the print bed, but this does not account for prints being on the bed during the post-print de-priming process. Even if the bed is lowered completely while the print head crosses the area of the print bed, raising the bed to full z height could cause prints to collide with the XY axes if they are over the print bed when the bed is raised.

I’m not sure if this would be counterproductive to the de-priming process, but is it possible to prompt for the removal of the print before de-priming the print core? Or to ensure that the print height does not exceed the clearance of the XY rails before raising the bed to maximum height?

Or maybe it would be better to create a channel for the priming/de-priming filament on the sides of the print bed to keep the filament off the print bed without having to raise the bed to maximum z height?

Edited December 9, 2022 by oneilloverland

[oneilloverland 0]

After doing more research and digging through posts, it seems like there is a proprietary priming/de-priming process that kicks off before and after each print. This seems to be controlled by the Firmware and not G-Code. Is there a py file responsible for this logic that can I can take a look at?

If this were in GCode, I'd say it's a simple issue of changing the GCode to move laterally **before** moving the Z axis. At the end of the print, the Z axis appears to be clear of the print, but when moving to the de-prime location, it's moving to the X Y Z locations at once, which risks creating a diagonal line through the print if the printer head is above the print. Then once the printer head has to move to the other side of the print bed, it would need to lower the print bed first, then cross, then raise the print bed.

Since this isn't happening in the GCode, it seems like this would need to be changed in the firmware.

Edited December 9, 2022 by oneilloverland