ARM discussion

[chamnit]

Freely discuss your opinions on an ARM platform for Grbl, moving forward after v1.1.

[alpharesearch]

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. So my question is what board with the right hardware fits the bill for the future. I didn't spend much thought on this yet, but i was interest if someone has any good idea. Like the Teensy 3.5/6, however these boards are not FOSS as far as I understand. This may be an issue for some people. The Arduino Due is only M3 and @Strooom suggested to use something with M4F for faster floating point math. I just think it would be good to have one common platform at first to develop and test and know this works. The next question is how easy is it to connect this to stepper drivers end stops buttons displays etc pp.

[chamnit]

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:

• Even if its designed to be modular, it's much more difficult to port the code to another processor, whether it be newer, faster, better, or has a new built-in technology.
• You constantly have to worry about breaking something or screw with the critical timing of the core motion processes. This is a headache I'd like to avoid and is the main reason why I've never accepted pull requests.

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:

• Grbl, on a slow 16Mhz 8-bit 328p processor, runs great for a vast majority of CNC applications and then some. The new laser mode has been reported to do raster jobs with 0.1mm pixels at a rate of 700 pixels/sec. I've heard a report that Smoothie on a 32-bit ARM 100MHz Cortex M3 can only do 0.5mm pixels at a rate of 500 pixels/sec. I know that it's not quite apple to apples and just one data point, but I was quite surprised that Smoothie isn't running at least 10 times faster. It seems like it's only a minor speed improvement.
• If Grbl's code is that efficient, Grbl should run on any ARM processor selected and run very well on it. Even if Grbl uses a much cheaper Cortex M0 processor, it is theoretically 4x-10x times faster than the 328p. If Grbl on an M0 can just be 2x-3x faster in real-world performance, this can still address a nearly all of the CNC needs now and in the future.
• With my experience as a researcher, developing fast and efficient code and algorithms always trumps using a faster processor. I think Grbl on an M0 will be fine. Grbl on an Cortex M4F could be way overkill.
• If Grbl ARM is written to be small, portable, and independent of peripheral support, the processor selected shouldn't matter. It should be easily portable by design to a Cortex M4F if needed or to any manufacturer.

@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.

[usbcnc]

I have done initial porting of 1.1e to stm32F103RBT6, it can be viewed here https://github.com/usbcnc/grbl. The spindle control porting should be done next week. (I am a little busy this week). It does use USB VCP. It does run on my desktop CNC 3020.

I use free coocox IDE to compile and program (STlinkV2). I am new to CNC and cannot judge the performance difference. I will be more motivated if more people are interested.

[Strooom]

@alpharesearch I think the succes of GRBL is due to:

• good performance on a standard Arduino Uno, which is cheap and available
• running very well on a wide range of HW, due to plenty of configuration settings

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 :

• more axis, more limit switches, 3rd order speed profile, larger buffers... (just to name some that I'd like).

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!

@Stroom, there is only one @Strooom :-)

[chamnit]

@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.

[alpharesearch]

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?

[gerritv]

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.

[chamnit]

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?

[Strooom]

Teensy's bootloader chip is proprietary and $8 a piece

I was not aware of this. From a personal point of view, 8$ looks justified. From an OEM point of view I understand it may be a problem. I am a defender of the 'fair share' : for a long term success, all contributors need to get a fair share of the profits and credits. So when considering Teensy as a candidate for the future of GRBL, we need to discuss this with Paul Stoffregen and the top 5 'customers' (Carbide3D, Inventables, Openbuilds, ...)

It's a non-technical thing, but also important to get solved, and better to tackle it early.

[alpharesearch]

I just try to understand the situation, please correct me if I have a wrong assumption. As far as I understand using Teensy for development would at first would lock Grbl to Freescale Kinetis K64 ARM MCUs. The Teensy has a proprietary programming interface (is this a bootloader too?) that can be used with Arduino IDE. This allows for a easy entry for anybody that used Arduino before. Do the OEMs create their own boards from scratch right now? What other programming interface/bootloader exists for the Freescale Kinetis K64 ARM MCUs (from my short google search it looks like there is a "FRDM-K64F: Freedom Development Platform for Kinetis K64, K63, and K24 MCUs" with open source hardware and bootloader)? I would guess if OEMs have multiple options, include a original Teensy with their product or make there own programming interface/bootloader or use the FRDM-K64F design and bootloader. I just noticed the FRDM-K64F board today for the first time, would this be a reference design option?

[Strooom]

@alpharesearch FRDM-K64F looks interesting. Will look into its spec over the weekend.

