Hi All,

I recently got back on the 3d printing scene after about a decade (Time flies!), the other day I was inspecting a failed print for a spool holder and noticed the Z axis striations seemed to follow some kind of oscillating pattern for the most part.

This made me think of the early day flight recording units and I thought if we were able to quantify these oscillations and compare them to the gcode we could derive what types of movement are causing these issues and hopefully troubleshoot them (perhaps even beyond our naked eyes capabilities)

So I drew up this back of an envelope concept and since I’m relatively inexperienced with 3D printing, I wanted to post it here and see what the communities thoughts are on it.

If it seems like a worthwhile endeavour I would be happy to invest my time in making it a reality and could hopefully publish this work (under FOSS of course) to help benefit everyones prints.

  • @Thorry84@feddit.nl
    link
    fedilink
    English
    123 days ago

    Getting good data would be very hard, a dial indicator probably won’t work very well with 0.2mm layer height and smaller. Maybe a laser would work better, but the amount of noise would be pretty high since 3D prints usually aren’t as consistent to begin with.

    A much better way this is done these days is an accelerometer on the print head. Then you can put the printer through a test program which wiggles the thing in different directions at different frequencies. The accelerometer can compare the expected result with the actual result and can pick out any weird oscillations or ringing of the machine. The data from this can then be applied when slicing, to compensate for the machine properties.

    This is a pretty standard function on most high-end printers these days. And is even in reach for cheap machines, since you can buy USB accelerometers for this purpose. The downside of those is the USB cable skews the result a little bit, but if mounted permanently and the cable routing is done well it can work great.

    • @bluewing@lemm.ee
      link
      fedilink
      English
      13 days ago

      And there is little reason to do input shaping on the start of every print unless you change the mass of the moving parts by a noticeable amount. And even then, it does nothing once the print starts. You get what you get anyway when the print is finished.

      What would be better is if a printer could measure and adapt to the changing resonances as the printer was printing. But I suspect that ain’t going to happen anytime soon due the complexity and the ultimate question: “How good does good enough really need to be.”

  • @Sphks@jlai.lu
    link
    fedilink
    English
    53 days ago

    What printer are you using?
    New printers like the Bambulabs, or Creality K1 are compensating lots of issues now, and you can print nearly perfect prints.

  • @SoulWager@lemmy.ml
    link
    fedilink
    English
    13 days ago

    I don’t think it has much practicality, just get some known straight/square object and attach your test indicator to the toolhead. Measure your motion error directly.

  • @morbidcactus@lemmy.ca
    link
    fedilink
    English
    1
    edit-2
    3 days ago

    i was thinking along those lines for equipment monitoring stuff, klipper works with Prometheus & grafana (have metrics from my printers), was thinking about looking at using the extra accelerometers I have to do something like vibration monitoring.

    I could see using a second sbc for extra sensors as well for support, thinking about printers that don’t run klipper, so long as you can correlate data it should still be useful. Honestly kinda thinking something similar to PLC data, was fantastic for fault finding and failure investigations, also useful for process control + condition based maintenance, there’s a heck of a lot that could be done with it.

    Edit: You have me thinking about this now, what would be really cool is an ability to anonymously federate data tied to events, I recall some enterprise software I used like 5-6 years ago could do this with condition indicators, I have 2 machines, I won’t see every failure mode, but if we had 1000 machines you can get much more accurate information about things like MTBF. Heck I’d even just be happy with some community FMEAs, really just thinking of taking a technical approach to my printer maintenance and usage.