Starting over

Ok, the joints-axis shift in the stepgen values

Xa => 0
Xb => 1
Y => 2
Z => 3

meant the outputs on the G540 shifted as well, the silk screen XYZA tripped me up - it could read port 0123 and I would have been closer to the issue. Bit of a forest-trees problem.

Just to muddy the waters a bit more, the mapping of logical axis to physical stepgens
in LinuxCNC is entirely arbitrary.

PnCConf seems to let you assign them in any order so to match your existing wiring, a:

Xa => 0
Y => 1
Z => 2
Xb => 3

mapping probably would make more sense (assuming PnCConf does the right thing with gantry configs)

andypugh wrote: I think that error is an actual bug.
github.com/LinuxCNC/linuxcnc/issues/159

Try skipping the test/tune part, then worry about it if the axes don't actually move with the final config.

I have the axis moving but I am just guessing at the tuning values. I have the step_scale at 1909.86.

I went through this wiki page:
wiki.linuxcnc.org/cgi-bin/wiki.pl?Tweaki...ftwareStepGeneration

However I learned "You are asking about a Mesa card. Those cards can generate steps in hardware, and latency becomes much less critical - to the point that the entire wiki page is irrelevant if you have a Mesa card."

Is there a command line work around to testing the steppers? What PNCCONF would have done were it working? Hand editing the config files, at least for me is not getting the steppers in line. .

The step scale setting is not normally something you tune or tweak , but rather
something you calculate and set once.
(you might make a small adjustment later to compensate for leadscrew inaccuracies)

For a standard direct drive step motor system, this number would be
ustep-ratio * 200/leadscrew-pitch (pitch expressed in machine units)

So for example: on a inch machine with a 20 TPI = .050" pitch thread and 8 usteps, the step scale
would be 8*200/.050 = 32000 (step pulses per inch)


Latency is much less important for hardware stepgens but cannot be entirely ignored
For hardware stepgens, a base thread is not needed so for example running

latency-histogram --nobase

Will give you a good idea of what your servo thread-only latency is

<100 usec or so is fine for hardware stepgens and more can be accommodated with some adjustments.

EDIT:

You can change the step scale while running axis by invoking the calibrate menu

PCW wrote: The step scale setting is not normally something you tune or tweak , but rather
something you calculate and set once.
(you might make a small adjustment later to compensate for leadscrew inaccuracies)

Thanks - 1909.86 was the equations results,which was just ball park, as it turned out. I rocked the axis back and forth in the MDI and tweaked it until I got consistent results. Not sure if 1909.86 is bad math or the Gecko G540 is acting up. I have to affix a heat sink because the g540 gets imprecise as the heat builds up - even with a strong fan pointed at the bottom. Eventually 2 (ports 0123) will just stop responding. Lesson learned, the G540 should be your second choice for a large system...

The axis moves but it is very slow. I took my step_scale to 10X to see if it moved any faster and yes it did. Not the actuate setting by any means but it sure zipped along. In my thinking that is not just more current but more pulses. So I am guessing that the setup can move faster than a snail's pace. The calibrate menu values can be changed but I am not seeing a significant influence in the slow movement so I am missing something.

Also, latency-histogram is a bit of a mystery to me. The official documentation I can find appears thin (less than one page) and doesn't tell me much.
the histogram page

What is you leadscrew pitch?
Do the step motor drive the leadscrews directly?
Is this a inch or mm system?

The latency histogram is used for determining latency maximums (most important) and statistics

Other than the command line options, its pretty straight forward (that is just running it with the --nobase option is all you need do)

To get a list of command line options, type latency-histogram --help

Rack and Pinion.

I'll be wordy so you can see if I dropped a step. The motor is 200 per revolution and the pinion is 1.0" driving a 3/1 reduction. So one revolution of a one inch pulley is 3.1416 inches of travel per revolution at the motor pulley. The G540 uses 10X micro steps so that equals 636.66 steps per inch, the result of 2000ms divided by 3.1416 inches. With a three to one belt/pulley reduction I should need 1909.86 steps to move the axis one inch, the result of 636.66x3.

1909.86 was a consistent 1.125 inches when rocking the axis through the MDI. I trimmed it back until it moved an inch to about 1750+/-. That is a red flag to me (1909 vs 1750) but unless it's the Gecko I am not sure where to look.

The distance per pinion turn should be the rack pitch * pinion teeth
It would be a bit odd to have Pi on the equation unless the rack pitch has a factor or Pi

Is this a rack-and-pinion drive? If not, what is it?

What comes after the 3:1 reduction?

Assuming that your 1" pulley is actually a 16-tooth XL pulley, that is actually 16 x 0.2" per revolution. So a scale of:
(10 x 200 x 3) / (16 x 0.2) = 1875. If it is a 17-tooth pulley then you would need 1764.7056 for the SCALE.

If the machine isn't going as fast as you want, but you have shown that it can go faster, you need to change the MAX_VELOCITY settings. (and check that feed-override is at 100%)

PCW wrote: The distance per pinion turn should be the rack pitch * pinion teeth
It would be a bit odd to have Pi on the equation unless the rack pitch has a factor or Pi

Most gears do actually have a factor of pi built-in. The tooth sizes are normally in diametrical pitch, rather than circular pitch.
A 12DP gear moves 0.261799 inches per tooth.
This makes gearbox design fairly easy. The centre distance of a 30 tooth and a 65 tooth 12-DP gear pair will be half of 30/12 + 65/12.

Belts and chains, on the other hand, use a fixed circular pitch.