[109JB]

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.

[chamnit]

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.

[Protoneer]

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" notifications@github.com 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 https://github.com/gnea/grbl/issues/67#issuecomment-267672105, or mute the thread https://github.com/notifications/unsubscribe-auth/ADqFI7pUsPM1VIkA_K810-JhAUsuzQEbks5rIuI1gaJpZM4LOO10 .

[usbcnc]

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.

[jahnj0584]

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.

[109JB]

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.

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.

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.

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.

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.

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.

[gerritv]

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.

[chamnit]

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.

[CreativeRobotics]

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)

[Strooom]

@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.

[CreativeRobotics]

@Strooom Cost, Simplicity, platform independence: For myself I like GRBL because it isn't tied to one OS like Linux and not everyone is a Linux user - I use Solidworks and CamBam for CAD and CNC work. Ultimately the only hardware that GRBL is tied to is the ATMega 328p. MACH is not free so for a hobbyist on a budget GRBL on an Arduino is a much better option.

[gerritv]

@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. Grbl also provides me with choices of GUI, if I ever get into laser stuff then I can use an appropriate gui for that, etc.. For my current needs I use my GrblPanel, etc.

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.

[109JB]

Having used TurboCNC (DOS), Mach3 (Windows), LinuxCNC (Linux), and Grbl, here are the benefits and shortcomings of Grbl as I see it:

Benefits:

1. Grbl offloads step generation to a platform that only does step generation and it does this at a very low cost. This is very important in my opinion and is the prime reason I even tried Grbl in the first place. I got to the point where I realized that external step generation was necessary and trying Grbl cost me $5 compared to getting a Mesa board setup for LinuxCNC at about $200. Options to do this are also available for Mach3 and other setups, but always at a much higher cost than Grbl. Generally $100-$200 more than the Arduino that runs Grbl. For me as a hobbyist, that is a significant cost.

2. Since Grbl runs on an Arduino, the User interface can be on just about any platform, from another Arduino, a Raspberry Pi, a Windows, Linux, or Mac box, or whatever can send serial data. This allows using obsolete laptops, that would generally not be suitable for LinuxCNC or Mach. I currently use a free netbook to run my user interface for Grbl, instead of having to have a desktop PC, monitor, and keyboard.

Current Grbl Shortcomings (My view and in order)

1. Lack of spindle synchronization for lathe threading, which is definitely a deal killer in regard to lathe usage.
2. Only 3 axis, would like at least 4 preferably 5 or more
3. No backlash compensation
4. No cutter radius compensation (can be overcome to some degree with CAM)
5. No native canned cycle support (I have canned cycles in my GUI so not as significant anymore)

[chamnit]

@109JB : Your list looks remarkably like my short-term development path. :)

[p3p]

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.

[chamnit]

@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.

[p3p]

@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)

[cube000]

Hello. I've created github account especially for joining this conversation. I'm using GRBL for couple of years for simple routers or another machines/robots (pick&place). Mainly advantage is that I don't need another PC for every machine and i don't need to learn any other programming language; everything are based on same gcodes. But there are really couple of things that i'm missing. 1) Spindle feedback would be great. I've done coil winder on two stepper motors, spindle and feed. It would be faster to do at single feed stepper motor and dc motor as spindle with feedback 2) 4th axis. I wonder of 4th axis with changeable destination. Axis, that could be configured as rotary axis (A - commanded by degree/radian) or another linear axis (mm/min) or as a slave axis that would follow one of main axis in machine. 3) cutter radius compensation - i'am working as big cnc machines technologist and i'am used to use radius comp.

About boards, suitable for next gen GRBL, what about MSP432P401R Launchpad from Texas Instruments? 40GPIO, Cortex M4F, Energia IDE (arduino clone for TI Launchpads) for 13$. Hmm?

[Strooom]

Are canned cycles and cutter radius compensation a thing for the future ? To my perception these are features which were useful in an era where GCode programs were written 'by hand'. Same goes for GCode with parameters..

Today I think the standard workflow is CAD-SW, CAM-SW and all the GCode is 'generated' for you, The post-processor which generates the code, does the cutter compensation for you, as well as generating the repeated sections for canned cycles...

So for the future of GRBL I think we need to understand why the above features are still important.

[CreativeRobotics]

My own experience has never required me to touch cutter radius compensation, it's all done by the CAD tools so I would agree with Stroom that the inclusion of these features needs careful thought given - we should not assume the target MCU will have significantly more resources than the current one, at least as far as the minimum specification goes.

