6 Axis Grbl Port on PSoC
If you have done any extensive poking around the Grbl source code you will eventually come across this line in nut_bolts.h.
#define N_AXIS 3 // Number of axes
It would be so easy to just change that to 4 or 6 and have some fun, right? No, unfortunately it is not that easy. With a little work though, it is not too hard to add those extra axes to Grbl. I decide to try this with my PSoC port of Grbl.
ABC Axes
Typically the axes after X,Y, and Z are labeled A,B, and C and are often rotary axes. Here is a simple 4th rotary axis.
Things get more complicated when you add more axes. Here is an example of a 5 axis upgrade for a 3 axis machine.
N_AXIS
While simply changing N_AXIS does not suddenly make the extra axes work, it does do a lot of the work. I found it used over 80 places in my port. It will do virtually all of the major code work. I just needed to do the following…
- Read the ABC parameters in the gcode.
- Add additional $$ settings for steps/mm, speed and acceleration for the A, B, and C axes.
- Add homing code for A,B, and C.
- Adds some #define statements to make it easier to configure between the axis counts.
As I was working on this I stumbled upon a few other people working on this. This code I found was especially helpful.
Configuring I/O
Grbl uses 1 byte byte each for axis step, direction and limits switches. Those bytes are used with a mask (to say with bits are actually used) and applied directly to an I/O port. This is a very efficient way of doing it, but it forces you to put all axes on one I/O port for each of the step direction and limit switch functions.
My port to PSoC uses Control Registers to output the step and direction signals and Status Registers to read the limits switches. These registers can be ‘wired’ directly to I/O pins. There are several advantages to this, but the main ones in this context are, you don’t need to map them to the same I/O port and you only have to connect the ones you want to use. Here I have defined all 6 bits on the Control Register, but have only connected the I/O pins I am using.
To make the PSoC port easier to maintain as Grbl changes, I did not change the Grbl method to much. The mask is still applied, but the mask is hard coded.
The homing switches work in a similar fashion. Here is a 4 axis setup.
EEPROM
The storage of the steps/mm, speed, and acceleration will increase the amount of EEPROM required. The PSoC has plenty, but keep in mind every time you change the axis count, you will need to reset the EEPROM because the locations will get shuffled and the restore from EEPROM will not work the first time you start under the new axis count.
Status
The status is going to report the extra axes, so I assume it will break a few senders.
? <Idle|MPos:1.680,4.568,-0.900,0.664,0.428,0.984|FS:0,0> ok
$# [G54:0.000,0.000,0.000,0.000,0.000,0.000] [G55:0.000,0.000,0.000,0.000,0.000,0.000] [G56:0.000,0.000,0.000,0.000,0.000,0.000] [G57:0.000,0.000,0.000,0.000,0.000,0.000] [G58:0.000,0.000,0.000,0.000,0.000,0.000] [G59:0.000,0.000,0.000,0.000,0.000,0.000] [G28:0.000,0.000,0.000,0.000,0.000,0.000] [G30:0.000,0.000,0.000,0.000,0.000,0.000] [G92:0.000,0.000,0.000,0.000,0.000,0.000] ok
Sending the GCode is pretty easy, but I don’t know of any basic gcode senders that support more than three axes.
My personal sender uses regular expression to do the basic parsing of the status. This is a robust way to to handle status that can change formats as long as it is predictable. I send the position data to a function that splits it into a string array. I’ll just need to add some DROs for the extra axes if it detects them.
Testing
I don’t have a 4 or 6 axis CNC, so I built a little test rig with 6 axes. I used a Gecko G540 and 2 single axis drivers. Each stepper has it’s own home switch triggered by a cam on limit switches with roller actuators. This allows the switches to be triggered , but allows the steppers to run continuously in either direction. The homing sequence is quite fun to watch. Building this test rig took about as much time as the firmware changes.
Here is a YouTube video of it.
Next Steps
I want to do a lot of testing, then build a machine to do some real world testing. I currently don’t have any decent CAM software over 3 axes, so I will need to deal with that. I will then add it to my GitHub repo for this.
Nice work! I like that you chose the PSoC for this, I feel they don’t get the attention they deserve in the hobby CNC community.
I developed some open source closed loop brushed and brushless motor controllers based on the PSoC4 that should go well with your machine controller https://goo.gl/photos/ez6WvvWxp35TmKAA7
Wanna try using them?
I would love to try one. Do you have a datasheet for the 24V 4000rpm motor you have on the crowd source page.
https://github.com/ottoragam/Tarocco/blob/master/Servomotor/38SRZ-R1-400qenc.pdf
It is a “small” motor, meant to replace NEMA17 steppers. I plan to get a 60W version soon. The rest of the source files are there in the repo.
I’m curious if it would be possible to fuse together the hardware position error tracking of my motor controller and the rest of the PSoC based GRBL firmware. It uses 75% of the UDB resources of a CY8C4245, so the bigger PSoC5 should be able to take care of several axes at once.
The code for my 3 axis port is on GitHub. You could load it in PSoC creator and start adding the resources you need. The link to the GitHub is in the blog post.
I am pretty excited about the PSoC 6. Dual core and an FPU sounds really powerful.
Totally! Hopefully they’ll be generous with the UDBs too 🙂
Can you guide me on simply adding 2 more axis on the standard official ATmega2560 GRBL?
In fact, I just need 2 more linear (not rotary) axis.
Cheers and keep up the good work!
Regards from Portugal
Nuno. Check out this code…
https://github.com/gnea/grbl-Mega/pull/21/files
Friend, what software are you using to control the step motors?
It is Grbl. Find it on Github
https://github.com/gnea/grbl
I ported it to 32 bit PSoC and added 3 axes.
The PSoC kit looks like an interesting piece of kit, I have just bought one to try out.
Inspired by your implementation I have already made an experimental driver for my HALified Grbl port.
The driver and the Grbl port can be found on github if you want to have a look.
https://github.com/terjeio/PSoC5GrblDriver
The main difference is that my implementation has the main Grbl-code and all the hardware specific code in separate projects.
Be aware that my port of the Grbl-code is quite a bit different from the current master, e.g. a lot of the #defines has been replaced by enums and unions and all floating point calls are changed from the previous double precision versions to single precision.
Among other things I also have provided support for adding user defined M-codes to the driver without changing the Grbl-code. The driver may also inject GCode into the parser when Grbl is in idle or jog mode.
Just found this project, a year later was/is psoc-grbl successful?
Yes, it is fully functional as far as I can tell. I do not have an actual 6 axis machine to test in on though. I regularly use the same code for a 4 axis machine.
Thanks, I have your “N_AXIS 3” code running now, piece of cake compiling and flashing with Creator 4.2. Thanks.
Hi, I was searching for a way to build a 5 axis Grbl CNC machine, then I found this blog. It’s been a year after the last comment, do you make any update on this project?
From your demo video I see a PSoC connect to a 4-axis motor controller, then wiring to the drivers and motors. How can you control 6 motors by that? May I also know what controller are you using? Thanks.
It can control a 6 axis machine. Here is a video of that. While PSoC is my favorite MCU, it is not very popular with DIY builders. I have shifted my focus to the Grbl_ESP32 project. The master branch is currently only 3 axis, but testing is being done with 6 axis.
Sounds good. Is that possible you can also post a tutorial of how to do 6 axis on Grbl_ESP32? Many thanks.