The Raspberry Pi in general (and the Zero W model in particular) are wonderful pieces of hardware, but they’re not entirely plug-and-play when it comes to embedded applications. The user is on the hook for things like providing a regulated power source, an OS, and being mindful of proper shutdown and ESD precautions. Still, the capabilities make it worth considering and [Alpha le ciel] has a project to make implementation easier with the Raspberry Pi Zero W Stepper Motor Module, which is itself part of a larger project plan to make the Pi Zero W into a robust building block for robotic and CNC applications.
[Alpha le ciel] is building this stepper motor module as the first of many Raspberry Pi hats meant to provide the Raspi with the hardware for robotics applications. This module, in particular, features two A4988 stepper motor drivers, a connector for a power supply or battery providing 7-20V, and a buck converter to bring that power down to the 5V needed by the Pi itself. All the relevant pins are broken out onto the Pi’s GPIO header, making this module the simplest way possible to add a pair of motors to a Pi. What does that mean? Printers or self-balancing robots, really whatever you want.
A stepper driver that conforms to the footprint of the Pi Zero is a good start, and the larger concept of creating additional modules is a worthy entry to the Hackaday Prize.
The trouble with RPI is the uSD card. Commercial temp range. Oh, and lets not forget RPI got so cheap that they dont provide locking uSD doors anymore. So far to people think they are good to use everywhere, when the only place they should be used in on a desk. Something for all the RPI lovers to consider. Name one cell phone that uses a uSD card for the OS. There is a reason for this.
Tinycore Linux runs from ram. PiCore
Nooks use an SD card for the OS, and they kind of count because they run android.
If you’re pouring molten lead through your electronics cabinet you probably have bigger concerns.
I doubt anyone is considering this for high end industrial usage.
You’ve obviously not heard of the Pi Compute Module.
Chemical cap under the driver ? That’s a bad idea the MTBF will drop really fast.
Explain your reasoning, that makes no sense. The cap isn’t thermally bonded to the driver package.
The driver will generate heat and the cap is right under where there is no airflow…
When you want to increase the MTBF of your chemical capacitor you need to keep them cool.
Heat that is radiated away from the TOP side of the module. And there’s an airgap underneath it. If the cap is getting above ambient temps then something else is wrong.
It only makes no sense if one wasn’t paying attention in 9th-grade general-science class, where it was pointed out that the rate of a chemical reaction doubles for every 10˚ C rise in temperature.
Except for this annoying, but universally true fact, it makes perfect sense.
Sure, but how does that heat get to the capacitor? It’s got a significant airgap between it and the driver, which forms an extremely good thermal break. Not to mention that those drivers themselves aren’t intended to run hot; if the heatsinks are too hot to touch you need to either turn down the current limit or add forced air cooling.
First I’m pretty sure it’s a QFN or a HTSSOP so in fact the heat is mainly evacuated through the PCB so by the bottom (Sorry for all those module putting a HS on top…. it should be on an open screen area under the thermal pad…) and secondly it’ll be warmer than on the side in the airflow…
I’m stopping here because I think we reach the dead end of the discussion :D
Got the same setup in the first Ultimaker, wasn’t really impacting the overal MTBF, the push on stepper drivers with limited cooling are much more of an issue.
How do you know ?
I’ll quote Panasonic without spending more time in complete equation for the capacitor MTBF but you can easily find them if needed. Let’s just look at one of their presentation sheet:
https://eu.industrial.panasonic.com/sites/default/pidseu/files/downloads/files/panasonic_polymer_combi_en_blanko_1.pdf
Page 4 you have a rough estimation: -10°C => 2x longerlifetime etc….
There are two parameters killing those capacitor: Current ripple and Temperature. I know it because I did the calculation at work for a PSU and because of temeprature in the enclosure we had to change the capacitor serie or we would have been at a hilarious 2k hours MTBF….
Sorry I could have quoted wikipedia !
https://en.wikipedia.org/wiki/Aluminum_electrolytic_capacitor#Reliability,_lifetime_and_failure_modes
Is it possible to check if raspigcd works with Your design? I don’t have Pi Zero right now at hand, but I know the software works on Raspberry Pi 2 and 3. ( https://github.com/pantadeusz/raspigcd )
Any RPi is completely useless for CNC and any other applications where some sort of realtime required. Because of that totally closed proprietary GPU who have real control over RPi. (Why does everybody forget about that unpleasant fact speaking about “openness” of RPi? ) This thing is much worse for realtime, than infamous Intel ME. So, RPi is not a solution. Go for BBB, or even Allwinner stuff, if you think about CNC’s.
Yes, RPi could be used to somehow slowly rotate some stepper motor driven thing where timings is not important at all, say, a table of 3D scanner or wheel of a toy, but that’s definitely have nothing common with CNC.
Forgive my ignorance, what does a GPU have to do with CNC and controls. Won’t all the other SoC like BBB and Allwinner have to deal with Linux scheduling?
When I was trying to remove the schelting issues, it is possible to remove 99%, the one i couldn’t stop was DRAM refresh, once every 100-500ms
Don’t some versions of the BBB have realtime cores seperate from the linux stuff?
All of them are based on the same SoC, and all have two PRUs.
RPi GPU periodically rudely stops CPU and do something on it own (nobody knows what specifically, but at least DRAM refresh is well-known unavoidable issue). Since OS runs on CPU, there are no way to make it realtime, independent of sheduling in OS.
This.
This project is flawed at the core. As main processor module it won’t work really well, and as extension module, it’s expensive and difficult to get 100% right. The PiZero is hard to source, and expensive for the task. Want a wireless motor module, build one on top of an ESP32. It got a dual core for a fraction of the money of a pi. So you can use 1 core for the step generation, and the other for WiFi handling.
I do not agree – there is working project that uses direct GPIO access to drive stepsticks. Checkout https://hackaday.com/2018/05/15/direct-cnc-control-with-the-raspberry-pi/, and how it works: https://www.youtube.com/watch?v=Nr__NRT2n3w
Try this on something more accurate and fast, and you will be disappointed. You could even just connect single stepper with stepstick and drive it to rotate. Connect oscilloscope to windings and you will see lags. You could even hear impurities in that winding waveform.
I never said that this approach is feasible for super fast CNC machines. I wouldn’t expect machine that moves 5m/s to use Raspberry Pi. According to my initial experiments, the accuracy is +/- 50 microseconds that were always compensated on next tick with slower tick, so probably the limit of this solution is 60 microsecond step.
https://github.com/pantadeusz/raspigcd/issues/19
“…The user is on the hook for…being mindful of proper shutdown…”
From the standpoint of power turn-off, the Raspberry Pi was poorly designed and could not be shut down without potentially corrupting the SD-card main data store…since the very first day of its inception, Eben Upton has successfully managed to dance all around this subject, without ever correcting the design.
The mystery is not that he gets away with this, but is–why do we still expect that all other electronic devices we buy can be turned off by simply flipping a switch, or ‘clicking’ a mouse twice?
Errr, you are aware that you can boot the Pi3 via both the network or USB connection to an external HDD/SDD. Also there are any number of HAT’s that allow for graceful shutdown, RTC shutdown, restart, scripting, UPS functionality etc..?
Errr, you are aware that your suggestions are totally irrelevant and out of place when it comes to the design-in of a device that is supposed to be inexpensive and simple enough for use and design by an eight-year-old?
Errr, you are aware of the fact that it is absolutely rational to expect that Eben Upton would have fixed a basic engineering-design flaw which has existed in the Raspberry Pi since day one? …And that one should not have to pay for a solution to a problem which was created by, and refuses to be fixed by the Raspberry Pi organization?
Err, If I’d be talking to you or answering a question of yours your response might be relevant. Care to try again..?
The matter at hand I referenced was a discussion around the use, abuse and issues with SD cards and the Pi’s power down process with response about the multiple manners in which it can be handled.
Yours is a rather whiney diatribe about your personal gripe about Pi, something that it appears very, very, very few people other than you are concerned about.
Suggestion, if you don’t like the platform, its design and use cases, don’t user it.
I don’t user it.
“…When I was trying to remove the schelting scheduling] issues, it is possible to remove 99%, the one i couldn’t stop was DRAM refresh, once every 100-500ms…”
“…RPi GPU periodically rudely stops CPU and do something on it own (nobody knows what specifically, but at least DRAM refresh is well-known unavoidable issue)…”
My hat is off to you folks–I am in the middle of a real-time design, and was (am) totally unaware of this DRAM-refresh issue. if someone could provide info on where I can find good, quantitative, and descriptive information on this issue, I will be deeply appreciative. Many thanks in advance…