search

grbl / 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
5.62k stars 3.09k forks source link

More axes? #117

Closed droftarts closed 10 years ago

droftarts commented 12 years ago

I know grbl is designed for 3 axis, non-rotational axis CNC machines, but how difficult would it be to add a 4th and/or 5th axis? I also appreciate that it is designed to run on low-end Arduino's, but are people realistically still using an AVR328 to run a CNC mill? A 644 has enough pins, and a bit more computing power, to support more axes. I have a reprap RAMPS board, which has 5-axis and 6 endstops. A simpler variation of this board, with spindle control rather than heated bed/hot end control, would be ideal for running a 4 or 5 axis styrofoam/balsa wood cutter powered by NEMA17 or 23 motors. Toolpaths for such machines can be generated in opensource software like Gmax http://www.turbosquid.com/gmax with the CNC Toolkit http://www.cnc-toolkit.com/ Imagine being able to cut a smooth boat hull with such a set-up!

The grbl-based Marlin firmware has added a 4th axis, and ability to tool change to a 5th. Axis independent steps-per-mm and acceleration would also be required, which already exists in Marlin. Also, other forms of robotics could then be supported, such as robot arms - which is my ulterior motive. See http://forums.reprap.org/read.php?146,153660

Unfortunately, I'm not a programmer, so I don't really know how to go about this. Unless anyone else has already done this?

simen commented 12 years ago

I have made a fork of Grbl that controls a scara arm, but it is not really somthing that can be meaningfully integrated into Grbl – it would have to be a separate project. Grbl will always be focused around cartesian setups. As it stands it is quite simple to add a fourth axis to Grbl given that this is a cartesian axis whatever that would entail – i suspect this axis would be plastic feed in Marlin? Adding rotation to the mix will require a complicated rework of the lookahead planner in grbl which I don't think is in anyones roadmap currently.

If I were to update Grbl to use a more modern processor, I would personally go for an ARM-based setup. I am still waiting for some board to go ubiquitous like the Arduino to make such an effort worthwhile.

droftarts commented 12 years ago

Hi Simen, thanks for the quick response. At the moment I fudge the gcode when using Marlin by calibrating it to move degrees on each axis, rather than mm; ie I position each arm section by degree. This actually makes the maths not too bad to calculate the actual position, but it's probably not how professionals do it! The advantage of the arm I have is that no part of the arm relies on another, so if I change the angle of the lower arm, the upper arm stays at the same angle to the ground. I think this is rather different from a SCARA layout, not sure if your other fork is going to help me.

I understand your reticence putting more work into grbl, given that more exciting hardware is on the horizon. However, I do think there is plenty of life left in Arduino - it's easy to program, availability and expandability will keep it going for quite a few years to come. I hadn't thought about how a properly rotational axis would affect the planner, but I can see now it would be tricky. But you could always define it as an axis that moves only 360 degrees and no more, or that the next increment after 360 is 1. But then I'm no programmer, I'm sure it's much more involved than that!

I'll probably persevere with Marlin, see if I can get the 4th and 5th axes to work independently. Perhaps I'll have to switch to LinuxCNC ultimately, which feels like a retrograde step, but at least arm control is built in.

simen commented 12 years ago

I did not mean that I am not interested in maintaining Grbl as it is, I just meant I don't see the point of upgrading it to a different atmega with the same processing power with just some extra pins as you will quickly run out of processing power trying to keep all those extra pins fed with action. I do however understand why the RepRap set would do it though as they have a bit more going on with the heaters and feeder and what have you. For milling, Grbl on a vanilla Arduino is still just the ticket for me personally.

chamnit commented 12 years ago

I agree with Simen completely. The math can start to get complicated with the rotational ABC axes, and there is more computation power required. A little more than the simple 328p atmegas can really do robustly. There is also the problem with memory. Grbl is stretched to the max to provide minimal yet consistent functionality for 3 axes. So it's mostly a compounding problem, the more you add, the more memory and computational power you need.

Personally, I think a 4th axis would be doable, if done very carefully for the Arduino. I don't think the math is too different from what we have in the planner already, but I would think there might be some compromises that would be needed to make it work robustly, since there are more cycles needed to compute that extra axis. (We would also have to change up the accelerations to axis independent too, and this is in my roadmap.) I'd like to see this happen at some point in the near future, perhaps as a different developmental branch.

