It might not be the kind of thing you’ve given much thought to, but if you’ve ever used a desktop 3D printer, it was almost certainly being controlled by an 8-bit CPU. In fact, the common RAMPS controller is essentially just a motor driver shield for the Arduino Mega. Surely we can do a bit better than that in 2019?
For his entry into this year’s Hackaday Prize, [Robert] is working on a 32-bit drop-in replacement board which would allow 3D printer owners to easily upgrade the “brain” of their machines. Of course, there are already a few 32-bit control boards available on the market, but these are almost exclusively high-end boards which can be tricky to retrofit into an older machine. It should also go without saying that they aren’t cheap.
With this board, [Robert] is hoping to create a simpler upgrade path for 8-bit printer owners. Being small and cheap is already a pretty big deal, but perhaps equally importantly, his board is running the open source Marlin firmware. Marlin powers the majority of 8-bit desktop 3D printers (even if their owners don’t necessarily realize it) so sticking with it means that users shouldn’t have to change their software configuration or workflow just because they’ve upgraded their controller.
The board is powered by a 72 MHz STM32F103 chip, and uses state-of-the-art Trinamic TMC2208 stepper drivers to achieve near silent operation. The board has an automatic cooling fan to help keep itself cool, and with an XT60 connector for power, it should even be relatively easy to take your printer on the go with suitably beefy RC batteries.
XT60 should be used for the bed and the extruder too
A typical 40W hotend heater takes only 1.6A at 24V. They is ABSOLUTE no need for a XT60 on the hotend! I run my hotend over a Flat Flex Cable with 1mm pitch and it works without any problems.
well, I would use slice’s heater, 50w isn’t it?, 2+ amphs. Is the xt60 that expensive?, could use XT30, but it’s a bit tiny for me to solder.. :)
XT30 is still gigantic and hilariously overkill for a couple of amps..
XT30 means it’s a 30amp connector. XT60 goes to 60amp application.
I man, for this application, XT30 is way enough for all of your use.
Were gonna use XT60 like in over-powered RC or something that need a huge, instant draining device.
I was under the impression that both the Marlin code and the PCB Gerber files would be available. I was wrong.
It appears Marlin code is available at https://github.com/hackaday3D/marlin_stm32, but you need a dark web build tool to build it.
Meanwhile [Hackaday] might also consider the use of their trademark there…
Dark web? Do you mean dropbox?
don’t even need dropbox, Platform.io will do the trick just fine :)
I meant that both would be available, not just the software.
Is any of these tools unavailable? https://github.com/MarlinFirmware/Marlin/tree/bugfix-2.0.x
Arduino IDE/PlatformIO?
I like that people are exploring alternate designs like this 32bit rig…
We build something less creative, as we wanted to preserve the existing Arduino use. This is mostly due to everyone already extensively documenting the 2560, and parts should be easily replaceable 5 years from now. ;)
However, I do understand about the Alpha/Beta design doc withholding though… while we do regularly publish our software config back to the community… we also now keep Beta schematic/pcb info within the legitimate core developer/users/parent-project/contributor community after seeing the hazards off-version RAMPS v1.4 clones became. The cloners simply fragmented several other open-projects with incompatible motives from irrational commercial interests, and content-publishers tended to to get their “hate on” before submitting a bug report. It really is a shame, as we all liked how well the RAMPS boards were so well documented.
We are also of the opinion that solving our own needs was more important than trying to satisfy the unrealistic expectations some users have for low-volume club electronics. Most of our stuff is made by volunteers for other club members… We support each other, respect the efforts involved, and encourage measurable improvements.
You can download our dev image from the user name, and the make scripts pretty much automate everything except a marlin boards configuration. Thus, not much has changed for regular builders… For people who contribute nothing but indignant negativity to the community… you will have to do some work to improve karma… Otherwise, you will have to wait a year like everyone else… as Hobby projects move at the speed of free-time, and can get glacial slow sometimes…. ;o)
> For people who contribute nothing but indignant negativity to the community
As someone who actively participates on the mechanical keyboard community, releasing some designs on my github, even some public domain releases, that offends me. Do not assume anything about others, you may be VERY wrong.
You have to start somewhere. I’m assuming you typed this yourself and read English, for example.
>It should also go without saying that they aren’t cheap.
BIGTREETECH-SKR-V1.3 is around $20 without the driver modules. It uses a LPC1768, support marlin2.0 and smoothieware. It supports TMC2130 SPI interface and TMC2208.
LPC1768: M3 Core 96MHz, 32KB RAM, 512KB FLASH
Files are on their github https://github.com/bigtreetech/BIGTREETECH-SKR-V1.3
uh, it’s been several years since the ARM RAMPS replacement fad kicked off and, like you would expect, there are a ton of $20 smoothieboard knockoffs on amazon and ebay. “these are almost exclusively high-end boards … It should also go without saying that they aren’t cheap.” they’re basically redpills with some specialized headers, of course they’re cheap.
If you’re going to the effort of making your own board then why not pick a newer/faster/better STM32 than the old STM32F103?
Just being newer or faster doesn’t in and of itself necessary mean that it’d be any more useful. The STM32F103 costs less and, very clearly, is perfectly well up to the task, so what would using a newer STM32 MCU bring to the table, apart from costing more?
The Cortex-M3 in a STM32F103 doesn’t support a FPU. Any floating point calculations are soft float only and slow. There are newer STM32s with a Cortex-M4 or better with a FPU.
The peripherals in a STM32F103 are old designs. The newer parts have peripherals with less bugs and work better. They also have errata but nothing as bad as the I2C controller in the STM32F103 which has a complex sequence to reset because it can get stuck.
There are newer parts for the same cost as the large package STM32F103 used in this board so why not use them?
The best option for a 32bit control board for a 3d printer at the moment is probably the duet wifi board
* Has an inbuilt web interface (think octoprint but inbuilt)
* Has wifi inbuilt
* Has support for a LCD Panel
* You can upload directly from Cura across to it over the network via plugin
* Configurable via G-code stored on an SD card and editable via a web interface (uses bootstrap for the gui)
* Uses trinamic drivers with 32 / 256 step interpolation
* Has a cnc mode / support for delta printers / bed levelling etc
There’s also cheap china clones available on aliexpress (although I’d recommend buying the official one to support the dev’s that do the firmware)
The problem is that virtually all of this can be done “good enough” with an 8-bit micro and a raspi running octoprint.
3D printing as a whole has been stagnant for years. There’s no real reason to move away from 8-bit micros because there’s no advantage that’s attractive enough to move more than a few people to the new technology and build a self-supporting community there.
That’s why these sorts of efforts to upgrade keep faltering.
3D printing has gotten very cozy with a standard stepper driven machine that runs on an 8-bit micro that’s spoon-fed a toolpath over serial from a more powerful computer. This toolpath is generated by literally slicing a model into layers and figuring out how to build each one individually, with maybe some peephole optimizations added on.
That’s why multi-material stuff for example is still such a kludge.
The standard model formats don’t support multiple regions of color or material well. The slicing software makes it a kludge to integrate them and often doesn’t adequately handle things like switching materials. The serial link and the 8-bit micro are constrained in terms of how flexible and real-time adaptive the command language can be, and the 8-bit micro imposes a low ceiling on how much the printer itself can handle. Then you have all the usual problems about the best way to build the hardware. Should we have multiple extruders? A Y-split bowden tube?
Imagine what would be required for continuously varying CMYWB color prints. Every step of the above process prevents it.
=> The model files can’t store volumetric color data (which could also be used to select materials). The best that can be done is surface color in .OBJ files. Ironically, it was a model format specified by microsoft years ago when they made a half-hearted attempt to integrate 3D printers into windows which actually attempted to solve this problem.
=> The slicers are almost *completely* unprepared from the point of the software architecture to deal with continuously variable color changes throughout a print, especially if you only have surface color to go on. You would need to take that and the geometric volume of the print and determine a 3D map of the color/material throughout the print. Then you need to take your extruder architecture into account while determining a toolpath that can print the object while also determining what the color/material is at each point along the path. This then informs the process of generating extruder control commands along the toolpath. That’s one hell of an overhaul for existing slicers.
=> The huge volume of continuously varying color/material information must then be relayed to the printer, either as a series of commands to the extruder or, if you want to be more extruder architecture agnostic, a series of values for a smarter printer to turn into extruder control commands to make it happen. The only ones I’ve seen who broke from the standard gcode stream to provide a more flexible way to talk to a printer that was extensible was makerbot, with their json-based model representation (which is actually now ironically somewhat open source, thanks to them).
=> This finally brings us to the brains of the printer itself. If you want to move away from an 8-bit micro, you need to do things with the extra power that *really* make it worthwhile for everyone to change. Extra smooth stepping or curves isn’t going to cut it because most people don’t notice or don’t care. The way I see it, one of the best things you could do is start to shift more of the decision making down to the printer so that it can do what’s best for it, rather than have the slicer decide everything and lead the printer by the nose using gcode instructions. We talk to regular printers with postscript, not bitmaps.
=> The extruder architecture and general mechanics of the printer after this are a footnote. Nobody uses servos because they don’t care enough about lost steps. It’s just not a problem worth solving because even if the cost is less you have to uproot everyone to move them. As for extruders, we’ve seen a couple of continuous mixing extruder heads that *could* print CMYBW, as well as some clever ways to swap materials without alignment issues (see bowden Y-splitter) but the supports for them to be practical just don’t exist further up the chain.
Where to begin…
FDM printing’s stagnation is primarily among the low-end hobbyist level stuff where cheapness is the primary selling feature. The RepRap Firmware development is definitely more advanced with the real problems of extrusion being addressed with things like nonlinear extrusion and pressure advance currently included. Delta printers operate at the hard limits of 8 bit CPUs.
The computer driving the printer by sending gcode via USB is the lowest end of 3D printing and is normally abandoned by people who advance beyond printing star wars toys and tugboats due to its inherent unreliability.
You’re right about model files- STL is a lousy way to specify the print form. There are more advanced files that use voxels, etc. to specify color, material, etc., but few printers/slicers can take advantage of them. They are certainly not at the low-end and generally not applicable to FDM printing.
FDM printing was picked up by hobbyists because it is relatively easy/neat/cheap compared to powder bed fusion or one of the other technologies that more readily enables multicolor printing. I doubt that multicolor FDM will ever get beyond the few hard-core folks who are willing to put in the time and effort to make such prints now. FDM just isn’t the right technology for multicolor printing.
In a few years we’ll probably learn exactly how hazardous it is to melt plastic and FDM printing will die out along with the hobbyists who used it. 3D printers will start showing up at swap meets and garage sales and be looked at the way we now view quack medical devices: “can you believe people used to melt plastic in their homes to make crappy toys and breathed the exhaust from these things? What were they thinking?”
No one uses servos because stepper motors are adequate to the task- there’s nothing to be gained by going to more expensive/complex servo drive. Steppers don’t skip steps unless you overdrive the mechanism or the mechanism binds due to poor construction. If the mechanism binds, it’s broken and should be fixed. That said, looking at what has been done to compensate for cheap unflat/unlevel beds (which should be flat and level), someone will probably come along and work out something to compensate for mechanisms that bind and ever crappier printers will be made useable. Servos cost more than steppers and the evolution of the hobby printer is downward, not upward in cost. Expect to see brush-type DC motors, not servos driving low-end hobby machines in the future.
Pardon the newbie question but why is 32 bit better than 8 bit in this context? Does it make the printer print faster or more accurately? What does the 32 bit board do that the 8 bit one can’t?
It helps in how many things can happen at the exact same time, and the math.
An 8bit system tends to burn several dozen clock cycles to accomplish what a 32bit core does in a single op.
Its not that one is better, but rather what type of problem one is trying to solve…
Similarly, a hammer will work with screws, but its more efficient to use nails… ;-)
Better maths calculations, resulting in more precision when translating real world coordinates into stepper position, especially for Delta printers which have a lot of trigonometrics calcs (cos/sin/tan) hence they rely heavily on the FPU included on 32bit µC when it is, and even without, it’s better doing those computation on 32 bits words than on 8 bits words.
Some 8-bit boards are flash-limited and might not be able to support all the features you may wish to add. With regard to speed, for traditional Cartesian printers, it’s usually not an issue. For Delta printers, speed can be an issue, with 8-bit boards barely able to keep up. Newer printers are also pushing boundaries on printing speed, and for this, a 32-bit board is preferred.
Other features, such as ethernet and wifi connectivity also require more cycles and firmware space, though of course you can also add such features by adding an Esp or Pi board.
Someone will correct me if I’m wrong, but it looks like Marlin 8-bit development has been frozen at 1.1.x, and all new development on the 2.0.x branch is 32-bit.
Also, I was recently looking through the Marlin config file. Some of the newer features are very processor intensive. According to bug reports on Marlin’s GitHub, developers seem to be having trouble squeezing these new features into the limited cycle count of 8-bit processors.
Marlin 2.0 is still in development, but does support the Atmega HAL.
1.1.9 is the last version in the line though… new stuff is always risky… so probably the mature code will be the stable choice for awhile. =)
2 simple reasons
1. faster/better mcu allows you to enable more features and less restrictions on firmware development
2. cheaper *compared to ATMega2560 (in fact, the mcu is way cheaper) which gives the board designer more headroom to use better components
I’ll never understand the religious obsession with making AiO boards.
If there’s a newer & better mcu or stepper drivers available then you’re stuck up shit creek without a paddle.
Thus further contributing to planned obsolescence and potentially pollution due to discarded electronics, since whole board would have to be replaced instead of just specific modules.
But I guess that’s partially a symptom of cutting corners regarding short term costs, and the thermal limitations of the stepstick form factor.
The stepstick is a standard pin-out, and plugging in step/dir signal leads to external high-power driver modules is trivial. We can agree going modular is a good long term solution though =)
We built our custom RAMPS style board as we needed a 65A 12v bus for 8-axis club projects.
I guess everyone’s use-case differ.
It is only a problem when your existing board can’t handle the work it was design to do NOT because you are envy of newer chips. Just because you have a more modular system, doesn’t mean you won’t need to throw away/recycle the modules that you swap out.
One thing that this board does better than individual stepper driver module is the cooling.
Having no experience in this area I was wondering how often the stepper driver modules fail.
I hadn’t thought about the upgradability.
Depends on the driver chip, but if you are customizing something it is common for wiring to accidentally disconnect or a circuit fault to occur. I have seen users with solder-ball shorts, broken up conductors, and random motor wiring.
Also, with JST connectors one has to careful they don’t tug free while running on some steppers…. zip ties, strain relief, and glues help. The classic A4988 drivers wold sometimes burn out half the driver if they disconnected while running.
On rare occasions the driver-chips and or current-adjustment resisters also fail, but it was usually related to excessive heat and corrosion. We have used Pololu modules for many years, and once a system is setup it is very reliable. The same module pin-out is available for several driver-chip options including Trinamic.
I can assure you our group didn’t take joy in soldering another 150 pins of headers on every member’s board, but rather we understood it was necessary to provide inexperienced users a maintenance/hack-able/upgrade-able option that doesn’t require a hot-air rework station. I am personally comfortable with both… ;-)
If you are mass producing thousands of something, than the priority shifts away from repair-ability to quality-control. For mass produced items, automated part-placement makes more sense than the added cost of plug modules.
Again, it depends on the end use-case. Trinamic drivers are great for some applications, but can pose a problem for some users confused by what they actually do…. Personally, I recommend prioritizing budgets for better hardware/motors, as the end machines simply produce better results. =)
Because they generally work better and they’re generally better optimized. Shoehorning an MCU to fit a legacy module pinout really limits its options, for example Re-ARM plugged into a RAMPS still leaves you with three less FETs than a conventional Smoothieboard. Stepsticks have been a bad idea from a thermal perspective, especially the pre-Watterott drivers which put the thermal pad facing down and users try putting heat sinks on the plastic side of the package to make up for the bad thermal design. And it’s more parts because of the pins and sockets to mate them, and each of those contacts is a potential failure point. Users can and have ruined boards by plugging in the modules the wrong way. The stepsticks with trim pots is another point where users can ruin their board by accidental shorting or poor adjustment.
One thing that hasn’t been mentioned yet is that using a monolithic design not only simplifies design and makes the unit cheaper, but all aspects of the design–mechanical/electrical/etc.–can be considered at once when creating the solution. For example, the positioning of the chips needing cooling can be optimized for efficient airflow over their heatsinks. It also means that separate cases/software/etc. aren’t needed for different combinations of components. Neither is insignificant.
>Marlin powers the majority of 8-bit desktop 3D printers (even if their owners don’t necessarily realize it) so sticking with it means that users shouldn’t have to change their software configuration or workflow just because they’ve upgraded their controller.
The installation workflow is radically changed and I think is a good reason to try a totally new firmware. I’ve never needed to compile a 32 bit firmware yet, and I intend to avoid it unless I’m actually making custom changes to a firmware. It’s well worth trying a different firmware just to see how other firmwares handle configuration. The way Marlin was even in the 1.1.x days, I ended up going line by line in the config anyways per upgrade because every x.x.x update rearranged things, added things, renamed things. As far as I’m concerned, flashing should only be necessary for upgrades, not to change configuration, and a firmware designed with 32 bit in mind enables that.
I’d love to see an A/B test of overall print time for a standard item to quantify any improvement to give a sense of how much of a print’s timespan is ruminating and translating.
+1
I’ve used A/R, Smoothieboard, and Duet.
A/R just sucks. The driver modules burn up frequently because you can’t easily set the motor current to a known value and the modules can’t dissipate heat. You have to compile firmware for changes, and every time they upgrade the Arduino IDE, it breaks your firmware, so you have to keep obsolete Arduino and plugins operating to ensure you’ll be able to make changes to your firmware configuration. Modifying configuration requires hunting through multiple files to find the stuff you need to edit. I left A/R behind about 5 years ago, so maybe things have improved, but judging by posts on forums, it doesn’t look like it.
SmoothieBoard is pretty good. Drivers are reliable, motor currents are set in config, all configuration is in one config text file. Edit text and reboot. No compiling necessary. Lousy web server, low speed gcode transfer via network port. Version 2 of the board has been under development for years. Use the SD slot on LCD panel and you’re good to go.
Duet is also pretty good, too. Quiet and reliable drivers, motor currents set in config, edit config and reboot. There are many config files like A/R and it can be a little tricky to get configured, but worth the trouble in the end. It has a great web server and has compatible touch screen LCDs. Reasonable gcode upload speeds via the network port. The LCD panel development is always behind the controller board development, so the touchscreen doesn’t provide all the control capability as neatly as the web server. As a result, I have both a computer and the LCD panel. All I want is an SD card slot ferchrissakes.
I don’t see the point in networking 3D printers unless you have a printer farm. You have to go to the machine to change filament, remove a print, clean the bed. Why not just plug in an SD card while you’re there? Since I switched from SmoothieBoard to Duet I miss my SD card slot. I don’t want to have a computer connected to the printer and I don’t really want/need it networked, but Duet forces me to keep a computer (I use an old netbook) connected to the printer. There is a uSD card slot (why uSD and not SD I’ll never understand- there’s room for 10 SD card slots) on the LCD panel, but enclosing the panel makes it very difficult to access the slot/card.
I don’t see the point of octoprint either. I just want to print stuff. I don’t want to have any computer connected to the printer and I don’t want to waste time trying to keep an unnecessary computer working. I design stuff to print on an i7 laptop, where I also do the slicing. I don’t want that computer tied to the printer and why would I want to slice on an RPi? My printer is reliable. I give it the gcode and it prints. I don’t need a bunch of graphs and stats. I don’t need to impress anyone with the ability to remotely start a print using my phone. Give me an SD card slot (not uSD) and I’m happy.
Well when you are trying to use 2-4 printers at once being about to monitor them in another room via Octoprint makes a lot of sense. A Raspi Zero W does the job just fine. I still slice on my main computer and then sending the already sliced file to one of my 4 printers without even having to get up out of my chair plus each one has a webcam so I can monitor them ….. I can even go work in my garage and monitor them from a Tablet or any device that supports a web browser ….
xiaomi home cameras better image quality, better network connectivity, it has time shifted recording, it has good telephone application and it dont need any computer. it’s way to better than webcam solutions in my opinion.
The PanelDue has an SD card slot, have you tried connecting and configuring that to work with Duet? I do agree that PanelDue is very limited, it seems to be the black sheep of the Duet ecosystem, there’s very slim options for control from PanelDue short of setting up macros for each operation you do, or manually cranking out g code.
I find there’s more to operation than just starting a program even if it’s to glance at the progress.
I really don’t know your network situation but I don’t think a hard connection is needed between the computer and the printer. You can either have WiFi on the Duet or hook up Duet Ethernet or Maestro to the LAN which can be accessed through the access point over WiFi. Any way you connect, once you transfer the file and start a print you could disconnect or turn off the computer without penalty.
I have a bunch of small macros set up for access on the Panel Due because I can’t remember all the gcode commands. It works, but it’s not as nice as having dedicated buttons and display areas on the LCD panel.
I have not tried to use the uSD slot on the Panel Due yet- it is in a very inconvenient location the way I have assembled my printer.
I use a netbook connected directly to the Duet Ethernet controller via a network cable. I don’t have a convenient network drop in my basement to actually put the printer on my network. I went from simply plugging an SD card with Smoothie to having both a Panel Due and a computer connected to the Duet board, so it felt like a big step backward in terms of work flow. I don’t think it would be any better with a Duet wifi.
There is already a 32-bit drop in solution that uses the RAMPS controller, the RAMPS -REARM, available from Panucatt (http://www.panucatt.com/Re_ARM_for_RAMPS_p/ra1768.htm). It is for the most part pin compatible (some pins are not available) with old RAMPS setup so it is an easy upgrade path and is compatible with Marlin 2.0 which is still in beta but the Marlin team has implemented most all functions for the re-ARM. It is based on the LPC1768 so it requires Microsoft Visual Code or Atom to compile the firmware, but these IDE’s are readily available and easily setup for this task. I have been using the re-ARM for more than 6 months now. It was a straightforward upgrade of my RAMPS (your old RAMPS simply plugs into the re-ARM) hardware and it prints beautifully.
You can also use the RAMPS 1.7 (in dev) or some other variation that are compatible with the Arduino Due board :)
i smell 199$
no matter what the controller can do, it shouldnt cost more than the printer lol
I decided to go with a PSOC chips from cypress. The ide is free, the board is $10 straight from them and then just add the stepper drivers . The board runs marlin fine and can run grbl as well. It does most of the processing for things like step generation for the drivers in hardware so you don’t have to worry about timing issues. Does quadrature decoding for rotary encoders and switches and hardware debouncing. I chose the chip based on the site:
http://www.buildlog.net/blog/2017/02/psoc-5-port-of-the-grbl-1-1-cnc-controller/
Is there really any improvement by removing my Mega based system and going to 32 bit? Or will I more likely than not fail to even notice a difference ….. Now if you were trying to use a high definition touch screen display then 32 bit make a lot of sense otherwise I don’t really see the need for it on any of my 4 3D printers ,,,,,,
Very good designed 32 bit shield for Arduino due already exists, this one look like a mix of nonsense.
But the list is to long.
You want cheap 3d print shield with heating part included? That means you want take risk of you house burn down. Stop to spread this bad designed cards and informations.
It would be great OTA for firmware updates
So i recently baught a mks robin e3,it hosts a stm32f103 aswell but the clock running on the board is 8MHz, this seems to be limiting me to a max of 64 micro steps with interpolation, I was hopeing to be able to run the drivers at 1/256 with no interpolation the board does it but crashes when things get faster, could i just remove the clock and replace it with say 16Mhz or even if it has a on chip clock just use that to increase board capability and will i need to do confiurations in marlin? like with serial comms and things so that every thing syncs?