Continuing on the quest to find the electronics to drive my new still-building 3D

Continuing on the quest to find the electronics to drive my new still-building 3D printer. Started with the question of using a Raspberry Pi 3.

After too much reading, my head wants to explode. :slight_smile:

My prior exploration of using a Pi 3 for low-level operations:

Seems the above was not needed. Again, I am a software guy who has not directly driven hardware for a couple of decades. What is common in current hardware was not my concern.

First, seems we can buy boards to stack onto a Pi that control stepper motors over the I2C interface, with relatively high level operations that take us away from “hard” real-time. Examples include:

Adafruit DC & Stepper Motor HAT for Raspberry Pi


Each of the above controls two steppers, and costs ~$20-30. To do XYZ and one extruder, I need two boards. If I want a second extruder, and perhaps fan control, then I need a third board. Right.

Frankly, I will likely just buy a stack of the above Adafruit boards. Though that would limit(?) to 12V motors and fans. Maybe not enough power?

Also, a three-board stack on-top of a Pi is a bit clunky. From the online tutorials, I get the impression I could build the needed function on a single board (with chips offering fairly high-level service). Right. Mentioned prior I am a software guy. Not really wanting to cook my own hardware.

Second, there are the BeagleBone boards - an attempt by TI unseat the Raspberry Pi, apparently. The cost per “cape” to control steppers seems to be about the same.

The BeagleBone boards have less CPU and memory compared to a Pi 3. Might be sufficient, or might not. Not convinced as yet.

Third, there is the wildcard. There are adapter boards to use Arduino “shields” with a Raspberry Pi.

Raspberry Pi to Arduino Shields Connection Bridge

Raspberry Pi to Arduino/Genuino Shield Bridge.

Which might be used with:

SilentStepStick TMC2100 5V Stepper Motor Driver

The cost looks to be about a wash. The above shield looks able to drive motors at 24V (or higher). The software … and this point the rabbit-hole becomes deep. Not sure how much trouble is there.

This part is not fun. :slight_smile:

Look into the Replicape for the Beaglebone Black. The BBB is a better choice for motion control because of its coprocessor that handles real time processes while the main arm processor handles OS level tasks.

I’ve used the Raspi to run steppers using a few different approaches and have been very let down by it each time, but I’ve been happy with my Replicape.

Just some suggestions.

Direct control of stepper drivers using the Pi’s gpio outputs is chattery, produces annoying resonance even when standing still, and because of the uneven rate of step generation results not infrequently in lost steps.

I wouldn’t really recommend it for even single axis control (like an SLA printer) and would recommend it even less for a multiaxis printer.

@Stephen_Baird You are assuming userspace program, as that is all the prior examples.

Keep in mind I have a long history of writing software to get bare-metal performance out of hardware. The Raspberry Pi 3 is a pretty ferocious bit of hardware. If you read my prior post (referenced above), note that I am not staying in userspace. Note one of the comments about timed DMA. There is a lot of headroom.

So … pretty good chance we could do jitter-free low-level pulse generation on GPIO with a Pi. But … we are not going to go there.

Seems the common peripheral boards talk I2C and offer higher level operations. While I was under the initial impression we needed low-level control for the hardware driving stepper motors … seems that is not the case.

there are some very good boards out there - if you are not happy with the software you can always roll your own. but there isnt much point to start from 0. as a software developer you should be used to the advantage of using existing frameworks and libraries :slight_smile: i would start with a duet to be honest but also stm has some nice printer board.

You seem to have gone from the noble idea of trying to reduce chip count by removing the microcontroller (ie arduino) from the equation only to propose replacing it with even more complexity and cost of those pi-hats with their ‘dedicated PWM controllers’ which are likely just smaller microcontrollers.

Why not instead look to use an existing and cheap controller board like a RAMPS+arduino, which are good at the job of hardware control, but work to migrate the higher level control functionality out of the arduinos software and into a controlling Pi, this way you get to work on that higher level functionality, without having to reinvent the wheel

