[FR] Cut 50% of print time with "limited-preview filtered B-spline (LPFBS )" Algo

[dosono]

Engineers at the University of Michigan’s Smart and Sustainable Automation Research Laboratory (S2A Lab) have landed an algorithm capable of keeping layers in check at up 10 times the typical speed of an FFF 3D printer.

Please read
https://3dprintingindustry.com/news/cut-fff-3d-print-times-half-university-michigan-123158/

[fiveangle]

I'll copy/paste what I responded to the same question posted to the Marlin Facebook group:

Peter Stojcsics October 21 at 10:23am: I would like if that feature makes it to Marlin

Dave Johnson October 21 at 12:24pm: Users have a tough time understanding how to calibrate their pressure constant for Linear Advance (which effectively reaches the same level of speed improvement as claimed by MUE, although by a different method).

Combining Linear Advance with the MUE method should see an additional improvement, but I have a tough time believing your average Marlin user will be able to model the physical dynamics of their specific printer 😄 . But we shall have to see if they ever publish their method(s).

Dave Johnson October 21 at 12:57pm: I found it available elsewhere. I didn't read it in full but after skimming, as suspected, it appears they use accelerometers affixed to X/Y axes and sweep them through various accelerations while sampling the actual movements, then generate their algorithms to model the delta due to vibration so it can be used at runtime to pre-compensate stepper commands to pre-adjust for expected vibration.

In short, impossible to add to Marlin as there would be no way to effectively "calibrate" the algorithm. Would be good for a company like Prusa Research to invest in for their very normalized printers, but not feasible for the average joe.

They also mention in the paper they completely replaced the motion electronics other than the stepper drivers, so there is the question if existing 8-bit MCUs would even have enough computational power to implement the method, even if one could somehow "calibrate" using available accelerometers. They used extremely high-speed PCB Piezotronics 393B05 - $595 USD and Kistler 8704B100 - $300 USD used on eBay.

Just a sample of the math involved:

Based on this, even if someone could implement the characterization method they used using more commodity hardware can it be implemented in realtime ?

BTW- There are very effective means of using commodity gyros such as MPU6000 which supports 32kHz raw sample rate when connected via SPI to STM32 for example (highly optimised code is available for using this within the Betaflight project) but I'm not aware of any highly effective accelerometer to do the same.

Someone could dig into the research paper to determine what the real Nyquist limits we are dealing with are here, but again, without a lot of hardware-interactive development work, there is effectively no method for Marlin to implement the methods presented in this paper.

[JerryDurand]

An added problem is the resonance changes as the model is built up AND will depend on the particular model being built, material, and plate attachment.

…

On 10/24/2017 11:19 AM, Dave Johnson wrote: I'll copy/paste what I responded to the same question posted to the Marlin Facebook group: *Peter Stojcsics* /October 21 at 10:23am/: I would like if that feature makes it to Marlin *Dave Johnson* /October 21 at 12:24pm/: Users have a tough time understanding how to calibrate their pressure constant for Linear Advance (which effectively reaches the same level of speed improvement as claimed by MUE, although by a different method). Combining Linear Advance with the MUE method should see an additional improvement, but I have a tough time believing your average Marlin user will be able to model the physical dynamics of their specific printer 😄 . But we shall have to see if they ever publish their method(s). *Dave Johnson* /October 21 at 12:57pm/: I found it available elsewhere. I didn't read it in full but after skimming, as suspected, it appears they use accelerometers affixed to X/Y axes and sweep them through various accelerations while sampling the actual movements, then generate their algorithms to model the delta due to vibration so it can be used at runtime to pre-compensate stepper commands to pre-adjust for expected vibration. In short, impossible to add to Marlin as there would be no way to effectively "calibrate" the algorithm. Would be good for a company like Prusa Research to invest in for their very normalized printers, but not feasible for the average joe. They also mention in the paper they completely replaced the motion electronics other than the stepper drivers, so there is the question if existing 8-bit MCUs would even have enough computational power to implement the method, even if one could somehow "calibrate" using available accelerometers. They used extremely high-speed PCB Piezotronics 393B05 - $595 USD and Kistler 8704B100 - $300 USD used on eBay. Just a sample of the math involved: 22688020_10155516664004457_3394790427252395198_n <https://user-images.githubusercontent.com/2219447/31959254-0f49cf5a-b8a9-11e7-85b9-ee6e6b00423e.jpg> Based on this, even if someone could implement the characterization method they used using more commodity hardware can it be implemented in realtime ? BTW- There are very effective means of using commodity gyros such as MPU6000 which supports 32kHz raw sample rate when connected via SPI to STM32 for example (highly optimised code is available for using this within the Betaflight project) but I'm not aware of any highly effective accelerometer to do the same. Someone could dig into the research paper to determine what the real Nyquist limits we are dealing with are here, but again, without a lot of hardware-interactive development work, there is effectively no method for Marlin to implement the methods presented in this paper. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#8071 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHfZY2p5gnf2JWbuEoIzMrcFHDAQLn8Yks5svioagaJpZM4QETRF>.

