Re: Y-Axis fake(?) Crash detections - let's debug
I'll definitely try that. Have you witnessed any crashes? (seen them while they happened?)
Re: Y-Axis fake(?) Crash detections - let's debug
I'll definitely try that. Have you witnessed any crashes? (seen them while they happened?)
Yes, I had one part where I experienced nearly 20 crashes. I was watching closely when several of them occurred, seemingly without reason. I did not experience a crash printing the part a second time after making the current / sensitivity setting changes. However, this is hardly conclusive because it was an individual test and I've been running with crash detection completely off during my current 24h print -- I didn't want to risk any blemishes in the finish caused after rehoming.
Here is the part. It's interesting that a lot of the crashes occurred printing the outermost perimeter (about 8 out of the 20 crashes I experienced) -- the PETG takes a while to re-prime the extruder so I get an area of under extrusion when it restarts, hence the lines.
I've printed 8 more with crash detection disabled without any problems.
Re: Y-Axis fake(?) Crash detections - let's debug
Here is the part. It's interesting that a lot of the crashes occurred printing the outermost perimeter (about 8 out of the 20 crashes I experienced) -- the PETG takes a while to re-prime the extruder so I get an area of under extrusion when it restarts, hence the lines.
image1.png
I've printed 8 more with crash detection disabled without any problems.
Try turning off the filament sensor. There seems to be issues with some PETG filaments and the sensor. If the sensor fails to see movement, the head will stop momentarily and do a retract and retry, if all is good it continues on, but the result is a small nodule left in the print [which I see in your picture]. Turning the sensor off [leave crash detection on] may eliminate the nodules, and thus the small crashes that are occurring.
Re: Y-Axis fake(?) Crash detections - let's debug
I'll try settings with my next print.
Let's sum up what I changed now. As mentioned earlier I changed to Misumi bearings. Changed some of the 3d printed parts and now have a 16T Idler on my Y-Axis.
200% Benchy, One Y-Crash, unfortunately it's clearly visible as shifted layers.
Benchy Today, 9 Crashes
older Benchey, don't know how many crashed but apparently visible.
Yust for the lulz, this is a Benchy from my $400 Flashforge Finder with Petg. 🙂 Isn't that looking nice?
Re: Y-Axis fake(?) Crash detections - let's debug
I'm currently testing with:
M911 Y25
M912 Y25
M916 Y5
I would be really interested in the results from others.
Me too. I've put the numbers into my Start Script in S3D. I printed one benchy without a crash but I still run into them from time to time. Just had one when he did the brim outline 🙄 Can it be more obvious that this is not while crashing into the model?
Re: Y-Axis fake(?) Crash detections - let's debug
Have you looked to see if your Y bearing u-bolts hit the frame? Mine did ever so slightly on one side only when a little weight was placed on the build surface. I took a grinder to the frame. Works great now 🙂
Re: Y-Axis fake(?) Crash detections - let's debug
Have you looked to see if your Y bearing u-bolts hit the frame? Mine did ever so slightly on one side only when a little weight was placed on the build surface. I took a grinder to the frame. Works great now 🙂
I already checked that and I'd suggest everyone else checking that too. However I would have to press pretty hard until the U-Bolt catches the frame. Also I Printed the benchys at different locations on my bed, to make sure it's not a bad u bolt. 🙂
Nevertheless I tried to put the Smooth-Rod-Holders more up when screwing them to the frame, just so I have a little bit mor space.
Re: Y-Axis fake(?) Crash detections - let's debug
Here is the part. It's interesting that a lot of the crashes occurred printing the outermost perimeter (about 8 out of the 20 crashes I experienced) -- the PETG takes a while to re-prime the extruder so I get an area of under extrusion when it restarts, hence the lines.
image1.png
I've printed 8 more with crash detection disabled without any problems.
Try turning off the filament sensor. There seems to be issues with some PETG filaments and the sensor. If the sensor fails to see movement, the head will stop momentarily and do a retract and retry, if all is good it continues on, but the result is a small nodule left in the print [which I see in your picture]. Turning the sensor off [leave crash detection on] may eliminate the nodules, and thus the small crashes that are occurring.
This worked for me even with the default silver PLA. Turned off the filament sensor and went from 20 crashes per benchy to none.
Re: Y-Axis fake(?) Crash detections - let's debug
Here is the part. It's interesting that a lot of the crashes occurred printing the outermost perimeter (about 8 out of the 20 crashes I experienced) -- the PETG takes a while to re-prime the extruder so I get an area of under extrusion when it restarts, hence the lines.
image1.png
I've printed 8 more with crash detection disabled without any problems.
Try turning off the filament sensor. There seems to be issues with some PETG filaments and the sensor. If the sensor fails to see movement, the head will stop momentarily and do a retract and retry, if all is good it continues on, but the result is a small nodule left in the print [which I see in your picture]. Turning the sensor off [leave crash detection on] may eliminate the nodules, and thus the small crashes that are occurring.
This worked for me even with the default silver PLA. Turned off the filament sensor and went from 20 crashes per benchy to none.
But why would the filament sensor trigger a Y-Crash? ❓ Odd. But in the end it can always come down to a software thing. So it may help. Question now is, is it 'better' to turn off the filament sensor and risk to run out of FIlament, or just turn of the Crash detection and risk shifted layers.
My "problem" at the moment is, that the Crashes gone to a low level where they sometimes don't happen at all and sometimes there are 1-3 during a pint. Make it way harder to try different stuff and get a conclusive result.
Re: Y-Axis fake(?) Crash detections - let's debug
Can you guys do me another Favor? Can you try to move your Y-Axis by hand to see if it rund smooth all way to the front and back? Or it the resistance changes? My Y-Axis has a bit of jerk along the way. It's not much, I only feel it when pushing / pulling the bed really soft (just enough to make it move). But it's there.
Re: Y-Axis fake(?) Crash detections - let's debug
I would like to add a little bit of information that I have discovered after troubleshooting the relentless collision detection and layer shift issues. I know that this discussion is primarily discussing Y-Axis but I would like to add something I discovered with the X-Axis collision detect. When the last firmware release we had a Y and X re-homing check introduced in selfcheck to make sure that the home point is found and hopefully remains consistent to eliminate layer shift through a crash detect. What I have found is that the home check is done at the bottom of the Z Axis and X is checked to the left towards 0. This is the side where the Einsy case is located. The check is done right against the case and if you have any inconsistencies like cable ties turned the wrong way obviously your home point will be inaccurate and different as your Z axis climbs above the Einsy case. What I have done to help this is to make sure that the selftest is run with the ability to move as far as possible to the left against the Einsy case. This works if the print is not too high but I have found that no matter what I do there seems to be a different home point after the print climbs above the case and then has a collision detect which seems to happen no matter what I do even though you look at the print and think a collision should have never happened. if the collision happens above the Einsy case then a layer shift happens almost consistently and will not happen below it even though a collision detect is experienced and handled. I hope prusa will read this and find that there may be a flaw in how this is done and also realize this might be why there are so many complaints about a variable experience with layer shits and collision detects. I would be interested if anyone else has found the same thing.
Re: Y-Axis fake(?) Crash detections - let's debug
Some conclusions and theories as I think I'm in kind of a dead end now. As mentioned before, I'm at a point where the crashes happen very seldom. Like 1x per benchy. On other occations, with a 10 hour print, no crashes at all. I'm out of ideas at the moment.
If you look closely at the two benchys in front (blue = PLA, white = NGEN / PET) and the blue separate bottom part in the middle. You will the a "blob" at almost the same spot on those three models. That blob is a result of the crash, not it's cause. It happens just a few mm short of the "seam" where the layers start & stop. Meaning it happened just before the outline ended.
The dark Benchy is PLA with no crashes. The ugly white one is NGEN again and it's from earlier where the crashes, once it happened, just piled up. I think this "one crash happens -> a lot of crashed follow" is mostly because the blob that will be left when the nozzle lifts after a crash. It will leave a blob in which the nozzle will crash again and again. The white one far right it with the Standard Slic3r Optimal 0.15 colorfabb ngen profile. It had no crashes but I disklike the uneven layer lines. All other models where printed with slightly tuned S3D settings.
On the other hand, I printed this 10h print with 0 crashes. Apart from the blobs in the corners (coasting & wiping artefakts maybe?) I quite like it.
Re: Y-Axis fake(?) Crash detections - let's debug
I would like to add a little bit of information that I have discovered after troubleshooting the relentless collision detection and layer shift issues. I know that this discussion is primarily discussing Y-Axis but I would like to add something I discovered with the X-Axis collision detect. When the last firmware release we had a Y and X re-homing check introduced in selfcheck to make sure that the home point is found and hopefully remains consistent to eliminate layer shift through a crash detect. What I have found is that the home check is done at the bottom of the Z Axis and X is checked to the left towards 0. This is the side where the Einsy case is located. The check is done right against the case and if you have any inconsistencies like cable ties turned the wrong way obviously your home point will be inaccurate and different as your Z axis climbs above the Einsy case. What I have done to help this is to make sure that the selftest is run with the ability to move as far as possible to the left against the Einsy case. This works if the print is not too high but I have found that no matter what I do there seems to be a different home point after the print climbs above the case and then has a collision detect which seems to happen no matter what I do even though you look at the print and think a collision should have never happened. if the collision happens above the Einsy case then a layer shift happens almost consistently and will not happen below it even though a collision detect is experienced and handled. I hope prusa will read this and find that there may be a flaw in how this is done and also realize this might be why there are so many complaints about a variable experience with layer shits and collision detects. I would be interested if anyone else has found the same thing.
I haven't had a crash higher than the einsy case, (rarely print that big) but I can see how frustrating that could be.
Re: Y-Axis fake(?) Crash detections - let's debug
Hi,
I'm struggling with printing Benchys at the moment with around 20 fake y crashes per Benchy so will add to the stats:
Kit or Pre-Assembled?
[x ] Kit / Pre-Assembled [ ]
Firware
3.1.3.245
What Slicers did you use / did it make a difference?
Pre-Sliced Benchy provided on SD Card
Slic3r - no difference.
What are the Numbers on your Belt-Tension (Menu -> Support -> Belt Status)
X = 276
Y = 254 also tried tensions varying from 276 to 254 no noticeable difference over several benchys.
Which Version of the Y-axis Assembly / Heatbed Assembly do you have?
new
Only Y-Axis or also other crashes? (look it up in the fail stats -> Total)
Just Y (X =0, Y = 151)
Additional trouble shooting
Checked clearance underneath and no obstructions, u bolts clearing frame etc.
Different PLA filament similar random results.
Support suggested loosening the u bolts, I loosened them quarter of a turn but could then move the bearings by applying medium force to them vs the bed. So tightened up just slightly to the point if I pushed hard they would move but a moderate force they stay where they are. Bed sounds a bit noises though so suspect they may now be too loose?
I wonder if the u bolts being too lose could contribute to the issue? I've only ever seen tips suggesting loosening not tightening though!
Re: Y-Axis fake(?) Crash detections - let's debug
The most common place for a crash on the benchy is on the bow and the tangent at that point appears as though it could be relatively constant, they follow a line up the bow and are often symmetrical about the Benchy centre, I've drawn a white line to show this on Benchy 3 below:
By the fact that they are not all vertically above each other it suggests to me that it's not due to a specific location on the Y or X axis.
I sliced Benchy 6 with Slic3r and placed it near the from and left of the bed, while the location moved slightly up the bow they still occurred symmetrically about the centre of Benchy.
So I begin to wonder if it's something to do with a combined X & Y movement at the same time. I thought the x & y axis crash detection would be completely independent but I'm thinking they are not. Perhaps the physical speed rather than axial speed is used?
During the bow after a crash you appear to get several others, as has been pointed out. It was suggested that this may be the head crashing into the blob left behind, but I'm not so sure, after watching many of the 150 crashes it often goes through the blob (if there is one fine). I've even switched off collision detection after a few and waited until the surface has recovered, switched crash detection back on and it's immediately started crashing in the expected location, despite a smooth previous few layers.
I'm still on a quest to print a Benchy without hairs introduced by these crashes, I seem to also be fighting a common real crash at the top of the door arches which just rips the boat off the bed. Quite why the crash detection doesn't stop that I'm not sure, it's possible that it's not enabled despite showing as on as I'm sure there is a bug in the firmware that means when you re-enable crash detection despite it showing as on it's not actually on, similar with disable. I've ended up having to toggle the option 3 times to get the change to stick. Further testing required to identify this one, or perhaps there's only specific occasions when the mode is actually changed.
However I am concerned as to why I would get actual Y crashes on a regular basis at this location. See my thread on this: https://shop.prusa3d.com/forum/assembly-and-first-prints-troubleshooting-f62/benchy-failing-at-top-of-door-arches-t17579.html
The quest continues.
Re: Y-Axis fake(?) Crash detections - let's debug
Ok, some more information. So once it starts crashing on the Benchy bow it usually crashes several times each side of the Benchy where you see hairs on my previous post images.
I've just printed another Benchy and had the brainwave to remove the part printed Benchy during a the homing part of a crash. The printer continued to print and crash exactly where it normally crashes, proving that it's not rubbing into the filament left behind from the previous crash.
Instead there is something interesting about that part of the Benchy as it can be moved around the bed to different locations and behave the same.
Video of mid air crash:
Re: Y-Axis fake(?) Crash detections - let's debug
Hello,
I have the same experience. I was pleased about how nice was the Benchy turning out and then for no reason Y crash came and the printing resumed with shifted layers. This bullshit happens on almost every print and its really annoying. Has anyone came to an effective solution yet? I will try printing with the crash detection turned off and hope it will get better.
Re: Y-Axis fake(?) Crash detections - let's debug
I turned it off some time ago. Mt prints improved significantly.
Re: Y-Axis fake(?) Crash detections - let's debug
Oh I had something similar during assembly. Turns out I missed the part about putting the toothed pulley about 1/2 a mm away from the motor. When you attach the 16t pulley to the Y axis motor, make sure it's just a little away from the motor so it spins freely. If you don't, it will move in little spurts of smooth and not smooth.
Re: Y-Axis fake(?) Crash detections - let's debug
Ok, some more information. So once it starts crashing on the Benchy bow it usually crashes several times each side of the Benchy where you see hairs on my previous post images.
I've just printed another Benchy and had the brainwave to remove the part printed Benchy during a the homing part of a crash. The printer continued to print and crash exactly where it normally crashes, proving that it's not rubbing into the filament left behind from the previous crash.
Instead there is something interesting about that part of the Benchy as it can be moved around the bed to different locations and behave the same.
Video of mid air crash:
Hey thanks for posting this and especially the big post above this one. I also tried different Bed positions but could not any real value from it other than "it still happens".
I never ripped the benchy of the bed though. It's really interesting that the crashed still happened. So I guess the "it hit's the blob" theory is going down the drain with that.
My Benchys also have those 3 "hot spots". The lower Bow, The higher bow where the two small "windows" are and the start of the roof. Just like yours. 😯 And yes, I also witnessed the nozzle just driving through some real "blobs" like a plough and not caring at all.
Now that you show us, that it also happens without a Model to crash into is lust like. 🙄 ❓ 😆 😯 😎 Maybe it's stupid Software bug afterall and we can't fix it because there is no Hardware cause to it. Or maybe not I DON'T KNOW it's driving me nuts.
Can you do me the favour? Could you try wo move the bed by hand. With just enough force so it moves and see if you also feel variable restistance when it's sliding?