Wanting grbl without host PC

Go To Last Post
34 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm having a difficult time finding the answer to some questions I have regarding Arduino, grbl, and USB communication. Part of the problem may be that I don't know enough to understand if I do actually have an answer.

 

I have a desire for a standalone or "headless" configuration of grbl. I have found several posts from people that have implemented this using 2 Arduinos. One of them has grbl installed, and the other uses an SD card shield (for gcode storage) and sends the gcode to grbl via USB (just as a PC would do).

 

I have found posts from Edward Ford where he had flow control issues with overflowing the serial buffer. His solution was to implemented a poor man's version of hardware flow control.

 

http://www.shapeoko.com/wiki/index.php/Headless

 

He writes:

"Each time grbl processes a command it checks the serial buffer:

if(serialAvailable()>= 128) {LEDPORT |= _BV(LEDBIT);} //turn on LED13

If the buffer is >=128 then it's full. And if that's the case turn on LED13."

 

The sending Arduino then monitors the appropriate pin of the grbl Arduino.

 

My biggest confusion is why isn't this a problem during USB communication with my laptop?

 

Also, is anyone familiar enough with grbl to assist me with where that line of code is inserted?

 

Cris

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

aeroHAWK wrote:
My biggest confusion is why isn't this a problem during USB communication with my laptop?

 

USB has flow control built in.

 

Also, is anyone familiar enough with grbl to assist me with where that line of code is inserted?

 

grbl now has XON/XOFF flow control : https://github.com/grbl/grbl/blo.... You could either use that, or toggle an IO line where SEND_XON and SEND_XOFF are set.

 

Btw, most printer firmwares have the ability to read code from an SD card, as well as support an LCD control panel, but integrating that code with grbl would not be trivial. It is probably still quicker and simpler to use second Arduino as a sender.

Bob. Engineer and trainee Rocket Scientist.

Last Edited: Mon. Sep 19, 2016 - 01:27 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

donotdespisethesnake wrote:
USB has flow control built in.

So now I'm really confused. If USB has flow control built in, and the second Arduino is communicating with grbl via USB, why would Edward Ford have had any problems?

 

Is the XON/XOFF you mentioned, separate from USB?

 

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The second arduino connects to the grbl arduino via serial, not USB. You can see this in the picture as there is nothing connected to the USB connectors on either arduino board. Besides, you can't connect two arduinos to each other via USB as they're both devices.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
The second arduino connects to the grbl arduino via serial, not USB. You can see this in the picture as there is nothing connected to the USB connectors on either arduino board.

Ahhh... I see. So even though USB is serial, "serial" doesn't necessarily mean USB....

Kartman wrote:
Besides, you can't connect two arduinos to each other via USB as they're both devices.

But this is only a matter of software, isn't it? Couldn't an Arduino be programmed to take the place of a laptop in the USB communication?

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

above I wrote:
But this is only a matter of software, isn't it?

I now see there is apparently hardware required to be a USB host. I also found that a shield is available for that purpose. Thanks for the education!

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Technically, usb is serial in terms of the way it communicates, but we'd normally refer to usb as usb. A virtual serial port can be implemented over usb, which is what the Arduino does. As far as the mega328 is concerned on the Arduino board, it talks seria.
Other headless options might be a raspberry pi board or a wifi router with a usb port could be used to read from storage and output to grbl. No soldering involved.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

aeroHAWK wrote:

donotdespisethesnake wrote:
USB has flow control built in.

Is the XON/XOFF you mentioned, separate from USB?

 

XON/XOFF control is a software flow control method, XON and XOFF are control characters in the ASCII set. It doesn't make sense to use it over USB, but you could do.

 

Hardware signalling is more immediate, XON/XOFF have some delay so you need to tune trigger points.

Bob. Engineer and trainee Rocket Scientist.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use the grblweb server https://github.com/andrewhodel/g... on a raspberry pi 3. It does not use serial flow control to the arduino, instead maintaining something like 5 commands in the buffer by sending a new one after each OK response (which requires a limit on the number of characters in each command line). Several browsers can be attached to monitor the progress, but only one can be sending the grbl code.

Several other grbl senders are installed on the pi for local operation but I have had no need to use any yet.

 

