“Thou has missed daily prayers for two whole weeks”

Sorry for the late reply, tied up. Thankyou for the photos.

The Z-axis leadscrews look OK in the photos (nothing obviously wrong). That’s a very clean and new printer.

Q1. Is there any grease on those Z-axis leadscrews (tall metal spiral rods) or are they completely dry?

Q2. If you force your printer to move up and down does it make unusual noises at some parts of its travel height? You can try typing thing g-code into your printer monitor software to make it move up and down:

G0 Z100 F1000   (move to Z position 100mm.  You won't actually travel at 1000mm/minute, instead the printer will do whatever it's max is)
G0 Z0 F1000    (move to Z position 0mm, ie nozzle touching the bed)

You may need to home the axes first (G28)

Q3. Are these screws on both sides properly tight? I think I might possibly see a gap under one, but it could also be an optical illusion from reflections.

The fact the lines are at the same height between different jobs suggests something is wrong with your Z axis. Can you post photos of your printer, including the Z rails and/or screws?

deleted by creator

Assorted thoughts:

Also doubles as a filament runout sensor.

Bearings:

• Only a tiny angular movement -> technically a bad case for ball bearings due to lubricant not getting recirculated, but I think the bearings are being run dry in this project anyway (and are under next to no load)
• I wonder if sleeve bearings would be cheaper but work as well?
• Alternative solution: put a PCB on the left and right sides, then unthreaded SMD soldered standoffs like these as sleeve bearings? I think some are brass under the platings. Exact alignment isn’t necessary as once soldered they won’t move (and you calibrate the device manually afterwards anyway).

Micro:

• ATtiny’s are expensive last I checked :P I prefer STC (8051 clones) but even they’re a bit much these days. A padauk or similar would be an extreme.
• Staying with the Arduino IDE is probably an attractive goal for ease of development, so staying with the ATTiny might be best.
• Comms: I wonder what’s easy to interface with Marlin? Extra UARTs running at very slow speeds (eg a few thousand baud) might work well.

Applications:

• Do you adjust filament feedrate on the fly?
• is it necessary to delay the adjustments by X cm of filament? Or does it change slowly enough that it’s not an issue?
• Detect lumps in filament and pause/alarm prints! I once had lumps of some higher-temp plastic in my roll of recycled PLA, it would jam and cause my prints to fail. Very annoying!

Calibration:

• Using drill bits is brilliant, I love it.
• Do the magnetic properties of the steel cause issues? What happens if I accidentally magnetics my bits? Perhaps I should only insert them from one particular end whilst calibrating to maximise their distance from the hall?

Screws:

• I like using “coarse” 3mm plastic screws. They don’t have a tidy standard like “M3” but you can get them on lcsc and other places. They hold in 3d printed plastic really well, can be removed and inserted dozens of times (surprising but true, even if you cross-thread occasionally) and most of all: don’t need brass inserts!

Apologies if some of this was answered in the video. I’m sorry Mr presenter but you waffle more than I do :P so I skipped a few bits.

“If found, please PM @Rikudou_Sage@lemmy.world”

And they made a very satisfying thump when they hit the floor.

GARABALDI

There is an open source port that works natively on Windows, Linux and other platforms. I played it quite a bit :)

Interesting note in the project readme:

On 64-bit bug that killed the game

I did not find it, decompiled game worked in x64 mode on the first try.
It was either lost in decompilation or introduced in x64 port/not present in x86 build.
Based on public description of the bug (no ball collision), I guess that the bug was in TEdgeManager::TestGridBox