Another note: Alden Hart of TinyG/grblshield has been working on a 6 axis controller based on the atmega mega chips. Not sure where he is on his project now, but it works pretty well from what I last saw of it. He only supports his own TinyG specific hardware though.

simen commented 12 years ago

@chamnit Thinking about how to manage effective feed rates with rotational axes makes my head hurt. Won't the effective feed rate be a result of both the cartesian motion and rotational motion which must take into consideration the distance of the tool from each rotational axis that is moving at a given point in time. I agree that a single rotational axis may be manageable within the constraints of the atmega-architecture, but three? I'll have to check out what @aldenhart is up to. Sounds really incredible if he is able to pull this off, but then again he is rather clever!

chamnit commented 12 years ago

Yep, a bit of a head scratcher. You have to consider each axes' acceleration and speed independently at every point in time, but I think there may be a simple solution to how to handle them. I think the trick is that you have to limit each motion to the acceleration of the axis that is maxed out. I haven't worked it out on paper, but it should be doable without killing the Arduino.

For effective feed rates, these should be taken care of by CAM software or a post processor. This is one of the many problems that make 6-axis machines are so difficult. Most of the time machinists have to write a post processor themselves, specific to the machine. We have a 5-axis at work, and it's so testy that the machinists have to triple check their code to make sure nothing breaks when they start cutting. Particularly when the tool jogs out and when the workpiece moves and rotates into a new position.

chamnit commented 12 years ago

@simen : I've been thinking more about the effective feedrate problem and I've been talking with Machinist Mike about it. Here's some clarifications from our machinist.

So, the main issue is that when you have rotation and translation at the same time, these work off two different units, inches and degrees. To solve this, you have to use inverse time (G93). This forces both rotation and translation to move in sync by using one feed parameter, rather than two. If you use two separate feed parameters for rotation and translation, small simple errors of each can effect synchronization, where one would arrive before the other to their destination.

At this point, I'm not sure what exactly this means for Grbl, but I imagine we would have to update the inverse time code to convert the axes feedrates correctly. It could be doable... Anyhow, something to think about.

csdexter commented 12 years ago