-- Jerry Durand, Durand Interstellar, Inc. www.interstellar.com tel: +1 408 356-3886 @DurandInterstel

[fiveangle]

The author of the article, Beau Jackson, alludes that it's just a matter of "do[ing] the math":

By comparison, the algorithm proposed by Duan and Yoon under the supervision of lab lead Professor Chinedum Okwudire, is free, providing you can do the math.

Which is anything but the truth. She redeems herself later in the article though, coming clean [bold/italics added by me for emphasis] :) :

What does this mean for 3D printing?

If implemented at the manufacturing stages of machine development the LPFBS method could be revolutionary for desktop 3D printer software, giving consumers the all-important time saving solution key to the technology’s continued growth.

-=dave

[fiveangle]

JerryDurand: An added problem is the resonance changes as the model is built up AND
will depend on the particular model being built, material, and plate
attachment.

For any moving-bed designs, you're absolutely correct ! All the test prints in the paper are of relatively low mass by comparison, so naturally, minimizes the effect of the printed object on the machine resonances. I could envision anyone printing large objects on printers such as CR10 might encounter pre-emphasis on the stepper drivers that could start out as reducing resonance related vibrations but becoming additive to them once enough mass had accumulated on the bed to change the characteristics, resulting in poor print quality later in the print.

-=dave

[Roxy-3D]

I could envision anyone printing large objects on printers such as CR10 might encounter pre-emphasis on the stepper drivers that could start out as reducing resonance related vibrations but becoming additive to them once enough mass had accumulated on the bed to change the characteristics, resulting in poor print quality later in the print.

Agreed. But if limited to the case of Delta printers... The idea might have value???

[fiveangle]

Agreed. But if limited to the case of Delta printers... The idea might have value???

For Delta's it would probably be least-effective, since they have the lowest moving mass of any of the designs. But any Cartesian, Core*, Delta, that does not move the workpiece could theoretically benefit from it. But fitness-of-purpose doesn't solve the main hurdle to implementing: characterization of the printer resonances.

[dot-bob]

Perhaps more then anything this stirs up ideas to different possibilities out there. It would be interesting to simplify this concept and use inexpensive accelerators/gyro modules to measure machine vibration and dynamically adjust parameters to minimize ringing. The printer could learn what types of moves cause vibration or resonance and modify behavior to cancel them out. So classify types of moves somehow for quick lookup (axis, acceleration, jerk, distance, etc) create a dynamic table of modifiers for that move. So rather then have a one size fits all approach for accel, jerk speed, etc it is dependent on the type of move and look-up table is used as a result of the dynamic learning.

[thinkyhead]

Uses a pre-processor!

[Roxy-3D]

To identify the FRF's and implement...

The Double E's I went to school with always liked to point out something. If you want to analyze a circuit's behavior, you send in a Delta Pulse. That contains all frequencies and you can see how it attenuates them.

It would seem we could do the same thing with an arbitrary printer. We should be able to shake the nozzle back and forth in all dimensions and see where the poles and zeros are in the S plane. Right? (I'm not a EE. But that is how those guys talked.) It would seem we could figure out what things the printer doesn't like and not do those frequencies.

[fiveangle]

I'm trying to envision how I could mount one of my STM32F3 based flight controllers running Betaflight with an 8kHz / 1kHz gyro/acc sampling rate capturing pre-filtered output to the SPI-connected SD card in Blackbox format and observe the resulting behavior ? Only tough part is how to sync the inputs to the measured outputs...

We'd need to have some way to report motion to the flight controller with enough resolution that it wouldn't get lost in the noise. Perhaps send a scalled analog output for absolute position of X and Y to corresponding analog inputs on the FC (commandeering the Vbat and current sensor analog inputs) then just send it the sweeps while logging. Could use some kind of crude morse code to indicate start of motion sequence for human-readability on the resulting output.

So many ideas... so little time :)