Incidentally, the pi powers the arduino via USB but the stepper voltage comes from a PC supply. That can be turned on and off at any time without affecting the grbl program (the same plugstrip powers a fan on the arduino, the rotary head, and a vacuum cleaner).

 

Last Edited: Mon. Sep 19, 2016 - 12:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay, I'm beginning to fill in the blanks. With your help and more googling, I'm seeing a different picture.

 

Apparently, the Arduino talks to USB with the RX/TX pins, so it can't tell if the bits come (or go) from USB or other source. It seems that Edward Ford is using RX to receive data from the SD shield. When USB is used (or not), it is apparently transparent to grbl.

 

So a new question arises, if USB has its own flow control, how does grbl tell it that the buffer is full?

 

I suppose it could send some signal out the TX line. And since Edward Ford did not connect anything to that line, his setup has no way to tell.

 

If that is the case, I can see why he called his approach a "poor man's flow control". He could have been monitoring the TX pin for the appropriate indication, or he could instead insert a line of code to set a pin high when it is ready (which is probably a lot easier, and is what he did).

 

Well it looks like the act of writing this post has had me go through more of the thought process and maybe even answer my own question.

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

Last Edited: Mon. Sep 19, 2016 - 03:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just noting the thread title "without a host PC".

 

Given that a "host PC" can these days come in the form of a RPi or Beagle or similar for $10..$20 I sort of wonder what merit there is in trying to chop a PC out of the picture?

 

