element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Open Source Hardware
  • Technologies
  • More
Open Source Hardware
Forum CNC Interface Board discussion
  • Blog
  • Forum
  • Documents
  • Events
  • Polls
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Open Source Hardware requires membership for participation - click to join
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • Replies 35 replies
  • Subscribers 306 subscribers
  • Views 5686 views
  • Users 0 members are here
  • linuxcnc
  • engraver
  • cnc
  • bbb
  • machinekit
  • BeagleBone Black
Related

CNC Interface Board discussion

shabaz
shabaz over 5 years ago

This is a thread to discuss ideas for controlling low-cost hardware (machines), for the purposes of cutting or engraving for example. It was created due to the interest in ralphjy project to assemble such a device.

There are several ways to do this, typically the 'brains' are a normal desktop or laptop PC, or a single board computer (SBC), and then there is some interface board, that then ultimately connects via high-power drivers, to the motors. There are some other bits of functionality too, like feedback (e.g. limit switches) for detecting end stops.

 

In terms of motors, in industry servomotors will be used, but for home use stepper motors are a lot more popular due to lower cost. For controlling the tool, a 'spindle motor' may be a brushless motor, or alternatively a brushed permanent magnet DC motor (i.e. BLDC or PMDC motor respectively).

 

The PC connection to the interface board can typically be a parallel interface, or USB. When using a SBC then its on-board general-purpose input/output (GPIO) can be used.

 

The BeagleBone Black (BBB) is worth considering I think, since it has been the first popular Linux product to be integrated into machines, providing functionality for 3D printers and small CNC machines. Commercial manufacturing products have been launched with the BeagleBone inside, such as the PocketCNC. There are also third party add-on boards that act as interface boards (and some that integrate motor drivers too). The BBB is old now, but there is a BeagleBone-AI that could in future be used as an upgrade.

 

Partly the reason the BBB has been useful is because it contains some programmable real-time units (PRU) internally, and they can override some GPIO pins, for direct control without needing to go through the Linux system. So, the Linux system can push code to execute on the PRU, and the PRU will control the pins. This means high speeds, and no unexpected delays or jitter, since the PRUs are simpler devices that do not run an operating system that could have a task preempted.

 

To control the interface cards, PCs have a wider choice of software, and popular choices are Mach 3 and LinuxCNC. For the BBB, the software all the boards seem to use is called Machinekit, which is a fork of LinuxCNC.

 

Using it for BBB is not documented well unfortunately. When I first started looking a while back, it was hard to tell which information works, and which information is old. I wanted to automate a simple XY table I'd bought.

However, there is a fairly recent blog article with useful pointers.  It too discusses that information is spread out.

 

It would be nice to develop hardware (or to at least consider it first), and any software or configurations, documented, that would allow low-cost control of machines, and to bound it a little, to only consider home-grade machines using stepper motors, not servomotors. I think there is value in a new open source design, to collect up the wisdom of the various CNC users here, so we can all have low-cost home robots to make things for us!

After some initial thinking, these sketches were a couple of ideas: They are based around the thought that the BBB could be a plug-on daughter card on a larger interface board, that uses something like RJ45-style connectors (because it would be nice to use off-the-shelf cables where possible, to reduce wiring effort, otherwise there are a lot of wires to connect).

image

 

image

After some further discussions with balearicdynamics, it was suggested that scenario 1 could be more practical since it can handle more motors (low power and high power). I too like that idea, since it is one less board to make.

Edge connectors or some other connection location could still be left on the board, for those who do want to have a custom board for add-ons (e.g. to control a 3D printer instead, where they may need outputs for say a heater).

 

More input to any of this, including the practicality of it all, and board design (physical as well as functionality), and connector choices, is welcome. Meanwhile, I've been looking at the existing boards that are supported by Machinekit, to see what pins they use of the BBB, and why. I'll have to install Machinekit to better understand it. So far, I've looked at boards (or Machinekit configs) called CRAMPS, Replicape, and BeBoPr-Bridge and all use different pin mappings. I need to figure out which of these configs are using the PRU, and if so, which pins to allocate for that. I like the CRAMPS pin mapping so far, because it avoids eMMC and HDMI clashes (the BBB has these brought out to its connectors, and some interface boards tend to use these, which rules out using eMMC or HDMI as a result).

 