EDIT: and of course this wouldn't work at all on any of my printers since my X and Y moving gantries are different pieces. It would only work with moving-head-only designs such as SCARA, Hbot, CoreXY, Ultimaker, etc. * sigh *

[bobc]

Uses a pre-processor!

A dual-core 2GHz 64-bit CPU plus an FPGA card, "price on application". Maybe if they bought a decent printer and tuned it properly (from the video their belts are obviously way too loose) they wouldn't need $1000 of kit to improve it.

Do they publish the source code, or is it "Patent Pending" ?

[Deneteus]

@Roxy-3D What you said about the Delta Pulse is basically what we currently do with Stage Speakers to determine what frequencies cause distortion in the speakers signal reproduction. Same for current home surround systems. We use a microphone to record the frequencies being created and then adjust the signal from there. I think you could measure vibration with the motion chips that the WII uses attached to each motor and the printer bed and the frame and use it to control the printing in real time.

http://www.analog.com/en/products/mems/accelerometers/adxl330.html

[fiveangle]

I think you could measure vibration with the motion chips that the WII uses attached to each motor and the printer bed and the frame and use it to control the printing in real time.

Would realtime do any good unless you have perfectly tuned PID models for what to do with the data ?
I think that's the big issue. The paper mentioned above (and your stage speaker example) essentially work to predict what inputs would incur unwanted output and pre-adjust to compensate, eliminating the difficulties of realtime processing.

I suspect the outdated WII is surely below the Nyquist limit for the vibration info we're talking about. Using an STM32F3 flight controller with SPI-connected GYRO (like on the OMNIBUS using the Invensense MPU6000) should be able to capture the acceleration sensor info at approx 1KHz sampling when mounted to the moving hotend.

I thought about it some more and we could use something similar to the LED control (emulates digital control protocol over analog signal lines) to sync the inputs to the measured accelerometer results and ultimately feed into the algorithms described in the research paper. I don't have a printer that can even test the theory, so the result will be left as an exercise for the reader ;)

[fiveangle]

Haha 😂

https://hackaday.com/2017/11/29/peer-review-in-the-age-of-viral-video/

[dot-bob]

You don't really need to perform it in realtime other than use a look up table. It can be self learning and adaptive after the fact. Use a lookup table in which the index uses possible moves like vector (direction) and magnitude (acceleration). So when an acceleration is requested in a direction you would reference this table for the value the printer would use for jerk and or acceleration and so on. Default this table by filling out with the default jerk and acceleration. Use a chip like the https://www.adafruit.com/product/2019 on the hotend (or bed) to capture data during a move and read the result after the move then tweak the table. You could make it a low priority task that runs every couple of moves and overtime it would eventually update all entries in the table. Once a good table is established you could probably even quit sampling movement data.

I have used similar algorithms to electrically tune the gain stages of amplifiers used in satellite transmitters. So over time the performance of the transmitter increases.

[fiveangle]

I don't think you understand how much processing power is needed to adequately process the sensor data realtime in order to measure to the resolution required to support capturing mechanical resonances. An STM32F1 chip maxes out trying to sample the MPU6000 raw data at just 2Khz.

Sure you can use the filtered data from these accelerometers/gyros as-is but I doubt it will be of any real use since the in-built low-pass-filter on the chip is far too low to be of any use for measuring anything other than gross resonances. They are designed as-is to tell up from down and sense gross events like device-drop, etc. They cannot output fast enough for the types of measurements needed here.

The several milliseconds of latency due to the in-built LPFs can't help either. The Freescale MMA8451 used in the Adafruit board is horribly low performance compared to the Invensense MPU6000 btw. Put all this behind a sluggish I2C bus and you have all the makings of a wasted effort I think.

Using something like the OMNIBUS board (or any board with similar SPI-connected sensor with ability to sample raw sensor data) and the Betaflight / Blackbox stack as a dedicated outboard sensor / datalogging solution would certainly be fast enough.

Even if so, the hackaday link above illustrates the gains that may be on the table are likely far less than expected. Their algorithms might be better described as an effective way to improve the print quality of very low-quality printers with very non-optimal settings, rather than a method to move print speed / quality higher than the current state of the art.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.