(common sense disclaimer: if someone that does CNC machining for a living disagrees with my text, they are probably right. If my text disagrees with the book (Peter Smid's CNC Programming Handbook), the book is surely right)

On the issue in question, I have the following to say:

  1. It is recommended practice in the industry not to specify rotational movement at the same time as linear movement, specifically because it's hard for the human to get it right and for the controller vendor to guarantee that the controller will get it right. For machines equipped with a dividing head, rotating table or a combination of the two, moves are usually segregated into (X, Y, Z) and (A, B, C) blocks in the input. 1bis. Having said that, there are machines that do choreographed 4- and 5- axis movements involving both the linear and rotational axes while at the same time obeying the given feed rate (from the point of view of the tool tip!). They tend to sell for at least 6-figure amounts (in USD) and are not usually programmed by humans, but rather by the output of specialized CAM software.
  2. It is recommended practice in the industry to use inverse-time feed rate when doing linear-rotational combined moves, again because it's easier for the human to get it right that way. Any machine (that would actually be actively used in production) that supports combining moves that way, will support both (length units-per-minute and inverse-time) feed rate specifications without any loss in precision. Yes, that involves a lot of math in the controller and state-of-the-art mechatronics engineering in the movement, but that's why they are expensive. Getting it right is usually hard (and thus expensive) in any industry.
  3. As for the rotational axes, they are wrapped at 360 degrees (361 is in the same place as 1). Different machines use different mechanical arrangements, so some of them will actually rotate continuously if commanded so while others will periodically unwind to keep themselves within their mechanical range. The latter case involves extra planning from the human side which is machine-specific and cannot be addressed in the case of a generic firmware like grbl is.

Short conclusion on the rotational axes issue:

Hope it helps.

chamnit commented 12 years ago

@csdexter: Agreed for most, if not all of what you state.

  1. Talking with the machinist at my workplace, he stated that 'point-to-point' rotational and translational (or independent) movements are used 95% of the time, even when machinists have access to 6-axis machines. The main reason: it's difficult to coordinate the movements, even with the help of MasterCam ($$$$$). They only use coordinated movements when absolutely needed or for show-and-tell.
  2. Agreed, but I have a feeling that programming it won't be as difficult as you state. (i'm probably going to end up eating my words on this.) For the most part, the difficult stuff is taken care of by the CAM or post-processor, not the CNC controller. As long as you have the positions and the inverse time, the controller, i.e. Grbl, would only need to parse the command and sync the movements, just as it would moving in 3-axis only. The trick will be adjusting the acceleration planner for differing acceleration limits for each axis. (@jgeisler had worked on this before and it seems straightforward.) I've read a lot of journal articles relating to high-speed CNC control and what we are trying to do and are discussing here, has been done about two decades ago on CPU's that are probably on par with an Arduino 328 (or Mega). The high-speed machining is what is expensive. These algorithms that try to maximize speed and ensure feed rate throughout cutting. We do a simple ac/de-celeration ramp only. I will have to look into what it means to implement this completely, but I think it's possible (eventually).
  3. In cases like this, which is common, machinist typically adjust to the limitations of their machine and controller and work within them. If we select one general way of operation, it should work fine for most people.

So, if this is at all possible, I think it would be worth it to investigate synchronous rotation and translation with a 4th axis-only. The associated changes should be platform independent and we can add this feature later with more capable hardware, that is if we find that the little Arduino can't handle it. From there, with an ARM CPU, we should be fairly trivial to add the additional two BC axes for full 6-axis movement.

I agree with Radu that for CNC machining, 6-axis is limited by the availability of free/cheap software that can program it, but Grbl isn't about just machining. We have seen a lot of other neat and interesting applications of it for simple movement of art installations and other things, so I think, if we can do, lets do it.

VingTor commented 12 years ago

Hi

My first post here, hopefully not the last as I am trying to get my cnc machine up and running with grbl. Currently working on a GUI written in python using QT and OpenGL for 3D rendering of the gcode. Work is a bit slow, too many projects ongoing at the same time.

Regarding hardware required for more axis: The Arduino WiFi shield, http://arduino.cc/en/Main/ArduinoWiFiShield ,
could be an option, but not sure if it gives you access to all the pins you need (I was hoping that this board would be even more flexible). Could at least be something to look into. The Arduino Due (ARM device) could also be a great option. I have heard rumors that it will be available in the near future.

Otherwise, I have created my own board based on a UC3 device, and the board should be quite compatible with Arduino except for the IO voltage. Should at least be able to provide additional processing power and memory. http://uvolts.blogspot.no/p/uc3duino.html Some issues with my design of coarse (only on first revision), but could be a starting point for anyone who would like to create a board that is compatible with the current shields for grbl I guess.

Regards Tor Erik

aldenhart commented 12 years ago

I'll weigh in on how TinyG does it. The code is all available on github (Synthetos/tinyg) for review, use and reuse.

All 6 axes are coordinated, and they are rate limited. This is done by converting all movement to time units in the internals of the firmware - regardless of how they were specified in the Gcode. There is a dense section in the Kramer RS274v3 NIST spec about how linear and rotational axes should be related when doing non-inverse time mode coordinated moves that involve movement in both domains. I read this many many many times and hope I got it right.

Internally, all movement planning is done as a scalar value that is converted to movement via a 6 axis unit vector. The first operation is to rate limit the move to the minimum time the move requires given the physical limitations of the axes. Note that the axes all have independent parameters for max velocity, jerk and cornering acceleration (TinyG uses jerk to control acceleration - acceleration therefore is not a constant)

Yes, it only compiles right now for the Atmel Xmega chips. Anybody up for working on an ARM port with me?

droftarts commented 12 years ago

Wow, that has sparked a discussion! Thanks for all the brainstorming. aldenhart, TinyG looks really interesting, and definitely looks to be a serious contender to take over sophisticated machine control. You should definitely port it to ARM, assuming you can get enough I/O. I wish I could help, but I'm a graphic designer really - I could colour it in, maybe!

It's probably overkill for my specific problem at the moment (a robot arm), and I only have an Arduino Mega 2560, not the more powerful Xmega, so it's not something I can try out even. I think I can extend Marlin to accommodate the extra axis. Translation from XYZ to rotational co-ords will have to be done by the host (perhaps ultimately on the controller), but this shouldn't be too bad; if I want to translate a series of XYZ gcode commands (say, if I sliced something for 3D extrusion with an XYZ reprap that I wanted to reproduce using the arm), I should be able to write a python script to give me the same gcode in my 4 rotational axes - I think! Something like the way the polargraph drawing robot works, which would actually be a good starting point for me. Feed rates could be an issue, but not in the same way as with a rotational + tranlational system. Sorry all, I'm also thinking of these merely from the problem I want to solve, rather than for all CNC systems - excuse my myopic viewpoint!

alpharesearch commented 12 years ago

On 09/12/2012 06:31 AM, Alden Hart wrote:

Yes, it only compiles right now for the Atmel Xmega chips. Anybody up for working on an ARM port with me?

I would like to help!

I did participate in the Kickstarter for the Teensy 3.0 (there are still 10 hours left or you can order this next month)... it's not open source but inexpensive ($22) and the creator Paul Stoffregen is a regular contributor to Arduino too. I never did anything with ARM (well I do have a Android phone and table and Raspberry Pi but this is just Java or Linux programming). I think Paul made sure to provide a very nice open source tool chain with the Teensy 3.0 (as far as I understand this will work with Arduino and GCC) this is why I got one.

Do you think the used Freescale's "Kinetis" K-series PK20DX128VLH5 / MK20DX128VLH5 chip would be a good candidate for a ARM Grbl port?

Or would it be better to wait for the Arduino Due? Or any other ARM you had in mind?

I'm not affiliated with this company and I do not gain monetary if he sells these boards, here are more information on the Teensy 3.0

http://www.kickstarter.com/projects/paulstoffregen/teensy-30-32-bit-arm-cortex-m4-usable-in-arduino-a

Technical Specifications:

32 bit ARM Cortex-M4 48 MHz CPU (M4 = DSP extensions) 128K Flash Memory, 16K RAM, 2K EEPROM 14* High Resolution Analog Inputs (13 bits usable, 16 bit hardware) 34* Digital I/O Pins (10 shared with analog) 10 PWM outputs 8 Timers for intervals/delays, separate from PWM USB with dedicated DMA memory transfers 3 UARTs (serial ports) SPI, I2C, I2S, IR modulator I2S (for high quality audio interface) Real Time Clock (with user-added 32.768 crystal and battery) 4 general purpose DMA channels (separate from USB) Touch Sensor Inputs

All pins have interrupt capability.

aldenhart commented 12 years ago

I ordered some of the Teensy 3's a couple of weeks ago from the kickstarter just to try them out. One of the challenges for an embedded system is finding an ARM that's affordable for these uses (about $5, +/-), available (not perpetually stocked out), has a good enough development chain that's free or cheap (that supports simulation or in-circuit trace/debug), and has library licensing that's not onerous and supports Open Source projects (so TI is out - or was when we talked to them). Oh, and I want LOTs of IO pins for handling many things.

I also agree with Simen about waiting for an "Arm Arduino". The Pi and Beaglebone are ironically too powerful (complicated, IMHO) for these uses as you pick up all the complexities of trying to run a real-time system from a non-realtime OS, and the pinouts are murder.

We've been looking at all these factors and like the NXP1758 series the best so far. Step 1 would be to get the tool chain in place and probably FreeRTOS on it.

matthewSorensen commented 12 years ago

I also backed the Teensy 3 project, mainly because I was interesting in using it as the base for a new RepRap controller. Porting grbl onto it seems to be a good first step in doing this, so I'd also be interested in helping with an ARM port.

If everything goes according to my plans, I'll have few spare copies of a board designed to hold the teensy and pololu stepper drivers in a few weeks. I'd be happy to send a few of these out if it would help...

csdexter commented 12 years ago

I'm in the process of porting grbl to ARM as well, more precisely to Cortex-M3 and Cortex-M4F (basically the same code compiled twice with different -march options). The boards used (for development and prototyping) are the STM32VL-Discovery and STM32F-Discovery, both considerably under the price of the Arduino Uno. There is no cost and no problem associated with the toolchain as GCC has been targeting the ARM for quite a while now -- it just works. There is no cost and no problem associated with debugging as we have STLink by texane here on Github that does the job quite nicely. There is no cost and no problem associated with the library because we have libopencm3 for all the CPU-specifics -- and libc can take care of the rest. Maybe I'm blind, but I really do not see where all the pain people are talking about w.r.t. ARM is coming from :-) Of course, there are better and poorer choices, but the diversity is so high you really don't have to care about the people asking 10USD apiece or wanting you to sign an NDA before they show you the chip.

