Group Actions
Engagement
  • Author Author: mayermakes
  • Date Created: Date Created
  • Views 1571 views
  • Likes 8 likes
  • Comments 2 comments
Related
Recommended

Embedded Systems and the future of CNC-like Machines

mayermakes

Very recently I’ve been to Embedded World, a trade show in Nuremberg Germany that is focused on embedded systems (as the name implies).
What does that have to do with my CNC project?
A lot.

I don´t actually need a CNC for producing parts but more for learning about building such systems, as a test bed for weird and wonderful methods of shaping material and controlling that process.

image

So Instead of boring you with a blog post about how I struggle to cut a piece or hardened steel to size or the chores of wiring (again).
I´d like to make a little excursion into the future of CNC control systems.

The old school style to control a CNC machine was to use a stepper driver controller board (basically a Parallel Port to differential STEP/DIR/EN breakout board).
And a dedicated (industrial) PC running a real time operating System dedicated to the task.
The PC is parsing the Gcode and translates it to carefully timed pulses on the parallel port.
Therefore the actual physical performance of these pulses are critical to the accuracy of the machine. There are PCs better or worse doing this.
This system is still widely used in professional applications but also in the hobby space with LinuxCNC and MACH3 as the software suite.

Forward to 2010 and Simple MCU based G-code parsers like GRBL, MARLIN and others have taken over the hobby and lower end Professional scene.

They still involve a separate PC but its now communicating over Serial (USB) and does not have any real time tasks anymore. All time critical pulses are generated by the MCU.
These Parsers can be implemented on a simple 8-bit ATMega 328P (GRBL) and slowly moved on wards to 32-Bit platforms like STM32 and recently ESP32.

So why change a working system? Having a dedicated MCU doing its work happily alongside a PC with a fancy interactive GUI seems quite nice and efficient.

With the advent of affordable 32/64-Bit SOCs with multiple cores optimized for different types of tasks (OS, real time, AI, Number crunching etc.) there is the chance to unify and integrate it all into a dedicated affordable system without the quirks of Serial transmission and random lockup issues.

SOC integration is not trivial and routing DDR3/4 RAM is a can of worms most of us might not want to open. We are basically moving in complexity from wiring up a self sufficient MCU (with integrated Flash,RAM and IO controllers) to designing a PC motherboard from scratch.

Pretty scary stuff...until you learn about System on Module , System in Package and all the other names that are basically describing the same thing.
A computer with all its needed Components on a little module that can be soldered or plugged into another piece of hardware.
The Raspberry Pi Compute module is maybe the most widely known of these devices.
Technically the Pocketbeagle is a breakout board for a System in Package by TI just as Single board Computers can be seen as integrateable modules.

A lot of the new offerings on the SOM market I have seen at Embedded World are sporting multiple cores dedicated to tasks in the industrial sector including machine control.

I’m quite sure the next generation of 3d printer controllers might use a Supercharged SOC just running the same Software we use today with new fancy features, but I see a different future another generation down and maybe sooner for machines Like Pick and Place devices or CNC mills.

A SOM running Linux on 1Ghz+ ARM Cores with the control software for the user interface (for example OpenPNP) and running Marlin on another dedicated Realtime ARM Core is not far away, basically a matter of porting the software. While consuming 5-10W.
And currently such a board might be not much more expensive than current high end offerings like the DUET3 whos predecessor is currently used in my CNC machine.

If I get the chance, I might actually try at least to integrate some low end SOM into my CNC machine maybe with a very basic GRBL port. Or I just let it control the Duet2 currently built in.
I can´t get a hold of a Rasperry pi 4 atm anyway, so why not try something new?

I’m putting my biggest hopes for the return of dedicated fully integrated devices in RISC-V and in the OSM (open standard module form factor) presented by multiple Vendors and manufactures at the trade show, including Avnet embedded, who I think are a big link in the supply chain, making these modules more relevant to the average Engineer and Maker than ever before.
https://embedded.avnet.com/product/msc-osm-mf-imx8mini/

I really hope this style of SOM makes its way into the regular parts catalogue of distributors like Farnell. A few years from now maybe we use and buy them casually like we now do with microcontrollers.

So am I announcing, that I might picot my project towards using a SOM for the controls? Maybe.
Let me know your thoughts if its worth the huge workload that comes with it.

The advantages of integrating all the brains into a single entity that is exchangeable and upgradeable in the final product is pretty cool for long term usage of such machines, but is it even relevant to consumers/Enthusiasts? Wouldn’t they just buy a new shiny machine anyway after a while?
Maybe, but people also like to tinker and upgrade their machines.


This blog is a part of Clem's CNC Control Project.  Click the Previous button to jump to the previous blog in the series. 

Parents

  • There's an example of this called Machinekit, there is a version that runs on BeagleBone Black. However the devil is in the detail and in this case all is not rosy, because actually implementing it is full of hurdles for anyone who wants to DIY it. There is a small industry around it, with people selling hardware and selling Machinekit support as I understand. 

    I gave it a shot and was astonished at the mess that it is. There's no good documentation about how the BeagleBone Black should be interfaced, and some of the builds do not even use real-time capabilities in Linux, for anyone unwilling to pay for support I guess! Also, the real-time engine inside the BBB (known as PRU) is supposed to be used, but (you guessed it), that's not necessarily supported or configured and there's little documentation on it.

    It is possible to use a Pi or otherwise, but personally I'd be sceptical unless I was sure the developers had gone to some effort to use real-time capabilities and it was reasonably stable, because the last thing one wants is for the software to hang for a little bit while motors are spinning. The hardware should be very stable too.

Comment

  • There's an example of this called Machinekit, there is a version that runs on BeagleBone Black. However the devil is in the detail and in this case all is not rosy, because actually implementing it is full of hurdles for anyone who wants to DIY it. There is a small industry around it, with people selling hardware and selling Machinekit support as I understand. 

    I gave it a shot and was astonished at the mess that it is. There's no good documentation about how the BeagleBone Black should be interfaced, and some of the builds do not even use real-time capabilities in Linux, for anyone unwilling to pay for support I guess! Also, the real-time engine inside the BBB (known as PRU) is supposed to be used, but (you guessed it), that's not necessarily supported or configured and there's little documentation on it.

    It is possible to use a Pi or otherwise, but personally I'd be sceptical unless I was sure the developers had gone to some effort to use real-time capabilities and it was reasonably stable, because the last thing one wants is for the software to hang for a little bit while motors are spinning. The hardware should be very stable too.

Children