RE: 32 Bit Electronics
Getting back to the point, the Pi doesn't have enough I/O lines to directly drive a 3D printer anyway. You'd need something with more I/O lines (and a fast multi-core CPU of course). Dedicate one of the CPUs to the printer and you're set. In theory.
However, that's not the right solution IMHO. A 32-bit embedded CPU with 100+ MHz costs 5€, can't be crashed by a network connection because it doesn't have one in the first place, and requires much fewer engineering resources – not the least because these things have multiple timers and hardware PWM outputs. Also, what do you do when (not if) a Linux kernel breaks your printer (or, worse, randomly messes up 0.01% of your motor stepper commands) for no easily-discovered reason?
The one thing I'd want to improve is the serial protocol. Octoprint, my printer, and the MMU frequently go out of sync because they talk at, but not with, each other. And: please replace the repurposed IR sensor with proper filament movement detection!
RE: 32 Bit Electronics
the Pi doesn't have enough I/O lines to directly drive a 3D printer anyway.
I obviously am not in love with the Pi as a controller, but one could still argue that it's time for Prusa, and RepRap-derived printers in general, to get a better internal interconnect strategy. You can only go so far with a single microcontroller and a billion I/O pins. The big, thick, complicated cable rope that goes into the extruder is especially ugly, and in a perfect world it would be replaced with a couple of power lines, a CAN/I2C/whatever bus, and one or more simple on-extruder controls for the motor, heater, and sensors. Use a native protocol for real, noise-immune flow control, acknowledgement, and error detection, or layer on something like HDLC if there's no native one.
Commands from the central printer controller could be things like "advance filament 1 N steps/millimeters at rate X starting at time tick Y", or "set heater 2 PID temperature to Z degrees".
... or maybe the high current drivers would make the motor or heater electronics too big to stick on an extruder. But at least all of the sensors and accessories could be communicating over one pin or one pair.
Then you can start talking about quick-change extruders with standard connectors.
The one thing I'd want to improve is the serial protocol.
I agree, but I'd argue that if you're going to change that protocol, you should go ahead and fix the physical layer at the same time. Single-ended raw async TTL serial has all kinds of problems, not just with flow control and the like, but with raw speed. At some point that serial link is going to be a serious bottleneck.
The most software-compatible way to do it would be to replace the serial link to from the host to the printer with USB serial emulation... no actual serial line, not even within a single board, but the same software interface. Or you could go all the way to a "native" USB protocol. It does seem as though the host-to-printer interface should be some kind of USB.
I don't know about the link from the printer to the MMU. Maybe USB is too heavy there. I2C or CAN again?
RE: 32 Bit Electronics
@jbash
I agree WRT the wires to the print head. High current drivers are quite small, while they need to be cooled that's easily done by placing them in the airflow of the hot-end fan. I²C has the advantage that everybody and their dog talks it, including all the sensors you could possibly want to add, but it's not particularly immune to noise. CAN is much more resilient.
The link to the MMU is serial and not at all speed critical, but if we add a "3D printer bus" it'd make sense to replace that too.
Unfortunately most computers, including the Raspberry Pi, do not have an I²C interface that can be used here (no clock stretching, no multi-master capability). Thus it'd probably make more sense to do the mid-range interconnect with CAN, and if you want to add a Pi to the mix, well, CAN hats for it do exist, plus reasonably-good kernel drivers. NB, the RepRap Wiki has a page on CANopen that might be usable as a starting point, though that hasn''t been touched lately.
I'd keep the host-to-printer interface (nominally) serial. The controller in the printer can do the pseudo serial protocol in core, so there's no baud rate limit there. Also, we can add the new protocol to old hardware without replacing everything at once.
There already is a proposal for a binary gcode representation though I don't know if anybody actually uses it. Looks like a reasonable approach (we'd need to specify message ack / error recovery, and the structure of messages *from* the printer) if we don't want to restart from scratch.
RE: 32 Bit Electronics
I'm not sure we need this level of complexity in a 3d printer right now. The cable length are short and there are not so many actuators involved. Once you're going the route with multiple controllers, you will need to synchronize everything. This requires more computational power and results in higher costs. Just to have three cables less going to the extruder doesn't really justify this right now. (at least on the "small" size printers)
Often linked posts:
Going small with MMU2
Real Multi Material
My prints on Instagram
RE: 32 Bit Electronics
Getting back to the point, the Pi doesn't have enough I/O lines to directly drive a 3D printer anyway. You'd need something with more I/O lines (and a fast multi-core CPU of course). Dedicate one of the CPUs to the printer and you're set. In theory.
The Pi has more than enough I/O lines (and cores) to drive a MK3S. The Pi has 28 lines available (see here), so:
- 3 - SPI for control of the Trinamic drivers (MCK, MISO, MOSI)
- 2 - SPI selects for 4 Trinamic Steppers (X, Y, Z, Extruder)
- 8 - Step/Dir for 4 steppers
- 1 - Hot end fan
- 1 - Part cooling fan
- 1 - Hot End Thermistor
- 1 - Heat Bed Thermistor
- 1 - Extruder heat
- 1 - Hot bed heat
- 1 - Filament sensor
- 1 - Z sensor
- 1 - AC power loss sensor
- 3 - USART +Reset interface to TFT35 or similar LCD/Touch/SD UI
Total is 25 I/O, leaving 3 I/O free.
So, yes, no multi-extruder support, but enough to drive a stock MK3 with a few to spare. I am not saying this is ideal, but it is certainly possible. It would be interesting to set up the RT Kernel and see whether a Pi can really drive 4 steppers at a the required rate, and whether jitter would be acceptable.
Do any of you have a ballpark for the maximum steps per second per stepper for a ATMEGA 2560 based MK3S running Marlin? I think I have a Raspbian build with the RT Kernel, or I can build one. It would be easy enough to put a simple program together to test this.
RE: 32 Bit Electronics
@mark-l15
It depends on the resolution and the components used. You can start with 400 steps/mm. With pretty slow 40 mm/s, it will be 16.000 steps/second (for each motor). This is nothing fancy high res, just the bare minimum.
Often linked posts:
Going small with MMU2
Real Multi Material
My prints on Instagram
RE: 32 Bit Electronics
@mark-l15
It depends on the resolution and the components used. You can start with 400 steps/mm. With pretty slow 40 mm/s, it will be 16.000 steps/second (for each motor). This is nothing fancy high res, just the bare minimum.
Thanks, Nicolai-r . I did some additional research and found this step rate info at the reprap.org site. Prusa uses 1.8 degree motors and 16mm GT2 pulleys on the MK3. Using 1/16 Microstepping, you get 100 steps/mm. The Reprap site says the best you can do with that setup on Marlin 8 bit is 160mm/sec (0r 80mm/sec @ 1/32), so 16,000 steps/sec or an interrupt rate of 62 uSec. That is the max rate of all steppers combined, not of a single motor.
Once I get the kernel built I will try to simulate one or more step/dir signals on the Pi GPIO. 16,000 steps/sec is an 8-bit equivalent performance goal. I know that high GPIO rates are possible with the Pi as I recall reading a few years back about a Rpi 2B with preempt_RT driving a 4-motor quadcopter with no additional MCU. But I have never worked with interrupts on the BCM2711 so it may take me a while to optimize for the test.
I very cleverly broke my ankle so I am bedridden for the next couple of weeks. Once I'm on my feet I will get this going and report back.
RE: 32 Bit Electronics
What prevents you to control all stepper motors in the same interrupt? I would need to dive into the atmega specs to know for sure but as far as I remember, you can set all registers in the same interrupt and after couple cycles they will be all set. So you should be able to control all motors at the same rate.
BTW: You're looking on X/Y axis only. Here are the default MK3 values
#define DEFAULT_AXIS_STEPS_PER_UNIT {100,100,3200/8,280}
Anyway, looking forward to see some results. Please keep posting whatever progress you might achieve.
Often linked posts:
Going small with MMU2
Real Multi Material
My prints on Instagram
RE: 32 Bit Electronics
@nikolai-r
It's more than three wires, each part also gets its own power and ground.
@mark-l15
You're right, I had printers with physical end stop switches in mind which the Prusa is not. Silly me. Anyway, I'd use its USART for talking to the MMU. If you want an LCD interface, fine, the Pi already has one, use it.
That being said I'd still want to use I²C to talk to the extruder head. If you're concerned about syncing, that's legitimate, you can use separate wires for the extruder stepper. Still way better than the cable tree we have now and would not even require a CPU on the head, just a small board with a couple I²C slaves.
RE: 32 Bit Electronics
What prevents you to control all stepper motors in the same interrupt?
Imagine a 42-degree diagonal. A single interrupt means you'd have to skip one in ten steps on the Y axis (tan(42°) is 0.9). The vibration induced by this would be quite noticeable, even if the difference is small enough to not affect the print otherwise.
The funny part is that, unlike their ancestors, current microcontrollers can do smooth stepping control with DMA-controlled timers so you don't need a high interrupt rate … but at the same time they're fast enough to do it all in interrupt code – thus you don't need to spend a lot of effort writing that fiddly and hard-to-debug DMA code in the first place …
RE: 32 Bit Electronics
Hi folks,
I'm new to forum but have been following this thread. I'm a 20+ year veteran designing both hardware and firmware for realtime embedded control systems - stuff just like a 3d printer with communications, precision mechanical positioning, etc. using stepper motors, linear actuators, servo motors, limit sensors, etc. etc. etc.. A 3d printer IS a classic and perfect realtime embedded control system. Now, if you are not convinced of that then you can stop reading now since what I'm going to describe is completely consistent with that application.
WRT Raspberry Pi, this board is based on a chipset that is designed primarily for low-end compute applications, communications and graphical interface (communicating with CCD/CMOS cameras and controlling LCD's/digital TV). The chipset is optimal (but expensive) for surveillance cameras, standalone low-end personal computers, and as a human interface engine/communications for devices that require moderately complex graphical interfaces with inputs from various sources including keyboards, serial, parallel, USB, ethernet, wifi, etc. It has very limited GPIO capability to add flexibility for unique sensors and outputs but is not targeted or designed for complex and precision real-time control. That's why there are many add-on boards that have real-time embedded control processors for it that add substantial cost and software complexity driving overall system cost up substantially. The Raspberry Pi is a very sub-optimal solution for any sort of moderately complex real-time control. Yes, some will say, "well it's used in such and such and works ok" well, yes you can often shoe horn it in to do some real-time applications but it's expensive and almost always requires additional hardware and complex software to get sufficient precision and numbers of I/O.
There are plenty of great embedded 32 and 64 bit processors that have huge numbers of I/O pins organized into independent on-chip subsystems optimized for every kind of sensor interface and mechanical motion actuator devices. As well these I/O subsystems have hardware support to semi-autonomously do their job using DMA (direct memory access) and interrupts to signal when new data is available or an autonomous operation is complete while there processor is doing the necessary computing to setup the next set of operations. These processors include 32 and 64 bit (and even 128 bit) integer and floating point operations as well as various levels of DSP functionality that enable extremely fast complex vector and math operations. These processors have huge amounts of flash memory and RAM, are amazingly inexpensive (selling at $5-$10 for low volume (1-10) and require very minimal external device support.
Two modern and recent examples are the STM F7 and STM H8 series of embedded processors. The F7 is a high volume mature family running at 218mhz it has superscalar pipeline and DSP capabilities, up to 1mb of program flash, and 1/2 mb of RAM and many tens of GPIOs, along with versions that have built-in LCD controllers as well as USB and ethernet. They a sophisticated internal architecture with multiple internal busses and subsystems to enabling what I wrote earlier. Currently used in many thousands of applications not the least of which are high speed drones which require complex real-time computing with I/O running in parallel. Low cost and perfect for 3d printer applications
The STM H8 family is a newer generation that runs at 480mhz is similar to the F7 and code compatible but 2mb embedded flash andhas a bunch of added performance and functions making high-speed control applications easier to build with less software complexity. There are versions with dual cores and various communications interfaces. There are versions of the H8 that are pin compatible with the F7 for easy design upgrades.
With the availability of such processors it's a simple matter to get a hardware design done. The software porting is the more complex part and if you have to port the software to a new 32 bit processor than it should be done to one with plenty of headroom for future performance and capability improvements. The STM products are just example sever other chip manufacturers have very good competing products. By the way I have no affiliation with STM it's just that their processors are some of the most popular in the 32bit space and I've used quite a few of them in my own designs.
The bottom line of the above is to point out that there are very good 32 bit embedded control processor solutions well optimized for 3d printer control and in the move to 32 bit controllers it would be extremely short sighted to move to a sub-optimal board or processor that is a force fit for the application and without the headroom for future growth.
Ron Curry
InSyte Technologies
RE: 32 Bit Electronics
@rec
Hi Ron - wouldn't disagree with you having been in a similar job type before I retired. Wouldn't be a huge problem to simply replace with something like a Duet3D board. The new one has a ARM Cortex M7 @300Mhz . I fitted a DuetWifi to a Kossel and it runs flawlessly and was an easy conversion.
RE: 32 Bit Electronics
@rec, @stev-10
Yes, you are both right, of course, and in that regard Marlin has existing ports for many 8 and 32 bit MCUs and many predefined board packages. The list includes:
- Atmel AVR (ATMEGA256x, 128x)
- Atmel SAM (ATSAM3X (Due), ATSAMD51)
- NXP LPC1768
- NXP (aka Freescale) MK20DXxx, MK64FXxx (teensy 3.x)
- St Micro (STM32F1, F4, F7)
- ESP32
- Linux (build for testing)
- The IO map for a large number of predefined boards and display controllers such as Einsy RAMBO, MKR, Big Tree, Smoothieboard, etc. are also defined, see boards.h here
The Pi's application processor is obviously not the ideal platform for this use, nor did I propose it as an optimal 3D print solution as there are many of those around already. This is more a proof of concept to see if it could be done at all, and what the tradeoffs might be. It should not be too much work to port Marlin to a preempt_RT enabled version of Raspbian. Many of us are already hosting Octoprint on a Pi, and of course, a Pi is dirt cheap. Wire it up to a HAT containing four Trinamic drivers and a couple of MOSFETS, dedicate one of the four cores to motion interrupt processing, and you're in business -- if it works.
I spent 10 years of my engineering career (retired now) in MCU firmware development on platforms from 8 & 16 bit assembly to C/C++ and Python on 64 bit multicore Linux, in industrial real time motion applications. So I too have been down this road before. After looking at the available data on the BCM2711 - sparse as it is - and the current state of preempt_RT, I suspect interrupt response is going to be inadequate for this application. But not by much, so I'll try it. If I can match the performance of a ATMEGA2560 I'll call it a win.
The idea was not to replace Cortex-M Duet class performance at 240K interrupts/sec with a Raspberry Pi - that's foolishness. But an ATMEGA 2560 @ 16K/sec? Maybe 😀