Wanted to post a status update on firmware development.
I had to stop work shortly after the last code update was sent to Github to work on some heavy-duty production. I still have some more jobs to finish, but I'm nearly ready to resume work on this.
I've come to realize that the tower lean problem is more complex than I had originally thought. The effector platform is out of tram with the bed proportional to how much tower lean there is. This has three implications that I've thought of so far:
- If you have any tower lean at all, and we all have at least a little, forget about running multiple nozzles for anything but prints that have a small footprint. The Chimera and Kraken hot ends from E3D, tightened down to be perfectly tram at the center of the bed, will go out of alignment as the effector moves in any direction out from center. It will get worse the further out you go. Therefore, multi-extrusion (that's expected to work across the whole print surface) is better done with something like a Cyclops (if you can deal with the punishing learning curve) or the upcoming 3-in-1-out Diamond. Some people may have printers that are just so nicely aligned that they can get away with it, but I wouldn't count on it. If you're buying a new multi-extrusion setup, I would go with one of the 2+ in, 1 out setups.
- In order for the tower lean logic to be "complete," it would need to know the distance your hot end projects down below the effector. This is because if the effector is tweaked from tower lean (which it is), it's not tram with the bed, and its local down-vector will be pointing slightly off to the side in some direction. If your nozzle is 10mm below the effector, it will contact the bed at a slightly different XY location than it would if it was 20mm below the effector.
- Suppose your probe triggers 10mm above or below where the hot end would touch the glass at Z=0. (So, it triggers well before or after the hot end would crash into the glass.) Per the above problem (down-vector of the effector leans a little to the side), this means the probe will touch a slightly different point on the glass than your hot end would. My probe has an offset like this, of about 10mm, in the way that I mount it. I'm still getting great first-layer results. However, if I didn't already have this probe, I would look into either FSRs, or one of the designs where the hot end is on a stiff spring and it triggers an endstop switch when it contacts the glass. (Probably hot-end-on-a-spring. Simpler.)
Now, the next thing I need to work on is taking care of an irritating crash bug. It never crashes when I print, but it occasionally stops and hangs when I run the calibration. It's enough of a nuisance that I'm not comfortable uploading it in its current state. Therefore, my next task is to resolve the issue, which I believe to be pointer corruption in 2D array allocation. That will allow me to increase the grid size from 5x5 to 7x7, which I believe will result in better calibrations and finer depth-map (G31 A) correction. After that, I will decide whether I want to continue messing around with the tower lean stuff. Frankly, I'm more than a little tired of staring at the math, and I'd far prefer that someone who's actually
good at math do it and just hand me the formulas. If no one steps up, I will take this as a sign that the community doesn't care enough about the feature to warrant me spending any more time on it. (If you want the more perfect calibration, and you are or know someone who is good at math, this would be your cue.)
Because the new code has migrated a ton of stuff out of system memory and onto AHB0, it's likely that people who want to run panels and Ethernet will be able to do the calibration without having to disable those things.
----------
I'd be happy to run the G29 E1 N30 once this print completes. Do you need this run on the current config? or would it be more useful for me to temporarily start over and run a specific sequence?
Doesn't matter. It's only a repeatability test.
The brim on my first 0.1mm layer height print was gorgeous and perfect, but the machine was stuttering. So I bumped up junction_deviation to 0.05, and the stuttering went away, but it seemed to affect my gamma_max, and I had to manually set it afterwards. But after I did that everything else seemed to be fine.
In my experience, junction deviation is a setting with limited usefulness, which should be set and then left alone forever. I use 0.01 and it's fine. If it isn't for you, the only thing I can think of would be to use a different acceleration setting. Whatever it says in config gets overridden by what's in config-override, so make sure you set both with G-code commands and forget about editing them in the config file. (Well, maybe put them in there for the future, but they'll never matter until you start the printer without a config-override file.)
