[BrendaEM]

Hi,

I am making a budget small milling machine. I to have on hand 3 of Polulu/Allegro stepper drivers, as well as a first generation Arduino Mega, bought for other things.
Is there a popular open source g-code interpreter available that might run a small mill?

My milling machine also has centering limit switches. Might these be supported?

Thanks for reading,
Brenda

[jfong]

grbl

[123CNC]

grbl

jfong beat me to it, see link Grbl Gcode Interpreter - Contraptor

Most of your DIY 3D printers are run based on G-Code interpreters, if you want a different flavor or variant.

[123CNC]

https://github.com/alx/reprap-arduin...nterpreter.pde

[Eddard_Stark]

I too have used GRBL on an UNO, which is much less powerful than the Mega, so that's where I would start.

[dwalsh62]

The problem with GRBL, Contraptor and RepRap (derivatives of GRBL) is they're not really suitable for milling machines due to the lack of support for tool DIA compensation and other essential gcodes used in normal milling processes.

There really isn't a decent g-code interpreter that supports the FANUC gcode instruction set that runs on an AVR or STM32, there's just too much missing that the limited supported g-code makes it difficult to do anything without making these compensations manually which can be a tedious and very time consuming task for a complicated part.

If I could find one that runs on an STM32 without the nonsense of embedded linux or other OSes I gladly release an STM32 based 4-axis milling machine panel which would pretty much solve a lot of the machine control problems users experience.

-- Dale

[jfong]

The problem with GRBL, Contraptor and RepRap (derivatives of GRBL) is they're not really suitable for milling machines due to the lack of support for tool DIA compensation and other essential gcodes used in normal milling processes.

There really isn't a decent g-code interpreter that supports the FANUC gcode instruction set that runs on an AVR or STM32, there's just too much missing that the limited supported g-code makes it difficult to do anything without making these compensations manually which can be a tedious and very time consuming task for a complicated part.

If I could find one that runs on an STM32 without the nonsense of embedded linux or other OSes I gladly release an STM32 based 4-axis milling machine panel which would pretty much solve a lot of the machine control problems users experience.

-- Dale

Not having g41/g42 tool compensation certainly hasn't stopped the multitude of machines such as Shapeoko/vcarve etc. from using Grbl. I personally haven't used it in the many years of using Mach3/linuxcnc which does support g41/g42. It's easy to enter the exact tool diameter in the CAM program to spit out the gcode. I don't run production parts, just custom one off pieces.

[dwalsh62]

Not having g41/g42 tool compensation certainly hasn't stopped the multitude of machines such as Shapeoko/vcarve etc. from using Grbl. I personally haven't used it in the many years of using Mach3/linuxcnc which does support g41/g42. It's easy to enter the exact tool diameter in the CAM program to spit out the gcode. I don't run production parts, just custom one off pieces.

Having the cam program make path compensations based on the tool DIA is not the recommended method and certainly means that any tool DIA changes require you to regenerate the cut path based on the changed tool.

G41/G42 are only a small portion of what is missing in GRBL.

Your suggested solution to the cut path problem is to modify normal processing in lieu of a capable g-code interpreter and because people use this method doesn't mean it's good or right, they do it because they have no other option when using GRBL.

The fact that GRBL has not been updated in functionality in such a long time suggests that the code base while still available has been abandoned by the developers who are no longer interested in increasing/improving it's functionality and an OWNER/MAINTAINER change without code functionality improvements is not leading anyone to believe that it will ever increase in functionality especially when the current MAINTAINER has no intentions of supporting anything other than the Arduino Uno and other Atmega328 based boards but does offer an option for using the Mega2560 but adds no additional functionality to it.

I don't consider bug-fixes functionality improvements and there has been no functionality improvements as it supports the same g-codes since V0.6.

Any DIY'er or hobbyist porting it to the STM32 or other MCU uses the code base as it is and if they increase it's functionality they don't release the source.

Anyone using a FANUC compliant RS274 code base doesn't make the code publicly available which stifles development of related projects such as stand-alone panels that has decent functionality.

I've already created a stand-alone 4-axis panel hardware using an STM32 and can confirm it works with GRBL, if and when there is working FANUC compliant code available and working I'll release the panel as openhardware so it can be further improved by those who want/need more, until then it's pointless to release any hardware that wouldn't be any better in functionality than an UNO with GRBL.

[109jb]