Things are still in flux, the final product design may end up using an ARM in a "One Man Orchestra" solution and a board akin to the STM32-H152 from Olimex OR it may go down the route I'm currently developing at the moment which involves using ATtinys for all hardware low-level tasks and one ATmega328P (on a Pro Mini) for management, G-Code parsing and math.

chamnit commented 12 years ago

It's not that porting to ARM is particularly difficult, but it more has to do with creating entry-level CNC firmware for anyone with little risk and that works. Just about anyone entering into micro controllers has an Arduino and uploading Grbl to it is virtually risk free, since they can use the board for numerous other things if a user finds that CNC isnt for them. And as far as I know, the firmware is pretty rock solid, save for a few TBD minor features.

If we start to develop for multiple platforms, there then may be some dilution of the quality of the firmware, which would require more time and effort to ensure everything works after each update. Also if it begins to require specialized/unmatured hardware, then it begins to go away from the idea of using/trying out Grbl with little cost risks. We would then have a limited power user base if we did this.

What Simen has said and I support, until there is a standard ARM board that is universal, there is not much reason to develop for one, at least for what the spirit of Grbl is.

I personally think there is a lot more to be done with Grbl. There are some cycles left we can use to make Grbl more fully featured as a CNC controller, especially with some of these awesome GUIs people have been making for it. I think it's worth the effort to work within the limits of an Arduino so that it forces us to create very compact, modular, and efficient code that people can easily use as a foundation for other applications.

