Cnc Grbl 1.1f for T4 imxrt1062

I've been working with this (GRBL/HAL). It's going quite well and the few bugs are getting fixed quickly. GRBL/HAL is moving well beyond the limiting factors of the 8 bit Arduino world and making high end features like 4, 5 and 6 Axis milling available. The longer term plans for GRBL/HAL involve migrating even more high end CNC features into it.

I have designed a breakout board/motion controller for it. It's still a bit early but my design is available here. Currently I have working boards on the bench and will be stress testing in a machine environment soon. When I've had a bit more testing, I will put the design under open source, make the board design available on OSHPark and provide gerbers. I'm excited about the T4.1 as that will allow avoiding the backside pins and make it easy for average system builders to use.

Here are the basic design features:
  • 5 Axis controller.
  • External interfaces 5V minimum.
  • 3 Axis limit switch optoisolator interface.
  • Cycle/Start, Feed/Hold, Door and Halt support via an optoisolator interface.
  • Spindle on/off, PWM, direction and 0-10V interfaces.
  • Flood and Mist coolant relay drivers.
  • Vacuum/Dust Extraction relay driver slaved to Spindle on/off
  • 3 additional relay drivers.
  • Selectable relay voltage - 5 and 12V.
  • I2C interface (3.3V).
  • EEPROM (24LC SOIC footprint).
  • Screw Terminals for secure wiring.

I've designed a number of GRBL breakout boards for various arduinos and, compared to them, the Teensy 4 is a joy to work with. I'm also doing GRBL/HAL boards for the Due' and MKRZERO - the clean T4 design puts them to shame.
Last edited:
Thanks. You might be interesting in the T4.1 version that I'm hoping to finish layout in the next couple of days. It will have 5 axes (with limits and enables), Ethernet and maybe USB Host (for MPG/Pendant). Not sure if support for the pendant will be ready soon but Ethernet in grblHAL should be fairly straightforward. It works on several other platforms using IwIP. I've also reworked the relay section to allow easy support of both direct coil drive of relays and TTL drive for SSRs and those ubiquitous Chinese relay boards. Plus, it will allow the slaved dust extractor to be run independently via a header (with a switch attached).

Also, I'm considering getting a smallish number of boards built up. At least with the SMD components - sort of an unkit, the user would finish it with the TH components. Not sure what they would be priced at. guessing mid $20s.
Very interested in your T4.1 version. Your price point for an "unkit" would be amazing, even if it was a few more. I'll take 2 ;) Currently running 2 different 3 axis GRBL machines (Carbide3D's Shapeoko XL, and Nomad 883, with an older Shapeoko 3 build in the works. ). I can't wait to test and have no problem soldering TH components.

Embarrassing newb question, it looks like drivers are not part of the equation, so external drivers?
Yes, drivers are external.

While integrated drivers are attractive for easy system building, they have some significant drawbacks: driver failure requires full board replacement, hard to match to specific CNC machine stepper needs, problematic heat management and mixing noisy high(er) voltage with 3.3V or 5V digital logic. And, to be honest, it's about design philosophy - fully integrated vs modular. In my mind, a CNC system is highly modular by nature. Higher end systems are all modular. In fact, I can only think of a couple fully integrated CNC motion controllers that support more than 1.2 Amp stepper drivers (i.e not RepRap machines). A solid mid range or higher CNC machine typically uses at least 4A controllers. The CNC forums I look at seem to have a strong bias toward modular systems.

As to timing of an unkit, I have to get the T41E5XBB (T4.1 base, Ethernet, 5 AXIS Breakout Board) done and validated, then figure out pick and place, select a vendor and then run a batch. I'm sure there will be some hiccups along the way. It probably won't happen until July at the earliest.
Makes sense; I too have fallen victim to a failed onboard driver which required a replaced board. The GRBL board I'm using has intergraded DRV8818's and a giant heatsink that functions as the board mount as well. The board I'm using is a closed source Carbide3D GRBL board, but it's based on the Stepoko Sparkfun board.