The pin mappings are in text files, but not easy to compare, so I've put them in a spreadsheet, I'll attach that as soon as it is complete.

The pin mapping text files are: CRAMPS.hal,  replicape.hal, BeBoPr-Bridge.hal  (I'll look at a few more too, and put them in the spreadsheet).

The mappings are numbers like 817, which means header P8 on the BBB, pin number 17.

 

EDIT: I'd hoped to daisy-chain the supplies, but looking at the user docs of a random one, it recommends against this practice:

image

So, the in/out connectors may not be a good idea, and a single power connector on each motor driver could be preferred.

I'm still looking for a suitable connector, but thinking it may as well be another RJ45-style, since I cannot think of another high power cheap alternative. Ethernet will carry lots of current safely, if wires are paralleled. There is the risk of accidentally plugging it into the wrong socket, but they could be color coded.

  • Sign in to reply
  • Cancel

Top Replies

  • Jan Cumps
    Jan Cumps over 5 years ago +7
    shabaz wrote: ... some programmable real-time units (PRU) internally, and they can override some GPIO pins, for direct control without needing to go through the Linux system. So, the Linux system can push…
  • Jan Cumps
    Jan Cumps over 5 years ago in reply to genebren +6
    ... another good reason to use a proper stepper driver is that it generates stepper friendly currents. A half bridge design, controlled by a pulse signal, will try (and succeed) to run the motor with square…
  • balearicdynamics
    balearicdynamics over 5 years ago in reply to shabaz +5
    Good idea of opening a separate thread. Enrico
  • clem57
    clem57 over 5 years ago

    Here is a rather old discussion, but may still be appropriate to this project. What do you think shabaz?

    Clem

    • Cancel
    • Vote Up +3 Vote Down
    • Sign in to reply
    • Cancel
  • Jan Cumps
    Jan Cumps over 5 years ago in reply to shabaz

    I'm running the latest headless Debian (with fresh latest kernel upgrade), and it's flagging itself as PREEMPT

     

    image

     

    edit: probably not the PREEMPT RT you're looking for ...

    • Cancel
    • Vote Up +3 Vote Down
    • Sign in to reply
    • Cancel
  • clem57
    clem57 over 5 years ago in reply to Jan Cumps

    For anyone wondering:

    A preemptive kernel allows a process to be preempted while it is running in kernel mode. A nonpreemptive kernel does not allow a process running in kernel mode to be preempted; a kernel-mode process will run until it exits kernel mode, blocks, or voluntarily yields control of the CPU.

    I wanted to confirm what I thought it may be...

    • Cancel
    • Vote Up +3 Vote Down
    • Sign in to reply
    • Cancel
  • Jan Cumps
    Jan Cumps over 5 years ago in reply to Jan Cumps

    Two links on the build + installation of MachineKit for BB.

    https://github.com/rubienr/bbb-linuxcnc-config

    https://machinekoder.com/machinekit-debian-stretch-beaglebone-black/ (includes instructions to add PREEMPT RT)

     

    It includes building part of the code on BB, another part (where the BB doesn't have enough swap space) on another Linux with the BB's file system mounted. I think coffee is needed in huge quantities ...

    • Cancel
    • Vote Up +3 Vote Down
    • Sign in to reply
    • Cancel
  • shabaz
    shabaz over 5 years ago in reply to Jan Cumps

    Hi Jan,

     

    I too suspected the default kernel is PREEMPT RT based on uname -a as you say, but just to be sure, I installed a more recent kernel patch including PREEMPT RT, but the performance results from the test tool were not noticeably different. Both give values in the ballpark of 400 usec (still, that's better than what I'm getting on a virtual machine on x86, with no PREEMPT RT, where it went to 1700 usec. I don't have a non-VM x86 linux installed anywhere, but I compared with a Pi 3 with a default raspbian, uname -a reporting Linux raspberrypi 4.14.98-v7+ #1200 SMP, which gave a max value of 783 usec).

     

    The machinekoder website instructions use PREEMPT RT, but as I understand, Xenomai should give far better results, so I wasn't keen to follow those instructions any more : ( the website owner charges for consultancy, I guess that's when the decent real-time patches get applied.

     

    I checked with the beagleboard mailer, it turns out there is a machinekit specific Linux image, it just wasn't linked anywhere, so I've updated the elinux bbb page with the detail, and downloaded it. About to try to install it.. (I think it does use Xenomai).

     

    I also tried building a kernel, although the BBB booted up, there was no networks : ( just console access. So, as another thing to follow up on (in case the machinekit specific Linux image doesn't work), I've raised that on the mailer too.

    • Cancel
    • Vote Up +3 Vote Down
    • Sign in to reply
    • Cancel
  • shabaz
    shabaz over 5 years ago in reply to Jan Cumps

    Good idea with the coffee hehe : ).. done way too much typing in a Linux shell for the weekend!

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • Cancel
  • shabaz
    shabaz over 5 years ago in reply to clem57

    Hi Clem,

     

    One day I'll read up on the specifics in these Linux RT kernel variants : ) I don't know much (anything) about them.

    But from general RTOS techniques, it's likely to do with things like how long processes are allowed to run for, and when they can run. In any OS, sometimes you can 'hint' to the kernel, which tasks/processes are important to you, so it can schedule them accordingly. It gets messy because since there are many shared things (like storage), so if a disk unexpectedly takes longer to read a file (maybe it is fragmented), then it's difficult for the OS to know, should it wait for completion, or meanwhile should it let another process do it's thing? Just the act of switching from one task/process to another takes time.

    In a similar vein, the OS might not know, that a high priority task is actually waiting on something from a low priority task (e.g. waiting on a file to be written with instructions). If the high priority thing is given all the CPU cycles, the low priority one will never complete : )

    so it will try to never totally starve low-priority stuff either.

    A 'normal' Linux (excluding some older stuff like uClinux) is preemptive (i.e. it will switch out processes when it feels like it to a degree) but the algorithm that decides on what tasks should run when, becomes critical for controlling machinery.

    Also, part of the software fun is to do things like place content in memory, so that it can be read quicker. Oracle (amongst other) has made billions out of specialist databases that do such techniques, for fast data storage/access.

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • Cancel
  • shabaz
    shabaz over 5 years ago

    Final update for the day; it turns out there is a pre-built Xenomai kernel, so no need to try to build it from scratch. I added it to my BBB, but after it boots, it hangs! (perhaps 20 seconds after it the login prompt - I can log in during that time and use it). I cannot tell what is causing it (I cannot find a pattern to it, from the log files so far). In any case, on a hunch, I tried a normal BBB (well, a BBB-Industrial), rather than the BBB-Wireless. Then it worked : )

    To test the kernel, I need to install some user-space Xenomai stuff, and then run a test program. That's for another day!

    There is still the option of trying the pre-built Linux Machinekit image too, so it is still a 2-pronged approach, to see what works best.

    I worry just one avenue could be shut somewhere further down, so better to have two (or more) for now.

    But in conclusion, I think for BBB CNC stuff, it may be better to go for the standard BBB (or BBB-Industrial, since it is the closest to the original) rather than the others, simply because the real-time kernel patches may have been tested more on that.

    • Cancel
    • Vote Up +3 Vote Down
    • Sign in to reply
    • Cancel
  • Jan Cumps
    Jan Cumps over 5 years ago in reply to shabaz

    What I was wondering about: “Why the need for RT in Linux if the time critical (and jitter sensitive) functions are done in the PRUs?”

    • Cancel
    • Vote Up +5 Vote Down
    • Sign in to reply
    • Cancel
  • bwelsby
    bwelsby over 5 years ago in reply to Jan Cumps

    This is something I was wondering too, if there is a large enough buffer between "linux" and the pru then there shouldn't be a problem.

    • Cancel
    • Vote Up +5 Vote Down
    • Sign in to reply
    • Cancel
<>
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube