Much of the innovation in Prusa’s new MK3 is driven by the new Einsy board with connected Trinamic drivers, powerloss detection and interfaces for a whole bunch of new sensors. It’s still based on the same 8-bit Atmega processor we’ve been using forever, so the firmware needed a ton of custom work to support the new features as well.
The last great 8-bit board? Probably.
https://www.youtube.com/watch?v=RuvaSTg33r4
32-bit MCUs are everywhere these days… Why stick with 8-bit? Especially since a lot of new software had to be written anyway. Are there any good Open Source firmware implementations for 32-bit MCUs? I’ve seen Marlin being ported…
Marin version 2.0 is under development. This will support both 8bit and 32bit MCUs. They are implementing a new HAL which will make new boards implantation much easier and quicker without affecting the core implementation.
It’s going to be released with the Panucatt RE-ARM supported which uses the LPC 7168 chipset. Ray’s cohesion 3D board will follow suite. I’m still hoping it will be with the official release, @raykholo had done an awesome job with his boards.
I think after all the work gone into Marlin 2.0, I’m hoping to see a new Prusa printer with the Cohesion 3D Board and the new Marlin 2.0 driving their printers forward.
Having looked through 32 bit Marlin 2.0, it seems pretty underwhelming. It seems beholden enough to the legacy platform to the point of adding nothing new other than running old cruft on a newer controller.
@denix mature 32bit firmware options:
- RepRapFirmware (ARM M3, M4F)
- Smoothieware (ARM M3)
- Repetier (ARM M3)
- MachineKit (basically any x86 PC or a BeagleBone Black)
There are several more without much “market share” like G2.
Oh, and there’s Marlin4Due (which needs work but is already a thing), without waiting for Marlin 2.0.
@Panayiotis_Savva why on earth would anyone be interested in a port of old, krufty Marlin to an aging, ram-limited, GPIO-limited, non-Arduino 2004-vintage microprocessor, when that processor already has better firmware than Marlin? I mean… who actually wants Marlin on their Smoothie boards? Marlin4Due already has near-zero uptake on an equivalent ARM M3 chip. There’s just no interest when other 32bit firmware are so good.
I’m amazed at your response to be honest. I’ve been working with Marlin for years and know how to get things done with it. There is a plethora of information, tutorials and documentation available for Marlin. Not to mention a huge Development and Support Team to back you up…
Even Prusa is using it (and everyone in this great community with original Prusa printers)
The fact is that even the Raspberry Pi HAL has been implemented, as well as the Teensy HAL.
The firmware has come a long way since 1999, and suggest you try it out before calling it scuff…
With the 32bit microprocessors, double stepping won’t be needed anymore when running capable drivers.
@Panayiotis_Savva Sorry to insult your baby, but I’m still not seeing the point. Really the main value of Marlin in my view – the reason it’s popular – is that it’s hobbyist-legible Arduino code. Anybody can hack on it and recompile. Oh, and it runs on the cheapest controller hardware out there. That’s the two main reasons to use Marlin over other firmware. If you don’t need that, Marlin is a low-performing product of inertia, little else. Anybody who cares much about performance and UI/UX, which includes OEMs like Printrbot, are moving away from it.
Consider the alternatives:
- Repetier is faster than Marlin on the same processor, uses Arduino IDE for hacking, and already has a large installed 32bit base.
- Smoothieware has cleaner code, better end-user experience, doesn’t carry reams of legacy kruft, and already has a large installed base. (The Smoothieboard v2 will be a big step change when it’s out.)
- RepRapFirmware has cleaner code, better end-user experience, doesn’t carry reams of legacy kruft, and has a rapidly growing user base.
If you’re setting up Marlin on higher-cost non-Arduino platforms with mbed or eclipse toolchains or whatever, you’re kind of missing the point of Marlin.
Am I missing something? Maybe 32bit Marlin would be interesting if it were still 2013 and we didn’t already have a raft of really good options.
I think time will tell 
@denix it’s not about 32 bits. They will be eager to go to 32 bits but it’s about porting the software to 32 bits mcu’s which seems a very challenging task. Have a look at Marlin’s github. They (32bits dev group) have massive issues with the IDE and it requires lot’s of skills and knowledge to accomplish this port. For Prusa as a business, to keep momentum and releasing products, it’s wise to bridge that gap with this product despite being out dated processor technology. Same reason why so many people use grbl on 8 bit atmega’s. Porting software is just hard and takes a lot of time/resources that a small company does not have despite the need to rewriting stuff in 8 bits.
I’m hoping they provide the board for sale, as, I’m interested in the new board for a possible upgrade to my current mk2 multimaterial upgrade as just last night I had an issue which resulted in an air print after 3 hrs just at the very end. The only other upgrade I’m interested in is the spring steel (not even the new bed) as mentioned you could just use binder clips to hold it on the bed. Pinda probe would be nice but mine is working fine, as well as the heated portion of the bed. anywho…
It’s a good start for DIY beginners… “Specially when you at Ultra Saving Mode”
@denix 8 bit produces considerably less EMI and RF noise than a 32 bit equivalent. MFGers prefer 8 bit as it’s easier to clear FCC requirements. Plus most of the processing done by cartesian printers is easily handled by 8 bit until you start getting to the higher accelerations and step rates where you get double stepping
@Mike_Kelly_Mike_Make Not sure I buy the EMI argument. The vast majority of EM emissions from a 3D printer come from the stepper drive currents and heater PWM. Stepper drivers in particular have nasty chopping behavior in multiple frequency ranges and tons of energy to radiate due to coil inductance. (Look at 4988 H-bridge switching noise on an o-scope sometime… it’s GROSS.) Those EM sources don’t change with 8bit vs 32bit.
@Mike_Kelly_Mike_Make The MCU step pulsing is going to be a negligible source of noise compared to the motor coils. Step pulsing is a 5v or 3v3 clean square wave voltage signal with minimal energy behind it, at about 1 kHz to 50 kHz, through a few inches of PCB trace next to a ground plane and other traces. Oh, and basically nothing about this changes between 8bit and 32bit unless you also choose to use finer microstepping, which is really a separate decision from the MCU selection. For example, the Smoothieboard and Duet Wifi both use 1/16th stepping, same as most 8bit boards.
In comparison, motor wiring is getting +12/0v/-12v or +24/0v/-24v three-level square wave voltage pushing several amps across four wires several feet long, switched by an H-bridge at about 15 to 100kHz with tons of higher and lower harmonics. And the H-bridge doesn’t always get the MOSFET timing exactly right, so it’s throwing insane voltage spikes on a regular basis. It’s idiotically noisy, to the point where running untwisted motor wiring parallel to thermistor or endstop wiring will routinely cause spurious readings. Twisting the coil pairs should be mandatory for any printer, and a number of printers have required ferrite chokes on the motor wiring to pass FCC testing.
Likewise, the heatbed wiring is getting a +12v/0v or +24v/0v square wave voltage pushing ten amps through what is typically a big spiral coil PCB trace, although thankfully not usually at very high frequency.
@Mike_Kelly_Mike_Make That’s… not quite right in this context. Yes, the sharpness of the falling edge is important, but that’s really more a function of the PCB trace capacitance and GPIO transistor arrangement than clock speed of the MCU. I can’t find any data at all on the GPIO pin slew rates of the Atmega2560 versus LPC176x or SAM3X8E. Do you have a reason for thinking ARM M3 chips have higher output slew rate than AVR chips?
Regardless of the output slew rate, there’s simply no physical way for the step pulse signal to radiate very much energy. It’s a short PCB trace surrounded on three sides by copper. I think your electrical engineers must not be very familiar with printer electronics. They’re obviously ignoring the stepper driver PWM and just thinking about the main low-frequency motor coil stepping waveforms. Stepper driver PWM switching is nearly always much higher frequency than step pulsing. And it has gob-tons of energy and multiple big “antennas” attached. Here’s an o-scope trace (from http://www.engineerination.com/) of output from a DRV8825 showing a downright stupid amount of high-frequency switching going on:
missing/deleted image from Google+
@Mike_Kelly_Mike_Make Sorry Mike, I think you’re either misunderstanding your electrical engineers or they aren’t familiar with the specific class of drivers we usually use in 3D printers. Chopping stepper drivers are NOTORIOUS for generating EMI. (Not quite as bad as sparky brushed DC motors, but still really bad.) It’s not just the switching frequency, it’s also the fact that stepper driver H-bridges have multiple MOSFETs running at different voltage levels changing state simultaneously, which leads to inconsistent timing and nasty inductor kick transients. The switching noise is so bad the stepper driver has to turn off its own current detection for a microsecond or so (“blanking time”) until the transients settle out. Older drivers like the a4988 are particularly brutal.
@Mike_Kelly_Mike_Make There are tons of 32bit processors in printers that have passed FCC certification, including ones with worst-case designs like step pulse signals carried over cables between PCBs (like the FlashForge Dreamer) and it’s simply never been an issue that anyone talks about or does anything about. I’ve never heard of any printer manufacturer worrying about processor clock speed making more noise, and I talk to a lot of printer manufacturers. Including ones who run much faster Linux-capable processors on platforms like the BBB, or even using FPGAs for step pulse generation, and don’t have problems with step pulse EM/RF noise either. So… what printer manufacturers do you think prefer 8bit because it gives them easier FCC compliance? Give me a name of an experienced manufacturer that uses that as a meaningful design decision driver. Or show me a 32bit board design that has to do more to mitigate step pulse noise than is used in 8bit boards.
Whereas stepper driver EMI is a huge problem with widespread awareness among printer control board designers, and manufacturers regularly have to design motor coil noise-reduction measures into the printer to get FCC certs. Heaters, motors, and data lines for LCDs / SD readers are the EMI problems regularly discussed by printer designers.
I just can’t find any data or support for your “8bit makes less EMI/RFI than 32bit” statement. It sounds like the sort of thing an engineer would make up to justify the hardware he wants to use. I can’t prove it’s wrong, but I also can’t find anybody else making that claim anywhere. Noise emission from the MCU IC itself is a holistic design exercise involving semiconductor design and chip layout. Noise emission from the PCB is a holistic design exercise involving the trace layout, ground plane design, circuit capacitance, IC output transistor arrangement, and even firmware settings like controlled slew rate features designed into the chip. (Yes, ARM 32bit chips can control output slew rate for the “fast” functions like data transmit!) In every case, the antenna length or loop area is a critical factor in the amount of EMI, and there just isn’t enough of that in the step pulse signals to move the needle.
I clearly am not knowledgeable enough to refute or argue your points and that I likely misinterpreted the information passed down to me. I also should be wary of saying anything, even as vague as they were, and removed my comments. Once we get to FCC I’ll know more as to what, if any, a 32 bit processor does to our signal. My hope is that you’re correct and that we don’t generate high frequency noise, and we can isolate the noise to the motors and heaters.