µCNC

Software / Firmware
1

I there.
I’ve been playing around with 3D printers and CNC for a while now (not only on 3D designing and prototyping, but also firmware related subjects). 2 years ago I made a small contribution on Marlin (Axis skew compensation) and more recently for Grbl too, and last year the idea of coming up with my own custom CNC firmware was taunting my thoughts.
Since the second half of last year I started playing around with Arduino IDE to see what I could pull of and was trying to come up with something that has more flexible and less hardware dependable by trying to apply some LinuxCNC base concepts about Hardware Abstraction Layers and µCNC was born.

µCNC was also heavily inspired by Gbrl and was developed so that it’s interface is “Grbl compatible” and can make use of the Grbl tools ecosystem.

µCNC was created with 2 types of HAL.

  1. It’s MCU independent and can be extended to other MCU easily.
  2. It can support multiple kinematics. Modifying or adding new kinematics is also easy on µCNC.

If anyone is willing to try the firmware do it with care. It’s still in it’s very early stages and I need the help of the community to try it and report bugs and give feedback about the project.
The project is hosted on Github

Thanks for your attention.

4 Likes
2

Welcome to the forum. Fascinating project. I am very interested in exploring all the alternative firmware solutions for CNC. Need to get another Arduino and I’ll put this on the to do list of control alternatives.

1 Like
3

Very neat! Here come a million questions. What boards do you already have working? Is it focused on 32 or 8 bit boards? Have you managed to make the abstraction support advanced drivers like the SPI or UART tmc drivers? Does it work with any of the lcd interfaces? What about CNC.js (I assume it would work with the grbl settings).

1 Like
4

AWESOME!

You got that in at the exact same time we were getting the dual endstop stuff in! I remember seeing it get merged as I was obsessively checking for ours to get merged. Small world?

I am going to be keeping an eye on this for sure.

1 Like
5

Ok. I’ll try to answer them all.

For now Arduino Uno. And there is a virtual simulator that runs on Windows PC (Command line).
I believe I can get this to work on Arduino Mega in a few hours. Microchip PIC 18F too. 32 bit boards? I don’t see why not. I have little experience with 32bit boars but I’m planing on picking up a Raspberry PI 1 I have here and give it a go.
Has I said. It’s hardware independent. If it can generate predictable ISR responses it can be used. believe I can get this to work directly on a PC that has a RT kernel.

For now the firmware uses only stepper drivers basic functionalities like Grbl. It’s not designed to use intelligent stepper drivers. Also does not have any peripheral implementation (like LCD, or SD cards).

This should work. I developed it using a basic terminal and also using Open CNC Pilot. It should in theory work with other software like UGS, bCNC or CNC.js. The protocol and settings are almost identical.

2 Likes
6

That was a fun project and got me to think about this stuff more. I like these math algorithms challenges type of things.
This was also a reason I did this. I tried to make it more modular and clean. The firmware it self is very simple and easy to read because it’s almost internally written in plain C (no specific architecture targeted).

I hope people like it and help me improve it.

1 Like
7

Very cool. Does this mean that using grbl post processors work with this firmware? Adapting this to the Mega/Rambo would really open a lot of doors as far as software is concerned.

8

OK. So as far as G-Code goes it supports:

List of Supported G-Codes in µCNC 0.01:
  - Non-Modal Commands: G4, G10, G28, G30, G53, G92, G92.1, G92.2, G92.3
  - Motion Modes: G0, G1, G2, G3, G38.2, G38.3, G38.4, G38.5, G80
  - Feed Rate Modes: G93, G94
  - Unit Modes: G20, G21
  - Distance Modes: G90, G91
  - Plane Select Modes: G17, G18, G19
  - Tool Length Offset Modes: G49
  - Cutter Compensation Modes: G40
  - Coordinate System Modes: G54, G55, G56, G57, G58, G59, G59.1, G59.2, G59.3
  - Control Modes: G61
  - Program Flow: M2, M30(same has M2)
  - Coolant Control: M7, M8, M9
  - Spindle Control: M3, M4, M5
  - Valid Non-Command Words: A, B, C, F, I, J, K, L, N, P, R, S, T, X, Y, Z

It also supports all of Grbl real-time commands (although the behavior may be slightly different).

Grbl system commands are almost all supported except for these ones:

