Hi guys

My first post in this forum. I ordered the micRo just about a week ago, can't wait to get it up and running.

Meanwhile, I have set up my old dell laptop to run Ubuntu with the EMC2 (downloaded the preprepped cd for linuxcnc.com), it is my only computer with a parallell port. I draw in Rhino from my other computer running win xp.

I have started to read the EMC2 manual. Pretty tough reading for a guy that graduated some years ago... Anyway, I do not completely understand the basics of this CNC stuff. As far as I have learned: You draw in a CAD program (ie Rhino), you import it in EMC2 to generate toolpaths and g-code, EMC2 sends information to the motor drivers that moves the machine ?!?!

Also, how do I "train" my skills in EMC2 before I receive the micRo?

Well i have been doing the same waiting for my micro. I personally got to grips with emc2 by gcodeing by hand, start simple with a few strait lines using the simulator in emc2 then work your way up to feeding in external models. Try searching for a few beginer projects e.g finger joint cube or similar unfortunately i don't have the links to some good beginer projects to hand it look them up and post them when i can.

Hi Roger, welcome to the fray! EMC2 is just the machine controller, and excepting an interface for it called 'imgtogcode', EMC doesn't generate any gcode natively. There are programs called CAM programs that can generate toolpaths and gcode from certain types of drawings, like CAD and STL. Rhino is a 3d program that I have no experience with, but it may generate the gcode natively. If not, better look for a cam program that can work with your file type.

Another thing to do is to build up some materials; plastics, alum wood etc. You can never have enough of these things to cut up once you get your machine!

I'm with you there pal! Although I have experience ranging from punch cards and Fortran (college days) to C, Pascal, BASIC, and some others - I have trouble getting up to speed with just about any new software package.


Oh, the pain. (That's a bit of an inside joke.) Just hang in there and muddle through the best you are able. If you're like me it'll come to you in its own good time. But there's always someone around here willing to offer up some remote assistance if you're willing to display some patience and humor.

Good luck and if it's any consolation I'll be struggling soon too. Misery loves company and all that.

Hi, I am eagerly awaiting my micRo too. For 2D CAM work I found CamBam to be adequate for a start. But it will not work with your Rhino-files, because it is 2D oriented. Basically it generate different milling operations around the lines you provide in a CAD file. For CAD I plan to use QCad. I have not found a good free/open 3D CAM package yet.

I have had trouble sourcing a PC which is old enough to have a parallell port, yet new enough to run Ubuntu. To pass the time I have written Grbl, a machine controller / G-code parser for the AVR-microcontroller. It is written in C and will run on any Arduino-board based on the atmega168 (all modern arduinos).

It accepts most common G-code directly. Just pipe it throught the serial port. The Grbl takes care of all timing issues and if someone will write a driver for EMC2, Grbl will eliminate the need for the complex timing hacks of EMC2 - and the need for ancient computer systems.

As I do not have the micRo yet, the code is completely untested at this point. Contributors welcome. You can find it and contribute here:

http://github.com/simen/grbl/

Good idea, and great job!

Thanks for all replies. Good to see another norwegian as well!

I see, the EMC2 can only read pre-made g-code files and feed the machine. Thats pretty much the answer to my question. Now, another one:

How does EMC2 know what position the spindle is at the moment, where to start, what height above the material?

Each time you turn on the system, the position of the spindle will be somewhere else than last time you used the actual g-code? And then the computer has no idea of where it should start so it misses the workpiece?

I know these are pretty basic questions, but I do ask

Are you aware of the work done by Chris Meighan ? He has the arc code in there.
http://forums.reprap.org/read.php?12,19155

Maybe you could join up with him and collaborate ?

I've been keeping an eye on it ...

Yes, like I say in the readme: "Inspired by the Arduino GCode Interpreter by Mike Ellery" :-)

I had toyed with the idea for some time, but actually had no intention actually building this. When I discovered his project I intended to fork it and fix a couple of things I thought needed a little touching up. I needed better control over memory consumption, code size and other hardware resources, so I ported it from Arduino to regular C. In the process I got carried away and ended up ripping it all out, writing a new interpreter from scratch and refactoring the machine control beyond all recognition. In the end it was really a new project, and there was no way anything could be merged back into the source.

Grbl is licenced under LGPL which means anyone is fee to use the code for any purpose. If Ellery, Mehigan or Hoeken finds any of my code useful, I will be proud to see my code merged into the project as I will be sure to check out the new arc-interpolator. But I personally did not like the Arduino framework with a demanding application like this, so I guess I will not be contributing code directly to the project.

I'll try your code as soon as my micRo arrives. I've been waiting since last July, and it should be here any day now ...

As for a driver for EMC2, why would EMC2 be needed ? The RepRap folks just use a Java front end to send the gcode to their Arduino/Sanguino.

Do you have a basic circuit diagram to go along with your code ? I can compile and program the atmega168, and would love to give it a whirl.

Very interesting.

Rick: EMC2 will not be needed at all, but I have the impression that a lot of people like the interface it provides. Personally I plan to add a small linux computer like the Gumstix or Beagleboard with wifi and just ssh to my CNC to dump jobs via the serial port.

I just added support for asynchronous buffered stepping. Stepping is performed exclusively with timer interrupts so that the rest of the system is free to prepare future steps and parse G-code. I hope this will lead to smooth operation and minimal jitter.

Grayson: Could you tell me how many steps per inch I will need to generate for the micRo? I want to know if I'll be able to control the micRo at full speed.

