The past two days I have a brain-worm / project idea of building a 3D printer via a wall-mounted 6DOF parallel robot driven by 8 linear drives (i.e. the typical z-axis spindles) mounted in parallel on the wall.

+ That would make the robot over-determined and should avoid any singularities but add extra stiffness
+ Should be able to retract very near the wall when not in use
+ Uses mostly the same building blocks 8 times instead of different mounting methods per axis
+ Able to print in arbitrary 3D paths
- Slicers will not support this out-of-the-box
- I heard there is a thing called "inverse kinematics" and allegedly I need to understand that, OTOH I feel it should be simple to intersect the strut-length induced spheres with the linear drives and that should answer all practical questions.
- Doing this as my first ever CAD project seems a bit overambitious, speaking from the outside perspective.
- I have never built a 3D printer before
- I have never built a robot before
- I have never driven a stepper motor before

Any input/suggestions welcome.

Usable workspace is a lot smaller than I imagined, maybe there are better ways to put those linear drives?

In any case, shoutout to the authors of WeBots, awesome software.

Repository (much undocumented): https://gitli.stratum0.org/Drahflow/parallelprinter

Drahflow / ParallelPrinter · GitLab

GitLab Community Edition

GitLab
So, I ordered a Nema23 stepper, somehow imagining it to be a smidgen bigger than the "normal" steppers. Turns out it's actually 1.2kg and looks extremely eager to turn just about anything.
tfw I assemble the first axle for real and realize the back-wall is pretty much EUR-pallet sized (leaving just 5cm on each side to add the necessary stabilization to keep the print-bed at 90 degree angle).
Turns out it is a bunch harder to get a 1.2m wall stable relative to a horizontal surface, than I anticipated. But after some iterations, I can now pull with my full weight and it'll not perceptibly move.

After carefully tracing the 4 cable colors from the board to the stepper motor, I finally crimped a nice dupont connector. For the JST-XH socket. After having found them most incompatible, I finally crimped a nice JST-XH connector. Turns out I'm not actually that good in carefully tracing 4 colors.

BUT ANYWAY, I now have a working stepper connected and it's looks as if I knew what I was doing.

The endpoint laser beam is extremely finely adjustable (which is good because I need to aim at a 2x2mm sensor over ~1m) in two axes. Less fortunately however is the fact that one of the two axes is the laser diode's optical one.

Just because C doesn't have coroutines doesn't mean I won't use them. (And the machine can now drive to a defined home position.)

https://gitli.stratum0.org/Drahflow/parallelprinter/-/blob/main/firmware/src/homing.c?ref_type=heads#L51

firmware/src/homing.c · main · Drahflow / ParallelPrinter · GitLab

GitLab Community Edition

GitLab
Also, I'm quite impressed with the light barrier's precision. A single measurement appears to discern ~2μm across the beam.
I have recently again been disappointed by the fact that PLA does have neither the tensile strength nor the elastic modulus of adamantium (not even at 80% infill).

1. Want to build a 3D printer
2. Surely it can't be that hard
3. ?????
4. Learn about Lagrange multipliers to find solutions to finite element simulations I need to identify parallel robot singularities as a substep in optimizing 3DOF joint positions.
5. ?????

[TIL. And yeah, that's ultimately the point.]

Progress. I now have code to compute the forces acting on each strut within a complex truss construction.

E.g. on a simple tripod, loaded at the tip with a force vector of (0, 0, 0)N and fixed at the three feet, the algorithm now gives me
14.14N along the first strut, -0.00N along the second and -NaN on the third.

Current yak-shaving level: Improving the 3D-engine I use to render the finite element simulation results (for debugging / cross checking the linear equation solver and finite element generation).
Issuing movement commands and specifying 10μm increments. Fuck yes.

The automatic calibration software needs to tie together
* stdin (me)
* /dev/ttyACM0 (hardware control board)
* /dev/video0 (USB microscope)
* a TCP/IP socket (microscope + computer vision debug video stream)
* a bidirectional pipe via adb (the program on the tablet drawing targets)
* calbration.dat (output file)
* a timer
in one massive event loop.

I like where this is going. :P

While trying to connect the first iteration of the calibration software to the printer, I see this line: "Intercepted from printer: No free target buffers. Send slower.uffers. Send slower."

Cackling like the madman I am at the fact that yeah, looks like something is indeed not going well with some buffers.

Last night, I tested the first iteration of the calibration auto-focus algorithm (to measure z).

Algorithm: "Best: (392 390 -803.2504)"
Me: Lmao, who doesn't love extra digits. But maybe I shouldn't report it up to 100nm. *moves the machine back to z=-803.240 and reruns autofocus*
Algorithm: "Best: (392 390 -803.2505)"

WAT.

It seems legit 🤯

Current status:
`X/Y deltas: dx: 0.00076176, dy: -0.00046126`
`X/Y deltas: dx: -3.662e-05, dy: -0.00095162` (as in, X is off by -36nm)

Watching the auto-targeting algorithm reliably move to within 1μm of the desired position in x/y and trying to get the z moves to the same precision reliably.

Watch me overthink the task of holding two 15mm aluminium t-beams in place