cmcgrath5035

I can’t offer any suggestions, don’t use limit switches yet.
Many do, someone will stop by and comment, I’m sure.
In the meantime, have you read thru the wiki info?

https://github.com/synthetos/TinyG/wiki/Homing-and-Limits-Description-and-Operation

Ted
Needless to say, something sounds seriously wrong. There are still bugs being worked in tinyG, but basic moves as you describe should be executed OK for sure.

It is unclear how you are now configured. You WERE using an Arduino to directly drive your Polulu drivers, or via a G shield?
And you are NOW driving your motors directly from tinyG, or are you interfacing tinyG to Polulu stepper drivers to drive your motors?
I don’t have direct experience with this setup, but wonder if you are aware that tinyG has 3.3V logic swings that may not be compatible with the Polulu drivers. There is a good wiki item on the topic of driving external stepper drivers from tinyG.

You reference pots at 10 o’clock a lot, which seems to imply you are driving motors directly from TinyG (unless Polulu have pots too). If that is the case, sort of have to ask-are you sure the motors are wired correctly?
I run NEMA 17s, and never changed pots from 12 o’clock until I ran into some very speed aggressive GCode. I’d suggest perhaps 1 o’clock as a good starting point for NEMA 23s.
Run fast, but don’t run slow is sort a a new one on me; high speed is the usual trouble maker.

If this part of the setup is good, then we’ll need some other info to help out:
tinyG hardware (V7, V8, etc) and FW build loaded
How do you interface to tinyG? (Win, MacOS, Linux)?
All three work, but troubleshooting tools are different on each platform.
How do you run GCode? (tgFX, Coolterm, putty, etc)
If tgFX, what build are you running?

In the last paragraph of this wiki item you will find an equation that probably answers your “how fast can it be” question:

https://github.com/synthetos/TinyG/wiki/TinyG-Using-External-Drivers

My first thought when reading you question, assuming X and Y axis parameters are identical and set accurately, was belt tension. My second thought was “is the home position too close to a rail, such that the the motors are holding the home position under some sort of stress” ?

Is the first move still “short” if you follow this procedure:

1. jog to somewhere in the middle of the X-Y work area.
2. Set that as zero point (if using tgFX)
3. Reset tinyG (manual reset button). That will set tinyG to zero at that point and will release the holding tension on the motors so that the belt tensions should equalize and be fully relaxed when the hold current is reapplied at the end of boot.
4. Zero set you measurement system (micrometer)
5. enter Gcode F200 to set a relatively slow “non-aggressive” work velocity.
6. enter Gcode G1 X1.0 to move 1mm at F200

If 1-5 works, maybe try it at higher speed and/or at different zero points around your workspace

Other thoughts
-Worn belts? I have worn my belts near the ends somewhat by ramming the machine to a rail and spinning the pully. If Home is always in the same area, I think you can expect faster wear in that zone.

-Motor pully really tight on shaft?

– Tension on X carriage due to, for example, motor cabling/cabling track?

Good luck

Ah so, we were typing at same time.

Riley aware of the intermittent jogging (arrow key) bug and working it now.

Read your parameters and comments fields carefully – some(not all) of the huge numbers have new parameter scaling; e.g. what used to be 1000000 is now 1, but both are 1 million.

Funny thing is, it worked fine right after I flashed it, I was able to move around with no problems. Then when I went to actually do some work, it stopped

I believe one aspect of the bug Riley is chasing is that tinyG and tgFX are “in-sync” mode wise at boot, but get out of sync

Greetings.
When seeking help, it is always helpful to provide some info:
– TinyG hardware version ( you said brand new, so probably V8)
– TinyG FW version and build – (likely 412.01, maybe 429.01)
– How are you communicating with tinyG? (tgFX, Coolterm, putty, …)
– If tgFX, what version and build installed?
– What OS you running? (OSX,Linux, Win)

A couple items stand out that might head you in the right direction.
1. Most of the pre-built (or default) tinyG configurations at the moment are for 200 step per revolution motors, which yield 360/200=1.8 degrees per step.
I don’t think driving a 400 step per rev motor with 200 step settings will damage it, but it may not work properly and for sure won’t move accurately.
It sound to me that the motors may have been moving during the speed ramp up and ramp down phases, but not when constant velocity called for.

2. Depending on tinyG FW version, you will find settings for X,Y and Z travel, min and max. Defaults might be something like $xtn=0, $xtm=180 (for a ShapeOko1 machine, in mm). TinyG may not traverse outside those limits, and you may see messages like “outside range” if using tgFX.

Suggestion: Read thru the tinyG configuration Wiki pages a few times, get the basic configs set and rerun your experiment.
And, when you finally have a real machine built, play in short steps, such as G0 X10.
A G0 X1000 will almost always send your machine into a side rail at blazing speed and bang on it (or worse) for a while. Limit switches might help,if you have them, but their setup needs to be done correctly and verified as well.