Arduino GRBL VS LinuxCNC

[wizard]

Anyone work with the Smoothie Board ?

Haven't used that.

From what I can tell, motion algorithm is equal to the tinyg, and adds quite a few other features (like built in networking) but WHERE are the user interfaces that the CNC world is both used to and will demand ?

Even GRBL in the latest release runs "smoother" algorithms, the software for these microcontroller based systems is improving rapidly.

As for software that is a different ball of wax. The common approach is to use a G-Code sender app to stream a G-Code file to the micro controller. There are some more elaborate apps that emulate more robust CNC user interfaces. Generally up you need to look on the respective sites to find what you need. You might find a need to do some coding on your own too, to get exactly what you want.

I can't find any so far......

Software is out there but don't expect LINUXCNC or even Mach like interfaces.

Here Is developer info: https://github.com/grbl/grbl/wiki/Interfacing-with-Grbl and user info here: https://github.com/grbl/grbl/wiki/Using-Grbl. Well that is for GRBL anyways, it takes time to register or find all of this info.

[109jb]

Yeah, the GUI's are a bit lacking for the GRBL based microcontrollers, but they really aren't too bad. I have been doing quite a bit of research lately for them and it seems to me that any of the GRBL GUI's should work with TinyG as well since both use the same subset of G/M codes. The GUI's are just streaming the code through USB to the microcontroller. Having worked many years ago on production VMC's, I would say that some of the GRBL based GUI's have more features and functionality than those old VMC's I used to work with. Sure the available GUI's aren't on a par with the modern stuff in the production side, or even the mach 3 or linxCNC offerings. They do however have all of the functionality needed for at least a 3-axis machine. The GUI's are mostly open source and you can go in and modify to your hearts content if you have some programming knowledge. I myself am planning to do some modifying of the "Universal G-code Sender" GUI once I get my machine up and running again. As with all things in this realm of DIY CNC, there are tradeoffs, and the decisions on many of these come down to personal preference. For me, a full blown GUI is not as important as a motor controller engine that is rock solid. As long as the GUI has enough to handle the basics I am happy. Others may feel the need for more and that is a personal choice.

As for the Smoothieboard and TinyG, I see another drawback, at least for me. Both of these boards have integrated stepper motor drivers, but they are limited to about 30V and 2A, which isn't enough to drive the steppers on my current machine. The TinyG board has solder pads where you can pick off the step and direction signals, but that requires soldering to a brand new board. Not sure if the Smoothieboard has this. The GRBL Arduino and TinyG2 firmware on Arduino DUE are attractive because they have the pin sockets that will accept plug in connectors and not require soldering. I also prefer separate drivers because if one goes bad, I can just replace the individual driver whereas if using the on-board drivers, if one goes bad you either need to do component level repair work, or replace the whole board. Some people prefer to have everything integrated and to them it may be a plus to have this. The Smoothie and TinyG appear to be well thought out and well designed for their target audience. There again, everything is compromise and I'm sure the designers were thinking mainly about making their target audience happy rather than a few outliers.

As Wizard mentioned, GRBL's most recent release included a re-vamp of the stepper algorithms, and is said to be much smoother than previous versions.

I'm anxious to get the parts I ordered and try this out.

John B.

[RotarySMP]

The show stopper for TinyG and GRBL for me is that they do not support lathe threading. Without a spindle encoder input and spindle syncronised motion, rigid taping on a mill is also not going to happen.

Mark

[109jb]

The show stopper for TinyG and GRBL for me is that they do not support lathe threading. Without a spindle encoder input and spindle syncronised motion, rigid taping on a mill is also not going to happen.

Mark

Yep. For a lathe it is not going to be useful without spindle sync. I sent the developers a message and was told that it is one of the things on the to do list, but it is nowhere near the top of the list yet. Hopefully it can get to the top sometime soon.

For a mill, it is not 100% necessary to have spindle sync.All it really means is that without it, you can't rigid tap. I usually just pull the part off and use a tap block and a cordless drill to tap the holes anyway. Not a deal breaker on a mill like it is on a lathe.

[wizard]

The show stopper for TinyG and GRBL for me is that they do not support lathe threading. Without a spindle encoder input and spindle syncronised motion, rigid taping on a mill is also not going to happen.

Mark

While true let's not forget that this is probably the absolute lowest cost way to implement any sort of CNC machine. Combine that with efforts a foot to port to more advanced microprocessors and the future looks bright. In the context of this thread it is suitable for a low cost router since such a machine would be doing rigid tapping anyways.

[captbill279]

This is the future for anything that benefits from a 'Real-time OS'. Multi-tasking OS' cannot keep high resolution 'clock time', plain and simple. It has to be 'emulated' to some degree and approximated. This is 'soft real-time' at best.
Microcontrollers are much simpler and run a RISC OS (Reduced Instruction Set Computer). As a programmer you can keep track of the system clock MUCH easier.

The only issue is that this type 'software programmable hardware' concept is a brand new exciting concept. A whole new ball game. Definitely the way forward though. GRBL and TinyG seem quite capable and rather complete. It is the software 'front ends' that are less polished. GRBL separates the 'real-time' code into a type of hardware driver to be used by programmers to create CNC/motion control 'programs'. It blurs the line between a piece of hardware and the typical commandline application. No need for the programmer to do any real-time and low level programming. When the programmers get up to speed with this whole new concept, we should expect great things.

Even better: The FPGA (Field Programmable Gate Array)
Wait until what THESE are capable of.

[109jb]

The show stopper for TinyG and GRBL for me is that they do not support lathe threading. Without a spindle encoder input and spindle syncronised motion, rigid taping on a mill is also not going to happen.

Mark

I was thinking about the issue of not having spindle synch for lathe threading and had an idea. I posted the below text to the GRBL github issues as a possible idea for spindle synch using a servo drive for the spindle drive:

"I have been thinking about the issue of lack of spindle synchronization as it relates to lathe operation and I think I have an idea for smaller lathes t least. I have a 9 x 20 lathe that I also have a surplus DC motor that I intend to use for a spindle drive. If I were to add an encoder to the motor and drive it using a servo driver such as the Gecko G320X, GRBL would see the motor as simply another step/direction motor like a stepper. All of the encoder and servo feedback control would be internal to the Gecko driver. The motor could then be hooked to the spindle with a timing belt drive so that the motor position could be related to spindle position. Since GRBL is 3-axis only, the normal lathe X and Z axes would take up two of the available axes, leaving the third available to control the spindle motor through the Gecko driver. Since the motor would be seen as just another axis, then coordinated motion would be possible, allowing lathe threading. The issue is how to implement this within GRBL.

For example for a lathe, lets say you set up the spindle as the Y-axis with a distance of 1 inch corresponding to one revolution of the spindle. A G91 command of G1 z-1 y10 would give a 10 thread per inch type of move. But this isn't the way that lathe threading is normally programmed and doesn't account for non-threading use where you would want the spindle to run continuous at a set rpm.

This could also be applied to mill spindle synchronization in a similar fashion allowing rigid tapping but would require a fourth "axis".

I think the use of a servo for the spindle drive could provide a way to incorporate spindle synchronization in a fashion that is possibly easier than having an encoder and index pulse mounted to the spindle that GRBL would have to monitor and adjust the other axes for. The servo drive on the spindle would adjust to keep up rather than having to have GRBL adjust the other axes due to spindle speed fluctuation.

I think it should be possible to have the GUI interface handle most of the heavy work with GRBL just keeping track of the spindle position by keeping track of the number of step pulses sent to the driver.. The gui could then convert any type of canned threading cycle into a series of G1 coordinated motion commands. For example. for this G33 threading code snippet:

G90 (absolute distance mode)
G0 X1 Z0.1 (rapid to position)
S100 M3 (start spindle turning)
G33 Z-2 K0.125 (move Z axis to -2 at a rate to equal 0.125 per revolution)
G0 X1.25 (rapid move tool away from work)
Z0.1 (rapid move to starting Z position)
M2 (end program)

