Thomas Daede

@xiphmont There are some absolute crimes in the source code only possible because rpis are so fast. A doubly linked list to store move history, where each entry is malloc'd and the whole list is searched every time a new move is queued

@xiphmont If it makes you feel better I'm currently segfaulting klipper. Though at least I can gdb that one

Well. It took a few days to figure out the serial/USB/Eth/WiFi hardware setup on the XLBuddy (good lord embedded software stacks have *not* gotten less buggy in the past 30 years), but I am extracting voluminous telemetry from within all the Prusa XL's hardware ISRs.

@xiphmont There is always the slightly monstrous option of running klipper firmware on the dwarf and adding protocol support to prusa firmware...

@enginetankard That's not to say we can't employ a little selective Klipperization. I never like dogmatic purity.

Initial testing indicates this M572 / M400 bug is at very least two bugs. And I think I know what one of them is.

@xiphmont I'd half suggest just klipperizing a mk4 to skip the entire desync side quest but unfortunately that'd exclude the xl (doing klipper xl would be a massive undertaking)

@enginetankard ...so i know what i need to do first.

@xiphmont I was looking at klipper code recently for how it handles synchronization - it has a NTP-like PLL system that calibrates all of the mcu clocks to the host clock. Although it calculates out round trip delays, you're still stuck wrt some effects of those - like endstops.

strategy 3: Planner only on the Buddy, and it sends blocks to the Dwarves in a sort of half-Klipper move. No one is going to like this one. Prusa keeps their firmware as close to stock Marlin as possible and Marlin will probably have a stroke seeing that PR.

@aras_p @FilmicWorlds @SebAaltonen Indeed, dav1d is currently the fastest open-source decoder. Though turning on NEON regardless of which you use is even more important, as you found out :) (I worked on a small part of AVIF, glad to see it used in games!)

@FilmicWorlds @SebAaltonen My understanding (but have not double checked) is that dav1d should be quite a bit faster than libaom at decoding. github.com/videolan/dav1d

