Ok, then back to simple and effective again. It’s good to see that the Stock design is still winning on those points. This show’s how good it already is. The simplicity doesn’t let itself get tackled by anything more complicated. 
Still if there is something more advanced that can take things to the next level without breaking the bank that would be a killer feature.
3 Likes
https://neutis.io/ for an other option 
So in fairness i only skim read these posts, but why do we want to change from an arduino board?
I proram these chips for a living, and an 8bit AVR is EASILLY up to the task of running a maslow…
If you want to get some more speed out of it, you would be way better off rewriting the code to not use the arduino libraries as they are often quite bloated and slow (not all of them, there are some great ones) but you get a LOT more freedom from writing the code in plain C.
If you were to port, theres a 5V ARM processor (im not actually sure if the motor driver and encoder etc require 5V I/O or not, but 99% of arms run on 3v3 which is often a problem when converting)
An ARM is MUCH more powerful, but also significantly more complex to setup and use.
I wouldnt mind seeing a nice all in one board with just a USB socket and some motor/encoder connectors and everything else in a nice single purpose made PCB, but i wouldnt go away from the mega just for the sake of it because its way more than capable of doing the job (unless ive missed a post or issue?) and you can get the cheap aliexpress boards if you wanna save a couple bucks
2 Likes
I’ll point out that we are running into problems with some of the calculations
taking too long to complete already, and that’s simple calculation code, not
library calls.
the math for the maslow is pretty ugly, and the fact that we don’t know how to
calculate one direction and have to find it iteritively makes it pretty ugly.
what @dlang said.
There is also directional planning that could be calculated, I.e. going around a sharp corner the machine slows down, but a straight line down would be able to move quicker.
for what it’s worth, we had an attempt to avoid floating point math and found
that it was actually a smidge slower.
so the current processor is marginal for the stock machine, anyone building it
with faster motors (or a lighter sled and larger sprockets) would run into more
trouble.
Gero added the label Assigned (@Ned)
1 Like
Thread revival - Is there a reason the Pi3 GPIO is not a consideration for “Hat/Shield”. I’m looking for cleaner integration. On a Pi we could implement code and controller in 1 place. It could still have a windows / mac client.
Thoughts?
Thank you
The Pi does not do precise timing well, so it is generally not considered for
CNC machine direct control.
However, since we are doing closed loop control and don’t have to do the
super-precise timing of a stepper, it could be a possibility.
with 4 hardware GPIO pins, it could be done.
As for people who are going to worry about responding to encoder pins fast
enough, I expect that the difference between the 8MHz arduino and the 1GHz+
cores of the Pi will make up for the less efficient software
good thought.
David Lang
the more I think about this, the more I like it.
we just need to do some testing to find out how high a rate of encoder pulses it
can handle.
but with the recent generations of quad-core Pis, you could dedinate one core to
track the encoders, one to do the kinematics calculations, one to do the
planning, and still have one to manage a GUI or network
between VNC, X11, and HTTP there are lots of ways to remotely manage the thing,
and touchscreens are commonly available
David Lang
1 Like
It would certainly remove the software restrictions the Arduino carries with it.
1 Like
not to mention those pesky USB issues.
1 Like
I’m not apposed to a sub processor to watchdog the encoders and report back in a more PI friendly way.
My 2cents
Thank you
With a full 12.16V the present PowerControl board sees a pulse edge from a chain motor every 300uS, roughly 3.33kHz. With three motors running concurrently, it would get busier though, as there is no coordination between them. Each PID loop presently checks the cumulative value of its encoder every 10mS, so a sub processor to manage the encoders might be reasonable though adding cost.
One other thing about setting this up as a Pi hat, is the project could become a docker container, making maintenance for the user almost nil. I will try to devote some more time to testing setup of Kivy on Raspbian. For other OS’s we would need to develop a client or as I do now rely on remote desktops. My goal is not to push people to linux but get a much tighter integration of the controller and software.
Thank you
1 Like
LinuxCNC is already ported to the Beaglebone Black, as Machinekit. The BBB has a couple (iirc) high speed low jitter step generation processors, the PRUs that would be a significant advantage over the RPI.
The Maslow’s motors are essentially servos with LinuxCNC supports well. I believe (it’s been a while since I looked) that porting new kinematics into L-CNC is straightforward, and it already has a well developed machine controller with many of the features that the current firmware lacks.
Porting to either device will take some effort; why not use the one that already has great CNC hardware and software? The costs ate pretty close, my minimal Pi configuration (a UniFi controller) ended up being around $70, and both will need a new daughter board. Doesn’t seem like an RPi adds a whole lot in a CNC controller enviornment
1 Like
FWW - I chose the Pi for it’s wide spread availability and support.
Thank you
BBBs are also widely available and supported, better so in the machine controller community. RPis weren’t fairing well there the last time I paid attention. If they were I’d expect they’d dominate the 3D printer market and trounce those pesky just barely adequate Arduinos, which hasn’t happened.
I think you are better informed then me, however - I think these are all options. I own at least 1 of every system discussed. The Pi has a much larger user bas and a much larger list of problems answered, that said it has progressed to the point you need to be able to filter out answers that applied to the Pi1.
Thank you
Can you amplify on this? I think of servos as wanting step/direction control and the Maslow as closed loop control of a brush motor+encoder. I’ve seen a board that accepts step/direction commands and does brush motor+encoder control from that. Could LinuxCNC directly control the Maslow motor+encoders?