And what about using pyboard and pyCnc ( with 4 pololus drivers?
I’ve tried to build myself a small 2axis controller with raspberry and motor shield but no way to get the two motors to work properly together.
Now I’m using the pyboard (with micropython) and it’s working very well. My project drives 2 steppers and 1 servo together.

@David_Sherwood Preston wants to use an RPi for the whole shebang. Which is a great goal but there are challenges that he needs to evaluate for himself rather than listening to conventional wisdom :slight_smile:

@Preston_Bannister ​​
I like that you are obviously a guy who thinks about the whole thing instead of reducing a printer functionality to just a few components.
However, I get more and more the impression that you will end up running in circles and you’ll never reach the point where you get a printer that comes close to simple printers.
And believe me, this will disappoint you sooner or later and then your motivation will go down because nothing really works. Even though you spend hundreds of hours.

Maybe it’s a good idea to try finishing your printer with mostly known things. As soon as it delivers reasonable results you can start your own “big” things.
But trust me,even if you try to build a printer from skretch with available knowledge you will encounter more then enough problems you have to solve.

But this is the important track! Because on this way youll probably drop a lot of your initial ideas and do something else instead.
You should collect some experience first before our start to change the world and the relativity therory at the same time.

And trust at least some of the guys that you ask. There are thousands of people working since more than 10 years on this topic and they can’t be all totally stupid.
And there are also “software guys with a lot of experience” :wink:

And if you really want to give something back to the open source community spend some of your time as an experienced software developer in one of the firmware projects. Or maybe one of the slicer projects. They would be really happy to get support and at the same time you’ll get even more knowledge about the real big problems.

Don’t get me wrong,I don’t say that you should stop your “out of box” thinking. But if you’ve just started with this topic it’s maybe not the most motivating approach for you to start at the end of the topic. From a long term perspective at least :wink:

@Stephanie_A Thanks for the links.

I do not (yet) have enough context to compare stepper driver boards. As there is a nice review from @Thomas_Sanladerer , figured the SilentStepStick drivers were a good starting point.

Also, Stephanie you are an evil person. Did I mention that I am a software guy? Hacking the Linux kernel, locking down CPUs and re-routing interrupts does not bother me. The notion of using a soldering iron makes me nervous. :slight_smile:

And you sent a link to a prototyping board…

@Ryan_Carlyle Well, almost. :slight_smile:

I like the headroom we get with the Pi 3 - 4GB and quad CPUs (plus everything else) is very nice. Using mainstream stuff (in hardware or software) is usually a good bet, as there are usually more options and better support for add-ons.

I assumed finding the appropriate peripheral would be more straight-forward than has proved to be the case. So … have to re-evaluate.

The BeagleBoards are nice, but I wish they had more headroom. Yeh, a 1Ghz ARM CPU and a half gig of memory might be enough. If not enough, then later I am lashing a Pi to a BeagleBoard. Possible. Not desirable.

(There is the ~$270 X-15 … er, no.)

So I am left weighing the risk/effort levels for each approach.

Guess I need to make clear, I am planning ahead. My first project is this slightly unconventional 3D printer. My second project is smarter software to make prints faster. I need processing headroom to use the first result for the second.

The short-term pragmatic answer would be to buy a pile of the Adafruit boards. The ideal answer would be to build a custom board (nope, not me, nope, nope!). The better pragmatic answer might be to use mainstream shields like Pololu or SilentStepStick, and use an existing connection bridge.

So … there is a rabbit-hole visit to see how weird things get. :slight_smile:

@Preston_Bannister The RPi-to-Arduino adapter option sounds really promising if you want to drive stuff directly with the RPi, assuming you can use a RAMPS board. They’re cheap as chips. Not sure how all the GPIO would wire up though – haven’t looked at it.

Marlin runs on 8 KB of ram. Smoothieware runs on 64 KB. You sure you need gigs?

@Sven_Eric_Nielsen Your concerns are entirely valid. :slight_smile:

I have spent my working life at small companies and startups. I am accustomed to working with very high levels of risk. Very few of my projects have failed.

The last project I did was operating at a very high level of risk. I delivered a proof of concept in exactly the time promised. Got a small group built around me, and we delivered a product on time and with exactly the promised function. All while operating at a very high level of risk. Saved about a billion dollars of business. Presented at an OpenStack conference. Then got fired. (The social dynamics of large companies are … weird.)

I like new/challenging things. You will find me listed as an early days contributor to CVS, Apache Tomcat, and Mortbay Jetty (and maybe others).

Learning to factor risk is an acquired skill.

It would be very easy to take on too much, and stall out. I am asking that question pretty much continuously. :slight_smile:

While building my 3D printer, it would be easy to spin on “this bit could be better”, but I move on when good enough, and put notions for improvement into my backlog. Making good progress so far.

And … now to the question, what is the risk with a bridge to shields?

@Ryan_Carlyle Sorry, need to ask a clarifying question:

What is a RAMPS board?

I gather that this is a board that takes weak signals from the CPU, and generates the robust voltages and currents needed to drive a stepper motor. Have not yet found a description of what is needed to interface (and still looking) in more specific terms.

@Preston_Bannister …dude, really? You need to learn what the status quo is before you try to make something better.
It’s an old, obsolete, but still very popular shield for Arduino to run the motors, fans, heaters, etc. Probably the most-used 3D printer controller option to date. (There have also been a ton of Mightyboards but those are also EOL.) Check the schematics.

@Ryan_Carlyle Heh. Again, software guy here.

Yeh, I had already read the page you referenced. Tells me how to build the hardware (not my interest), but not so much what that looks like from the point of view of software.

As you are the guy writing a book on building 3D printers, there is a question you might want to visit.

I know that I need something to convert the feeble signals from the CPU into the robust voltages and currents needed to drive stepper motors. I have reached the point where I need to know something about the alternatives, and whatever might be best practice.

If there is a reference that summarizes the present choices, I have not yet found it … and it might not exist. Still looking.

I just realised you had said something “smarter software to make prints faster” I think you will find that cpu speed has almost nothing to do with print speed, even an 8-bit arduino can run the printer faster than is practical, and the orders of magnitude faster smoothieware boards can improve the quality of the curves and the smoothness of finish but they wont make it print any faster.
its comes down to a matter of physics you see, there is only so fast you can accelerate and decelerate the mass of the printhead without wobbling and maintaining accuracy. the mass of those heaters, extruders, cooling fans etc. have quite a bit of inertia.
then there is the physics of squeezing hot plastic out of a small hole, of how it flows, and how it sticks, the rate it cools, and so on, faster often means lower quality results, and there is a sweet spot which unless your printer is of a bad design/build quality, is somewhere below the maximum speed your controller board can already achieve.

tl:dr: its just not as simple as cpu and ram, no amount of software can improve some of the fundamental limits of the technology

Stepper controllers and mosfets. It’s basic hardware interfacing, you cannot do it through software. To interface you need to know how to read datasheets and how to configure the hardware. For a project like yours you absolutely must know how the hardware is connected. For reading temperature values you must know how the sensor is attached. For driving stepper motors you must know how the drivers are attached. the simplest hardware is those that I linked earlier, if you can’t figure out how to connect those then you’re going to have a very hard time doing anything. Even with a shield that has an Arduino you need the Arduino to know what pins are connected where. Real world interfacing is vastly different than creating widgets, you need to know about the physical device and how it works.

3d printers have a steep learning curve if you want to develop. You need to know software, hardware, physics, cad, cam, materials and their properties. The only one people don’t have a good handle on yet is fluid Dynamics.

@Preston_Bannister stepper driving uses a dedicated IC containing a MOSFET H-bridge. The MCU sends step/direction pulses straight to the driver IC and the driver handles everything else. This is covered in great detail in my book but it’s not out yet :slight_smile: This might help: