Hi,
I stumbled upon GRBL while trying to get my CNC-ready development environment and I am curious about the actual performance as a real-world 3 axis controller. What kind of speed/inches per minute can be expected, compared to a full blown LinuxCNC or Mach3 setup?
Most importantly, do the Arduino/microcontrollers posses "real-time features" due to their simplified electronics? I am surprized, shocked even, at how well the Arduino/GRBL seems to be overcoming this biggest hurdle...real-time pulse consistency.
Any input/observations from people that are using GRBL would be appreciated.
I think you will find very little GRBL info on this Forum. Is there a GRBL forum or Wiki? And try some of the CNC forums.
As far as I know GRBL uses the same GCode thal is used by LinuxCNC or Mach3. Presumably the performance depends on the mechanical setup that it is driving?
Most importantly, do the Arduino/microcontrollers posses "real-time features" due to their simplified electronics? I am surprized, shocked even, at how well the Arduino/GRBL seems to be overcoming this biggest hurdle...real-time pulse consistency.
Microcontrollers are 100% real-time and deterministic.
You should be shocked at Windows/Linux CNC controllers. :~
You can also see TinyG
which I have been told (by no less an authority then the author of TinyG) is much better then GRBL.
It looks like they also have a version for the Due.
Nothing with interrupt handlers is fully deterministic. Deterministic
timing means exact to the clock pulse, the same every time.
Real-time means guaranteed response within some specified time limit.
LinuxCNC runs on a real-time version of Linux. The response time
depends on the speed of the hardware, but remember the hardware is
1000 times faster than a microcontroller, so a few dozen us is typical.
That's not much more than the jitter caused by the timer0 interrupt on
an Arduino.
Most importantly, do the Arduino/microcontrollers posses "real-time features" due to their simplified electronics? I am surprized, shocked even, at how well the Arduino/GRBL seems to be overcoming this biggest hurdle...real-time pulse consistency.
Microcontrollers are 100% real-time and deterministic.
You should be shocked at Windows/Linux CNC controllers. :~
which I have been told (by no less an authority then the author of TinyG) is much better then GRBL.
It looks like they also have a version for the Due.
Wow. TinyG looks awesome. 50mhz clock speed. It seems to make the most sense to have the pulse stepping done on a specialized board vs pc based RT kernels.
This really takes a huge burden off of the client side programming job. Totally changes the equation in the CNC landscape by eliminating the parallel port pulsing standard model of doing things. This is even better than the new USB stepper drivers. This is like the big fancy industrial grade CNC centers do things. Awesome.
I wish you told me months ago though. haha
You answered my main question which was 'do microcontrollers naturally good at real time/deterministic jobs'. Excellent.
MarkT:
Nothing with interrupt handlers is fully deterministic. Deterministic
timing means exact to the clock pulse, the same every time.
Real-time means guaranteed response within some specified time limit.
LinuxCNC runs on a real-time version of Linux. The response time
depends on the speed of the hardware, but remember the hardware is
1000 times faster than a microcontroller, so a few dozen us is typical.
That's not much more than the jitter caused by the timer0 interrupt on
an Arduino.
Thanks Mark,
I have a lot of interest in the old school parallel port/RT path if it is still applicable. Any info concerning the pros and cons of each way is greatly appreciated.
I just ordered up the gShield v5. Couldn't resist. Thanks for the tip.
Nothing with interrupt handlers is fully deterministic. Deterministic
timing means exact to the clock pulse, the same every time.
Ok, if an interrupt comes in during a 2-cycle operation (and I think the AVR has few of them), then the instruction is going to complete. So there is (at 16mhz) 62.5ns of jitter.
Real-time means guaranteed response within some specified time limit.
LinuxCNC runs on a real-time version of Linux. The response time
depends on the speed of the hardware, but remember the hardware is
1000 times faster than a microcontroller, so a few dozen us is typical.
That's not much more than the jitter caused by the timer0 interrupt on
an Arduino.
Well, it doesn't make much sense to compare latency with jitter. And latency is unimportant for a timer-generated interrupt. But I suspect if you compared jitter/latency on an AVR to jitter/latency on RTLinux you would find the AVR 'wins'.
Of course, for CNC use, it really doesn't matter. I use DOS-based TurboCNC for my CNC needs, and what I like about it is...low latency. 8)
I turn on the computer, it boots from a compact flash card, and about 18 seconds after turning it on it is ready to go!
I've been curious about this for a few months now, but I haven't really got past buying my steppers and driver boards.
It seems to me the critical requirement for CNC is to maintain the relative positions of the various stepper motors so that the tool tip will follow the intended path. I don't see any problem programming an Arduino to do this. Whereas I can see that the latency (I thing that's the correct term) inherent in the USB system might not be able to maintain the relative positions if stepper motors are controlled by pulses sent directly over a USB connection.
And it seems to me that speed is a separate matter. On the one hand there is the maximum speed at which the "computer" can generate pulses for the motors and on the other hand there is the speed at which the motors are capable of moving without losing steps (not to mention the speed at which the tool can remove material). I assume that an Arduino Uno or Mega is fast enough for Home/DIY CNC.
One of the things that continues to intrigue me is the general decision (inherent in GRBL and other Arduino CNC / 3D printing programs) to interpret the GCode on the Arduino rather than on the PC. Doing it on the PC would seem to make the job of the Arduino a great deal easier thus allowing for fatser speeds.
Robin2:
One of the things that continues to intrigue me is the general decision (inherent in GRBL and other Arduino CNC / 3D printing programs) to interpret the GCode on the Arduino rather than on the PC. Doing it on the PC would seem to make the job of the Arduino a great deal easier thus allowing for fatser speeds.
...R
Good question. Seems that the actual gcode interpretation could/should be done client-side, ideally. I imagine it's to keep things as simple as possible. Certainly should be able to pre-process the translation from gcode into a flat file that the Arduino scans line by line. I will say that, from what I have seen, it is driving steps at a very respectable speed regardless.I would assume the developers are making future plans along these lines.
Most importantly is the concept of using small microcontrollers to totally replace the PC/parallel port standard way. Seem to make lots more sense. Horses for coarses. No more trying to get 'real-time' pulsing from a 'personal computer OS'.
I just ordered a Due and a gShield. With an Uno, Due, and gShield supposedly you can run GRBL and tinyG on the Due. I plan on putting through some paces shortly.