I dabble with LinuxCNC and drive step & dir via a parallel port. The image from LinuxCNC has a realtime thread process in it - and it is strongly recommended to not apply Ubuntu updates as they might undermine the RT thread. There are latency tests that come with the image one should run to determine the fastest reliable stepping speed the computer can handle.
Here’s the irony: Faster multi-core systems suck. Seems older systems with fewer cores actually perform the latency test better than newer fast one. My guess is that newer systems have a boat load of unpredictible IRQs that mess with the thread’s ability to stay in lock step with the outside world.
The questions are: is there a Pi version of Linux with RTT support? does the Pi hardware keep the IRQs to a sane level?
@Ryan_Carlyle BeagleG is an entirely independent implementation, one of the first that used the PRU of the Beaglebone to create fast and accurate stepmotor pulses; it is used by various people on their CNC machines and engravers and specialized medical hardware, but it is somewhat beside mainstream so not used widely yet as far as I can tell. It doesn’t have code yet for heating PIDs (as mostly used for CNC machines), so might need some work for a 3D printer (Disclaimer: I wrote BeagleG, so you should check for yourself).
@Ryan_Carlyle There is no need to precompute the entire pulse stream. There is only a need for the soft-real-time processes to compute the stream, as-needed, and a buffer between soft and hard real-time large enough to absorb variations in “soft” scheduling.
For a dedicated device, this is not a hard problem.
As to “everyone uses” … yes, this argument I have before, and believe I understand the reasons behind, and in this specific case.
I have a long pattern of ignoring the “everyone” case, and winning.
Rather a lot.
The Raspberry Pi 3 needs a dumb board that takes GPIO pins and drives at least four (preferably five) stepper motors. I would like not to run a mess of wires. I would very much like to not write to an API specific to a board that might not be around tomorrow.
Step, dir, enable for each stepper driver. There are spi enabled stepper drivers, but can be complicated to work with. By far the common ones use step, dir, enable.
You need a rtos, it’s gotta be consistent or you’ll get bad prints - why design something new if it can’t compete with the existing.
When dealing with the real world you will always need custom hardware, whether it’s made by you or someone else.
For 3d printers you don’t even need a board to put everything on. A bunch of jumper wires and you’re good. This is how many people prototype. When you start looking into a microcontroller to handle the timing your costs and complexity goes up, might as well buy a regular 3d printer controller.
You also gotta think the same with using a rpi, is it going to be around for long, is the gpio going to change. Microcontrollers have lifespans of at least 10-15 years, often much longer. Gp-cpu is 3-5 years. Linux kernels change, but hardcoded firmware and robust hardware last lifetimes.
@Stephanie_A Are you saying I need three GPIO pins for each stepper motor? No one else has offered this observation.
There are enough Raspberry Pis around to ensure that something compatible will be around long after the current crop of parasite boards are no longer obtainable.
If the same software works, whatever hardware works is acceptable to the end user. Put differently, software is more permanent than hardware.
In the long term, no one cares if the hardware is different, as long as it works with the existing software.
As said elsewhere you need 3 output lines per stepper driver, the timing on those isnt so critical other than smoothness of motion, but you also need PWM outputs to drive heaters and fans, and those do need very precise timings. You also need a bunch of A2D convertors to read in the thermister values for temperature control.
By the time you have built the interface board that carrys all of the step-sticks, the MOSFET drivers for PWM, and the bias resistors for the temperature sensors its a relatively trivial couple of extra dollars to throw on an ATMega or other microcontroller chip to handle all of that hard realtime for you, and those chips have hardware modules to generate those accurate timings for you.
You can do it, but the results will probably be unsatisfactory. The rpi running linux just doesn’t have the timing precision to do it well. The beaglebone supposedly has dedicated hardware for this type of thing, but it’s more expensive.
Alternately if you don’t want to drive the Arduino over serial, you can use spi between it and the rpi for more of a “single integrated device” feel rather than a computer-plus-peripherial. You’d have to write some code, but less code than you would for your own gcode runner for the pi.
@Preston_Bannister For stepper drivers using pulse train inputs, you must have STEP and DIR pins but you SHOULD have an ENABLE pin as well. That way the printer can turn off the steppers when not in use, for things like manual repositioning and filament loading and the like. It’s a pain in the rear to have to turn the entire printer off just to move something by hand. Doable though.
You also WANT to have an analog Vref line controlled by the MCU so software can set motor current. Typically a digipot voltage divider is controlled by the MCU via SPI or similar. Not all boards do this, but most nice ones do.
There’s tons more stuff to worry about that we’re not getting into. A full-featured 3d printer board uses something like 50-60 GPIOs.
@Ryan_Carlyle As a guess, a single GPIO pin could be used to ENABLE all the XYZ steppers. Similarly a single pin could ENABLE all the extruders. Might be missing a use-case.
Going to need inputs for the three XYZ limit switches, I assume, at the very least. Could use GPIO pins for that as well.
Yes, my first exercise was to count GPIO pins, to see if enough.
Note that the while the signals to the steppers need to be fast and precise, the ENABLE outputs and sensor inputs are not remotely as time-critical. If there is an existing cheap gadget that could serve, and connect via I2C, USB (or rubber bands…) to the Pi, that might be an option. (Remember I am a software guy. Not especially familiar with the current crop of widgets.)
But … so far, I think there are enough GPIO pins.
Getting to the point where I need to read up on the funky little boards to drive stepper motors.
" The controller is written in highly optimized C utilizing every clever feature of the AVR-chips to achieve precise timing and asynchronous operation. It is able to maintain up to 30kHz of stable, jitter free control pulses. "
Some (most?) of the recommended boards are using grbl.
@Preston_Bannister I for one, hope that you work this out. The idea that we need additional processors to keep up with timing that is 1/1000 the clock speed has always bothered me.
I hope you can work out the software and timing to where all anyone needs is a rpi and the drivers.
Well, after walking through the exercise of how to drive GPIO pins at high rate … this might be completely unnecessary. Seems using I2C between boards is somewhat common to pass higher level operations. But there are a mess of alternatives…
What are you hoping to improve on again? The core uC IC on a Duet is $6 & change USD in bulk, under $8 in single quantities and it can run ten axes. I think it’s worth trying that platform anyways.
@Jeff_DeMaagd We might perhaps have a different point of view.
I am a software guy with an excessive amount of experience. I bet on small computers (and GUIs) as interesting back in the late 1970s. (One of my college friends built a small computer around an Intel 8008 - about 1976.)
There were lessons learned along the way. There was a time when the concerns of hardware were dominant (pre-1980). The usual assumption before was that rewriting all the software for new hardware was completely acceptable.
That changed. In the present, in the small computer market (that now includes anything non-simple with a CPU), when you introduce new hardware, you have to make it compatible with existing software. Software is dominant, and has been for decades.
Which means we have in present a crop of hardware engineers that missed the lesson.
In a Raspberry Pi we have a ~$35 board running about a billion dollars worth of software. If a new board requires rewriting that software, a moment of reflection is needed.
If your CPU is not running Linux, and not able to use well-tested drivers for the hardware, you likely have crap drivers.
The crop of niche boards tend to have crap USB, SD, ethernet, wireless … etc. That is not going to change. It is extremely unlikely the drivers for those boards will ever match what is in Linux.
Do I want cheap hardware with crappy software? Nope.