On Sep 16, 2012, at 3:37 PM, Radu - Eosif Mihailescu < notifications@github.com> wrote:

I'm in the process of porting grbl to ARM as well, more precisely to Cortex-M3 and Cortex-M4F (basically the same code compiled twice with different -march options). The boards used (for development and prototyping) are the STM32VL-Discovery and STM32F-Discovery, both considerably under the price of the Arduino Uno. There is no cost and no problem associated with the toolchain as GCC has been targeting the ARM for quite a while now -- it just works. There is no cost and no problem associated with debugging as we have STLink by texane here on Github that does the job quite nicely. There is no cost and no problem associated with the library because we have libopencm3 for all the CPU-specifics -- and libc can take care of the rest. Maybe I'm blind, but I really do not see where all the pain people are talking about w.r.t. ARM is coming from :-) Of course, there are better and poorer choices, but the diversity is so high you really don't have to care about the people asking 10USD apiece or wanting you to sign an NDA before they show you the chip.

Things are still in flux, the final product design may end up using an ARM in a "One Man Orchestra" solution and a board akin to the STM32-H152 from Olimex OR it may go down the route I'm currently developing at the moment which involves using ATtinys for all hardware low-level tasks and one ATmega328P (on a Pro Mini) for management, G-Code parsing and math.

— Reply to this email directly or view it on GitHubhttps://github.com/grbl/grbl/issues/117#issuecomment-8599935.

nemoskull commented 12 years ago

ive been folowing this for a bit and id like to chime in. why not just a 4th axis, something simple and basic on the existing hardware? it dont have to be perfect, people will find new ways around things. you could build a trasmision with just 4 axis...

crob09 commented 11 years ago

Maybe:

define MM_PER_INCH 25.4

define X_STEPS_PER_INCH 6400

define Y_STEPS_PER_INCH 20000

define Z_STEPS_PER_INCH 42850

define E_STEPS_PER_INCH 50.0

define FAST_XY_FEEDRATE_INCH 50.0

define FAST_Z_FEEDRATE_INCH 100.0

define FAST_E_FEEDRATE_INCH 25.0

define CURVE_SECTION_MM 0.5

// Limits

define SENSORS_INVERTING 0

// Resistor current for nozzle heater

define HEATER_CURRENT 100

// Pins Mega2560

define SERIAL_RX_PIN 0

define SERIAL_TX_PIN 1

define X_ENABLE_PIN 2

define Y_ENABLE_PIN 3

define Z_ENABLE_PIN 4

define E_ENABLE_PIN 5

define X_STEP_PIN 6

define X_DIR_PIN 7

define X_MIN_PIN 8

define X_MAX_PIN 9

define Y_STEP_PIN 10

define Y_DIR_PIN 11