I would be wary of basing anything on an MCU manufacturers development board, be it the TI one mentioned above, or the Nucleo line from ST. I would prefer a board that has an open source design and can be implemented with the most basic configuration (The 328P just needed a crystal and USB-Serial interface). The SAMD21 fits that bill for me as a candidate for the baseline hardware, with the option of moving up the ARM ladder if more power is required.

[cube000]

Of course canned cycles and especially tool radius comp are necessary! I.e. Haas mill. I've got macro/parametric subroutine made for planning surfaces. By changing couple of parameters i can roughen any size surface, with the tool that is best handy for now. So, to planning any surface should i run every single one time to computer, make new program in cam, copy to pendrive, run back to machine? Man, i'm not a marathon runner! Same situation with spiral milling of holes, length milling for bar stocks... I've got macros so many operations could be covered by one program. Supereasy.

Same as above refer to cutter radius comp. When i want to add another finish pass i can simply put -0.05 in compensation table and run same program without running to PC. What about indexable tools? Noone of them had nominal diameter. 20mm end mill would have about 19.9dia. With 3 flutes, i can not simply measure diameter without tool probe. Only by a first cut. So after first cut, should i run to computer change nominal diameter for tool, generate gcode, run back to machine? What about tool wear? After couple of parts done tool dia will decrease. When working with small tollerances, i don't need to perform another machine-pc-machine jogging. Another example: i'm out of 6mm end mills but i've got some of 5,5mm mill. I do not need to change program, simply by adding 0.5mm tool wear to tool compensation table, program does the job. Radius compensation is great thing and i would strongly recommend to add it.

[Strooom]

ok, thanks for your feedback. GRBL is being used in very diverse environments, and personally I never needed radius comp, canned cycles or parameters. Indeed I do run often from CAD to CNC and back to iterate programs. Maybe when having the feature above, I would learn to appreciate them.

thanks for your feedback - to be continued

[gerritv]

@CreateiveRobotics But each SOC has its own peripherals and other features so you are still having to choose a vendor. The advantage of chip vendor boards is that all of the SOC features are pinned out, as opposed to some 3rd parties idea of what you need for CNC. And they general supply long sale life and schematics as well as low cost. They generally also include hw debug/trace support, a vast improvement over printf style tracing. You add drivers and sensors to the generic pinouts, perhaps with a good quality breakout board. If you need to upgrade to better drivers, no problem.

Sonny has also already stated several times that the SOC will have enough power to spare for radius compensation and the canned cycles as well as other features. I don't know how many more ways he can say this.

[cube000]

I'm thinking about another things. More outputs commanded by Mcodes. Useful, in example for another type of coolant activation (mist), for clamping details or clamping tools, opening and closing doors, activating spindle dust cover and lot more. Just like M08 to turn coolant on and M09 to turn off, Mcodes above M100 could be used to done it. Output 1 - M101 (on), M111 (off) Output 2 - M102 (on), M112 (off) and so.

Are there any MCUs that have internal pulldown resistor? It would be nice to have NC limits inputs, which are much more resistible for external disruptions.

[electrokean]

I've seen a few mentions of using an "MCU manufacturers development board". I'm not sure about all manufacturers, but some have draconian restrictions in their license agreement due to the fact that these dev boards are subsidised.

For example, see the STMicroelectronics EVALUATION BOARD LICENSE AGREEMENT http://www.st.com/resource/en/license_agreement/evaluationproductlicenseagreement.pdf

STMicroelectronics (“ST”) grants You the right to use the enclosed Evaluation Board offering limited features only to evaluate and test ST products solely for Your evaluation and testing purposes in a research and development setting. The Evaluation Board shall not be, in any case, directly or indirectly assembled as a part in any production of Yours as it is solely developed to serve evaluation purposes and has no direct function and is not a finished product.

No idea how this could ever be enforced on a small scale, but I wouldn't risk it. In most cases the dev board isn't as necessary as it once was, considering the fact most modern MCUs can be brought up with minimal external components, and USB bootloaders are almost standard at the level of chip we're considering.

I'd be happy to work on an open source design, but I'm sure there are already some suitable ones out there. Organising manufacturing and distribution is much harder than the design process.

[DEHiCKA]

Please, consider Nucleo-64 boards from ST. They are cheap and easy to get worldwide. ST-Link debugger integreted and no proprietary bootloader needed. From M0 up to M4 cortexes in the same form factor. Wide RTOS support also.

[chamnit]

