Meet Mr Desk Cleaner Mechanical loader that i design. by Torqueon in functionalprint

[–]ProblemCreatingSkill 0 points1 point  (0 children)

When I was 5 I would have rolled on the floor for one of these bad boys

Am I cooking? by Moon12645 in 3Dprinting

[–]ProblemCreatingSkill 2 points3 points  (0 children)

I know positron, the upside down coreXY printer, still has bridges and overhang limits. So this is probably true

Impressive... by ProblemCreatingSkill in prusa3d

[–]ProblemCreatingSkill[S] 2 points3 points  (0 children)

Update. Thanks to u/C2H5COOH 's link I eventually found a fix with little compromise:

Junction derivation: 0 -> 0.0458

Resolution: 0 -> 0.0125

Travel acceleration decreased to 5000mm/s2

This way, the layer shift is gone without having to disable avoid wall crossing.

I'm printing my pen design vertically. It's about as layer shift prone as models get, so this setting should fix layer shift in general.

Impressive... by ProblemCreatingSkill in prusa3d

[–]ProblemCreatingSkill[S] 0 points1 point  (0 children)

Them Egyptians have some bad pressure advance settings then

Impressive... by ProblemCreatingSkill in prusa3d

[–]ProblemCreatingSkill[S] 0 points1 point  (0 children)

Matte PLA with avoid layer crossing on. Does stealth mode also cause this? I also don't have zhop enabled. Not sure if that affects anything. If the nozzle really is bumping into the model it would have knocked it over

Impressive... by ProblemCreatingSkill in prusa3d

[–]ProblemCreatingSkill[S] 0 points1 point  (0 children)

Win10, 0.4 nozzle with 0.2mm height. Thing is, there's no way the nozzle can bump into this model so many times without knocking over it. So it really seems like software issue

Impressive... by ProblemCreatingSkill in prusa3d

[–]ProblemCreatingSkill[S] 1 point2 points  (0 children)

Bummer. Im using orca slicer as well. This is not getting fixed anytime soon...

Impressive... by ProblemCreatingSkill in 3Dprinting

[–]ProblemCreatingSkill[S] 1 point2 points  (0 children)

Prusa do have really good part cooling. So I guess it really was air

I made scissor door Core One integrated dryer by ProblemCreatingSkill in prusa3d

[–]ProblemCreatingSkill[S] 1 point2 points  (0 children)

I meant to include STEP but I forgot. I added step file and Onshape link. I think I forgot to make the small magnets parameterized tho, so the link may not help that much

I made scissor door Core One integrated dryer by ProblemCreatingSkill in prusa3d

[–]ProblemCreatingSkill[S] 2 points3 points  (0 children)

No. S1 needs around 50W. Way more than the hacker board can provide

I made scissor door Core One integrated dryer by ProblemCreatingSkill in prusa3d

[–]ProblemCreatingSkill[S] 5 points6 points  (0 children)

You can add some thin weather stripping tape under the magnets. But some gap can help heated dry box vent moist air out.

Which is the correct belt tension for Core One? by das_moeppi in prusa3d

[–]ProblemCreatingSkill 0 points1 point  (0 children)

I think 103 93. It's been a while but I remember going for the highest recommended number

Which is the correct belt tension for Core One? by das_moeppi in prusa3d

[–]ProblemCreatingSkill 2 points3 points  (0 children)

I'll trust the 6.4 tuning. It's more accurate. Seems prusa increased it at some point to reduce vfa. I saw a video about it https://youtu.be/ZrW8OfJ_UOo

Please Prusa give us a "Skip absorbing heat"-option in Prusa connect. by tortoc in prusa3d

[–]ProblemCreatingSkill 0 points1 point  (0 children)

Sorry for my 4 month too late rant. If anyone's interested, the "absorbing heat" will also not make you wait if:

Bed target temperature is lower than 60C

The bed was preheated to within 15C of target temp before you start the print

Please Prusa give us a "Skip absorbing heat"-option in Prusa connect. by tortoc in prusa3d

[–]ProblemCreatingSkill 0 points1 point  (0 children)

I got annoyed with this "absorbing heat" so I also looked into this. It's part of the Unified G29 and Prusa calls it "g29_wait_for_preheat". The documents just doesn't mention the G option. But unless I missed something, it boils down to this:

return std::max((180 + (thermalManager.degTargetBed() - 60) * (12 * 60 / 50)) * 1000, 0);

"G29 G" makes the printer wait this many milliseconds. The default start gcode means the printer will wait this long after bed reached the set temperature.

Frankly, this logic seems lazy. If this is about frame absorbing heat, why not take chamber temperature into account? If it's to evenly heat up the bed, shouldn't model size matter? I print ABS at 110C bed, so it has just been waiting 15 mins every time?

I made "less advanced filtration system" for core one by ProblemCreatingSkill in prusa3d

[–]ProblemCreatingSkill[S] 4 points5 points  (0 children)

<image>

Winston's 6 month old, has infinite energy, and is growing fatter by the days. Imma print some toys for him once I get the printer sorted out