define Y_MIN_PIN 12

define Y_MAX_PIN 13

define HEARTBEAT_PIN 14

define Z_STEP_PIN 15

define Z_DIR_PIN 16

define Z_MIN_PIN 17

define Z_MAX_PIN 18

define MOTOR_ON_PIN 19 // HIGH = ON, LOW = OFF

define MOTOR_DIRECTION_PIN 20 // HIGH = Clockwise, LOW = Anti-clockwise

define PANIC_STOP_PIN 21

define PANIC_OVER_PIN 22

define LCD_SERIAL_PIN 23

Add/ include THERMISTORTABLES from "Sprinter", and maybe some other stuff I may have missed/ forgotten for the hot end. It should work.

Rob

http://whatisacnc.com

derFrickler commented 10 years ago

Very interesting Thread!

I am about to build a CNC Portal Cutter with two X/Y Portals, one left, one right like these ones for Example: http://www.cnc-multitool.com/cnc/foam-cutting-machine/4-axis/cut1000s.html Most software that generates the cutting data generates 4 Axis GCode with X/Y for one Side and Z/A for the other side. Additionally the heating for the cutting wire is switched.

I have a grbl Shield with 4 polulu drivers as well as a reprap board lying around.

But the Question is which firmware to use. I saw a grbl fork with a 4th Axis some time ago, but i can't find it right now. On the other Hand most 3D Printer Firmware allow 4 Axis, but i have no idea if they can be configured to drive them independent via X/Y/Z/A

any Ideas here?

Thanks
       Johannes
victorhantelmann commented 10 years ago

On the main topic of this talk (with hudge potential) there were two ideeas:

  1. use 4 axis coordinated movement that Marlin is builtin with T0 (G specific X,Y,Z,E - where E equals XrotaA or YrotaB or ZrotaC - in mill, lathe or router case) and only occasionally use T1 to change extruder (G specific - X,Y,Z,E - where E equals YrotaB or ZrotaC or XrotaA - in mill, lathe or router case) wich can be done because only G code is involved as follows: N0001 T0 ;first extruder is selected N0002 G1 X0 Y0 Z0 E1 F1000 ;rotate after X axis with 1 deg N0003 T1 ;second extruder is selected N0004 G1 X0 Y0 Z0 E1 F1000 ;rotate after Y axis with 1 deg This is an example of non coordinaned movement.
  2. use true coordinated movement that involves rewriting of Marlin firmware as follows: N0001 G1 X0 Y0 Z0 A0 B0 C0 F1000 S1000 ;take 0 position N0002 G1 X1 Y1 Z1 A1 B1 C1 F1000 S1000 ;go in coordinated movement with 1 unit on 6 axis

To achieve 2 would be a worthy goal. Would anyone do this work for free? I wonder ... Marlin or Grbl are great firmwares for Arduino I love both. I think that 2 might be acheived.

ashelly commented 10 years ago

So I'm ready to start putting serious time toward adding a 4th axis, and I want to do it on a more capable board than the Uno, to avoid compromising on memory, IO or speed. I've played with Matthew Sorensen's Teensy3.1 port and it looks promising. It also appears there is a Mega port at https://github.com/EliteEng/grbl. My question is which board to choose? Which port is has more interest from the community? Is either one likely to get merged back here - will grbl ever officially support multiple boards, and what can I do to help make that happen?

shapeoko commented 10 years ago

This is just my two cents on the situation:

I like and have always liked, the simplicity of the project. That grbl has focused on one platform, and one mission of making a fully capable (up for interpretation) parser/controller for the 328p. I think that this focus has really made us consider what is a 'must have' and what can be left for later, or left out completely.

So to me, when someone asked if grbl will ever support another board, I always think: "it can't".

By definition, grbl is a no-compromise parser/controller that will run on a straight arduino. If one were to remove the 'straight arduino' part of the statement, then it won't be grbl any longer. It would be something else, based on grbl.

I'm not saying the code base shouldn't be used to create another parser/controller on another platform, but if that's done, it needs a different name and a different mission statement.

-Edward

getSurreal commented 10 years ago

+1 for the Teensy port. It is very Arduino compatible and can be programmed with the Arduino IDE. Both give you additional pins and memory, but the Teensy also gives you a big boost in speed with 96mhz vs the Mega which is the same speed as the Uno.