I'm skeptical of RTOS on a motion controller. Granted, you do have better control of processes than on a full-blown OS, but you still have some black-box interaction with it. There are plenty of effective methods to handle real-time tasks without an RTOS.

I'm not excluding ST controllers completely. I'd like to organize Grbl ARM to be relatively independent of the manufacturer. I know that's nearly impossible, but I think it could be possible with some additional help. Like a user-supported branch for ST. I do have an old LeafLabs Maple board with an STM32F103RB chip to test with. It has about half the flash and RAM of a SAMD21, but runs about twice as fast.

That said, I don't anticipate the SAMD21 being an issue. It has some interesting timer abilities that can offload a lot of real-time calculations, if done right.

[109JB]

Not everyone does everything in CAD/CAM. Assuming everyone uses a CAD CAM work flow is not based in reality. I personally do a lot of hand programming and canned cycles and cutter comp are definitely a part of that. I probably hand code about 75% of my jobs.

Also, just because you use CAD CAM doesn't mean that cutter comp or canned cycles aren't useful or even necessary. For example imagine a part that has one or more interpolated bores that have close tolerances. Further imagine that due to tool wear the bore is coming out undersize. It is a simple matter to adjust the radius compensation and move on, but if cutter comp isn't programmed then the only recourse is to either head back to the CAM and re-post, or hand edit the code. Both options are terrible in my opinion. Cutter comp cam be programmed in with the CAM software too. Same goes with canned cycles. Take a peck drill cycle where you decide that the hole needs to be deeper. Simple to change just the one Z parameter in the G83 cycle rather than have to add a bunch of G0 and G1 moves to add additional pecks.

As for the board that gets chosen. I don't much care except for a couple things.

1. It has to have an easy method to upload the firmware. The ease that UNO can be loaded with the Arduino IDE is one benefit that I think has spurred Grbl's popularity. Upload by USB and without external programming hardware would be best.

2. It has to be relatively cheap to acquire or Grbl loses a lot of its benefit. Less than $20 for a board is a necessity.

[DEHiCKA]

STM sells 3D Printer eval board: STEVAL-3DP001V1 It has STM32F401RE MCU, same as on $11 NUCLEO-F401RE board (84MHz Cortex M4 + ST-Link Debugger). They've recently ported marlin firmware for it: https://github.com/St3dPrinter/Marlin4ST

I think it can't be any cheaper for M4+Debugger and Arduino shield compatible.

[usbcnc]

Here is my take of STM32F103C8T6. https://www.youtube.com/watch?v=5DBtbAYmfEE&t=93s. It can run 180K steps/sec without any issue as is. It should be able to go a little faster. The board is about $2. The tool is free coocox and can program the chip within IDE. EEPROM is just simulated using 1K of ram and flash.

STM32F103RB is even better option. Porting to other higher end of STM32 family should not be of an issue.

[chamnit]

@usbcnc : For me, there are a lot more reasons to stay with the SAMD21, which have already been discussed here. However, I also understand the reason to go with ST, particularly if you live outside the US. As things start going with Grbl ARM, I'll be open to accepting help with an ST port, but I won't actively invest much time into it.

[langwadt]

if the all hw init and access was separated out from the main code, I'd like a separate file for easy maintenance, porting to any processor with the needed resources is easy.

I've ported grbl to ST a few times and most fo the work is finding all the places the code directly accesses avr specific things

[parnz]

@chamnit : SAMD21 doesnt have eeprom. Is this will be an issue?

[langwadt]

STM doesn't have eeprom either, it can usually be emulated with a sector of flash

[XRay3D]

It is better to add support for i2c bus and the eeprom chip, who collects cnc machines not so stupid to add one small chip in the future date it will be possible default stand Shield.

[DEHiCKA]

It would be really great to have a HAL layer. It's always major stopping point for me to port a project with hardware specific calls all over the code.

@langwadt Lots of the ST's M0/M3 MCU (L0/L1 series) actually do have an EEPROM.

[GNaruhn]

@usbcnc Have you already compiled a version for the STM32F4 used on the STM Discovery board?

[GNaruhn]

@DHKRUS same to me. I'fe just downloaded the Project from usbcnc and tried to change the mcu from STM32F103 to STM32F407. I get a lot of error messages and find in the whole project a lot of queries like #if !defined(STM32F103C8). This has to defined at only one point to make a project portable. :O(

[usbcnc]

@DHKRUS , No I did not. I think all my defs for STM32F103C8 can be replaced for STM32 and properly define it. However, I think VCP might not work and you need to remove USEUSB for now. I will try to compile for F4 and let you know what to do. I do not have F4 board to test though.