A little confused and annoyed…

Nice Dropbox data set.

I am not familiar with Ox, have only see the pictures on web site.

My initial reaction was that Z axis is ‘different’ (than Shapeoko).
Why do they use a 400 step per revolution motor? Just curious.
What really caught my eye was the Z movement – 16mm/rev.
A Shapeoko with ACME screw is 2.11 mm/rev. From the Pics, Ox looks like a direct drive to screw as well. Are you sure about 16mm/rev?

X and Y axis travel / rev sort of high too, 60mm/rev vs 36.54 mm here.
NEMA23 motors on X and Y? X and Y velocities are high, but GCode may have a lower F speed.

Might also help if you added your Gcode file to the Dropbox for a look-see.

Can you describe ‘squirly’ Z : can’t keep up, lags, intermittent, ??

Did you try to run the job ‘in air’ above the work, spindle off, just to remove machining load?

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 🙂

• This reply was modified 10 years, 2 months ago by chmr.

chmr – You know the Ox design well. Thanks for comments. I’ll agree with your characterization “nifty idea with unwanted side effects”.

Rhino – When I play with CLI moves, I keep these in my head:
G0 moves are at max velocity
G1 moves are at F velocity
G2 and G3 moves are arcs, I don’t try them from CLI

So, from a tiny G reset with the Z above the work surface, which sets current position at (0,0,0) , you could do
G1 Z10 F20
G1 Z0
G1 Z10 F40
G1 Z0
etc., incrementing velocity (Fxx) until it starts to misbehave.

From where do you get the 50mm/min slow start velocity value? From tgFX? That velocity display is tgFX diplaying the status messages returning from tinyG, which are the results of the 3rd order calculation tinyG is doing. Not clear why this would be happening, your parameters seem reasonable (jerk, Vmax). If this persists, perhaps cut your $[xyz]vm and rerun, as an experiment.

Electro-mechanical considerations:
Z motor making any strange noises? Have you tried a run with current pots maxed out? You’ll need more torque from Z motor to move spindle up down with 8mm/rev speed.

Are the Z motor to lead screw coupling set screws good and tight?

Are you running your tinyG(and motors) from a 12V supply?
Why? Is that what Ox recommends?

Most folks run 24V, 4 to 6Amp capability, you can go higher V (tinyG rating 30V)if willing to deal with heat.
I’m thinking that NEMA23s are seriously starved for torque with 12V.
And use descent wire between your power supply and tinyG – 18ga suggested.

See

https://github.com/synthetos/TinyG/wiki/Connecting-TinyG

On tinyG, 12V pins are for fans, NOT input.

Gantry should move with some resistance manually. Resistance depends A LOT on belt tension, which from chmr’s description sounds like a lot.

From your description, movements up to F10000are OK
A G1 X300 F8000 moves to X300 at velocity 8000mm/min
A G0 X300 moves to X300 at velocity $xvm, You have $xvm at 16000

Try changing $xvm to 10000 and see if G0 X300 now works.

Your funky motor noises sound like not enough torque per step pulse.
Torque comes from current thru stepper winding. Twice as much current when pulses are 24V vs 12V.

• This reply was modified 10 years, 2 months ago by cmcgrath5035.

To summarize, when a simple linear move is requested, tinyG computes a move plan that starts at 0, accelerates as fast as possible toward $xvm (a G0 move) or current F setting(a G1 move), then decelerates to 0 at the far end. Jerk and other magic determine the shape of the actual speed profile. tinyG does not really know what the motor is doing, so can’t tell that there isn’t enough current to achieve the profile.
When running G code, tinyG is looking ahead to what it has to do next, as some next moves (consider a 179 degree change of direction) require different speed and accleration profiles.

When in doubt, keep things slow at first, ramp them until a job breaks, then back off some on speed.