carneeki
commented
5 years ago I'm not sure a slave/master approach is the best way forwards for a few reasons:
- There's not much spare memory in the ATMega 328 that Grbl is based on
- High step rates (close to 30khz) could mean that there isn't much spare MCU cycles for comms + motion planning on additional axes.
- (related to above) - Having to track / maintain state of "the other GRBL" could be taxing on the MCU.
chamnit has said on many occasions that the 328 chip is pretty much at it's limits.
To that end, I think a a larger MCU/CPU could be the best route. There's a fork of Grbl-Mega based on the ATMega2560 that you might be interested in for 5 (and I think maybe a sixth axis) - https://github.com/fra589/cn5X
Also consider what chamnit says in this thread: https://github.com/gnea/grbl-Mega/issues/48#issuecomment-365738509
Something like a Beaglebone Black (ARM with a lot of IO pins) running Grbl would be pretty sweet, there's heaps of spare CPU cycles and memory to enable things like encoders to close the loop and detect + maybe recover from stepper stalls, and the IO pins could also help with more buttons / pendants too.
The relatively low cost of an Arduino is great, but the low cost clones fitted with CH340 chips have been problematic for many (issues page). The price difference between a genuine Uno and a genuine Mega is about $16 right now, which in the scheme of building a machine tool with more than three axes is minimal. The ATMega 2560 is also used in some systems supporting 6 axes (checkout a board called "RUMBA" which also does a boat load extra stuff too, some of the things could be useful for spindle and coolant control on top of the six axes). Admittedly, RUMBA is substantially more expensive and not Grbl (It's Marlin), but it's a starting point should you wish to explore the route of getting Grbl-Mega onto the board, and could be as simple as changing pin mappings (I don't know, I've not explored it, you'd want to do a spreadsheet mapping the pins first, maybe using Marlin configurations as a guide to assist with pin numbers), and then uploading a hex file.
With the future of Grbl probably being CPU based, I'm excited to see what chamnit has in store for us, but he's been busy and hence unable to share too much here, so until then, growing systems are looking at various ports to other MCU/CPUs including the 2560 and STM32. Personally, I'd be leaning towards the 2560.
Good luck!
109JB
fra589
MeJasonT
Hi,
I wish to suggest an idea to expand a standard GRB to a 6 channel GRBL. Because the GRBL hardware (Arduino and drivers) is now almost inexpensive, I consider to pair two GRBL systems to drive 3+3 channels. The two GRBL uses a different firmware. Because the standard GRBL ignores the channels A, B and C commands, and processes just X, Y and Z, I plan to parallel two GRBL (a master and a slave) using the RX port. The same data received by the RX pin of the master is sent also to the RX pin of the slave. The master receives data from USB and processes them as usual. The slave processes just the commands related to A, B and C channels. Obviously, the slave sends back the feedback through the TX pin, so the master in addition to the data from USB must check and control this feedback from the slave. This requires one free pin on the master. The master needs some modifications to handle the slave's feedback but it remains almost the same as standard GRBL, while the slave needs a greater modification. With the same principle, it is possible to build even a 9 channel (or more?) GRBL system.
What do you think about my suggestion? Is it realistic?
Thanks for your attention.