I also have limited work space on my table, so I need to figure that out to add a rotary table. Given a couple of months, I'm sure I'll figure something out. I'm totally appreciative of your endeavors, so a release anytime would be welcomed.
Last edited:
Been able to run GRBL port on Bluepill STM32 @ ~240kHz step rate max with some tweaks.
I wonder, how high T4 can go, considering more than 8 times MCU frequency?
Probably interrupt latency will be a limiting factor, not the core frequency.
Why don't you ask the developer, Terje? He is quite responsive and helpful. Post your question in the issues section of the github repository. You can also read the code. He's done a great job of "HAL-ifying" GRBL, moving the processor dependent stuff into the driver section.
Is this still an active project, I'm very interested. I'd like to play with this before diving into LinuxCNC (I'm trying to run it on a raspberry pi 4 and struggling)
Yes, very active. Numerous ports to various processors (12, iirc). The developer, Terje, is using LinuxCNC as a model for the various G and M codes. Personally, I find LinuxCNC overly complex but it is very capable. A goal with grblHAL is to replicate the richness of LinuxCNC without the complexity.

Github repository here.
I still have a few BoB "unkits" available here.
Schematic, gerbers, manual, prebuilt firmware, etc available here.
This looks really good Phil. My finger is on the "order" button, but...

Looking through Github and the docs, I don't see a change log. What is the difference between v2.05 and v2.07?
V2.07 is what I have available now. The only significant electrical difference is V2.05 digital inputs are not 5V tolerant, V2.07 are. This is called out in the manual. Also, the 2 LED resistor values are a bit higher (I moved to the assembler's LEDs and they are much brighter than the ones on my prototypes). V2.07 also has a few silk screen updates. From a grblHAL perspective, the two versions are identical.
I've ordered one too, great price (until I get stuck for the customs admin fees and import VAT)!

Wish I could do something about customs and VAT but it's kind of above my pay grade. I guess there is at least one thing about the USA to be grateful for - we have a pretty high customs minimum compared to most countries and clearance is super fast. Hopefully yours is not as bad as a certain Nordic country where a friend has been waiting 4 weeks for several packages that are sitting in a customs house about 40 km away. Germany, on the other hand, has been amazingly fast on customs clearance - I'm hearing 1 week end to end delivery.

Anyway, it will be on it's way to you come Monday morning Pacific time.
Looked over what I could find in your links and have some questions. I'm also curious about what niche you are intending to fill.
I run Gecko Drive G320 DC motor drivers at 20A, 56V with 2024 line encoders. They can run at 250kHz.

1. I'm currently using 4 axis of an 8 axis PoKeys57CNC ethernet board that can output 125kHz max. That gives me 45 inch/min, fast enough for me. Is 25kHz (9in/min) your max?

2. Typical servo drivers need an enable and output an error signal. Its nice to have this for each motor so you can stop before messing up something and know which axis caused the problem. Will this be possible with your design?

3. Why are you using I2C? SPI is way faster and made for off board peripherals.

4. I am not familiar with the GRBL stuff. I use Mach4. Are they compatible? Is there something that would take the place of Mach4 that I could run natively on a Apple mac?
You are running a fairly high end configuration. The goal of grblHAL is to be able to handle that sort of setup though I'm not sure the software is there yet.

On your specific questions.
1) my board can output a 160 kHz step rate. (I've spec'd this conservatively, faster is possible with grblHAL.) I'm sure you know this but your feed rate is dependent on gearing and microsteps. I have a customer that is running at 5000mm/min (about 200 IPM). I believe he is using 1/8 microstepping. Based on 125 kHZ/45 IPM, your max with my board would be 57.6 IPM.

2) I have 4 5V tolerant conditioned digital inputs that could be used for the error signal though a driver would need to be added to grblHAL to do something with the signal. What is supposed to happen on error - stop the job? That would be a pretty easy plug-in to add.

3) The I2C interface isn't meant for high speed stuff - things like MPGs, DROs, etc.

4) No, GRBL replaces Mach 4. What you need to run grblHAL (or any GRBL system) is a sender application running on a host PC that sends G-Codes (and other commands) to the grblHAL board. There are several senders that run on Macs - typically they are java based. One that I am well familiar with is Universal G-Code Sender (UGS) which works well on a Mac. There are several others like bCNC and jSender that I haven't used much.

To be honest, if your system is working fine, I don't understand why you would want to switch.
Hi @PhilB,
Thanks for the quick reply. I really like open source and really like to have things run the way I want them to. Also get tired of things happening or usually not happening with vendors. The latest is that Mach4 V2 may not be compatible with PoKey57CNC. Previously I waited for upgrades to the awesome Gecko G100 drive controller and Mach3 that were supposed to support threading. It never happened and later after I smoked it found they had discontinued it so I switched to the PoKey.

My set-up is probably on the high end, for DIY. Its a Shoptask Mill/Lathe I converted to CNC with junk parts or e-bay specials. Thats why the 2024 lpi encoders instead of something more reasonable.

Back to the questions.
1. Thought I'd read that your optical encoders were only good for 25kHz, the 160kHz sounds great.

2. Had to learn LUA language to get Mach4/Pokey to basically do an E-stop, save some data and dereference the axis. Not to bad, but how many languages does a person have to know to play with CNC:confused:

3. Playing for years with Teensy 3.2, 3.5, 3.6 and now 4.1 I have all kinds of inexpensive sensors and displays, all on SPI. Its just what works best for wired sensors with cables around 6ft. I2C stuff tends to be on the board and still fidgety.

