search

gnea / grbl

An open source, embedded, high performance g-code-parser and CNC milling controller written in optimized C that will run on a straight Arduino
https://github.com/gnea/grbl/wiki
Other
4.02k stars 1.6k forks source link

Where Headed? #21

Closed 109JB closed 7 years ago

109JB commented 7 years ago

@chamnit : Just a few questions regarding where GRBL is heading if you can answer. These would obviously be questions regarding the ARM version as the UNO is maxed out.

  1. Backlash Compensation - Sounds like it is already already planned
  2. Canned cycles - Although mine and a few other GUI's have incorporated some of the canned cycles, is there any plan to incorporate them natively into GRBL?
  3. Cutter radius compensation. This is a feature that I think is preventing a good number of people from implementing GRBL on metal cutting milling machines. I have looked at implementing this in a GUI, but it is problematic since it requires look-ahead, look behind, position tracking, mode tracking,(G90/G91), etc. Much of the work would be re-creating much of what GRBL already has to do. This one is definitely not trivial even in grbl. Just wondering if it is even on the horizon?
  4. Spindle synchronization - I remember you mentioning you have a CNC'd lathe, so you would know how important this feature is to lathe operations in particular. In my opinion, without spindle sync GRBL is not an adequate option for lathes. I love GRBL and am a definite convert, and would love to see this so I can use it with my lathe. Are there any future plans to implement this?

I know there are likely many other things planned and that the above list is specific to metal cutting. I am a metal head and these are the ones that interest me the most, but I fully understand that there are many other users that are not using GRBL on metal cutting lathes and mills, and they have interests as well, and the above list might not do anything for them. I'm just wondering at this point.

Thanks,

John B.

chamnit commented 7 years ago

@109JB : All of those items are on the table for the ARM version. I'm very aware of the limitations that Grbl itself poses for professional users. I'd like to address these in the ARM version for sure. It's primarily a function of how much time and energy I have to work on all of this. Grbl v1.1's impending release has been quite draining for many different reasons.

Cutter comp will be tricky, and honestly, I haven't really investigated into it very deeply because of all the reasons you laid out. Plus, you need to know and track tool information internally as well, which means that the ARM version will need to keep that data on hand. I've been warned by developers who have done some cutter comp code. In short, it's horrible.

That said, it's not very high up the list of things to implement, because re-generating the program in CAM with the altered tool radii would do essentially the same thing, but not nearly as convenient.

109JB commented 7 years ago

In regard to cutter radius compensation there is an option that would not require GRBL to track tool information. Similar to G43.1 where tool length is given as a distance rather than having to read a tool table, G41.1 and G42.1 use a numeric diameter passed. For example G42.1 D0.5 would offset the tool to the right of the programmed path by 0.25 units rather than having to read a tool table.

Where tool radius compensation is a huge benefit is things like bearing pockets where the diameter may have to be held to within 0.0001" This can certainly be done in CAM as you said, but going back and forth to CAM is not practical in many cases.

I fully understand the time constraints.