ARM discussion #67
Comments
|
I think Grbl success is partly to the fact because of standardising on Arduino. It it easy to get an Arduino all over the world. This allows for easy entry with Grbl. |
|
There have been a lot of questions about what Grbl is going to do and how it'll move into the ARM world. Several dozen in the past and again just today from (@alpharesearch and @Strooom). I think it's time to start publicly talking about Grbl's long term strategy now that v1.1 is finally out. I have an extremely strong feeling against monolithic processor models with a very large codebase, supporting everything on one chip. This does two things:
To improve the core motion control problem that everyone wants, it's critical to retain tight control of what the processor is doing at anytime. So, I think Grbl should remain somewhat independent of the noise and provide just a set of high-bandwidth communication methods to it, not just USART serial. This will allow Grbl to continue developing the hard motion control problem. As for what processor gets used by Grbl ARM, personally I don't think it really matters. Here's why:
@alpharesearch : I totally agree with you that Grbl is successful because of the easy of trying CNCing with an Arduino and being able to compile custom or new versions easily through the IDE. I think the Teensy is a good platform, but isn't that great for OEMs due to the bootloader issue. This is why I'm targeting the SAMD21 Cortex M0 series. In my tests, it's more than adequate for everything I intend to do in the short term. It retains the core principal of keeping Grbl easily accessible due to the increasing popularity of the platform. As for supporting peripherals, I think this really needs to be a separate community project, MIT-licensed, and on a separate MCU directly connected to Grbl ARM as a co-processor model. This will bring in the interest and the help of OEMs and allow users to help out with the project. There is no worry about breaking the motion controller timing and critical processes. The co-processor idea isn't anything new, but I think it really needs get rolling and be officially supported. |
|
I have done initial porting of 1.1e to stm32F103RBT6, it can be viewed here https://github.com/usbcnc/grbl. I use free coocox IDE to compile and program (STlinkV2). |
|
@alpharesearch I think the succes of GRBL is due to:
Still, I think it makes (IMHO) an entry-level CNC controller. After some years of experience, you may want something with more features and more performance :
As GRBL on an Arduino already does an excellent job at that entry-level, I think the ARM-version should go in the direction of that 'next-after-entry-level' controller. GRBL will still be there when you build your first machine.. When you are upgrading your CNC (or other machine) with this kind of controller, it only makes sense if you also upgrade your hardware. (motor controllers - spindle - bearings - ...) so in the total picture, the cost of the controller board is very small, and should play no important role. @chamnit I agree that GRBL does a great job on the 16 MHz 328P, but (IMHO) this comes with a price of complexity of the code : in order to fit in the ROM/RAM/CPU-cycles, features are implemented in ingenious, smart ways, but not easy to understand and certainly not easy to modify or extend. Other examples are buffer sizes which are rather small, due to the limited resources on the Arduino (eg. its Rx buffer is too small for GCode maximum block size of 256 bytes). The move to ARM should (IMHO) also relax those constraints. By having 'plenty' of ROM/RAM/CPU I think the code could be more modular and simpler, with more people contributing to it. I am not aware of Teensy bootloader problems: I program it via the Arduino IDE, I agree you need to manually put it in program mode - minor inconvenience imho. About Teensy SW not being open - I am not aware of that either - would like more info on that. In general it is my opinion that the ARM sw libraries are better quality than the Arduino... Thanks for this great discussion! |
|
@Strooom @usbcnc : Grbl ARM will not be a direct port of Grbl on the 328p. For same reasons that (one and only) @Strooom stated. Grbl's code is the way it is because of flash, memory, and speed constraints. You simply can't modularize things without effect any one of those. As for complexity, it's not complex to me! :) But don't worry, I plan on re-writing things to be of a more functional programming style so it's easier to test and port. @Strooom : I hear you on all those things: more axes, higher order motion control, more inputs, and larger buffers. All of that can be accommodated on the SAMD21 series. There is a J-variant that has 64-pins. In the off-chance it isn't adequate, it'll be easy to port to STM or Freescale, as @usbcnc and others has already shown. The plan has always been to be the LinuxCNC replacement at a minimum. Things like real-time feed hold and overrides needed to be figured out first. Which they now have. Higher-order motion control is next, along with more axes. The crux of the higher-order motion control problem has been solved already. Now it's implementation. A better streaming interface is already planned as well to remove streaming constraints, particularly at high data rates. Like I said before, I don't accept pull requests in large part due to the sensitivity of maintaining a jitter-free step output without effecting performance. If a separate co-processor model is used and created, the host for Grbl (that would stream directly to it and support LCDs, joysticks, SD cards, Wifi, BLE, native USB, etc.) can be contributed to by everyone. There is no concern of breaking the motion controller with code alterations. You just have to maintain a stream of motions for Grbl ARM to execute. Like you said, the cost of the micro controller is nothing. So having one Grbl ARM controller and a Grbl Host controller is completely feasible and the right way to approach this problem for future proofing. As for Teensy, Teensy's bootloader chip is proprietary and $8 a piece. This makes it very unfavorable for OEMs or hardware people, but it also protects the Teensy from out-right clones. I understand why Paul has this model, but it's not ideal for companies to use Teensy, which is why you don't see a lot of Teensy-based hardware. Also, I still don't plan on using any Arduino or Teensy libraries, which Grbl never has. Things are being built on existing software frameworks from manufacturers that are not GPL based. |
|
I was thinking more about a reference design (line the Arduino now) that just works for end users. I guess a plus would be if some of the existing components like stepper drivers can be recycled and other components like displays and buttons from other systems can be used. I just think it would be nice if people can use mainly off the shelf part and create a system with ease and quick. @Strooom I think is Teensy HW is the only thing that is not open, but the SW should be all good. By the way I personally have no issues with that. @chamnit if I look around for M0 and M4F development boards at mouser it looks like both have plenty of options and many are priced the same ($10-$40). Do you have a particular development board with M0 in mind? |
|
SAMD21 example is Arduino Zero. Sparkfun also has a SAMD21G board. The best example is Atmel SAMD21 Xplained board. It is inexpensive and has a J chip, with the full 64 pins. Also has a hardware debug interface on the board which makes it IMO the only choice for development. Keep the drivers etc off the Grbl board. If you don't then you are stuck with whatever that design is. No changing pins, adding/altering interfaces etc. Keep your HW designs modular. One thing to keep in mind is that ARM specifies the core cpu and a very few peripherals only. (e.g. interrupt controller). All the other stuff such as USB, I2C, SPI, Can etc is up to the chip vendor. And they all do that differently for the most part. Thus it is not enough to say M0 ARM, you need to pick a vendor to get the details. |
|
So I spent some time today re-analyzing my decision for SAMD21 and did some benchmarks of the important metrics. While the SAMD21 is indeed at least 3 times faster than the 328p, I'm starting to have doubts again about it. It'll definitely work short-term, but it might be too short. I'll be stuck in another 328p situation. (Surprisingly the stm32F103RBT6 is only twice as fast as an SAMD21. Good but not great.) This brings me back to the Teensy. There was a time I was committed to the Teensy 3.x series, but the bootloader issue was the main problem. Does anyone have a workaround for this? |
I was not aware of this. It's a non-technical thing, but also important to get solved, and better to tackle it early. |
|
I just try to understand the situation, please correct me if I have a wrong assumption. |
|
@alpharesearch FRDM-K64F looks interesting. Will look into its spec over the weekend. |
|
It seems most of this discussion is in terms of what platform to use. As an end user, who is by no means as expert in programming, microcontrollers, etc, all I can say is that the means of uploading the Grbl firmware should be easy or I think you will be driving a bunch of potential users away. The current method of uploading via the Arduino IDE is super simple and user friendly. I am not saying that this method has to be the one, but something just as easy would be best. Perhaps once a platform is chosen, a simple interface for uploading can be created by one of the gurus here. My only other comment about the platform is that it should have enough input and output pins to allow for future expansion. 4 or more axes, limits separate from home switches, spindle encoders, axis encoders, all come to mind. As for non-platform specific enhancements for Grbl, My biggest vote would be for Spindle feedback for lathe threading and mill rigid tapping- Lack of ability to thread on a lathe makes Grbl almost useless on a lathe since threading is pretty common for lathe operations. On a mill this isn't as big a deal, but would definitely be a benefit. I believe this limitation sends a lot of potential users away for a couple reasons. People who have lathes don't want to switch back and forth the controller they use and so will chose something else like linuxCNC or Mach3/4, and then on their mills they are likely to use the same program rather than have to learn another one. Also, some people using only milling machines will also use them for lathe operations by mounting a chuck to the mill spindle. I do this myself from time to time. and it would be awesome to be able to sync and thread in that case too. This would of course require adding the feedback and also the G-code commands for threading. |
|
Ok. I think I was jumping the gun a bit on the Teensy or an alternative to the SAMD21. I was reminded of a long term plan that makes the speed of the MCU not as important. However, I think it'd be wise to have the Teensy (or another faster MCU) as a backup. I'll make sure to decouple all MCU processes to facilitate this. @109JB : As for number of pins, the SAMD21 J variant has 64 pins. Plenty for 4+ axes and limit pins. Even the normal G-variant has enough (38 I/O, 48 total), but they are often not all connected or used for dedicated SPI, USB serial, etc. I hear you on the lathe threading. It's actually something pretty easy to do. Rigid tapping, on the other hand, is a little more difficult because you need a spindle capable of precise synchronized motions. |
|
This is the closest bootloader I could see for the Teensy :
https://github.com/scanlime/fadecandy
ST and NXP have built in bootloaders on some of their Mcu's making it very
easy and cheap to program.
Smoothie uses one of the NXP's I mentioned but its getting old and finding
supplies can be a pain with prices jumping as supply get low.
ST on the other hand has a huge market share and is highly available from
China.
Documentation and community support is also a big thing to look at. ST
seems good at that.
Then there is JTAG. If you want to make it easy to debug then you cant skip
this bit. The Arduino Zero has this built in but its hugely experience.
ST has that solved as well with its cheap st-link jtag programmers running
on STM32F103's.
…On 17/12/2016 8:11 am, "Sonny Jeon" ***@***.***> wrote:
Ok. I think I was jumping the gun a bit on the Teensy or an alternative to
the SAMD21. I was reminded of a long term plan that makes the speed of the
MCU not as important. However, I think it'd be wise to have the Teensy (or
another faster MCU) as a backup. I'll make sure to decouple all MCU
processes to facilitate this.
@109JB <https://github.com/109JB> : As for number of pins, the SAMD21 J
variant has 64 pins. Plenty for 4+ axes and limit pins. Even the normal
G-variant has enough (38 I/O, 48 total), but they are often not all
connected or used for dedicated SPI, USB serial, etc.
I hear you on the lathe threading. It's actually something pretty easy to
do. Rigid tapping, on the other hand, is a little more difficult because
you need a spindle capable of precise synchronized motions.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#67 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADqFI7pUsPM1VIkA_K810-JhAUsuzQEbks5rIuI1gaJpZM4LOO10>
.
|
|
Program and debug on STM32 is very easy with STlink. It took just 2-3 seconds to erase and program 35KB flash. I always have STLink connected even while running GRBL. I found, however, in order to DEBUG, the USB feature cannot be used. You have to have USART since USB re-enumeration will kill the debug session. (I normally use Win GRBL simulation to debug so this is not an issue for me). There is a big family of STM32 from F1 to F4. I use coocox which is free IDE and it serves the purpose well. |
|
I think it might be time to specialize the use of GRBL instead of pleasing everyone. Lathe tapping, 4th axis, servos+encoders (isnt that just a hardware anyways that sends its own stop command?) are all pretty specific things that should use community made specialty plug-ins or something along those lines. If GRBL just did 3 axis control as well or better then mach 3 (which it almost is!) we'd have a very good firmware. Ive never ran into any issues yet where grbl was the cause of it in over my year of use (over 200 hours). We should perfect grbl and its/a GUI software of choice for the UNO before switching rails to the specialty stuff that isnt so hobbiest in nature. If you are able to afford encoders, a 4th axis, spindle control + VFD I REALLY doubt a 50-200$ control board will be an issue as well. What about making your own GRBL board, like the tinyG after version 1..2 or whatever is next? More input pins for ground, spindles, relays, limit switches, door locks, maybe even auxiliary power/Lights , etc without just being another 20$ breakout board for mach. |
No they aren't. They have to be incorporated into the motion planner (Grbl). Lathe threading requires that the axis motion be coordinated with the rotation of the spindle. The axis motion needs to slow down if the spindle slows down and speed up if the spindle speeds up. Nobody said servos with encoders, but feedback from an encoder mounted on a stepper can be used to halt the machine if missed steps are encountered. Not a full feedback system, but a simple monitor. This can be done outside of the motion control, but can also be monitored inside which would be more robust.
And lathe threading, rigid tapping, etc are reasons why more don't use GRBL. the motion planner is already there except for higher stepping rate which a faster MCU will take care of.
GRBL for the UNO is maxed out. It has been said many times before. There is no more room. What GUI of choice? Grbl should still stay away from GUI development because GUIs are going to be a matter of choice. Also, who says a spindle encoder is expensive? How about 99 cents, which is how much an optical sensor costs that can do lathe threading. It is what I have on my lathe right now with LinuxCNC. I would love to switch my hobby lathe over to Grbl, but not without lathe threading. I am a hobbyist and saving money anywhere means that money can be spent somewhere else, whether that is a 4th axis, or whatever. BTW, what exactly is not hobbyist in nature when it comes to a 4th axis or lathe threading. Many hobbyists use these features. Just because it isn't part of you hobby vision doesn't mean it isn't part of another persons. The cost of going to a board with a lot of pins is not an issue cost wise anyway, but an UNO number of pins just isn't enough. If you want GRBL to compete with Mach3 or LinuxCNC, you have to support the things that they can do. |
|
I am a hobbyist machinist on fixed income (retired in 2007) so cost conscious. I would love to get lathe threading, full gcode (threading, drilling etc codes), and a way to slave a stepper to spindle so that when spindle rotates, the stepper moves as well, but with a selectable 'gear ratio'. This enables hobbing gears (yes you can make your own cutters), cutting helixes etc, things that I can't do on my manual machines. As 109jb wrote, none of these things are expensive, thus well with reach of hobbyists. I don't want to run Mach3/4, been there. Also don't want to run Linux anything, been there. Grbl, on the Uno and on whatever is next are more than adequate for hobby and non-hobby use. You even get to choose the GUI you prefer as there is a large selection, supporting a broad range of machines from homemade routers to Bridgeport milling machines. |
|
Thank everyone for the kind words. I do plan on expanding the g-code parser to fully support the remaining g-codes. I'll have to assess what makes sense, but likely remain on LinuxCNC's standard and first install canned cycles. There's just a lot more that can be done with the additional flash and RAM by (finally) moving away from the 328p. @jahnj0584 : I may do something with hardware at some point, but it's too early. Some of the longterm development path is still a little undefined. I'd like to clear that up so the hardware will support it when the time comes. |
|
My first thought as I read this was the SAMd21 because it is being integrated into the Arduino product lineup but also because it can be flashed with a USB bootloader and implimented as a very minimal PCB with just a crystal, USB connector and voltage regulator. As a hobbyist this is very appealing because I can think of designing a custom board, or just using one of the boards from Sparkfun or Adafruit, and at very low cost. I use GRBL for CNC milling at the moment so the speed enhancements with respect to laser cutting aren't a priority (but that may change) - my preference would be for extending GCode support, something that would be enabled with the extra flash and RAM on the D21, and for the option of an extra axis and a spindle encoder. In terms of long term development, by basing it on the D21 and keeping it within the Atmel family of MCU's the peripherals set will be the same across the whole family of MCU's and I would also expect that some of the more powerful SAM devices based on M3 or M4 cores might appear as official Arduino products using a derivative of the SAMD USB bootloader - this would (I assume) provide an easier migration path away from the D21 whilst maintaining the out-of-the-box ease of use for customisation that comes from staying with 'Official' Arduino products and toolchain (As opposed to going with Teensy) |
|
@gerritv Gerrit, could you elaborate a bit more on why you prefer GRBL to Mach and Linuxcnc? Its important to identify those strengths and not loose them in the future version. |
|
@Strooom |
|
@Strooom Grbl means 1 less PC for me to feed and care for. Mach3 requires a parallel port, Mach4 requires an expensive (to me) external driver board which I am then locked into (can't use it with anything else). Linux I want nothing to do with anymore in any shape or form. Too many years with Unix, and too much manual messing about. Lastly I am very impressed with Sonny's analytical approach to the implementation. I have been around computers, both hw and sw since 1965. It is not often that I see good product management and feature control combined with good design. Coupled with his approach to machine safety it is a great combination. |
|
Having used TurboCNC (DOS), Mach3 (Windows), LinuxCNC (Linux), and Grbl, here are the benefits and shortcomings of Grbl as I see it: Benefits:
Current Grbl Shortcomings (My view and in order)
|
|
@109JB : Your list looks remarkably like my short-term development path. :) |
|
It's nice to see you discussing how to move forward away from the 328p, Arduino has done some amazing things for hobby electronic projects but for the last few years it has seemed to be holding them back, Marlin Firmware (for 3D printers) are also in a transition phase to ARM. ARM mbed OS5 is rather large, but can be cut down significantly through configuration to pretty much just the HAL, I'm still not sure it will have the performance or an acceptable footprint but I just I thought I would make sure you are aware of how far that project has come along and how many devices are supported, mbed-cli means it's not cloud based anymore which is a godsend. The main issue I still have with mbed is that "supported" is relative apparently. I'm looking forward to seeing how this progresses. |
|
@p3p : From what I can tell, most ARM manufacturers have a HAL through their software frameworks. I still don't know enough about them all to say how good or bad they are, but Atmel's ASF seems ok. Switching between Atmel MCUs looks to be straightforward, because they have plenty of examples to pull from. The NXP-Freescale Kinetis framework (Teensy) is very similar. Grbl's core doesn't use very many peripherals, just a few timer interrupts and some basic I/O. As long as this core is kept separate from everything else, Grbl ARM should be able to go to any platform and stay flexible for future developments. |
|
@chamnit ARMs mbed still relies on the manufacturers HAL, I guess its more of a HAL abstraction layer, but I agree that with the minimal use of peripherals in grbl core it wouldn't be worth the overhead, especially if you go with the grbl co-processor design and keep any extra interfaces separate (sdcard, ethernet ect) |
|
Yeah, 13 LED, rookie error. sigh. Good point on the EEPROM. Does EEPROM Emulation as discussed in the PJRC Teensy 4 description page not work for you? I reworked the doc and added alternate pin assignments if any of the i2c channels were to be needed. One channel is on the back side pins |
|
oops, here's the doc I also added a "simple machine" definition. The goal is to ensure that people don't need to use the SMT pins in order to prototype a simple machine. |
|
Support for external EEPROM via i2c is also good, if possible to use both.
There are some shields that are starting to add some i2c eeprom chips (I
mean, I am adding one to my shield project, but I am sure there are others).
…On Thu, Feb 13, 2020 at 11:52 AM phil-barrett ***@***.***> wrote:
Yeah, 13 LED, rookie error. sigh.
Good point on the EEPROM. Does EEPROM Emulation as discussed in the PJRC
Teensy 4 description page not work for you? I reworked the doc and added
alternate pin assignments if any of the i2c channels were to be needed. One
channel is on the back side pins
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#67?email_source=notifications&email_token=AAAM55IFZ2NBIZPIJWRM7GLRCV3D5A5CNFSM4CZY5V2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELVXSVY#issuecomment-585857367>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAM55PG2JS4NJHUNKLCRATRCV3D5ANCNFSM4CZY5V2A>
.
|
Yes, agree it's worth allowing. Plus I2C is a very useful expansion bus so having the ability for at least one channel is a good thing. |
|
I think I would be remiss if I didn't suggest that we might move this conversation to https://github.com/terjeio/grblHAL/ (or some other more appropriate venue). If no one cares, I'm fine continuing here. |
|
EEPROM emulation works, the easiest to add I have to say, but I am not fond of storing settings in flash. I am using the Arduino IDE for building so a fair bit of low-level code is already present, however I try to bypass as much as possible for speed. Having an I2C port can be useful for other stuff too, my BoosterPack design has one with a level shifter for selectable 3.3V or 5V operation. Currently I use it for a keypad (jogging etc) and for communicating with the ATC I am experimenting with. Is anyone prepared to do some testing? |
|
@terjeio I am getting a Teensy 4 delivered tomorrow, but I don't have a machine hooked up yet, but I want to test anyway @phil-barrett Maybe there's a forum or Discord or something? This issue became the best place to learn about GRBL/others running into ARM/modern MCUs |
|
@tereio I will do some testing for sure. Not on a real machine right away but have bits and pieces I can cobble together to at least see it running steppers and various inputs like limits and such. I've got too many projects going to switch my machine over right now. I've been planning a rebuild of the electronics so can do some real machine testing at that point and I'll want to make a break out board for it. Probably weeks away from a real test. I believe Paul at PJRC has EEPROM emulator for teensyduino. It really is a very high quality Arduino IDE add on. And, I want to say, thanks for doing this. I really do appreciate your efforts. |
|
I need a few days before I can commit a driver to my gitHub account. Discussion can then move over there. Major bits still missing are input signal handling and native USB > serial. |
Under the "Controllers" category on MakerForums is probably a decent place: https://forum.makerforums.info/c/controllers/99 There are several GRBL projects already on there (AVR, LPC, ESP32), so it'll be in good company. 😄 |
|
Driver for Teensy 4.0 is now up. EDIT: info for speed freaks - stepper isr execute time is 250 - 400ns... |
|
I agree with the thinking that grbl was successful because it started on standard hardware. Now that it is successful it can reach further out if the hardware is solid. |
|
I agree though would add the most important need is a binary distribution based on a standard pinout so people don't need to install Arduino to build the binaries. Terje's GRBL/HAL is very capable and runs on a broad number of ARMs. The Teensy 4 (imxrt1062) port is working pretty well. Needs more testing - which I have been doing on my board - GRBL Teensy 4. People are welcome to use it. I've placed a version on OSHPark but honestly, it's cheaper and faster to go JLCPCB or others. They built my first batch of PCBs and did a good job - 6 days from start to finish, last week. 10 boards for $22 USD. I intend to release it into Open Source once finished and will provide full gerbers. There is a pinouts document in the repository that defines the Teensy 4 pinout scheme for GRBL/HAL. As a starting point, at least. The Teensy 4.1 is coming and will be able easily support a 5 axis machine. I have a couple other designs that work with other processors - I am getting ready to fab a MKRZERO version though it's limited pin count means it will be for a fairly small machine. |
|
Phil, that's great! Thanks for this! |
|
It's been a while since I last checked in here (or used my own CNC). If you have a look at for example: Bigtreetech Skr V1.3 3D Printer Board 32Bit on Aliexpress: It's hard to compete as a hobby with such prices. USD17 for a board with a LPC1768. (Without stepper motor drivers). https://github.com/bigtreetech They also have boards with STM32F407ZGT6 I accidentally bumped into this company on Aliexpress and bought a "TFT 1.5-V2.0" from them, just because it was about the cheapest PCB with both an TFT with touch screen and STM32F103VCT6. I have not powered the board up yet. |
|
I did not see a GRBL board there. The company looks very focused on the 3D Printing market with Marlin support. It would be possible to port GRBL to those boards and there may be a port out there. There is no question that "China Inc" can produce very low cost products. For CNC, I want something focused on that rather than a repurposed 3D Printing controller. |
|
I run grbl on a bigtreetech board with an STM32F407 and TMC5160 drivers |
|
did it come stock or did you have to load it yourself? which grbl variant are you using? |
|
my own port of gbl-mega |
|
SuperGerbil: Another STM32F103C8T6 fork. While researching info to put an STM32 fork of Grbl on a (probably clone, you know, "China"...) I bumped into SuperGerbil (3D printer board with 5 step-sicks) and MiniGerbil. (For laser engraver with 2 step-sticks). It's also STM32F103C8T6 and it was a kickstarter in 2018. https://supergerbil.com/ |
|
Has anyone ever considered using the Adafruit Feather/Metro M4 products for running GRBL? I'm an awful programmer so I wouldn't even know the steps involved in making GRBL run on different platforms. Is it a huge lift? |
|
The ATMEGA's are a bit strained for GRBL, but apparently lots of folks are still happy with them, but I never bothered. GRBL already runs reasonably well on the old AVR's and all those mentioned above are much speedier. I am very doubtful that the fast Teensy 4 has any benefit for GRBL. If you don't want to fiddle with firmware yourself, then I recommend to just buy a board with GRBL already installed. |
|
Check out grblHAL. It runs on a variety of ARM processors. It was designed to be portable via a Hardware Abstraction Layer (thus, grblHAL). The big advantage is that all the processors specific code is isolated to basically one file and you don't need to know much about how grbl works. Unfortunately, the SAMD51 is not currently supported. If you are looking for a 5 axis breakout board and don't mind using a Teensy 4.1 (600 MHz, ARM M7), then take a look here. The cost of the extra speed is marginal. |
I just took a peek at this board, IMO this is not a good target for anything but a basic grblHAL driver due to the limited number of pins brought out. Not worth the effort even if it is a very capable processor?
That depends on your application. E.g. if you want to do high speed laser raster engraving then I have managed to sustain > 70000 mm/min feed rate with a T4.1 (planner buffer size @ 1400 entries). For that a fast CPU and plenty of RAM is required.
grblHAL has driver support for that too, Trinamic support is work in progress. |
It isn't that simple. The newer ARM based boards (iMXRT1062 in the Teensy included) have faster speed, larger flash and ram and more pins. grblHAL supports up to 6 Axes (my Teensy board supports 5) and lots of new features via plug-ins like TerjeIo said. The cost of the additional performance and space is pretty much marginal. You may be overpaying by pennies for the extra performance. And, I think it worth pointing out that the Blue Pill is not a very good example of a "cheap" processor as it is inconsistent in quality and features. The likelihood of getting a Blue Pill with an actual STM processor is pretty low - 6 different fake STM32F103 chips have been identified. Plus, unlike the Arduino, Teensy, Feather, Pico et al, there is no real definition of Blue Pill hardware - you are at the mercy of the vendor's suppliers. Blue Pill is a classic "race to the bottom" scenario. Personally, I think basing a breakout board on a Blue Pill would be a nightmare but if someone feels strongly about they should absolutely do it. grblHAL runs on the STM32F103. |
|
I've also run about 7000mm/min on a "Blue Pill" on my CNC, which has 2Nm closed loop Nema23 steppers and a 1605 ball spindle and microstepping. GRBL is set for 640steps/mm. I reduced the maximum speed and acceleration partly because the steppers loose most of their torque at those speeds, but mostly because those fast rapids are too fast to push the emergency stop button if needed. bCNC also does quite a good job in minimizing rapids, so the issue is no big issue anyway. 7000mm/min = 116.67 mm/s I'm not sure, but I think I did tests up to 8000mm/min and it cropped out about there. I don't know if it was because of the stepper motors + drivers, or because of the STM32F103C8T8. I have not taken any measurements to diagnose, just dialed the settings back. I have not used grblHAL (yet), and have no experience with those plugins. The "Blue Pills" are unfortunately pretty much a dead end. My last bath of 10 were fakes (had to change programmer ID) and I'm thinking of just throwing them away cause I don't want to waste time on them. STM32F401 or STM32F411 may be a better choice these days: Also weird: |
I wrote 70000 mm/min 😉 The Pi Pico is an interesting board, wonder what can be achieved with PIO and the second core... Expect a grblHAL driver soon. |
|
Thanks everyone for the great information! @terjeio I'm loving the idea of the Teensy4.1 running grblHal. This is for a k40 laser engraver that I'm currently running GRBL on an Arduino Nano. It really struggles with raster images and I've noticed that when it runs out of instructions (I assume that's what is happening) the laser head will stop for a split second leaving a little pinpoint burn in the engraved image until it can process some more moves. I'm hoping that a control board that can read in and process gcode faster with larger buffers will help that. I'll read through all of the documentation on your port and I'll probably have questions which i'll post there. Thanks again everyone! |
|
I've been using GRBL for years on my CNC but this is inspiring me to )yet again) consider an upgrade to a D21 MCU and grblHAL. There were some nice boards available from Mattairtech, and they have a superb arduino boards distrubution that supports the whole range of SAMD21/L21/E21 and D51 MCU's. Unfortunatly they are discontinuing their development boards. If people are really keen to try out a D21 breadboard compatible board with GRBL then I have some home brew ones for the 48 pin D21 - the design philosophy is to break out every single pin in order into a breadboad compatible module so its a close to using the raw MCU as possible. I'm not (yet) selling them commercially but I would consider making a few to order if people really wanted to try one out. I was contemplating a home brew CNC board using the D21 and with support for six axis. I got as far as sketching out a design that uses the Pololu stepper driver boards, and had them in groups of four with mounting holes for a cooling fan over each group. I might dig out the design and try and finish it - another lockdown project! |
and others
Freely discuss your opinions on an ARM platform for Grbl, moving forward after v1.1.
The text was updated successfully, but these errors were encountered: