Contraptor

Thanks for replying so quickly!

I'm already using the 328, so I assumed the firmware would work right out of the box. The only modification I made was to rearrange the pins in the code.

I even opened the serial monitor in the Arduino IDE and sent the g-code line by line. I get an "OK" and movement from every line until one of the last few I posted about (I forget exactly which one). I get no "OK" reply and the arduino becomes unresponsive. Could it be one of the calculations runs into an odd value? Can someone else try the gcode I posted? The CNC machine aside, if I just have a 328 arduino loaded with this firmware and I send it these gcode lines, it should reply with an "OK" or a "Huh?"…. I assume.

Hi.
How are you sending the data to the arduino ?
I had a similar problem when starting using the mini-cnc because my script did not wait for the OK before sending another line.
So the data got lost ( I guess it overflowed the serial buffer ), and it stopped working/responding after a few G commands.
Making the script wait for the OK fixed it ( or using the script here : http://www.contraptor.org/motion-control ).
But I'm not sure that's your problem because you still have the problem when using the arduino serial console ( maybe you are not waiting for OK there ? ).

I thought it could be that too until I ran the code line by line. I waited until each move had finished and then started the next. I have found the offending line. If I run this code, my machine will start moving erratically and not take notice of the limit switches:

G90
G20
G2 X3.4364 Y2.0438 I1.4981 J1.1094

Other arc commands function as normal.

My problem aside, how does the firmware handle the number of commands to accept? From what I can tell, the firmware sends back an "OK" after receiving a command but before completing the move. So what parameter limits the number of commands the firmware buffers?

It's nice that you have a reproductible gcode program to describe the problem.
Can't test it now the machine is not wired up.

About the buffer, it has a 1/2 command buffer : it has the actual command, that it is executing right when it is received, and it also stores the next command, no more, so it accepts 2 commands in a row.
That allows it do do command look-ahaed : it does not slow/stop the steppers if the next command is in the same direction for a given axis.
But it must not accept more than 2 because then it would have to accept a whole gcode file, and there's no room on the arduino for that.

The firmware code is hairy, good luck, I have read most of it to fix issue I had, ask if you need any help.

The look ahead function is optional, if you only give it one command at a time, it will just go to a stop before the next command, so it's no cause for bugs.

Awww man, I'm really pulling my hair out on this one. I'm 90% sure this is some sort of buffer over run. The reason I say that is because the behavior changes as I flash different firmware on it. I've modified the code every which way, but when I flash back the original firmware, it'll get stuck at a different point in the program, or it'll behave differently at the point that it gets stuck. Sometimes it'll run endlessly (broke two limit switches that way). Other times it'll sit there not responding. There is a ghost in the machine…

You guys seem to have been running this firmware for a while now. The only portion of the code that I am changing is in _init.pde. I just don't understand what the problem could be. Maybe my steps per inch is so large that rSquared gives the sqrt function some trouble. I tried to modify the firmware to accept R-code where I calculate sqrt(I^2+J^2) and fed it in as RX.XXXX, but it gave very bizarre movements. (Update: this isn't the problem as I can get the arduino to print out 'r' even on runs when it gets stuck. It seems to get stuck at the end of the arc. It never finishes the move.)

Oh, btw, I noticed that the firmware did not behave as you described it. My script waits for the arduino to send an "OK" before sending the next command. The arduino allowed my script to get three moves ahead of where it was. So it sent three "OK"'s beyond its current move. After the third "OK" it will wait until it is on the next move to send another "OK". This doesn't seem to be a problem because I modified my script to only send the next command when I press "Next". And with that setup, I still have the same issues.

Are you using some sort of fine microstepping ? 1/16 or more ?
That caused me tons of problems and I had to modifiy the firmware a lot.
So maybe it's that.

If you are just doing 1/2 stepping, then I don't see where the problem is.
But putting more Serial.print everywhere should help you point where the problem is ( from what I read it's probably in steper_control ).
You should go into the main interrupt loop, and monitor values like move_phase, move_finished, can_step, last_t, sequence_step_number, delta_t etc …

I'm just doing half stepping using L297s. So it shouldn't matter as far as my micro-controller knows. It is just sending step commands.

I just grabbed a brand new Arduino Uno, disabled the min/max pins in _init, and with nothing attached to it, flashed it with the firmware and ran my gcode on it line by line. It gets stuck just the same way. This can only mean a few things:

1. Something is wrong with the firmware and this is a big practical joke played just on me.
2. Something is wrong with my Arduino IDE (I'm using 0021)
3. I am not using the same firmware as you guys.

If this firmware was developed when a different version of the Arduino IDE was out, maybe the newer IDE breaks something that worked before. Which version do you use to compile your code?

Thank you for staying with me on this and for all the advice. I just wish I had one solid piece of code to work off of. As it is, I'm starting with a non functioning piece of code written by someone else and trying to debug a problem that only I am having.

You seem to be working with the same firmware.
Nobody still tested your gcode ( I can't right now ) so maybe the problem will be the same with somebody else and that gcode.

Just to see, you should test your blocking command by changing one by one every number to a random one ( X/Y/I/J ) and see if one is the culprit. Also try with less decimals on all, just to see. If it makes it work, that's a clue of something.

I'm using arduino 0017 ( the only one I could get to work on my 64bits ubuntu, still have not tested with most recent versions ), so maybe you could try using that one.

The firmware is far from bug-free and the guy developping it is not available since a long time, so a bug from the firmware does not seem like an unreasonable idea.

Well, I managed to make my machine run the code from begin to end by changing certain arc movements into linear movements. It still doesn't output the correct motion. Comparing its motion to that of CutViewer Mill, it is making unnecessary complete circles. It seems to only get stuck on large or small radius arcs. Here is both my original gcode and the modified version.

http://www.mediafire.com/?sdl4x9kgmxb3f5d

Changing to Arduino IDE 0017 didn't change anything. Reducing the decimal places also didn't change anything.

From seeing people's videos of the Mendel in action and other machines based on the same code, I was under the impression that most of these bugs were worked out and the code was pretty solid. If it is this easy to trip up the code, I may want to start from a more basic code that I can develop. I just hate reinventing the wheel when I don't have to. Maybe I can just develop if conditions to catch buggy arc commands on the fly:

if(you're going to misbehave)
do linear motion

Or maybe feeding in a code that has the time it should take the move to finish with the current feed rate. If the machine is still moving at the end of that time, it aborts the current command. That might have saved some of my limit switches.

I'm going to take a break from this for a bit. Thanks again. Let me know if you ever get around to trying my gcode.

There are many branches of Arduino GCode Interpreter firmware; if you're using the Chris Meighan version (sounds like you are), be sure it's the latest version.

OTOH, I recall a problem with arcs that possibly never got checked into the source UPDATE: it did, so it should work.
http://www.contraptor.org/forum/t-192541/mini-cnc-case-study#post-749373

One possibility is that the problem occurs on Uno but not on Duemilanove. I don't recall anyone on forums using Uno yet.

I got the firmware from here: [http://contraptor.svn.sourceforge.net/viewvc/contraptor/trunk/firmware/]
as linked from here: [http://www.contraptor.org/arduino-gcode-interpreter]

That version is 9 months old and does not have the fix you linked to. So is there a source that is more up to date?

I manually added that fix and it did solve the problem I was having. You don't know how happy you've made me. I would have never been able to figure out the problem. Thank you!

Glad you finally got it working, please show us stuff you do with your machine when you do some.

Vitaly, if you are going to update the code in the sourceforge repo to add that fix, please tell me, I have a few fixes related to the microstepping problems I had to submit to you so you can add them at the same time.

I still have a ways to go:

Step 0: Add vacuum system so that my wife doesn't kill me.
Step 1: Make a spindle mount so I can get rid of the zip ties holding the dremel in place.
Step 2: Make a better spindle mount using the previous spindle mount.
Step 3: Make the housing for the electronics.
Step 4: Make a cutting bed.
Step 5: Make circuit boards for my actual large scale CNC mill.
Step 6: Make alignment sensitive components for large scale CNC mill.
Step 7: Make and begin trouble shooting large scale CNC mill.
Step 8: Add extrusion/temperature control components
Step 9: Add laser cutting.
Step 10: Add pick and place.
Step 11: Go broke.

I'll keep you guys posted as I progress. I'm hoping to fix up the gcode sending interface and release another version. Right now I have it reporting back the limit switches and the spindle state. I also added a debug mode that lets you run your gcode line by line. Hopefully, I'll add a jogging interface, a home button.

On the firmware side, I want to add arcs in the XZ and YZ plane (which I'm hoping will be a cut and paste operation mostly). I've already added manual controls for an external joystick. This is great or positioning the machine and stopping it when it is out of control.

Hey you're making a big-cnc too ! Using contraptor ?

About wife issues, you can considerably reduce the steppers noise/vibration ( not really an issue when drilling, but good when drawing/pick&placing/lasering ) by dampening the motor mounts.

I'm very interrested in all the firmware ameliorations you describe, I planned on writing these so it'll save work :) ( also you need a BIG RED STOP BUTTON ! ).

Unfortunately, I found contraptor.org after I had already bought a cnc kit from zen toolworks. It is still a great machine, but I have plans for much bigger machine. Yours looks good, but are you concerned at all about the structure being too flexible? In my design, I had to compromise and use only one long axis that is supported by the table/ground along its entire length. The other two are fairly short to keep the structure and the tool head rigid. I guess it all depends on what you will be milling.

So once I got the XY arc working, it wasn't too hard to get XZ and YZ arcs to work. I'm going to do a bit more testing and add some comments and I'll post the firmware here in a new thread.

I still don't know if the firmware I have is the most up to date though. That fix that Albanetc linked to was from April, and it still hadn't been included in the version I downloaded.

The machine will mostly be used for drawing/painting, so not much flexibility concerns.
There was discutions about that, calculations ( ended up with 40x40x3mm iron square tube, less than 0,02mm deflection ), that's what the 3 big iron square tubes are for. I guess for serious milling work it would need more aluminium angle replaced with iron square tube.
I hope it will be able to mill aluminium very slowly, but it's not a problem if it does not.

XZ/YZ arcs are a very nice addition, good work !