A little confused and annoyed...

Sorry for the long response time. Work got busy for me. I'll try to address your questions in order. ;0)
400 step per rev motor? I really don't know. It's just what was sent to me when I ordered off the parts list that they provided.

Yes, it's basically a direct drive for the Rod. There is a flexible coupling that attaches to the motor shaft, and then to the threaded rod.

For the Z movement, that is what I was able to calculate based on a few internet "calculators" that took into account degrees per step, rod pitch, etc. I'm really new to this, so I'm trying to learn everything at the same time. The details on the threaded rod I have are:
•Tr8*8 No idea what this means
•4 Start No idea what this means
•Pitch 2mm Used in my calculations along with motor info.
•Lead 8mm Used in my calculations along with motor info.
But, yeah. I see what you mean. 1 complete revolution of the rod shouldn't go 16mm now that I think of it. But strangely, when I do distance measurement testing, all 3 axis are spot on with the numbers I've entered.
When I was testing and calibrating the movement on the X and Y, that was the only number that got me accurate for my movement tests. Yes, my feed rates are a lot slower when it's "performing it's cut" I don't have my spindle attached yet.

I'll upload the quick little G-Code I created in Sketchup / Sketchucam to my drop box.

Squirly Z. Well, when I start a job, It brings the Z axis up, moves over into the work area (It does this really really slowly I might add. It takes a few minutes to move the gantry. Slowly ramps up to a velocity of 50mm/minute until it gets to where it needs to drop the spindle) Then the Z goes down into the workspace, but goes down way too far, and bottoms out on the bed. If I pause the job, manually move my Z up, and resume, it goes about it's business fine. I figure it's got to be some sort of weird configuration / faulty end user issue, but I'm at a loss of where to start. I have some limit switches enroute, but they won't be here for about a week. I plan to use them as limit, and limit/homing sensors. Do you think that would help my cause out?

Thanks a bunch for the help.
Rhino

Hi, I try to chime in with some info to clear things up:

Threaded rod: TR8*8/4-start means: TR=standardized trapezoidal screw; the first 8 is the outer diameter of the rod; the second 8 is the lead, 8mm per revolution; 4 start means there are really 4 threads on the rod, each with 2mm offset (pitch) to the previous. 4-start helps with max load and smoothness, and is important to match rod and nut, but it does not influence the calculation of lead. Your $3tr should really be 8.

Step angle: According to the parts list, both the Nema17 and Nema23 motors are 200 steps per revolution (1.8 deg step angle). Set your $3sa=1.8 . Because your $3tr was also wrong, it evened out to the same distance (when tinyg tried to move the Z axis 8 mm, it calculated that it needs 0.5 motor revolutions = 200 steps with the old settings; with the new settings, it uses 1 motor revolution = 200 steps). But this does not explain the squirrelyness.

X/Y travel: 60mm per revolution is correct according to the parts list (20 tooth pulley * 3mm belt pitch).

I ran your gcode circle files, both of them run "fine". I noticed some things in the files:
1. You placed 4 tabs on the inner circle, but not on the outer circle. For the tabs, the machine has to decelerate x and y, lift Z up a bit, cut the tab, drop z down, accelerate x and y again.
2. The gcode assumes that Z=0 is at the top of the material (very common). That means that positive Z coordinates are in the air, negative ones are cutting in the material. If you set up the 0 coordinate at the top of the work bed (not the material), it would explain why the machine tries to cut into the workbed.

Velocity: The feeds in your files and parameters seem to be quite fast (in fact, I think 5000 mm/min feedrate would be too fast for all except *very* soft materials). I cannot see the 50mm/min and slow speed to move the gantry. Did you do this test with a different file or different settings?

Limit/homing switches are a good thing, but I don't think they would change anything about your problem.

Edit: Nearly forgot, another common issue with Z going to deep is when the Z axis actually goes too short when commanded to go up (caused by sticking/binding Z nut, over temperature of driver or motor, too fast max speed $zvm, slipping pulley/coupling, slack belt). I don't think this is your problem, but you can try to send the Z axis up and down manually with "G0 Z35" and "G0 Z0". If it does not stop at the same point every time, investigate further in this direction.

Btw, thank you for reminding me to download sketchUcam 1.2 :)

Yes, thank you very much Chmr! I'm finally starting to understand this stuff a little. When I get home tonight, and put the family to bed, I'll go down to my garage, and go through everything. And, you're welcome for the reminder! ;0)