I just found out that over 50% of our game load time is spent on: 1. Generating LODs 2. Decoding AVIF textures On old <99$ Androids worst case load time is 10 seconds. New phones load in ~1 second. AVIF decoder is missing NEON (fails to detect arch). LODs are not baked :(

@xiphmont I have never intentionally changed temp between layers, but I know the temp changing by not doing a long preheat is a common issue: ellis3dp.com/Print-Tuning-G… In particular klipper even has a linear correction some people use with temperature sensors (see links at bottom)

As always, interested in others' results. Couldn't figure out why first layer was glass-perfect, but second and third layers were full of digging in some places, underextrusion in others, elephant-footing that went up several layers... I hope this really is the fix.

New, unexpected Prusa XL lesson learned-- I'm printing .1mm and smaller layers. Do NOT change bed temperature between first and second layer. 80C->70C or 70C-60C, the second layer gets randomly wrecked as the bed flexes/shifts away from the initial MBL result.

@xiphmont @ZombieHedgehog_ Eddy current sensors like Beacon and Cartographer use an air core PCB inductor rather than a ferrite/iron core and operate at way higher frequency. As a result, the insurance change they measure is more from the eddy currents induced in the print bed rather than its permeability.

@ZombieHedgehog_ [genuinely not trying to be difficult, it just doesn't sound like anything new or unusual on the surface]

Eddy sensor!?! Is this the first commercial printer with a proper bed probe? Of course it's on a mini printer though 😅

@xiphmont I think the laser thing is purely a gimmick. It being a big printer is not, though.

Current thoughts on the H2D: Probably a nice enough printer, but a Harbor Freight kind of thing. Lets people try out a limited amount of laser 'stuff' before getting a better tool. It's not killing the K40. And it probably can't stop the march of the cheap tool/pathchangers.

@xiphmont I've had pretty good luck with pressure advance with a newer extruder. I think x1c style auto calibration of the value at the start of each print is a great idea, though the sensor could be improved. It also can't really calibrate for moist filament.

@enginetankard Assuming it's not a simple bug (I don't think it is), the obvious answer is yes, but How? I've done way too much thinking about Why for a while, and do not yet have any answers for How. Printers are now good enough that we have to revisit a few early assumptions.

Spent all day wondering where a ghosting/ringing artifact was coming from in a 3D print. Almost always shows up on models that have embossed text or patterns on the side.

@xiphmont Yeah that results in the too big or small holes problem and it's frustrating that it still exists 10 years later. I sometimes work around it with smaller nozzles if I'm patient.

@enginetankard Even a simple ones, like, "how far behind the printhead is the center of extrusion?" Extrusions aren't centered on the nozzle opening, but every part of the chain implicitly assumes they are. A few tenths of a millimeter are bigger than they seem (seam? ;-)

@xiphmont wonder if the horizontal banding could be solved by more accurate pressure advance

That said, it's also showing real and obvious PrusaSlicer bugs; a whole bunch of feed rate changes are getting omitted from where they *should* be, and that inconsistency is also causing horizontal banding in addition to the vertical ghosts.

@xiphmont The sync stalling out everything else is at least a very old Linux problem, LWN has a whole bunch of articles in the writeback category #Memory_management-Writeback" target="_blank" rel="nofollow noopener">lwn.net/Kernel/Index/#… (maybe the first relevant one is the USB stick stall problem) That said, they don't explain the slowdown on sync.

Only seems to happen on transfers to USB 'drives', might be due to some interaction with fuse? Anyone seen this, is it a known thing?

Hit an interesting "Linux" bug today, not sure where it is in the stack... Copying files to a thumb drive formatted in NTFS, it chugs along nicely at ~10MBps (slow drive). However, issuing a 'sync' causes the copy to throttle down to a few kBps (with long pauses) until done.

@xiphmont Cura had the first implementation of Arachne so that's not surprising :)

Orca, Slic3r and PrusaSlicer, unsurprisingly, show nearly identical planner behavior, though Classic and Arachne have important differences. Cura acts like an Arachne that's missing a few settings. I think I need to experiment with some post-processing scripting.

@xiphmont @lu_zero_ Er sorry, python not perl.

@xiphmont @lu_zero_ Cura is basically the oldest currently used slicer, it was a rewrite of Skeinforge from perl to C++. Slic3r was from scratch but was definitely made with influence from Skeinforge.

Oh wow. Even Cura has the same start-of-extrusion behavior.... Does every slicer trace back to the same ancestral codebase?

@KanjiCRT There is a knob on the top for vertical size, so you can set it however you want. Size is identical between modes - e.g. if you set it as 4:3 for 31khz Windows it will be 4:3 in 24khz DOS.

@enginetankard Great video. Curious how it handles the aspect ratio for PC-98 games which are 640x400.

The NEC Multisync JC-1401P3A is the first Multisync monitor. It's a great monitor for 1985, and can sync anywhere between 15-35kHz! vimeo.com/753467587

@xiphmont Also apparently there are multiple nextruder revs, might want to contact them and see if you can get it replaced Assuming that you didn't want the excuse to design your own :)

@enginetankard [for testing I'm also running at the same speeds as a MK3S, considerably reduced from the XL default. Though speed reduction seemed to make no difference whatsoever, so it's not 'running too fast' by default. Also nice to know.]

Awwwwww sh*t. This problem may be inherent to the Nextruder design.

@xiphmont Is the bearing on the extruder gear centered, or is it applying leverage on the planet carrier? Hard to tell from pictures. Also curious if it's consistent between extruders

@xiphmont The nextruder firmware is the dwarf "puppy" firmware in the firmware repo. I don't think schematics are being released anymore.

Oh, hmm, no schematics or firmware for the Nextruder electronics as of yet? Or am I looking in the wrong place (pruda3d on github)? #3Dprinting