The gui could easily calculate that the Z axis has to move a total of 2.1 inches and with a K value of 0.125, there would need to be 2.1/0.125=16.8 revolutions of the spindle. To get 300 rpm out of the spindle if set up for 1 unit=1revolution, the feedrate sent to GRBL would have to take into account the Z axis travel. So, the feedrate sent to GRBL would be (300/16.8)*(16.8^2_2.1^2)^0.5=302.33 IPM and the thread would be cut. GRBL would just see a G1 F302 Z-2 Y16.8 where Y is the spindle servo. I used G33 because it is simple to illustrate.for this you would have to provide a thread relief cut at the end of the travel since the spindle would stop in this example.

The only thing I am not sure of is how you would keep the spindle turning say for non-threading commands. Maybe a simple binary variable that grbl uses to know if the intent at the time is syncronized motion or not. Or implement a G33 within GRBL that is simply the same as a G01 except that using it tells GRBL to convert M3/M4 SXXX commands into syncronized motion.

Just thought I would throw this out there as a possibly easier way to implement spindle synch. Much of the above is simply rambling while thinking about this. Would something like this be possible?

[109jb]

This is the future for anything that benefits from a 'Real-time OS'. Multi-tasking OS' cannot keep high resolution 'clock time', plain and simple. It has to be 'emulated' to some degree and approximated. This is 'soft real-time' at best.
Microcontrollers are much simpler and run a RISC OS (Reduced Instruction Set Computer). As a programmer you can keep track of the system clock MUCH easier.

The only issue is that this type 'software programmable hardware' concept is a brand new exciting concept. A whole new ball game. Definitely the way forward though. GRBL and TinyG seem quite capable and rather complete. It is the software 'front ends' that are less polished. GRBL separates the 'real-time' code into a type of hardware driver to be used by programmers to create CNC/motion control 'programs'. It blurs the line between a piece of hardware and the typical commandline application. No need for the programmer to do any real-time and low level programming. When the programmers get up to speed with this whole new concept, we should expect great things.

Even better: The FPGA (Field Programmable Gate Array)
Wait until what THESE are capable of.

LinuxCNC users have been using FPGA for quite some time in the form of MESA FPGA cards

anything i/o

The issue for me is cost. Even though these FPGA cards aren't terribly expensive, costs do add up and GRBL is advantageous because of the super low cost of Arduino compatibles due to the open source design of the Arduino hardware. I hope to have GRBL working for about $10 because of this. That's pretty cool for me since this is a hobby for me an I have to pinch my pennies to be able to do anything CNC.

[RotarySMP]

Hi 109jb,

Your concept will of course work, but most lathes have an induction motors for spindle drive. If you want to retrofit them, replacing that motor (which may be anywhere from 0.5-30kW) with a servo is going to be unacceptably expensive for larger machines.

[109jb]

Hi 109jb,

Your concept will of course work, but most lathes have an induction motors for spindle drive. If you want to retrofit them, replacing that motor (which may be anywhere from 0.5-30kW) with a servo is going to be unacceptably expensive for larger machines.

Yes, this is envisioned for "smaller machines", where it is cheap to retrofit with a servo. For example, My 9 x 20 I believe has a 1/2 hp induction motor (might be 3/4, not sure). In this case, I can retrofit with a surplus DC motor for about $40 and a surplus PWN controller for about another $40 for general turning without synchronized motion. Changing this to be a servo uses the same motor but requires a servo controller and an encoder, but eliminates the need for the PWM controller. The encoder is $40 and the Servo drive is $110 for a net increase of $110. Certainly for larger machines the cost will be prohibitive fast. My motor that I bought is about 2 hp continuous duty and upwards of 3 hp intermittent. This should be adequate for a wide range of home shop type lathes and mills for that matter.

What I don't know how to do is implement this in GRBL or tinyG. With the open source code, it should be able to be modified, but I don't know if I am a good enough programmer to do this, but I will likely try after I get my lathe CNC'd and retrofitted with the DC/PWM motor.

John B.

[109jb]

