I can’t help but think that 8 bits is all we need to send data for any motion control that we might need for a 3D printer. 6 bits for step/dir, 1 bit to select between two sets of stepper motors to control and 1 bit to select an alternative use for the other 7 bits. If just 1 set of motors then there are 2 bits to select different modes. An i2c or spi module that does motion control could be added onto a cheaper board with not enough controls easily. That could make an add on set of 3 stepper controls as cheap as $12 or an add on set of 6 stepper controls as cheap as about $20. I am just making a guess on the prices based on component costs and some finished product costs. What do you folk think?
Check out the Klipper firmware. It’s essentially using 8-bit platforms like the beaglebone uses the PRUs. I’m of the mindset that certain microcontrollers would be better tasked to handle individual component pieces and then communicate between each set of discreet chips.
Temp measurement, PID tuning, extrusion can be handled by a single super-cheap controller, and motor control/timing/calculation can be done by a motion control board.
I’d rather buy multiple $2 8-bit chips, than buy a single $40 32-bit or 64-bit chip in order to handle everything.
If you have two modes controlled by one bit and you use the other bits for either step or direction according to the mode, you would have the ability to control 7 stepper motors on one board, but the board would cost a little more. Of course, not much more because those are cheap chips. 3% of the bytes sent would be direction commands and 97% would be step commands. The only problem with that setup is that you would need to have one added chip to hold the bits. That is unless you sent 16 bit packets received by this chip. https://www.adafruit.com/product/732
Just 8 bits would be covered by this chip. https://www.adafruit.com/product/593
Oh yeah. I think that first one can be used in a mode that handles two ports of 8 bits each.
Not that it matches you intent of your post…but I currently use Ramps,i2c, and marlin to control a daughterboard for 5 extruders and could actully be as many as you like. The I2c is feed into an ardunio pro mini on the daughter board, which takes care of controling the extruders. It ended up being a very easy solution to what at first glace was a complex problem.
@NathanielStenzel I’m not sure we’re all talking the same language here when it comes to number of bits… when most of us talk about 8bit vs 32bit, we’re referring to the silicon architecture in the MCU processor. To simplify things a bit, 8bit processors need more clock cycles to do math operations on larger numbers, while 32bit processors can do math on large numbers much more efficiently. When you’re doing tens of thousands of floating point calculations per second, needing a tenth or hundredth as many clock cycles per math op makes a huge difference to processor load.
It’s also a shorthand way to refer to processor generations. The “8bit” processors we use are various models of the Atmega AVR series, which dates back to the late 1990s and was intended for use in things like coffee makers and car alarms, not realtime motion control. They only run around 10-20 MHz clock speeds. It was a small miracle of programming brilliance in GRBL that made it possible to do realtime motion control for CNC/3DP with AVR chips. In comparison, the “32bit” processors we use are all ARM chips designed in the 2000s specifically for embedded hardware applications like this, and run around 80-200 MHz clock speeds.
Protocols like I2C and SPI send serial data over 1-4 wires and the bit size of the data packets doesn’t really matter at the application level.
8bit chips often have MORE usable input/output ports than 32bit chips, are more robust against overvoltage, are easier to control at a hardware level for fancy tricks, etc. But 32bit chips are better for performance otherwise.
So, the difference between 8bit and 32bit isn’t really a matter of addressable bit count, it’s how fast the processor can churn through all the complex math we have to do in a timely manner to run 4 motors in sync with sub-millisecond timing precision.
As far as separating work across different chips, we can TOTALLY do that. There are lots of different models, here’s just a few that people have explored at various times:
- Desktop computer does all the computation work and sends step/dir commands to drivers using a parallel port card (Mach3)
- Desktop computer (or RasPi) processes the file into step pulse commands and sends the pulse train data to a cheap 8bit MCU for pulse timing (Klipper)
- Desktop computer generates step counts and the 8bit MCU does acceleration math and pulse timing (Sailfish)
- Desktop computer generates gcode paths and the 8bit or 32bit MCU converts that to step counts, does acceleration math, and pulse timing (Marlin, Smoothieware, RRF, Repetier)
- Single board computer uses its main processor to generate gcode paths and do acceleration math, then uses a secondary processor (PRU) to do pulse timing (Redeem, MachineKit)
- Desktop computer generates gcode paths, 8bit MCU does acceleration math and sends trajectory commands to intelligent drivers, intelligent drivers internally generate pulse timing (nothing released to my knowledge but some folks have worked on it)
Then there’s stuff with FPGAs, servos, blah blah it’s all possible.
@Matt_Barth extruder count is another thing that I imagine you could use the setup for but you would probably need a more complex setup like what you did due to the temperature controls. That is unless the temperature was kept as stable as possible and controlled by a knob and only on/off signals sent to the i2c controlled board.
@Ryan_Carlyle I am not concerned with the number of bits that the processor can handle right now. I am just hoping for a more modular set of options in 3D printing and other areas needing motion control with a limited amount of fiddling and wiring needed. Nice follow up though. I am interested in using whatever you want to do the processing and having the data sent to this setup. Ideally, we should have as many options as possible, including using an old Android phone and an app to send data to the board. Of course, measures would need to be taken to avoid the app updating mid print.
I don’t understand the benefit of going through all this effort. Costs are mentioned, but it’s not like microcontroller chips are terribly expensive.
@Jeff_DeMaagd when you add up an ARM M4F, ESP8266, and a bunch of 2660s like you have on a Duet WiFi + Duex5 rig, you start to hit board cost floors based on simple component selection that a lot of people would like to improve. It’s not a bad idea to look at alternate architectures to see if something might be better.
Another benefit of a nice and modular approach is that you can make more of a module since it can be used as a part of many combos. Making in bulk cuts costs. In the case of a module like this, you can also reuse the module after the microcontroller chip gets too old for your tastes.
I still don’t get what 8 bits vs 32 bits has to do with it. As previously mentioned, the bits usually refers to for how much data can be processed in one clock cycle. I don’t understand what’s that got to do with how motors et.c. are connected.
I get the feeling I’m missing something. Are you refering to the SPI bandwidth? Care to explain?
@Johan_Jakobsson data transfer requirements is 8 bits for the control of 3 stepper motors. It is about simple stepper motor control addons. The focus is not about processing.
@Johan_Jakobsson I think Nathaniel is imagining a ribbon cable / parallel wiring setup, which makes the number of lines matter. Some expansion boards already use that. If it’s SPI or i2c of course it doesn’t matter because it’s serial
Roughly ground wire, logic level voltage wire, motor power voltage (used to power all motors) wire, i2c wire. That is just 4 wires if i2c unless you need multiple wires to pass enough current. A little more for SPI.
Oh. And that is assuming you even need the logic level voltage and motor level voltage to be different or separate (due to electric noise).
How would that differ from using an arduino which are dirt cheap with an external driver board?
@Johan_Jakobsson the only external stepper driver boards that I could find online in the last 10 minutes was for a Single stepper motor. I am talking about something to support 3+ stepper motors. If done with 16 bit data packets, it could possibly support all of the motion and temperature controls via i2c communication or maybe USB. The data processing would be separate.