I was thinking BeagleBone Black only because it runs Machinekit/LinuxCNC/EMC. I have a Chinese 3040T CNC and after getting GRBL running on a Arduino Nano working with it I’m working towards getting Grbl-ESP32 and then Machinekit. I have Machinekit/BeagleBoneBlack on a CRAMPS board running one of my Kossel delta 3D printers.
It’s not the smallest or cheapest board but it does have onboard EMMC and the 2 onboard 200MHz micro-controllers are a bonus for realtime use.
But MaslowCNC is an interesting beast in that it’s budget minded while being very capable with a large build platform. So there should probably be a couple of upgrade paths. One which is still in the budget minded realm( rPiZW or ESP32 ) and then one on the higher end like a full realtime Linux based Machinekit on a BeagleBone Black.
Bart Dring is doing great work with the ESP32 and his GRBL port so if that can work he might even be an asset to help since there are small cheap encoder based versions of the MaslowCNC motors he might be interested in.
I was thinking BeagleBone Black only because it runs Machinekit/LinuxCNC/EMC.
we would have to teach linuxcnc to handle DC motor/encoder setups, and then
teach it to handle the maslow kinematics
But MaslowCNC is an interesting beast in that it’s budget minded while being
very capable with a large build platform. So there should probably be a
couple of upgrade paths. One which is still in the budget minded realm( rPiZW
or ESP32 ) and then one on the higher end like a full realtime Linux based
Machinekit on a BeagleBone Black.
the BBB is cheap enough that if it is the right thing for the job, we could
eaasily use it.
Bart Dring is doing great work with the ESP32 and his GRBL port so if that can
work he might even be an asset to help since there are small cheap encoder
based versions of the MaslowCNC motors he might be interested in.
I’ve posted a request for information on any work already done with hangbot kinematics on Machinekit. Also asked about DC motor encoders although I’ve seen information in the Machinekit documentation for encoders. http://www.machinekit.io/docs/man/man9/encoder/
@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?
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.
@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
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
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.
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.
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.
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
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?
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)
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)
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.