The 5000 mm/min federate is just what I'm using for my "in the air testing". It will definitely be slowed down accordingly for whatever materials I wind up cutting.
The 50mm/min issue has persisted through every file I try to send it. I will try again with different settings. Good thing I'm an insomniac.
Good thought on the Z going up short. I'll check that out by trying out the G0 Z35 and G0 Z0 I saw somewhere about a G00 command. Is that a valid command to move things at maximum speed?
Thanks for everything so far guys, and I'll be sure to report back when I've gotten it all sorted out and working. Hope to have a Youtube vid of some chips flying around soon.

Rhino, yes G0 (or G00) is a fast move, only limited by the setting of $xvm/yvm/zvm. G1 X100 Y100 Z30 F500 is a feed with 500mm/min (limited by $xfr/yfr/zfr), usually used for the actual cutting.
A good cheat-sheet for common gcode commands is at http://linuxcnc.org/docs/html/gcode.html
The issue with slow moves has me stumped -- are you sure that you didn't change any of the *vm or $fr settings from the dropbox settings?
Please post results, and when you have success, a video is always fun to watch :)

Carl, a true philosophical question indeed. If you want real answers, you'd have to talk to teh Openbuilds guys. I *guess* that they did not intend to make the machine faster, but had to use the pulleys out of necessity: They wanted to run the belt inside the extrusion slots and dual-use their solid V wheels as belt-idlers. That means that the belt must be even narrower (5mm) than the GT2 belt on the Shapeoko2 (6.3mm), and it is already a limiting factor on the Shapeoko. They had to move to 3mm pitch (== thicker/stronger belt) to offset this. And to make sure that enough teeth are engaged, they had to use 20 tooth pulleys.
I'm inclined to call this a nifty idea with unwanted side effects. Although the *theoretical* accuracy of the Ox is 0.0375mm (60mm per revolution / 200 steps per revolution / 8 microsteps) is worse than that of the Shapeoko2 (36 / 200 / 8 = 0.0225), the *real* accuracy of both machines is limited by other factors (rigidity or lack thereof, backlash in belt, wheels, bearings, and chip-size of material).

Hey guys.
Those settings in the config file are what I was running during the tests.
I did do a bunch of testing with the velocities, and feed rates on all 3 axis. I would adjust the Max Velocity, and Feed rate Velocity up by 1000 increments. Then I did a G1 f(insert number from 2000 - 10,000) x300 then G1 f(insert number from 2000 - 10,000) y500 and then G1 f(insert number up from 200 - 1000) Z29
Every single test worked perfectly fine all the way up to 10,000 even with my spindle attached. But, when I go and do a G0 command on ANY of the axis, it starts to move, motor makes a weird noise, and it looses all the steps. I have no clue as to where it is getting the velocity speed for the G0 command. I've gone through the $$ "printout" from within Coolterm, and tgFX. Seeing as I have a capture of the config file for reference, I may do a "factory reset" and try it all again. I'll do up a quick little video showing what I did for the testing, and post it up. You guys would likely know by the sound of the motors and such what they are doing. I also did the AMP calibration on the motors as well.

The $[xyz]vm is velocity maximum correct? Also, I'm not sure about the jerk rating. I've not been able to find a good explanation of what that kind of jerk is.

The 50 mm/min velocity value is unknown to me.

The lead screw to coupling is good and tight. It's not spinning out at all.

Just out of curiosity, how easy should the gantry be able to move? Mine has a little bit of resistance to it, but I don't think it's too bad....

Wow! What a novel!

Well now. Just for poops, and giggles I changed the power wire going from my powersupply to the 12V of the TinyG and WTF (Why The Face)! G0s now working fine. Was my TinyG actually starved for power? But starting up the job, I still get the slow traverse out into the work area, but it's not as long. The GCode for that job is up on the drop box. It's the one named Lotsoshapes.cnc Anything in the G-Code that sticks out, or any other weird $command it could possibly be that I can't set from within tgFX??

Yes, I'm running from a 12v supply right now. I have no problems going up to a 24v unit. I think I'll actually pick one up. The 12v supply was just me being too cautious I think. But, as it stands right now everything is working since I changed my power wire going to the TinyG. I am definitely going to upgrade to a better powersupply. Need more volts & amps! ;0)

I have $[xy]vm at 10000, and $zvm at 1000, and everyone is doing max velocity G0 moves now with no problems.
Thank you guys so much for the help. I hope that I soon become knowledgeable enough to help pay it forward.

Rhino.

Factory reset, and then re-configuring made everything work perfectly. No longer getting that slow movement to the cutting area. My lotsoshapes GCode file now takes under 2 minutes to do with no changes to the GCode. Pretty darn happy with this TinyG, and OX configuration. ;0) Time to make some sawdust!!!