DWalsh62- We get that you think GRBL isn't adequate but much of what you are saying just isn't true. You need to check your facts before you go stating things a gospel. First of all the MAINTAINER (why caps by the way) is active and the project is actively being worked, it has been updated and the most recent commit was just 13 days ago, and the current maintainer has indicated that GRBL WILL be moving to an ARM platform in the future. The program is about maxed out in terms of features that can be supported on the Atmega 328P platforms due to limited memory available, but it isn't totally maxed out yet. That is why the current maintainer has stated that eventually a switch for the currently supported Atmega 328 to a 32-bit ARM core microcontroller will be happening. He has chosen to eek every bit of functionality from the 328P platform to support the many current users out there right now so as to not force them into the ARM platform if they don't want to. Also, the switch hasn't been made yet because he is working on the next release (1.0) WITH NEW NEEDED FEATURES and the memory hasn't been totally exhausted in the 328P yet. In order to make the switch he is working to make the code easier to port in terms of hardware calls and program layout. Also, being a free open source project, it is worked on for free by the maintainer and others and as such they have to have real jobs and work on GRBL in their spare time. Even so, functionality HAS been added since V0.6. Like probing, dynamic tool length offsets, and helical milling to name just a few. Also, the way GRBL operates it has to have another front end program to feed it commands. Those user interfaces are where much of the functionality can and should be added.

In a previous career, I programmed, set up, and operated vertical machining centers, so I do know about the benefits of the things that you mention like G41/G42 etc, and I do know about industry practices regarding work flow. But GRBL isn't intended to run a VMC, but rather is intended for hobby machines at an ultra low cost. Something that in my opinion it does very very well. I have since changed careers and no longer run CNC machines for a living. CNC is now a hobby for me, but I do have the background.

I have been using GRBL on my G0704 milling machine for coming up on a year now. Yes, GRBL only has a basic instruction set which, as stated, is due to the limited memory available on the Atmega 328P microcontroller that is used in the UNO. However,saying it isn't suitable for a milling machine because of the limited instruction set isn't really accurate. Sure it would be great to have all of the features of a commercial CNC machining center, but they aren't absolutely necessary, especially for a hobby machine. I'd venture a guess that most hobby users wouldn't know what G41/G42 is anyway.

What is missing in GRBL that really kept me from trying it for a long time is the lack of canned cycles, not the lack of CDC. There just isn't enough memory for either CDC or canned cycles. However, GRBL doesn't just work by itself. It needs an interface to feed it commands. In that vein, I have written a user interface for GRBL that incorporates the most used canned cycles (G81, G82, G83, G85, G86, G89). The interface reads line by line and when it encounters a canned cycle that isn't supported by GRBL natively, it converts the canned cycle into individual moves that GRBL can deal with. For example, a G81 drilling cycle is really just a combination of linear G00 and G01 moves put together in the right sequence., so the interface can do it and GRBL doesn't have to. My user interface doesn't have support for G41/G42, but it really depends on the parts being made anyway. For simple parts who cares. Most parts are over-toleranced anyway. For more complex parts, as was mentioned, a CAM program can regenerate the code by just changing the tool diameter in the CAM program. Sure this isn't industry standard, but as was said GRBL isn't for industry, it is for hobby. So what if you have to regenerate the code. It works!!! My somewhat low power laptop that I use for my machine is capable of generating a 50,000 line g-code file in just a matter of minutes. If it was a production part in a commercial shop then I agree that it would be unacceptable. For hobby, it really depends on the user if that is unacceptable. Obviously for you it isn't acceptable, but it doesn't really cause me any heartburn.

BTW, I originally built my machine and used LinuxCNC via parallel port as the G-code interpreter for it. As you know LinuxCNC supports G41/G42. The reason I switched to GRBL was due to LinuxCNC generating real time warnings which was a bit disconcerting. I admit I never had LinuxCNC ruin a part due to real time issues, but the warnings worried me. I had a choice to make which was to invest in in new hardware for LinuxCNC or try something else. New hardware for LinuxCNC would have been several hundred dollars from my hobby budget. I decided to give GRBL a try for $7 for an Arduino clone board and was thoroughly impressed. The thing that is most attractive to me about GRBL is that the microcontroller is doing nothing but g-code interpretation. It isn't running a full blown OS with all kinds of background tasks that can interrupt g-code interpretation. After switching, I don't really miss not having G41/G42.all that much. I seldom have parts that require tolerances that tight anyway. I may at some time go back to LinuxCNC if/when I decide that it is important enough for me to use several hundred dollars of my hobby budget for the hardware upgrades, but for now I am very happy with GRBL.

My GRBL interface is here

[jfong]