I got my Arduino NANO finally. It apparently got lost in the mail between me and the other side of the world. In any case I was able to get it all fitted out for use. At this point the only features I will be using are 3 steppers, 3 limit switches, and 1 probe. I will be using this on my G0704 mill that was already set up for LinuxCNC running through a parallel port breakout board. Right now I am just going to be trying out GRBL, so I didn't want to remove the breakout board and wanted a quick and easy way to switch from GRBL control back to the LinuxCNC setup. What I wound up doing is cutting the end off of a parallel port cable, checking the wires with a meter to determine the pin/wire configuration of the cable, and then soldering the appropriate wires from the cable to the NANO. I put the NANO in a small project enclosure and I think it came out pretty good.







I had another breakout board like my mill has, so I hooked up a spare driver and stepper motor to it and ran a test. It worked awesome and was very smooth. Didn't get a pic or video, but it worked great.

John B.

[datac]

Neat... keep us up to date as to what you learn. You certainly did the right thing by just creating a quick interface so you can switch between the old and new until you dial everything in.

[trentster]

I got my Arduino NANO finally. It apparently got lost in the mail between me and the other side of the world. In any case I was able to get it all fitted out for use. At this point the only features I will be using are 3 steppers, 3 limit switches, and 1 probe. I will be using this on my G0704 mill that was already set up for LinuxCNC running through a parallel port breakout board. Right now I am just going to be trying out GRBL, so I didn't want to remove the breakout board and wanted a quick and easy way to switch from GRBL control back to the LinuxCNC setup. What I wound up doing is cutting the end off of a parallel port cable, checking the wires with a meter to determine the pin/wire configuration of the cable, and then soldering the appropriate wires from the cable to the NANO. I put the NANO in a small project enclosure and I think it came out pretty good.







I had another breakout board like my mill has, so I hooked up a spare driver and stepper motor to it and ran a test. It worked awesome and was very smooth. Didn't get a pic or video, but it worked great.

John B.

This is a really cool idea! - I think I am going to try and do the same, do you by any chance have some docs on the wiring connection you used ?

[109jb]

This is a really cool idea! - I think I am going to try and do the same, do you by any chance have some docs on the wiring connection you used ?

I don't really have anything. On the parallel port cable, I just used a meter and probed the pins and the soldered them to the arduino nano according to the pin out on the GRBL wiki page. The nano and the uno have the same pin out. The nano is just smaller.


Sent from my iPad using Tapatalk

[tekno]

nice read - gonna tag for updates

[109jb]

I have my new GRBL user interface available. Here is a screenshot and a link to more info in the thread about my machine

http://www.cnczone.com/forums/bencht...ml#post1771134

[gharley]

I realize I'm coming to this party quite late but if you are considering the move to GRBL this might be of interest...https://www.thingiverse.com/thing:2731388

[109jb]

I realize I'm coming to this party quite late but if you are considering the move to GRBL this might be of interest...https://www.thingiverse.com/thing:2731388

I used a Nano clone with the CH340 USB to serial chip, but would not recommend any board that has the CH340 for CNC use. If you decide to use a Nano, make sure to use a genuine Nano with the FTDI Usb to serial chip. The CH340 has a problem that doesn't occur often, but it can drop parts of a command line when used with Grbl. I have since abandoned my Nano converter in favor of a Uno cloe with a Atmel 16U2 USB to serial chip. Either the FTDI or the 16U2 should be OK, but not the CH340. Al least not in my opinion.

[gharley]

I used a Nano clone with the CH340 USB to serial chip, but would not recommend any board that has the CH340 for CNC use. If you decide to use a Nano, make sure to use a genuine Nano with the FTDI Usb to serial chip. The CH340 has a problem that doesn't occur often, but it can drop parts of a command line when used with Grbl. I have since abandoned my Nano converter in favor of a Uno cloe with a Atmel 16U2 USB to serial chip. Either the FTDI or the 16U2 should be OK, but not the CH340. Al least not in my opinion.

Thanks for the feedback, I am using a clone with the CH340 chip and it seems to work well but I have seen occasional issues that require a reset and might be explained by what you describe. I will look for clones with the other chips as I really can't justify 10x the cost for "genuine" Arduino.

[109jb]

Here is an Uno from sainsmart for $10 that has the 16U2

https://www.sainsmart.com/collection...ino-compatible