Thoughts on designing a new controller

[dlarue]

@bar @dlang Has it been settled to try and use an esp32(Grbl-esp32) as the
upgrade to the current Arduino platform? ie step up to a wireless GRBL
platform and keep the client(Ground Control) / server(firmware) based design
as opposed to something like an embedded computer(SBC-rPi,BeagleBone, etc)
design?

no, both are being worked on.

The ESP32 version has the advantage that it works with the existing
motors/encoders while the embedded computer version really needs different
encoders. As a result, the ESP32 varient is getting the most attention at the
moment

ok, good to know. As for the motor encoders not working within the Machinekit environment I might take a look at that. I’m not a great coder by any stretch of the imagination by maybe I can hack something together to read those motor encoders.

I have a MaslowCNC hardware kit(version 1) and I also have some smaller motors with similar(if not the same) encoders on them. I also have a couple BeagleBone Blacks and a CRAMPS board which hasn’t been assembled yet. The assembled CRAMPS is running Machinekit on my delta 3D printer.

I know Machinekit/LinuxCNC is a huge step for developers and users alike but
to ease the development I found an open source BiPod design implemented in
Machinekit using encoders(different ones though) which would ease some
development.

Another option is to run Ground Control( it’s Python… ) on the Beaglebone
Black platform with the Arduino firmware ported to Beaglebone PRUs initially.
This leaves Machinekit as an option still and moves porting efforts to the
backend while leaving the front end(Ground Control) consistent for users.

does machinekit/linuxCNC support the PRUs? or is that additional software that
needs to be written and merged upstream

Machinekit supports the PRUs in that it can communicate with the memory shared with the PRUs. I believe the configuration for the Kossel Delta 3D printer and the CRAMPS board uses the PRUs to run the delta motion control kinematics. Charles Steinkuehler is active on the Machinekit google group and designer of the CRAMPS board. Good guy and good engineer and he groks both hardware and software very well. He is the one who put together the Machinekit code for the delta 3D printer(kinematics and all).

I have a Chinese 3040 CNC machine which has a parallel port for control and after getting GRBL running on an Arduino Nano and controlling the 3040CNC with bCNC I was interesting in connecting a BeagleBone Black to it so I could just connect display, keyboard/mouse in the garage instead of tieing up a laptop… Similar in function to what we’re talking about with MaslowCNC. Charles commented so I know he’s still active in the Machinekit forums.

Back to the PRUs, they are still developed for as an embedded device inside the Linux environment. Thankfully C code is now used instead of assembly. It’s been almost 5 years since I dabbled in the Machinekit system so I hope the PRU coding has been made much easier. But I don’t have hands-on experience with that.

[madgrizzle]

Has it been settled to try and use an esp32(Grbl-esp32) as the
upgrade to the current Arduino platform? ie step up to a wireless GRBL
platform and keep the client(Ground Control) / server(firmware) based design
as opposed to something like an embedded computer(SBC-rPi,BeagleBone, etc)
design?

As long as I can, I plan to continue to develop webcontrol. esp32_grbl supports external senders (verified that with the author) so webcontrol will work with it with a little tweaking. I’m not sure I have resources (time and energy) to rebuild webcontrol from scratch to make it into a compact c++ application. Life would be easier if you could run c++ on one core of the esp32 and micropython on the other core… it might be possible but I haven’t found that to be true yet.

[dlang]

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

[dlarue]

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.

[mooselake]

does machinekit/linuxCNC support the PRUs?

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

[dlang]

thanks, I found http://www.machinekit.io/docs/man/man9/hal_pru_generic/

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
relationship.

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
testing)

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

[dlang]

I found https://github.com/mattvenn/machinekit-bipod/blob/master/bipod.hal

[dlang]

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

DC Motor + Stepper FeatherWing Add-on For All Feather Boards

Adafruit DC & Stepper Motor Bonnet for Raspberry Pi

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)

Adafruit DRV8871 DC Motor Driver Breakout Board - 3.6A Max

[mooselake]

The fu is strong with you, young chainwalker

[madgrizzle]

hey 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)

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)

[JWoody18]

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.

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.

Jeff

[slomobile]

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

You would still have to sync some settings (pid values) between the RPI and the motor controller

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.

[madgrizzle]

When you say PID values, are you just talking about the setpoint, or also Proportional, Integral, and Derivative coefficients?

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…

[slomobile]

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.

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.

[bar]

Here is the layout I am leaning towards now:

Or if you want an interactive version: https://maslowcreate.org/run/?200385438

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

[2cents]

Hi there!
You may want to check this out, they are in California and they are a reliable source.
Phoenix Enterprises
https://www.peconnectors.com/female-headers-pcb-1x-row-.100/hws1879/

[blurfl]

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

[bar]

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

@blurfl I sure do! Thanks

Edit:

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

https://www.digikey.com/product-detail/en/sullins-connector-solutions/NPTC151KFXC-RC/S5607-ND/776065

https://www.digikey.com/product-detail/en/samtec-inc/SSM-115-L-SV-TR/SSM-115-L-SV-TR-ND/7858764

[blurfl]

a part number for some 15 place .100" surface mount female headers?

Here are some possibilities…

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

[2cents]

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

https://www.mouser.com/ProductDetail/Harwin/M20-7861546?qs=sGAEpiMZZMs%252BGHln7q6pmzzqnf3%2F1AeIR0hnMc3ILas%3D