Dwalsh,

grbl isn't just for milling machine use. It can be used for controlling 3 motors for such applications as a 3D printer, pen plotter, art piece installations that need motor control etc. I used grbl for a simple embedded motor control project to move 2 steppers. I don't need the extra gcodes and a lot of people don't either.

You have the option to take the source code and modify/add whatever you want for your application.

This is really the wrong place to complain about grbl. Contact the authors and give suggestions or better yet send them software patches to add new features.

[Tkamsker]

hi i didnt like the grbl setup so on my mf70 cnc i tried a marlin ramps 1.3 setup works like a charm using an lcd and encoder mount it works from sd card perfect ( you only have to set dangerous extrude to yes. - so in my case i use it for doing pcb made from eagle pcb-code it maybe the cheapest way ,.. and i will give the linuxcnc machinekit a try but that is an beaglebone black think ,..


Gesendet von iPad mit Tapatalk

[dwalsh62]

DWalsh62- We get that you think GRBL isn't adequate but much of what you are saying just isn't true. You need to check your facts before you go stating things a gospel. First of all the MAINTAINER (why caps by the way) is active and the project is actively being worked, it has been updated and the most recent commit was just 13 days ago, and the current maintainer has indicated that GRBL WILL be moving to an ARM platform in the future. The program is about maxed out in terms of features that can be supported on the Atmega 328P platforms due to limited memory available, but it isn't totally maxed out yet. That is why the current maintainer has stated that eventually a switch for the currently supported Atmega 328 to a 32-bit ARM core microcontroller will be happening. He has chosen to eek every bit of functionality from the 328P platform to support the many current users out there right now so as to not force them into the ARM platform if they don't want to. Also, the switch hasn't been made yet because he is working on the next release (1.0) WITH NEW NEEDED FEATURES and the memory hasn't been totally exhausted in the 328P yet. In order to make the switch he is working to make the code easier to port in terms of hardware calls and program layout. Also, being a free open source project, it is worked on for free by the maintainer and others and as such they have to have real jobs and work on GRBL in their spare time. Even so, functionality HAS been added since V0.6. Like probing, dynamic tool length offsets, and helical milling to name just a few. Also, the way GRBL operates it has to have another front end program to feed it commands. Those user interfaces are where much of the functionality can and should be added.

In a previous career, I programmed, set up, and operated vertical machining centers, so I do know about the benefits of the things that you mention like G41/G42 etc, and I do know about industry practices regarding work flow. But GRBL isn't intended to run a VMC, but rather is intended for hobby machines at an ultra low cost. Something that in my opinion it does very very well. I have since changed careers and no longer run CNC machines for a living. CNC is now a hobby for me, but I do have the background.

I have been using GRBL on my G0704 milling machine for coming up on a year now. Yes, GRBL only has a basic instruction set which, as stated, is due to the limited memory available on the Atmega 328P microcontroller that is used in the UNO. However,saying it isn't suitable for a milling machine because of the limited instruction set isn't really accurate. Sure it would be great to have all of the features of a commercial CNC machining center, but they aren't absolutely necessary, especially for a hobby machine. I'd venture a guess that most hobby users wouldn't know what G41/G42 is anyway.

What is missing in GRBL that really kept me from trying it for a long time is the lack of canned cycles, not the lack of CDC. There just isn't enough memory for either CDC or canned cycles. However, GRBL doesn't just work by itself. It needs an interface to feed it commands. In that vein, I have written a user interface for GRBL that incorporates the most used canned cycles (G81, G82, G83, G85, G86, G89). The interface reads line by line and when it encounters a canned cycle that isn't supported by GRBL natively, it converts the canned cycle into individual moves that GRBL can deal with. For example, a G81 drilling cycle is really just a combination of linear G00 and G01 moves put together in the right sequence., so the interface can do it and GRBL doesn't have to. My user interface doesn't have support for G41/G42, but it really depends on the parts being made anyway. For simple parts who cares. Most parts are over-toleranced anyway. For more complex parts, as was mentioned, a CAM program can regenerate the code by just changing the tool diameter in the CAM program. Sure this isn't industry standard, but as was said GRBL isn't for industry, it is for hobby. So what if you have to regenerate the code. It works!!! My somewhat low power laptop that I use for my machine is capable of generating a 50,000 line g-code file in just a matter of minutes. If it was a production part in a commercial shop then I agree that it would be unacceptable. For hobby, it really depends on the user if that is unacceptable. Obviously for you it isn't acceptable, but it doesn't really cause me any heartburn.

BTW, I originally built my machine and used LinuxCNC via parallel port as the G-code interpreter for it. As you know LinuxCNC supports G41/G42. The reason I switched to GRBL was due to LinuxCNC generating real time warnings which was a bit disconcerting. I admit I never had LinuxCNC ruin a part due to real time issues, but the warnings worried me. I had a choice to make which was to invest in in new hardware for LinuxCNC or try something else. New hardware for LinuxCNC would have been several hundred dollars from my hobby budget. I decided to give GRBL a try for $7 for an Arduino clone board and was thoroughly impressed. The thing that is most attractive to me about GRBL is that the microcontroller is doing nothing but g-code interpretation. It isn't running a full blown OS with all kinds of background tasks that can interrupt g-code interpretation. After switching, I don't really miss not having G41/G42.all that much. I seldom have parts that require tolerances that tight anyway. I may at some time go back to LinuxCNC if/when I decide that it is important enough for me to use several hundred dollars of my hobby budget for the hardware upgrades, but for now I am very happy with GRBL.

My GRBL interface is here

Oh please, picking and choosing one or two parts or a sentence from a paragraph to make a point shows your lack of comprehension which is also noticed by other users who have sent me PM's wondering why you are on the attack with colorful quips I can't publicly post.

I reference CDC as most know what it is but canned cycles (including drilling and tapping) as I stated, "are only a small portion of what is missing in GRBL, 7x, 8x I use frequently, 41,42 I also use frequently and a gcode interpreter that doesn't support them is still in diapers.

What new gcode functionality are you claiming has been added in this recent commit as no one who reads the english language has been able to find any.

The port to an ARM device while novel doesn't guarantee it will be an STMicro device and it is unlikely to happen in the next 12 months based on the MAINTAINERS history since taking it over.

I checked the recent commit, still no new gcode functionality so stop implying the commits are adding gcode functionality no new gcode support has been added for a very long time.

AGAIN, bug fixes are not added functionality.

A machine that doesn't require CDC or canned cycles such as 3D printers can use GRBL as it stands but this does not change the fact that important functionality is missing and has been for a very long time.

When CDC and canned cycles are available in GRBL it will be useful and this opinion is shared by many.

I have no issues dumping $5K on a full blown panel but the majority of hobbyist can't and this leaves them with Mach3, LinuxCNC and GRBL (to name just a few).

I have access to two version of FANUC compliant RS274 code that compiles and runs on an STM32, I would like nothing more than to publicly release it but a financial loss prevents me from doing this so I quietly use it waiting for the day that something public becomes available and I dump an inexpensive panel in the open-hardware market.

[Tkamsker]

brenda i am sorry that your thread is taking this direction i hope my answer helps for budget machine and what you have at hand ,..


Gesendet von iPad mit Tapatalk

[jfong]

Dwalsh,

Seems like you are on the attack of the maintainers of the grbl open source project. They probably don't read CNCzone and can't reply back. My guess is they don't get paid to work on grbl and are doing work on their free time like most open source projects. Ranting about them not adding gcodes on a timely manner is disrespect. I use many open source projects and appreciate the hard work for everyone to use.

Maybe you should instead take that $5k and support the grbl by a financial contribution instead. I have no idea what a "Panel" means and what use it would be for anyone here.

[dwalsh62]

Dwalsh,

Seems like you are on the attack of the maintainers of the grbl open source project. They probably don't read CNCzone and can't reply back. My guess is they don't get paid to work on grbl and are doing work on their free time like most open source projects. Ranting about them not adding gcodes on a timely manner is disrespect. I use many open source projects and appreciate the hard work for everyone to use.

Maybe you should instead take that $5k and support the grbl by a financial contribution instead. I have no idea what a "Panel" means and what use it would be for anyone here.

WOW you don't know what a "panel" is in the CNC world??? amazing....

A panel for CNC equipment is one that can be used to control it without the need for a PC and an operating system such as windows or linux to run software such as Mach3 or linuxcnc.

In most open source project there is usually more than one contributor and in a 10 year period functionality increases and the increase can be seen by examining the changes to the code, the same cannot be said for GRBL, more than 10 years later and the same gcode is supported without additions, the original creator has jumped ship and passed it along to someone who is willing to accept responsibility for it and a couple of years later it still only supports the same gcode so those version changes were basically (much needed) bug fixes and some rewrites of poorly written routines so to some degree it is being maintained but nobody considers this advancements in development.

My opinion is that GRBL is not an open source project that warrants a $5.00 financial contribution let alone $5k from me, I see nothing useful in an open source project that's functionaly stagnant and certainly doesn't deserve a financial contribution just to incite functional progress and working on code in your spare time is what open source contributors do.

No public forks of GRBL have been created that have any more gcode functionality than the original GRBL, porting it to a dsPIC, different AVR, STM32 or FPGA doesn't make it better, it just makes it ported.

The smoothie GRBL is popular for the 3D printer world as it has been tailored for this use but it doesn't need CDC or canned cycles so it's a good fit for it.

The RS274ngc base code was used in linuxcnc and it was completely rewritten and no longer resembled the original code before it was implemented, people don't consider using it (linuxcnc) to make a standalone controller as the amount of work required to get it to run alone on any platform with an IO driver outputting a line of text of a motion move (this would give you IO hooks to tie into) is daunting and getting the original RS274ngc code to actually do something far outweighs the results it would achieve since it has no useable/direct or redirect-able IO and you can't just insert the IO anywhere so a complete rewrite is required using the code as a base or template.

No one ports linuxcnc or even makes it standalone because the code was written in the obfuscated way that linux itself is written (locks it to linux giving it linux security) and is the reason it's difficult to port and the time required to do so would be overwhelming but I suppose if you have a year or two you could tackle it and possibly have some success if your any good at programming.

If you want to use linuxcnc the best you can do is a BBB or RPI with linux and linuxcnc which really is not better than using a PC running linux and linuxcnc.

If you require minimal gcode functionality, GRBL on an STM32, Teensy 3.1/3.2 or a Mega2560 and not an 328P is the way to go and adding support for macro configurable IO (mcodes) for the unused pins which can then be used (for example) with a tool changer, lathe turret, bar feeder is possible because I've done it but I would not waste my time putting together a package and releasing as open source/hardware with keyboard/disk IO/LCD/TFT with minimum functionality GRBL.

GRBL runs quite nicely on an STM32F103CBT6, I've already given a base schematic for a standalone STM32 based mini-control panel to a couple of different china factories who are producing and selling it and it's using GRBL 0.9i with some minor code tweaks I made but I wont buy and use it due to the minimal supported gcode, I gave it because my china friend was looking for something to run a Sherline mill and Denford lathe (or copies) that are popular in china and GRBL is capable of running them if you don't mind the missing gcodes.

Attached is also a picture of a PCB for a mediocre BLDC servo drive that I gave to a china factory with the hopes they produce and sell it inexpensively which didn't get offered cheap, I'm working on a better design and have been offered help from Mihai (who is MIA for several weeks now) and crinq from the STMBL team who recently offered to help with the coding who had me make drastic design changes along with information and instructions from a couple of STMicro engineers I'm hoping shortly to be able to publicly release a free open source/open hardware BLDC servo driver (just waiting on code from crinq) that outperforms the current commercial STM32 based china designs such as LeadShine and MCUEnergy and PCB's and programmed MCU's along with fully populated boards and inexpensive boards+motors since I can produce these for less than $130.00 a set which makes them an inexpensive solution and a reasonably priced upgrade path from stepper motors.

If you have the intentions of trying to capitalize on a design, I advise you to reconsider, cheap high quality solutions for panels, drivers and motors are coming, just waiting on better GRBL for the panel and driver code from crinq so a $250.00 driver wont sell when you can buy a decent one for almost half the cost.

The attached driver board fits on a NEMA23 sized stepper driver heat sink and has a little better performance than the LeadShine BLDC driver which is considered mediocre performace.

[jfong]

Wow is the word. For someone who likes to put down other open source projects. Why would anyone want to put any time and effort into yours.

[dwalsh62]

Wow is the word. For someone who likes to put down other open source projects. Why would anyone want to put any time and effort into yours.

You misunderstand my opinions of the other projects in question, I don't put them down, I don't use them because they are in my opinion inadequate which seems to be the general opinion shared by many others.

I have no issues voicing this, these other projects have the potential to be so much more but it is unlikely to happen given the history of some of the projects in question and trying to defend GRBL as a project with claims or implications of advancing gcode functionality doesn't help the project, it's creator or the current maintainer, it only further disappoints the person interested in the project to find out these so-called advancements are nothing more than bug-fixes or code rewirtes for one reason or another.

The projects I offer are offered complete and free, they are offered as soon as they are completed, not six months to a year from now, the projects are beneficial to the hobbyist/diy'er, I make absolutely no profit from the projects and don't care if someone else produces for the hobby community as long as the price is reasonable but it is offered publicly to prevent anyone one individual from using it as a profit project.

If the project is incomplete but relying on resources promised by someone else and they fail to deliver the resource such as code for the project, it is released in the hopes that someone who is capable and competent can complete it.

crinq has stated he will provide me with code, he had me make drastic changes to the design and I'm confident he will do as he stated, it wouldn't reflect well on him if he fails to provide the code for the changes he had me implement, the reflection would pour over to his involvement with the STMBL team so the negative implications outweigh any effort required to do as he stated and I just have a hard time believing he would have me go through these drastic changes for his personal amusement.

I consulted with STMicro engineers about his proposed changes and they have confirmed his proposed changes to be what they would recommend which leads me to believe he has a great understanding and knowledge of the STM32 and motor control design so I have no need to question any further changes he wishes me to implement.

Anyone wishing to produce the DC Servo project for a minimal markup to cover expenses has my blessing, anyone attempting to profit from it or others like it will find it difficult to compete with the low cost the driver and motor will be made available for.

The STMBL AC Servo project is a good project, I used it for one customer but due to the production cost I wouldn't produce it for general consumption as is, when the discrete component version using inexpensive parts is completed (they are working on it now) it will be time to look at it again and generate an inexpensive motor or two specifically for use with it, I've created enough motors to do them correctly and with access to engineers at International Motors (an AC motor design company) a motor correctly designed is not an issue but currently at $80.00 a pop for the driver due to cost of a couple components makes no sense to waste the time designing a motor for an inexpensive AC Servo solution when the driver isn't there so I'll wait for the cheap driver to come out.

As far as the STMBL project goes, even if crinq didn't offer to help me with writing the code, if the STMBL team asked for or needed a donation of $50.00 to help with development, I'd cough it up without hesitation, they have an open source/hardware project that works exceptionally well and are now working on reducing the cost to produce it and this is beneficial to the hobbyist/diy'er and you can clearly see the project has progressed significantly from it's original design in both feature and functionality.

While Mihai has some basic knowledge/understanding of the STM32 and motor control, he's not even close to being in the same league that the guys from the STMBL team are in and I don't say this to put Mihai down, this is clearly evident by his choices in design and coding confirmed by STMicro engineers who said it's not optimal or what they would recommend and STMBL developers whose opinion I now accept as coming from experts in the field agree with this statement.

I don't personally know Mihai or the people involved in the STMBL team but can assure you that the knowledge and understanding of the STM32 in motor control systems the STMBL team has is about the best I've come across and impressive when the STMicro engineers advise that the advice given regarding the design changes is what they would have given me, for me it wasn't really advice, it was doing what I was told by an expert with significantly more knowledge and experience in the field asking me to do as it would be the best direction for the project to go in.

I forwarded the e-mail from the STMicro engineer to Mihai in the hopes that he follows their advice and implements at the very least some of the pin changes

In my project works I still credit Mihai for his initial design contributions which got me moving in a direction even though the project no longer follows his design concepts and choices because without his initial works I wouldn't have made any effort to simplify and improve the design, reduce it's production cost and I certainly wouldn't have asked for assistance from the STMicro engineers or the STMBL dev team as I don't have the background or experience in this field to do it by myself.

[jfong]

That's a matter of opinion. I certainly hope the STMBL team has some integrity. But sadly that's lacking these days.

[109jb]

BrendaEM,
This post is for you. I am sorry that this thread has taken this direction. You originally asked if there was a G-code interpreter that would work on an Arduino Mega. GRBL is probably the best option out there, or one of its derivatives. You can check out GRBL at their github site https://github.com/grbl/grbl/wiki GRBL does have a limited set of supported G-codes, but many users have worked around this limitation and are happy with the results. As you can tell others aren’t so happy with GRBL’s progress. I for one am very happy with it and it performs well for me.

Since you already have the hardware it costs you nothing to try. There are a few simple tasks to perform to get it operating on a Mega. Once downloaded you will need to edit the config.h file and change the following line:

#define CPU_MAP_ATMEGA328P
To
#define CPU_MAP_ATMEGA2560

That change will allow you to upload GRBL to your Mega. The pin mapping description can be found in the cpu_map_atmega2560.h file in the cpu_map folder.
If you need any help feel free to ask and I or someone else will try to help.

[dwalsh62]

That's a matter of opinion. I certainly hope the STMBL team has some integrity. But sadly that's lacking these days.

From my brief and limited dealings with the STMBL team they seem to be people with integrity and have given me no reason to think otherwise.