$I - view build info
$N and $Nx= - startup blocks
$SLP - sleep mode
9

Awesome project! I’ll definitely be following your progress.

Purely selfish feature request: plasma thc!!!

10

Ok. New progress. The last hours I’ve been working on modifying the atmega328p mcu HAL to kind of a more “broadband” HAL.
This means that it has the potencial to work on Uno, Mega, Rambo, whatever just by creating the custom mcumap file for the board and configuring the pins, ports, and a few other registers to be used.
It’s still on a branch and has to be tested but looks promising.

4 Likes
11

So this is the current point on the project.
I’ve done a ton of bug fixes and optimizations on the code.
Added a bunch of features like laser mode support, path modes G61.1 and G64, TLO G43.1 startup blocks and other stuff. Initial Rambo board mcumap was created too.
When I started looking at RAMPS I saw that they have function group pins (for example step pins) all scattered over several different ports (which is less efficient). Never the less I’ll have to redesign the HAL a bit so it can be more flexible at the price of a slightly more extensive mcumap file.

I’ve gone through several tests with some gcode files and everything was ok.
So let’s where I can lead this boat :stuck_out_tongue_winking_eye:

4 Likes
12

Sounds very interesting. Where could you use help, or is it not yet to that stage?

13

Looks like another page for the docs… :grin:

14

At this stage I need help with testing and reporting all the bugs that I missed. That would be a major one for me and would help me speed up the development.
I want to focus efforts on stabilizing the core functionalities and HAL interface.

If any one is up to it there are two branches currently available:

  1. The master branch has the version 1.0.0-beta that was designed like Grbl (all pins of the same family/function must be in the same port). This limits the level abstraction so this version only will work on a limited number of boards.
    There are two configurations available. One that matches Grbl 1.1 pinout. And one (that is kind of incomplete - no control pins configured) for the Rambo board.

  2. A few minutes ago I just pushed the new branch (1.0.0-beta.2) that has a completely redesigned HAL to allow complete pin freedom.
    Also the only configuration file ready to use is the one that matches Grbl pinout. But soon I’ll create and upload other ones for Rambo, Ramps, etc…

This version also leaves the door open for dual enstops :grin:
Thanks

15

That’s awesome, thank you for your work! On important thing 8bit grbl is missing is dual endstops on cloned axis, such as dual Y axis machines, I assume this can be setup soon?

If there was a possibility to implement clustering for like how cohesion 3d/lightburn have created, I would try this on my new laser build.

16

I think I can get a working version of a cartesian XY machine with dual drive on one axis and self squaring running on an Arduino Uno by tonight. I’ll see what I can pull out.

1 Like
17

Thank you! I have a spare machine I can load this on that’s not in production. I think this is great, a really clean implementation with simple adaptation to different boards.

18

Ok I think I got it.
I’ve uploaded a compiled hex file here.
The pin connections are exactly like Grbl on Arduino Uno. The only difference is that the second Y stepper driver step and dir pins are plugged where the Z axis would be. The same goes for the second Y limit switch and the Z limit switch.

I did not set the pull up flags on this so be carefull not to forget to test all switches and check the status report to see they are reporting right.

If you prefer to compile it your self or modify something go the the beta.2 branch and configure it by following these steps

  1. open the config.h and modify #define MACHINE_KINEMATICS MACHINE_CARTESIAN_XYZ to #define MACHINE_KINEMATICS MACHINE_CARTESIAN_XY2

  2. On the mcus\avr folder open mcumap_grbl.h and modify all Z limit related definitions to Y2 like this:

#define LIMIT_Z_BIT 4
#define LIMIT_Z_PORT B
#define LIMIT_Z_ISR 0

becomes

#define LIMIT_Y2_BIT 4
#define LIMIT_Y2_PORT B
#define LIMIT_Y2_ISR 0

then run compile the code following the instructions on the readme file and you’re good to go.

1 Like
19

Do you lose the Z axis though? Since you are replacing the pin assignments with Y2?

20

In this case yes. Sorry. I thought your machine was an XY2(with a dual drive on Y) and no Z. Not a XY2Z.
If that’s the case that is an easy fix. In Uno there is an unused pin. You just need to sacrifice one of the other assigned pins to do that. Which pin do you want to lose?