4. I'll have to look at this stuff.

Why would I want to switch :D ... Because its there;) Half the stuff I've made is for the milling machine itself, although in the last few years my attention has switched to a Prusa 3D printer with half the stuff I make for it! :D. Now I design and refine with plastic on the Prusa, then go to the CNC for final parts.
I keep thinking I should do a mill conversion. Maybe someday. It would sure be nice to be able mill steel.

I see where the confusion on step rate comes from. I don't use optos for the stepper outputs - just limit and switch inputs. The assumption is that the stepper drivers use optos for input which is probably where that came from.

I don't disagree about SPI for speed and I like SPI since you can bit bang it pretty easily. The whole pull-up confusion around I2C is a bother. Both have their places though. The beauty of grblHAL is plug-ins are pretty easy to add. The whole HAL layer (er HA Layer) means you don't need to know too much about how grbl works.

On an error signal from servos, what should be the action? Stop? Pause? Adding more digital inputs is pretty easy.
I don't disagree about SPI for speed and I like SPI since you can bit bang it pretty easily. The whole pull-up confusion around I2C is a bother. Both have their places though. The beauty of grblHAL is plug-ins are pretty easy to add. The whole HAL layer (er HA Layer) means you don't need to know too much about how grbl works.

My reason for pointing this out is that the Teensy I/O is not as flexible as it might seem at first glance. Certain functions only work or work best on certain pins. SPI only works good on a few pins and I think you were using them for something else.

On an error signal from servos, what should be the action? Stop? Pause? Adding more digital inputs is pretty easy.
With the Gecko's the error signal means that the servos are > 115 steps from where they should be. That means you should stop all axis ASAP so you don't make a larger mistake. Some servos have brakes that you'd want to apply, but usually whatever the issue is does this for you.:p

A properly set up system will do this only rarely (but it will do it). I had been running for many jobs since I put in the 57CNC controller without realizing this function was not working. I commanded a higher cutting speed on a dull bit than the HP of the spindle could deliver and it slowed down(no spindle speed control, adjustable belt drive pulleys). With the spindle slowing the chips got thicker, increasing the load to in this case greater than ~320 pounds it takes to fail the driver. So the X axis stopped but the Y axis and spindle kept going making an odd design with lots of noise, aluminum welded to $20 mill bit, scared operator etc. (Amazingly, and fitting for this discussion the part had not moved on the table and the error occurred away from the final surface. So all I had to do was put in a new bit, re-home and start from the failed location.) In this case had some sensor noted the spindle speed slowing the whole thing could have been averted by stopping or pausing at the next opportunity and messaging the operator.
Phil, I bought one of your Teensy 4.1 grblHAL boards back in the summer and I'm just getting round to assembling it into the box of tricks that will eventually run my converted Harrison vertical mill. I want to use a raspberry pi to send the g code as I have limited space (and the pi will fit in the box in a DIN rail case). I can connect to the teensy 4.1 using ioSender, but I'm really struggling with UGS (seems to be about the only g code sender that will run on linux/rpi. The initial connection with UGS seems to be the issue and not just from the rpi, it doesn't seem to work on windows either. I know this is unrealted to your breakout board, but I don't suppose you tried connecting with UGS?
Thanks for reaching out. Yes, UGS does work with grblHAL but only in compatibility mode - I've tested it on windows. I have heard about issues running it on a Mac and RasPi, though. There is an issue open on the UGS github repository about full support (with enthusiastic response, btw). I need to pull my RasPi system together enough to test it out. The reports of issues with compatibility mode are a little unclear so I need to figure out what's going on.

In the mean time, you need grblHAL built with compatibility > 0. There are prebuilt binaries on my github repository. Start here. You want to select one of the "compat" hex files. If you need a ganged axis, let me know and I will build a compatibility hex file for you.

By the way, bCNC works with the Mac and Linux. I've run it on a RasPi 3. There is also an open issue for full support on their github repository.

Since I'm sure you are wondering. Compatibility >0 leaves out the new grblHAL commands and some Grbl settings. The problem is that a lot of GCode senders choke when they see something they don't understand. So compatibility restricts the responses from the motion controller to only those that "Grbl classic" (AKA grbl/gnea) responds with. One of the things you lose is ethernet support. Sigh... Hopefully in short order this will not be a problem anymore.
Good info Phil. I'm in the same boat, bought mine in the summer and just now clearing off a section on the bench to start working on it. But all the other "moving pieces" of the puzzle are bigger questions to get a couple running systems up... RPi, Windows, or Mac... which sender to use... which stepper drivers (or if there are any issues there)...

Life is always fun at the bleeding edge.