[Closed] 32 Bit Electronics  

Re: 32 Bit Electronics

Nigel

Totally agree, but for me it is not the 16-bit aspect but the 16Mhz clock speed.

Although the controller used on the RAMBo has plenty of memory available, even Vojtech mentioned yesterday that features like max end-stops would be pushing it too hard.

I do note that Marlin has been ported to the Raspberry Pi which seems to be a great ready-made option for controller upgrade with its higher speed, 32-bit quad core processor.

Peter

EDIT: link to firmware for Pi etc: https://github.com/Wallacoloo/printipi
NOTE: this can also run OctoPrint at the same time...

Re: 32 Bit Electronics

Maybe Josef and his team could design a new bang up to date board?

(Something 32 or 64 bit, capable of having 4+ extruders/hotends, X, Y, Z (x2) motors, 12/24 volt switch-able input/output, 1 heatbed connector, 6 fan headers (4 for hotend heatsinks, 1 as print cooler, 1 for enclosure fan (optional), Min/Max X, Y, Z end stops, separate probe connector, 512KB+ Memory, 40MHz+ [Maybe even an ARM at 1GHz+], USB, Ethernet, WiFi, SD card).

Still I suppose the existing ones are more economically viable... The Duet does sound good and can go upto 84MHz and supports upto 512KB.

For those wondering there are details of the Duet board here: http://reprap.org/wiki/Duet

and the MCU here: http://www.atmel.com/devices/ATSAM3X8E.aspx

Hmmm just noticed in can even take an expansion board... interesting...

UPDATE
======
There is a new version of the Duet coming very soon, the DuetWiFi: https://www.duet3d.com/index.php?route=common/home#features

Some of it's features are:
Atmel SAM4E8E: 120MHz ARM Cortex-M4 microcontroller with floating point unit, 512Kb flash memory, 128Kb RAM and many peripherals
Super quiet TMC2660 stepper drivers: SPI controlled stepper drivers capable of up to 256 microstepping. Current and microsteps can both be changed on the fly for optimum speed and power efficiency.
Dual extruders: 3 heater/thermistor channels for a heated bed and 2 extruders. 3 PWM controllable and 2 always-on fans. These can be run from either the input voltage, from 5V, or from external power for added flexibility.
High Power rating: Each stepper driver is capable of 2A motor current, with further increases possible after thermal testing. The bed heater channel is specifically designed for high currents.
Dedicated Wifi module: Running on a separate processor, this leaves the main processor free to do precise stepper pulse timing and implement other advanced features.
Flexible: Connect via PC, tablet or smartphone on the same network: there is no need for an app install or internet connectivity. Also connect via USB or serial if desired.
Security: WPA-2 encryption for network security, with further security changes coming soon. The DuetWifi does not need to be connected to the internet - keep it on a local network for added security.
Touch Screen Support: The optional PanelDue controller provides a full colour graphic touch screen controller with virtual keyboard. Also talks G-code for maximum flexibility.
Advanced Calibration Support: Use an optional add-on of DC42’s highly repeatable contactless IR bed probe combined with advanced firmware features for more accurate printer calibration.
Accurate temperature control: Automatic ADC gain calibration for thermistors allows for accurate and repeatable temperature setting. In addition PT100 and Thermocouples are supported through new SPI daughterboards.
Up to 7 extruders: Support for a further 5 stepper drivers and heaters on the expansion header. Firmware support for mixing nozzles and remapping axes to use high power external drivers.

Looks very promising, and it's Open Hardware, Open Source Software, Open for collaboration. It costs just £99 very comparable to the existing RAMBo Mini!

Re: 32 Bit Electronics

The Duet does sound good and can go upto 84MHz and supports upto 512KB.

And that is not sufficient to control the printer, run a web server and other new developments (such as max end stops...), hence my suggestion regarding the Pi.

According to the YouTube video I saw, it was running at 45% processor usage when controlling a delta printer and running octoprint, so an 84MHz processor would simply not be sufficient.

Furthermore, the Pi and other similar boards are future-proof designs, whereby you swap out the controller board when a new one comes along. Any all-in-one board does not have that advantage.

Peter

Re: 32 Bit Electronics

Maybe we are expecting the electronics to do too much... after all they are there to simply make the printer print, not be a self contained complete Computer! As long as there are ways to connect a Pi/PC/phone/tablet/Mac to it then that can handle what individual users want...

I think the new DuetWiFi sounds good 120MHz/32bit/512KB(128KB) should be enough to handle what is needed of it, Up to 7 extruders keeps it future proofed for at least a while 😆 The WiFi/Ethernet/USB means you can connect just about ANYTHING to it for extra control. You can connect to it via any browser as well...

I suppose it comes down to what features the majority of users want... Only a few may want Octoprint support (I don't), others might want Wifi (I do), still others may want touchscreens (not sure)... It depends on what audience Josef et all are aiming for.

RAMBO/RAMBo Mini - basic functionality, simple to use, easy to maintain for Prusa.
Duet Wifi - Total Machine control, complex to use, harder to maintain for Prusa.
RasPi - Total Machine control + Basic 'PC' like features (that could include slicing/webcam/internet), easy to use after high learning curve, complex to maintain for Prusa.

There is also all the costs to consider, R&D, Manufacturing, support, etc...

Re: 32 Bit Electronics

We at Prusa3D are actively investigating a conversion to a 32bit board, but it is currently not a pressing issue to us and our effort is better spent on other tasks as of today. The 8-bit RAMBo is adequate to the tasks it has to perform and there are thousands of units out there, which we are still supporting, therefore a conversion to a 32bit architecture is not justified as of today.

A 32bit conversion would be justified, if there was some better firmware with smoother stepper control and smoother planning. But as of today, all the firmware flavors I am aware of implement the path planning copied from the GRBL project. The only difference I am aware of is the TinyG controller, which achieves significantly smoother moves.

To connect a Prusa3D wirelessly, a Raspberry PI or even the Raspberry PI zero is adequate. To just allow a wireless file exchange, the Toshiba FlashAir SD card will be supported in the upcoming 3.0.6 firmware.

A conversion of a firmware to another architecture is not as simple as it seems. One has to port the hardware abstraction layer, if the firmware has any hardware abstraction layer in its architecture at all. Usually the hardware blocks are very different across various CPU / micro controller chips and it takes a significant effort to port and often completely rewrite significant part of the code for a new architecture.

Another issue is, whether the given CPU even implements the necessary hardware blocks at all. For example, the Broadcom System On Chip of the Raspberry PI does not allow such a precise timing control as the much simpler Atmel of the RAMBo as far as I am known. I would be happy if I am proven wrong and if someone ports the Marlin firmware to Raspberry PI, we may consider porting to Raspberry PI. But there is also an issue with the availability of the Raspberry PI boards. One cannot quite reliably hope that there will be enough R-PI boards available for us to ship our 3D printer kits.

Vojtech

Re: 32 Bit Electronics

if someone ports the Marlin firmware to Raspberry PI

Here you go:

That may not be Marlin, but as you say most bases are from GRBL.

Peter

Re: 32 Bit Electronics

But even on the video, the author comments, that his "firmware" stutters.

> In this video, the machine is printing at 30mm/sec with 1/4 microstepping for each axis and 1/8th microstepping for the extruder. Speeds of 90mm/sec are achieveable using 75% cpu. But the sharp corners in this testprint seem to cause a few missed steps every layer if running above 30mm/sec.

This "firmware" controls the pulses of the steppers from a user space process. That will be neither reliable nor smooth. With Raspberry PI, you would have to either to run the Linux as a service of some real time system on the Broadcom processor, or to offload the stepper motor control to some real time micro controller, possibly something cheaper than what runs the RAMBo board. I would certainly go with the second option, but then we are already there with the OctoPI and Marlin.

Vojtech

Re: 32 Bit Electronics

You should than have asked for someone to "reliably port" Marlin to a Pi...

It's not a Prusa "original" - what do you expect?? 😉

Peter

Re: 32 Bit Electronics

Thanks for the info vojtěch.b3, always nice to hear a developers viewpoint. What about the new DuetWiFi I mentioned? Would it suffer from the same problems as the Pi (being ARM based)?

Re: 32 Bit Electronics

It seems that the cause of problems with a Pi is the operating system and the lack of proper interrupt handling.

Linux as an operating system was never designed for (multiple) interrupt handling by programs written to run under that operating system, whereas Arduino-base programs don't really run under an operating system per se, and all the interrupts are directly available by software written in C/C++ (which is an ideal programming language for "bit-twiddling").

The only problem with languages like C is that they become less portable simply because programmers tend to use machine-reliant code ("bit-twiddling").

So porting to a Pi is very problematic and porting to a Linux-based processor is equally problematic, so the end result, despite the relatively high power is extremely poor performance.

Peter

Re: 32 Bit Electronics

It's not like you can't do it in the Pi -- you can. The problem is really how you want to implement it. After you go through all the contortions, you'll probably wind up back at the original situation, which is "a driver board drives the hard realtime hardware, and the Raspberry Pi handles the soft realtime stuff like interface and network stack, and they talk to each via gcode".

That said, the smaller MCU's in use are running out of time and space to drive all the components (hotend PID, bed PID, LCD, SD card, all the stepper motors, jog dial and debounce, and most importantly -- live mesh bed leveling). I think it's the mesh bed leveling that is breaking the camel's back.

Electrically, these printers are also a huge mess, if not a huge safety hazard.

The components really need to be split up a bit further. The hotend/carriage should have its own PCB with its own microcontroller and power control. That way you offload the hotend PID, fan controls, leveling sensor, and thermistor A/D from the main CPU. Then if you add a wireless transceiver pair like Xbee or nRF51822 or something your main driver board can talk to the hotend wirelessly. That would reduce something like 12 wires going to the hotend/carriage to just 2 -- power and GND. It would also immensely reduce the wiring clutter at the main board side as well.

Same goes for the heated bed, which is already a huge PCB anyways.

And while you're at it, this will allow you to add more safety features locally, like thermal limit switches.

This would put you light years ahead of anything currently cobbled together by other manufacturers.

Re: 32 Bit Electronics

gz1

You may have missed my post where I linked a youtube vid showing a delta running via a Pi. The problems with the poor interrupt handling are evident there.

You may also have missed my post where I mentioned that an all-in-one board is not an ideal solution. With regards to comms between boards, there is no need to complicate matters with wireless, when a pair of comms wires would work more reliably and cost less (the 2.4GHz band is a little overcrowded nowadays).

I get the impression that you and I agree on most things 🙂 ; should we not get together to build a printer?

Peter

Re: 32 Bit Electronics

What about something based around a BeagleBone Black? http://beagleboard.org/

ARM Cortex-A8 32‑Bit RISC Processor 1GHz
Interrupt Controller (up to 128 Interrupt Requests)
Up to Three External DMA Event Inputs that can also be Used as Interrupt Inputs
Integrated 15- to 35-MHz High-Frequency Oscillator Used to Generate a Reference Clock for Various System and Peripheral Clocks
Supports Individual Clock Enable and Disable Control for Subsystems and Peripherals to Facilitate Reduced Power Consumption
Five ADPLLs to Generate System Clocks (MPU Subsystem, DDR Interface, USB and Peripherals [MMC and SD, UART, SPI, I 2 C], L3, L4, Ethernet, GFX SGX530], LCD Pixel Clock)
Real-Time Date (Day-Month-Year-Day of Week) and Time (Hours-Minutes-Seconds) Information
Internal 32.768-kHz Oscillator, RTC Logic and 1.1-V Internal LDO
Independent Power-on-Reset (RTC_PWRONRSTn) Input
Dedicated Input Pin (EXT_WAKEUP) for External Wake Events
Programmable Alarm Can be Used to Generate Internal Interrupts to the PRCM (for Wakeup) or Cortex-A8 (for Event Notification)
Programmable Alarm Can be Used With External Output (PMIC_POWER_EN) to Enable the Power Management IC to Restore Non-RTC Power Domains
Eight 32-Bit General-Purpose Timers
DMTIMER1 is a 1-ms Timer Used for Operating System (OS) Ticks
DMTIMER4–DMTIMER7 are Pinned Out
One Watchdog Timer

£35 - £45

Re: 32 Bit Electronics

PJR,

I saw the delta printer thing, I just have a strongly different perspective on what you're calling interrupt handling.

As an example, if your CPU is "stressing itself" trying to bitbang PWM over GPIO because it doesn't have hardware PWM support, the problem isn't that it can't handle interrupts, the problem is... it doesn't have hardware PWM support.

(Raspberry Pi has 2 PWM channels, only 1 of which is easily accessible. A tiny 8-bit ATmega 32u4 on the other hand has 7 PWM channels.)

As far as comms, you'd be trading a massive congestion of wires for literally a wireless serial port. The main board would see gcode and go, "Hey, this looks like it should go to the hotend/carriage. I'll just forward it and its return values." That's it.

If I can fly a model aircraft a couple hundred feet across an urban neighborhood with a tiny hobby-level TX/RX pair, I'm pretty sure it will be just fine in the confines of a 3d printer.

I think the future will validate this idea. The winner will validate it.

We do seem to share opinions on other stuff for sure.

I am so frustrated right now from having put a divot on my otherwise new, clean PEI sheet because of BUNK FIRMWARE.

Regardless of what processor/board is used, none of it will matter if the firmware written for it is JUST PLAIN CRAZY.

Re: 32 Bit Electronics

I like the idea with Xbee comms, but I also like the same idea without Xbee. That part can be very easily replaced by 3 very thin and flexible wires (GND, TX, RX). Regular servo cable, If we talk in RC modeller way. And it is waaaaay more reliable than any wireless system.
But the idea of all extruder logic dedicated to extruder itself is very inspiring.

Re: 32 Bit Electronics

Just a few more comments as a catch-up

An R/C model is extremely tolerant of dropped packets; not so with a 3D printer.

I haven't looked into the situation, but I guess the Pi Processors themselves have multiple interrupts; they are simply not available to programs written for the Linux platform.

PWM on the Atmel and PIC use interrupts; those same interrupts are also available to programs. PWM is significantly more reliable when using interrupts. However, with a quad-core processor, a single thread could be dedicated to pseudo-interrupt handling using semaphores to other threads.

Only 2 additional wires are necessary for serial comms as the ground and power are already present. But 2 wire serial comms is not the best option for this type of communication, so 3-wire would be more reliable.

And finally:

@gz1: Many of us have divots in our beds (and I am referring to the PEI sheet on the printers...) which may or may not be due to faulty firmware. Please don't keep banging on about it - it's not the worst thing that can happen and is easily rectified. Get in touch with customer support and order a new PEI sheet. I love your input on this forum, and this thread has so far seen a great discussion of future possibilities with a load of different opinions.

@Nigel: Many thanks for kicking off this thread!

Peter

Re: 32 Bit Electronics

Dropped packets don't necessarily mean dropped information.

The chatter with the hotend is very little if the control is localized. "Set this temperature. Turn on the fans. Get probe status." There is plenty of time and space for error correction. With the proliferation of wireless devices like ESP8266, nRF-whatever, Xbee-whatever, RFM22-whatever, EZ430-RF-whatever, CYRF-whatever combined with the inconvenience if not safety hazard of printer wiring as it is handled today, it's hard to imagine how the industry has managed to stifle progress this long.

The usual way the PWM is handled, yes it's a realtime race to get your interrupt serviced before your period is up.

But what happens if you're trying to run something so fast that no interrupt handler can run fast enough to service it?

You could say that Linux, or the Raspberry Pi, can't handle the interrupts. Doesn't have enough interrupts, can't handle them fast enough.

You could also say that Linux or the Raspberry Pi shouldn't be handling the interrupts in the first place.

Speaking of packets and interrupts, Linux networking is typically interrupt driven. However, in cases where you want to go really fast, you disable the interrupts and switch to a polling mode so you can pull packets as fast as you can, and even then, some packets will still get dropped, but the upper layers will handle it.

Re: 32 Bit Electronics

My first involvement with interrupts was programming a Nascom 1 in machine code (direct Hex code) and then with an assembler. Hardware and software interrupts.

A RTOS will be required for the Prusa Mk2 ie not Linux as we know it. A BeagleBone Black may fit the job, but other options are out there.

Re: 32 Bit Electronics

> That said, the smaller MCU's in use are running out of time and space to drive all the components (hotend PID, bed PID, LCD, SD card, all the stepper motors, jog dial and debounce, and most importantly -- live mesh bed leveling). I think it's the mesh bed leveling that is breaking the camel's back.

What is really breaking back of the MCU is the motor control interrupt routine and the path planner routine (jerk and velocity control), not the mesh bed leveling. The mesh bed leveling routine on its own is relatively cheap.

> The components really need to be split up a bit further. The hotend/carriage should have its own PCB with its own microcontroller and power control. That way you offload the hotend PID, fan controls, leveling sensor, and thermistor A/D from the main CPU.

That is certainly a sensible option.

> I am so frustrated right now from having put a divot on my otherwise new, clean PEI sheet because of BUNK FIRMWARE.
> Regardless of what processor/board is used, none of it will matter if the firmware written for it is JUST PLAIN CRAZY.

Would you please be more specific?

Talking about the standards and firmware quality: Prusa3D firmware is based on Marlin Firmware, which is considered to be a standard. But the Marlin firmware is really all but the kitchen sink and I have the feeling that the main focus of the firmware was lost: a reliable smooth control of the print. The "standard" Marlin firmware does not even guarantee, that the machine envelope (maximum velocities and jerks) is not violated. So we applied a "standard" firmware and we discover the bugs in the "standard" firmware along the way and we are putting effort into fixing them, which can be followed from our github checkins on the MK2 branch.

Usually when the printer crashes into the PEI sheet, it is due to

1) a misaligned sensor due to the builder inaccuracies (this shall not be the case for the pre-built machines and it shall be remedied by our novel XY calibration procedure in the upcoming 3.0.6 firmware)

2) broken sensor, broken sensor cable or disconnected sensor. Disconnected sensor shall be revealed by the auto test procedure by the builder. Homing shall be stopped due to the broken sensor / sensor cable in the upcoming 3.0.6 firmware after the first of the 9 points is not homed correctly, minimizing the PEI film damage.

3) some inherited Marlin bug. In very rare cases the Marlin firmware 9 point homing did not move the print head in the XY plane before lowering the print head. This situation was so rare, that we did not discover it in our print farm. This shall be fixed in the 3.0.6 firmware.

4) due to some incorrect user action

You see, we are really putting effort into the firmware to minimize the chances of the PEI film damage. If you experienced another case where the print head crashed into the print bed, please let us know. We really appreciate a constructive feedback as it helps us and our customers to improve our products.

Vojtech