I'm also a Rhino user, it will not output G-code at this time. CAM programs get expensive very quickly. The least expensive that I've seen that also looks decent is MeshCAM ($175). Another good one is Cut3D ($300). By the way: Cut3D is also recommended by joecnc2006, who knows his way around a CNC machine. If you really like the Rhino interface you might want to check out RhinoCAM ($900) which is a plugin that works within Rhino.

Steps per inch is easy to calculate. You need the steps per revolution for the motors, the turns per inch (TPI) for the screws, and the microstepping multiplier - you just multiply them all together. One way or another the store isn't loading for me so I can't double-check these numbers for you, but if I remember right the micRo motors are 200 steps per revolution and the screws are 12 TPI. I don't remember the microstepping setting of the micro drivers, most that I've seen are either 10x or 8x.
200 * 12 * 8 = 19200 steps per inch
If you're trying to run the machine at 50 inches per minute you'll need to be running the motors at 600 RPM (50 * 12 TPI). 600 (RPM) * 200 (steps per revolution) * 8 (microstepping multiplier) = 960,000 pulses per minute required for 50 IPM, which means you'll need to output pulses at 16 khz. I don't know how it works, but from what I've seen - stepper motor drivers require two pins: one for the step pulses and one for direction. So a 3 axis CNC machine will need 6 pins (plus a ground?).

Good breakdown and thanks for the CAM pointers! I couldn't find the details on TPI or steps per revolution for the micRo anywhere.

Grbl uses six pins for stepping (three for direction and three for stepping), and an additional enable pin to signal when it wants the steppers active. Additionally it will support two pins for spindle control (direction, power) and three input pins for limit switches on each axis.

I estimate that Grbl will be able to produce ~25k steps/seconds at 20MHz which amounts to 1.500.000 steps per minute - but time will show.

I was thinking of using the RepRap Java interface for your controller. Might that work ?

Have you looked at socat ? It works well on the Gumstix, and might be easier than having to transfer the gcode file and then pipe it to the serial port - one step instead of 2 ....

What do you think of having the front end send the config parameters as the first group of data before the gcode ? This way the steps per inch and other settings don't have to be hard coded into the atmega168.

Another question: Is anything in your code dependent on F_CPU = 20mHz ? Could we run it at 16 or 8 ? I do have a Gumtix and a Robostix with an atmega128 clocked at 16mHz laying around doing nothing, and a few other atmega chips. Adding in some ifdef's for the ports/pins/uarts/etc differences isn't a big deal.

I'd like to start playing with your code. I don't have a stepper motor or driver yet. While I can get the pinouts from the code, a circuit diagram of what you are using would help.

You have done most of the ground work already, I'd like to contribute.

I'm not sure about the RepRap Java Interface. When I look at the source for the regular reprap firmware they use their own secial protocol - but those guys also have something called "Replicator" which is exactly what would work with the Grbl. It pipes GCode via serial while rendering a little image of the toolpath. The project is a little rough around the edges still, but it could be fixed quite easily I think.

All of my timing calculations are based on F_CPU, so it could be recompiled for any clock rate with no other modifications than that. I guess a 16MHz build would be the "standard" distribution of Grbl, because that is the clock rate of most Arduinos. It will run fine at 8MHz, only slower. (But it will not support the atmega8 - I have a hard time getting everything in there and still keep it under 16k flash).

There is no need for a circuit diagram at this time. I am targeting anything that looks like an arduino. I will be testing it on the Mini Arduino and a Baby Orangutan (http://www.pololu.com/catalog/product/1215). It will run fine on a naked atmega168 on a breadboard as long as you provide it with power and a clock. Schematics is just a matter of hooking the designated pins on the board to their respective pins on the stepper drivers - at least for the time being.

You choose the pins in config.h. Because of a range of nice optimizations, all six stepper pins must be on the same port. The rest of the pins you assign freely.

I have the gumstix and the robostix myself. Might be a nice little platform for this project.

If you start playing with my code, beware that it is still largely untested. After I finish the arc interpolator tonight, I will start carefully testing each module in the target environment. I have gotten hold of three steppers with drivers so I can start playing around a little until the micRo arrives.

On configuration: Yes, I would like something like that. The serial protocol should be extended to accept configuration - and maybe you could even store it to eeprom.

Thanks for the tip on socat. I had never heard of it.

The motor step angle is 1.8°, or 200 steps/rev. Naturally the driver can microstep this to 400, 800, and 1600 s/r. The easy driver circuit is set to 1600 by default, but the premium micRo driver (upgrade) can be selected...though buswidth is usually not the limiter, V and A are. The motor's speed is directly related to the V you feed them, and torque to A/V. In theory, the V can rise to the dielectric breakdown, meaning the motors could go really fast, though step motors lose torque with speed, and gain a lot of heat with the A required to make torque at higher V (got the burns to prove it). The only time step angles and microstepping would limit speed is when the throughput on the bus is too small to send 1600 pulses instead of 200. Only recently did we encounter this problem...Robin has the data I believe.

I am just done with making my new workshop, ready for the micro. I have also installed ubuntu with emc2 on a computer. This is my first experience with ubuntu/linux, so I am not very familiar with it...

Does anyone know how to do a latency test on my computer?

Work your way through this:
http://www.distinctperspectives.com/emc2in...etup/index.html

From the beginning:
"I will start off by saying I am NOT a Linux expert, guru, or enthusiast, nor do I know everything about EMC2."