Maslow Home Maslow Community Garden Newsletter

Thoughts on designing a new controller

is it using the PRUs to control steppers? or to support encoders?

The 3D printer stuff uses steppers and stepper drivers.

I have not looked at the code for the BiPod museum piece. It uses encoders and not sure if the PRUs are used for that or not.

Yes, it’s LinuxCNC ported to the beaglebone black and definitely uses the PRUs for step generation. Iirc there was talk of and possibly ports of machinekit to other hardware but I wasn’t interested or followed any of those, but if it’s BBB you want you get PRU support. Giggle machinekit bbb pru for more info. On my phone or I’d invoke the fu and link

thanks, I found

this has PWM output and encoder input (as well as stepper output), there isn’t a
servo output, but I’m not sure we could use one without having to put the entire
kinematics/PID functionality into the PRU (and I don’t know if it could do all
of that) since the motor motion and sled motion do not have a linear

but this looks like it could work to test the assumption that the timing is not
that critical for the PID loop and support existing motor/encoders (but needing
a different motor board or at least remoting the board with a maze of wires for

you mentioned that there was something resembling the maslow kinematics in
machinekit somewhere?

I found

a couple things that popped up in my inbox from adafruit

they have a couple motor controller boards that you just talk i2c to and they
generate the PWM on the board to control the h-bridges (limited to 1.2A, so not
suitable for the maslow directly, but an idea of what can be done and how you
can build a 2 motor system that can easily be expanded to 4 motors or more)

same thing in two different form factors

and a breakout board with a motor controller that we may be able to use, up to
3.6A @48v using a DRV8871 chip (current limiting, thermal shutdown)

The fu is strong with you, young chainwalker


That goes back to my suggestion of isolating motor control from the microcontroller that’s running ‘grbl’. If you just leave it to the motor controller to accept pid inputs and report error, then you eliminate all the real-time requirements needed for the ‘grbl’ part and therefore can run on something like an RPI.

You would still have to sync some settings (pid values) between the RPI and the motor controller, but it would allow you to reuse work that’s already done (web control). Rather than rewriting grbl into webcontrol, you could run webcontrol (python) and a de-motorized version of grbl (c++) on the same RPI since it can handle multitasking and all the real-time components of grbl were shifted to the motor controller. Eventually you might be able to evolve the entire operation onto the motor controller if you use a powerful enough microprocessor for it (i.e., like a large memory esp32)

1 Like

I wonder if this is what the Yetitools SmartBench is doing. They are quite open about using the Pi for the UI and controller but they also reference grbl in some of their videos.


Could you expand on that a little? When you say PID values, are you just talking about the setpoint, or also Proportional, Integral, and Derivative coefficients? It just struck me that for most machines PID coefficients are constant because the basic machine response does not change with position. But Maslow has different optimal PID coefficients at each position on the board.
Does existing code actually go to the trouble of calculating and updating these values at every position?
If so, that is really cool!
If not, is that feasible? It would be difficult to map out the optimal values to start with.
They would vary slightly with individual machines, but a general map should be good enough given a specific motor/controller/machine aspect ratio. The benefit would be much more linear appearing response from the point of view of higher motion planning algorithms, thus less error accumulation, more compatibility with generic machine controllers.

After thinking about my idea for a while, I don’t really know the true value of it since you can get the entire grbl running on the microprocessor easier than you can get it running on a RPI.

Regardless, I was suggesting sending pidsetpoints to instruct the motor controller where to go as well as sending the PID coefficients as setting so the motor controller could be updated. I don’t think for traditional maslow designs that the PID coefficients change depending upon where you are. Working on a four motor design with the rope self contained on the sled, I saw that it might be necessary to do just that because the circumference of the spool that held the rope changed over time as the rope intentionally wrapped on itself. but thats another story…

Ironic. The affects of wrap layers are highly predictable and depend only on one cable length. Optimal PID coefficients (on Maslow, not in general) are constantly in flux and have many variables. It took the later to prompt the former.

Here is the layout I am leaning towards now:

Or if you want an interactive version: :wink:

The Bill Of Materials works out to:

Which seems pretty reasonable to me.

Can anyone find a part number for some 15 place .100" surface mount female headers? I can’t find anything but maybe by digikey fu is just off today :cry:


Hi there!
You may want to check this out, they are in California and they are a reliable source.
Phoenix Enterprises

1 Like

Looks good! Is that ‘DRV7783’ in the BOM meant to be ‘DRV8873’?

1 Like

@2cents Do you know if they make a surface mount version?

@blurfl I sure do! Thanks


I was able to find some from DigiKey, but nothing in stock. Here’s what they have:

1 Like

Here are some possibilities…

Edit - this limits the list to include ‘in stock’ and ‘active’, a much shorter list…

1 Like

Sorry I missed the “surface mount part” : p
Check this at Mouser

1 Like

Nice finds guys! Thanks! Those are exactly what we need. Awesome work.

1 Like

So the ports are X, XX, Y,YY & Z?

Thank you