Advanced controllers in the future
-
Hello everyone,
This is a few questions I have been thinking about the future for controller boards. I know there are options out there, like using a raspberry pi and microprocessor together. I'm talking about single board systems.
Do you think we will see advanced 3D printer controllers? Controllers that are smart, fast, all-in-one kind of system.
Do you think we will ever see machine learning on a 3D printer? Maybe something that can detect printing issues like, temps to high or low, blobbing, under and over extruding, etc...
Do you think we will ever have multi-core processors controlling one machine? Maybe one core doing the movement calculations, another (or more) cores managing the movements, etc...
Do you think we will see FPGA's processing movements? The FPGA would controll all of the timings, the accelerations, jerk, speeds, etc... I'm only suggesting FPGA's because the movement control doesn't need computational decisions, it just have to do what it's told, when it needs to (similar to Klipper)
What other advancements do think we may see in the future for 3D printer (or machine) control boards?
For me, I would love to see something like a raspberry pi combined with a FPGA all on one board. That has the capability of true, real time closed loop control, advanced PID for the heaters (always learning and adapting), advanced crash detection, and more.
-
I think an individual 3d printer will not have enough data to learn on during normal operations unless you do very intensive guided learning with prepared data sets.
I think with better models of both printers and materials, machine learning might become a part of slicers so that techniques like the recently linked non planar surfaces or better supports (optimized for removal, material used or print speed) can be determined within a couple thousand iterations for a print before plastic is melted.
-
I think the all-in-one approach will have limited appeal for several reasons...
From a market perspective, an all-in-one with the features you list would be expensive to produce and therefore would have a limited market. The cost would also make it prohibitive to upgrade when new versions of the components become available. It's a "locked-in" platform.On the other hand, a multi-component solution such as the one the Duet3 is going down would allow manufacturers to produce a basic platform as well as adjunct components to provide the advanced features that would probably be useful to a more limited audience. It also offers an easier and probably cheaper way to upgrade components without having to invest in an entirely new platform. Who knows, maybe some future Duet board won't have any stepper drivers on it at all and just concentrate on being a great motion controller with replaceable expansion boards with Trinamic's latest and greatest drivers.
Or maybe even the SBC becomes the hub to which you can attach multiple motion controllers, etc.
All of this would require very well defined interfaces and it to most end-users, it would have to appear as a single integrated solution.
Just my thoughts.
-
We could put the latest, biggest processor on there, but we still feed this misrepresenting piece of monstrosity that we call gcode to it. I can imagine a printer being able to just print a 3d model without intermediate steps, but there are ways to go first. I'd just take an overpowered PC and slap it onto the printer because I don't care and want the latest, shiniest tools. I'm a believer in general purpose computing and tiny processors make my life hard on the printer and at my work.
-
One of the biggest issues with controlling 3D printers from PCs or single-board computers is that the operating systems that run on PCs and on most SBCs such as the Raspberry Pi are not real-time operating systems. That makes them fundamentally unsuitable for controlling 3D printers by themselves. There are variants of Linux/Unix that claim to be real-time (e.g. QNX), but none in widespread use in the open source community.
IMO an obvious way forward would be to develop a variant of Linux that allocates only 3 cores of a 4-core RPi to Linux and runs a proper real-time OS such as FreeRTOS on the 4th. Together with a prioritised interrupt handling system, this could in theory allow an RPi alone to control a 3D printer properly. However, the RPi probably doesn't have enough I/O capability - although I haven't checked the Pi 4. Forget I/O expanders, they are too slow to drive stepper motors.
FPGAs are a good solution where a limited and predefined set of tasks needs to be done very quickly; but in other cases, a 32-bit microcontroller is more flexible, easier to program, and probably costs less. We don't think it's worth using FPGAs in motion control applications unless there is a compelling need for extremely high step rates.
Our strategy with Duet 3 is to support and encourage running the user interface and initial GCode processing on a RPi or other SBC, but to keep the motion planning and step generation on a dedicated processor running under a real time operating system. The ARM Cortex M7 MCU on the Duet 3 is possibly overkill in this application, but it gives us the CPU power and extra RAM to provide additional functionality in the future.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 That part about the OS - I think there already are flavors of Linux or possibly Windows which do just that, but so far I've only had people tell me about it. One of the future projects I might get involved in is a shared-memory communication interface between a real-time process and a non-real-time process within the same OS (on a machine probably similar to the latest Pi, but I'm not sure at the moment as it's in a very early stage and details are scarce due to reasons). In any case, it is a way to go, but do we really need it? Maybe controllers with encoders which are able to do complex movements are enough being real-time themselves?
-
I think the the bottleneck for printing quality, ease, reliability, predictability, and speed are not the controller but the FDM printing method. The big leap will come from mass production of printers that use better printing methods. Similar to the switch in 2D printers from dot matrix to inkjet and laser.
We are still in the 3D dot matrix stage.
-
I think a good approach would be to devide 3D printing into it's tasks and decide which hard- and software shall fulfill it:
Overall plan with one or multiple printers is not time critical and can be done in advance, but is complex => high power CPU, no realtime necessary.
Stepper movements: must be exact and is time cirtical, realtime OS needed => near hardware, realtime OS like the Duet 3 core.
Heater, Fan, Heatbed Calibration etc. not time ciritical => delegate to low power MCU, but with high priority interrrupt power to stop printing in case of emergency.
Quality assurance with camera, measure dimensions (e.g. control every layer quality) => good image processing hardware like Raspberry and maybe some GPU for neuronal network for image classification.
GUI for user interaction and visual control need to be able to manage html 5 => powerful enough hardware running a web server, like the Raspberry or a Tablet/PC/....
I would then assemble the hardware (modulize) by good interfaces. The Firmware on the different components need not to be the same language/OS, only the protocols of the interfaces. There needs to be a central realtime clock.
I would not use an integrated hardware, because I loose flexibility. Using a good interface is IMHO better.