Are you trying to save $5 by using a $5 Arduino instead of a $10 Linux host for a huge amount of grief and hair pulling? Why? (don't tell me "because Everest is there"!!)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Are you trying to save $5 by using a $5 Arduino instead of a $10 Linux host for a huge amount of grief and hair pulling? Why?

My goal is to have an inexpensive solution with minimal hair pulling. To a carpenter with a hammer, every problem looks like a nail. My "hammer" is AVR, and to a much lesser extent, Arduino (since it is an AVR). I am unfamiliar with RPi and beagle. I did not know they could be that simple a solution.

 

I know nothing of Linux (except for attempting to use it for my CNC - I went with MACH3 if that tells you anything). So I'd have to learn about that. At this point I expect a steep learning curve no matter the direction I take, I don't yet see that your suggestion is better (or worse).

 

What are the steps it would take to do what you suggest?

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Linux (in an embedded sense) is worth finding out about as it's kind of the next step up from low level MCU programming.

 

You'll find a lot of devices in your home (in mine that include TV, DVD player, PS4 console, camera, several tablets, several smartphones) are all Linux computers at their heart. As soon as you start wanting to add any kind of networking or other well known, high level software processing (MP4 compression, audio codecs etc etc) to a piece of electronics then Linux starts to look like the natural choice. Building apps in Linux is a very "Arduino like" experience in that instead of messing about with a few bits in one register you are tending to bolt together solutions from large, existing building blocks. You want Zip functionality? There's a lib for that. You want JPEG dcode? There's a lib for that? You want to be able to read/write Hex/ELF/Srecord/etc/etc? There's a lib for that. In fact there is a lib for pretty much every computing task you can think of because someone before you has already done it on Linux. (again this is very Arduino like - libs available for anything you can think of).

 

Sounds like there are already libs / instructions for Grbl on Linux too:

 

http://zapmaker.org/projects/usi...

 

In googling that I also notice comparisons being made with something called LinuxCNC. This whole area is new to me but obviously it would be worth investigating if, supposing Linux were being used, might LinuxCNC be a "better" alternative? For example...

 

http://www.cnczone.com/forums/di...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think we are talking apples and oranges. Zapmaker does not look applicable at first glance. LinuxCNC is what I started with when I converted my old Bridgeport CNC. As I said, I went with MACH3. It was Sooooooo much more user friendly and easier to setup.

 

When I installed grbl, I followed a "cookbook" recipe and it worked out of the box. I think a lot of the reason is that I have some background with AVR and therefore Arduino. Linux looks great! But I have no idea what people are talking about because it's all Greek to me.

 

If I can buy a Raspberry Pi that can read an SD card and send the data strings over usb for $25 or $50, then I'm golden. But so far I haven't found that in a (near) turnkey state. And if there is something close, it is too far from being a nail for me to understand.

 

I understand what you mean about "Arduino like" by connecting building blocks. It doesn't matter to me if they are Arduino blocks or RPi blocks. That isn't why I've gone down the Arduino path. Arduino is the path that includes grbl and I am familiar with AVR. I already speak some of the language and have some success.

 

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

aeroHAWK wrote:
Arduino is the path that includes grbl and I am familiar with AVR. I already speak some of the language and have some success.

 

I think if I was you I would stick with Arduino for now. Linux is highly powerful but a whole new can of worms.

 

Looking more closely at the headless setup by Edward Ford, it appears he is using a single TX line from sender to grbl. I guess that is because the sender is really simple, it reads the text file and sends data as fast as possible, with no parser for responses from grbl.

 

I would insert the code to toggle pin 14 around https://github.com/grbl/grbl/blo...

 

Something like

 

 if (serial_get_rx_buffer_count() >= RX_BUFFER_SIZE-2)
    LEDPORT |= _BV(LEDBIT); //turn on LED13
 else
    LEDPORT &= ~_BV(LEDBIT); //turn off LED13

 

Bob. Engineer and trainee Rocket Scientist.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

donotdespisethesnake wrote:
Looking more closely at the headless setup by Edward Ford, it appears he is using a single TX line from sender to grbl.

Yes I agree. After Kartman pointed out that there was no USB cable in the picture, I started looking at it more closely too, and noticed the same thing.

 

I also found some more info on other forums. I found this:

 

"All you do is connect the GRBL TX to your micro RX, and GRBL RX to your micro TX. Then, it's simple serial calls, such as 'Serial.println("G00 X1.0 Y1.0")'."

 

And this:

 

"Just to warn you, it's not that simple. GRBL requires a peculiar type of flow control. Hardware flow control isn't available through Arduino's USB connection, so GRBL can't do that. It doesn't implement software serial flow control (XON/XOFF), either. However, it sends out confirmations for the commands it processed and removed from its receiving buffer, and the size of that buffer is known, so senders have to pay attention to confirmations and stop sending when they calculate that GRBL's buffer is full."

 

This answers some of my above questions.

 

Thanks Bob for the code suggestion. I will spend time studying it. Also, I may need to use a specific output pin as one of my applications uses most of the available I/O for various options.

 

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rather than do a hardware work-around, the obvious solution would be to obey grbl's confirmations.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
the obvious solution would be to obey grbl's confirmations.

I'm learning about more options.... There is a compile time option to enable XON/XOFF, and then hardware flow control isn't needed.

 

So the choices are... one could do a makeshift hardware workaround, or the "sending Arduino" can do the necessary calculations to keep track of the status of the buffer, or one can enable XON/XOFF.

 

To me, it comes down to which is easiest to accomplish based on the specifics of the task at hand and my programming skill. If I/O is available, it seems like the hardware workaround is the least work. But one of my applications uses all the outputs so for the hardware solution, I'd have to change an unused input to an output, which makes it less attractive. Keeping track of the buffer size isn't very attractive either. So at this point, enabling XON/XOFF sounds like the way to go, since I will be also customizing the "sending" Arduino's program.

 

One of my applications requires a short gcode file (maybe 20 lines). Once it is fully debugged, it will never change, so it can be embedded in the "sending" Arduino's program. This eliminates the need to have an SD card reader or other easily swapped memory.

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If 'easiest to accomplish' is the criteria, i'd be going the raspi direction as no programming is needed. Plus you've got the benefits of networking so you don't need to . shuffle sdcards or usb sticks. The fact that there is superior alternatives to grbl that utilise the processing performance of the raspi means you have more choices. It also means you can do stuff like have a $5 usb camera on the machine and keep an eye on the machine when you're out doing the shopping. Or send a nessage when it is finished and so on. This sort of stuff can be done by writing scripts rather than writing large programs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you use XON/XOFF option in grbl, then you can use standard grbl which would be easier. I guess you still have to build it with the XON option, I haven't tried that recently.

 

Parsing the responses from grbl would be ideal, you could also handle error conditions. The responses appear to be simple text strings, so easy enough to parse. As I write 3d printer firmware, I have some C# code to send test data from PC, although I normally use the "Printrun" software to drive the printers.

 

A simple sender might do something like:

 


open SD file
read first line
send_enabled = true

while (!end of file)
{
    if (send_enabled)
    {
     send line
     read next line from SD
    }
    
    read response
    if (XON received)
       send_enabled = true;
    if (XOFF received)
       send_enabled = false;
       
    if (error received)
       // do something with error

}

close file

 

Bob. Engineer and trainee Rocket Scientist.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
i'd be going the raspi direction as no programming is needed.

As I have said above, I am very unfamiliar with RPi and what it takes to make it work with grbl. I would have to learn a lot more than I currently know to be able to put it all together. You say no programming is necessary, but to me, writing a "script" still seems like programming.

 

No matter what the solution, I doubt I'll be writing any "large" programs. At most, I'll change a few lines in existing libraries.

 

I appreciate your suggestions. I am attempting to get more "bare bones" so all the extra bells and whistles are just that - extra.

 

The examples of the lofty capabilities you state don't apply to my applications, but if the RPi really is the easiest to accomplish, please give me an overview of the tasks involved. Also, what do I need to learn in order to accomplish them....

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

donotdespisethesnake wrote:
If you use XON/XOFF option in grbl, then you can use standard grbl

Yes Bob, that is one of the attractions. Recompiling with the XON/XOFF option is no issue, I've already been through the process of compiling to enable the mist coolant option and disable the spindle PWM.

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

aeroHAWK wrote:
The examples of the lofty capabilities you state don't apply to my applications, but if the RPi really is the easiest to accomplish, please give me an overview of the tasks involved. Also, what do I need to learn in order to accomplish them....
 

 

For me, half the fun is trying something new. i start out having NFI, by the end of it I will have learnt something. I've only seen a raspberry pi, so no use asking me for instructions. I'd use a wireless router, as I've got plenty of these things floating around. It's just Linux in the end.

I just Googled grbl raspi and got plenty of hits. Seems others have similar requirements to your own. 

This one looks interesting to me - http://www.rs-online.com/designs...

Firstly, since I have a beaglebone black and also as it uses the PRU co-processors. Might be a project for a rainy day. Currently I'm using Mach3 running on an old Windows computer.It gathers a bit of dust in the workshop. One day I'll put some effort into learning a 3D package and cam tool to do something useful. Writing G code gets boring after a while.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Beaglebone Black looks very interesting. It looks quite easy to boot-up out-of-the-box, has plenty of capability (overkill really), and is inexpensive. The hurdle comes in communicating with grbl. Since grbl's usb flow-control overhead is in the "gcode senders" court, it can be a hassle to get that going. Going to serial comm and XON/XOFF will simplify the gcode sender code, but I think I'd have to work out the serial comm details in the BBB (it isn't plug and play like USB comm). It does look like an SD card (if needed) is a no brainer though.

 

So comparing that to an Arduino connected to grbl via serial comm with XON/XOFF enabled, and a custom sketch do transfer gcode, the BBB only gets extra points for having the SD card built in.

 

The bottom line is that when one looks at ALL the little details of solving the problem various ways, none of them are a panacea! And the advantage of one over another is not very large (if at all). This was a very useful thought exercise, and it educated me about other single board computers.

 

I currently have two different applications in mind. One is a rudimentary Pick-and-Place machine for small quantity PCB assembly. The other is a proprietary, light duty assembly machine (not Cartesian coordinates but 3 axes) for microwave circuit assembly. The former would use an SD card to contain the gcode, the latter would have the gcode in memory (since it would not change after initial proofing).

 

If it is easy, the Pick-and-Place machine would be nice to not be tied to a PC or Laptop (but not necessary). The proprietary assembly machine should be devoid the cumbersome PC and operate in a fashion that the motion control stuff is transparent to the user.

 

So far, the winner is an Arduino connected to grbl with XON/XOFF enabled and a simple sketch to shuffle a short gcode program from memory to grbl.

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No mention of GRBL CONTROLLER 3.0 that talks to GRBL via USB? It looks like it sends the file to GRBL an takes care of the grimy stuff. That was only 10 seconds of Googling. I dare say there are other solutions.

 

Really, if the G code is small and can fit in the spare flash of the Arduino, bypass the serial comms and have it read the strings from flash.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dak664 wrote:
I use the grblweb server https://github.com/andrewhodel/g... on a raspberry pi 3.
Related to ChiliPeppr?

ChiliPeppr

Hardware Fiddle

http://chilipeppr.com/

Create Javascript software workspaces that talk to your hardware.

Use one of our hugely popular workspaces or create your own by forking one you like.

...

Grbl Workspace

http://chilipeppr.com/grbl

Grbl devices are now supported inside ChiliPeppr.

The workspace connects to your Arduino via the serial port over the ChiliPeppr Serial Port JSON Server.

...

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
No mention of GRBL CONTROLLER 3.0 that talks to GRBL via USB?

I attempted to install it on two different laptops and my desktop with no luck. I don't remember the exact problem but it throws an error and stops working. I suppose it can be installed on other devices, but still requires a monitor, mouse and keyboard. So it defeats the purpose of eliminating a PC.

Kartman wrote:
Really, if the G code is small and can fit in the spare flash of the Arduino, bypass the serial comms and have it read the strings from flash.

Here again, the devil is in the details. What does this ACTUALLY involve? My understanding is that grbl maxes out the Arduino so there may not be any room. If there is room, I'd have to figure out how to tell grbl to look in memory instead of the RX pin. It's bound to be a can of worms. Plus if I did figure it out, I would have spent all that time to solve half of my problem (the proprietary assembly machine) and none of it would apply to solving the other half of my problem (the Pick-and-Place machine).

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

Last Edited: Tue. Sep 20, 2016 - 03:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am now forced to learn what a grbl is. Gerbil? Garble? Something to do with g code and computer numerical control (I know nothing about either subject)

 

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
I am now forced to learn what a grbl is. Gerbil? Garble?

Bob, there are various explanations of it's pronunciation, but I call it gerbil. Anyway, grbl is a gcode interpreter jammed into and Arduino UNO. It essentially saturates the ATmega328's capabilities, but it seems to do its job pretty well. It is a part of a lot of DIY 3D printers and the hardware is available for very little $$$.

 

When grbl is installed in an Arduino, it is no longer really an Arduino since the bootloader is gone to make room for grbl. It is really just an AVR board with grbl.

 

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

Last Edited: Tue. Sep 20, 2016 - 10:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

After simmering in the back of my mind a bit, I've come up with a new idea for controlling the proprietary assembly machine. The Arduinos I have use the ATmaga328 with an ATmega16U2 to handle the USB tasks. If I don't need the USB, I can embed the gcode in new code for the ATmega16U2 and pass this gcode to the ATmega328 via the USART as it does now (for USB communication).

 

I am assuming that the ATmega16U2 is fairly standard to write code for (as other 'megas).

 

Is anyone here familiar with the ATmega16U2?

 

Do you see anything inherently flawed with this approach?

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How are you going to handle the flow control?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
How are you going to handle the flow control?

I have a couple ideas. The motion control task for this particular machine is rather rudimentary and the gcode program fairly short. I could use trial-and-error to add delays in the code that sends the strings to grbl to make sure the buffer doesn't overflow. Yes it's crude and inelegant, but it may be fine for a simple task.

 

My other thought is to use the hardware method described above by Edward Ford. It uses Arduino pin 13 which is pin 19 of the 328 and is the ISP connector SCK line. I could plug in a jumper from that ISP header to the SCK2 pin (or the MOSI or MISO for that matter) of the ISP header of the 16U2. It is a noninvasive way to connect the two MCUs.

 

It seemed like a waste of a good processor to do what Edward did if the gcode program was static and relatively small. No need to add more processors if one is already sitting there essentially at idle....

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

Last Edited: Fri. Sep 30, 2016 - 05:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

how are you getting on with this? i'm trying to do exactly the same thing using 2 arduino's controlling a laser engraver

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

3dfixer wrote:
how are you getting on with this?

I haven't yet done anything with hardware. I have two different projects that I want to do this, but one is far less demanding in that it won't ever need to change the g-code once it is figured out. The other - a pick and place machine - is a different story. To allow for different g-code programs, an SD card reader seems to be the way to go. For that I found this controller board they call Smoothieboard:

 

http://smoothieware.org/

 

This is what they say about themselves:

"Smoothie is a free, opensource, high performance and modular G-code interpreter and CNC control system for the Smoothieboard 32bits controller. The motion control part's ancient ancestor is the awesome grbl. The Source code is on GitHub."

 

They have installation guides for 3D printers, laser cutters, and CNC machines. The board is available with up to 5 axes and is limited to motor voltage of 35v and 2 amps, but you can use external stepper drivers by picking step and direction signals from a header on the board. The board is around $100.

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)