On 4/9/2014 3:52 PM, ashelly wrote:

So I'm ready to start putting serious time toward adding a 4th axis, and I want to do it on a more capable board than the Uno, to avoid compromising on memory, IO or speed. I've played with Matthew Sorensen's Teensy3.1 port https://github.com/matthewSorensen/k20-grbl-port and it looks promising. It also appears there is a Mega port at https://github.com/EliteEng/grbl. My question is which board to choose? Which port is has more interest from the community? Is either one likely to get merged back here - will grbl ever officially support multiple boards, and what can I do to help make that happen?

— Reply to this email directly or view it on GitHub https://github.com/grbl/grbl/issues/117#issuecomment-40014919.

This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com

chamnit commented 10 years ago

@ashelly : Agreed with @shapeoko. Grbl has always served as a seed for larger things. By keeping it small and restricted allows us to concentrate on the inner workings much easier. However, we're getting close to the point where the Uno can't take us any further. The path of least resistance is simply going to the Arduino Mega2560, which the dev branch has unofficially started supporting. It's compatible with all current shields and should be plug and play with people using Grbl on Unos.

Similarly, we can go the Arduino Due to keep the backward compatibility, but toolchains are still slowly coming up to speed. This would take more effort to convert everything. I think time would be better spent, at least on my part, finishing out the feature list on the Mega and then porting everything to an ARM-based controller as a different project (called Gnea).

EliteEng commented 10 years ago

I have been making quite a bit of progress lately on an ARM port of the latest dev branch. https://github.com/microCNC/GRBL_ARM/tree/Dev

I have used CMSIS, so porting to other ARM controllers shouln't be to big a problem ( although different vendors have different ideas for peripherals )

crob09 commented 10 years ago

You can write another Axis into GRBL, alternately consider MODBUS and EMC.

I've also read that the Mega isn't what you want for GRBL, I could be wrong but the 328 or UNO chip is the one to use, someone mentioned that they where concerned about speed, note that the Uno has a Baud of 9600 cycles per second, you don't need to process faster than that for the application (Driving a Stepper motor Via USB "Universal Serial Bus").

MODBUS can also be used with Mach3 and other Machine Software, or you can write your own machine software using Visual-Studio.

More on a "Bus" can be found here: http://tronixstuff.com/2011/05/13/tutorial-arduino-and-the-spi-bus/

Cheers and hope it helps,

Rob admin electric-canada.com Date: Wed, 9 Apr 2014 13:52:50 -0700 From: notifications@github.com To: grbl@noreply.github.com CC: crob.09@live.ca Subject: Re: [grbl] More axes? (#117)

So I'm ready to start putting serious time toward adding a 4th axis, and I want to do it on a more capable board than the Uno, to avoid compromising on memory, IO or speed. I've played with Matthew Sorensen's Teensy3.1 port and it looks promising. It also appears there is a Mega port at https://github.com/EliteEng/grbl. My question is which board to choose? Which port is has more interest from the community? Is either one likely to get merged back here - will grbl ever officially support multiple boards, and what can I do to help make that happen?

— Reply to this email directly or view it on GitHub.

chamnit commented 10 years ago

@EliteEng : That's awesome news about your progress on the ARM. I personally don't have the time to look into it, but I'm very glad that you are. We'll have to team up when things on Grbl are completed and the new Gnea project starts up.

@crob09 : Just to clear some mis-information up. Grbl and Arduinos are not limited to only 9600 baud. They can run at any baud rate up to 250000 (if I remember right). Grbl v0.9d runs at 115200 baud without any issues. Also, the AVR 328p is what the Arduino Uno uses, and Grbl should be able to support the AVR Mega2560 on the Arduino Mega2560 without much issue, since they are basically the exact same chip, only with more memory, interrupts, and flash storage space. An extension to the Mega2560 should be easy and would have the memory and space to expand Grbl further. (CPU speed is a bit of a concern, but current tests on the Uno and v0.9d show we still have a lot of overhead left with all of the recent code improvements.)

ashelly commented 10 years ago

Thanks for the feedback. I understand the appeal of the stock Arduino. I'll start seeing what I can do with 0.9d on the 2560.

LETARTARE commented 10 years ago

@ashelly you can watch an old version grbl-0.81 : https://github.com/LETARTARE/Mega2560-grbl-0.81 works on Mega2560.