U axis configuration

captain chaos wrote:

[MAX_VELOCITY = 81.4285714286...... this was generated by step config for "Gecko 540" with a 100mm input (TRAJ) I guess

Seems rather random, perhaps "80" would look neater.

MAX_ACCELLERATION = 30.............. this seemed a bit low and uped it to 150 with improvement and 300 even better
STEPGEN_MAXACCEL = 37.5........... same here 185 with above and then 375 ditto with improvement

You need STEPGEN_MAXACCELL to be about 10% higher than MAX_ACCELLERATION. 300/330 seems reasonable.

captain chaos wrote:

With these higher values I can now Jog in "WORLD" mode (continuous) but get a following error when I stop

This _might_ be because the base period is too long for the step rate. The f-error limit is higher at high speed, so perhaps you are running at (say) 0.5mm f-error, and that is fine until you slow down.

How many step per second are you asking for at max velocity? How does this compare to the base period? The only cause of a following error in a stepper system is if the stepgen reports back that it has failed to make all the steps.

Does your HAL file have "reset" active on the step pins, and a step-space of zero (this activates what used to be called "Doublestep" and allows one step pulse per base period, rather than on during one base period, then off during the next.

captain chaos wrote:

I have 2666 steps or 26660 micro steps and Base period is 35000

I am sorry, but I don't really understand your numbers.
26660 steps per inch? per mm? per minute? per second?

35000nS (or 35uS, to use sensible units) is 28.6kHz max step rate. If you have 26660 steps per inch and a 60inch/min rapid speed (or, 1" per second) then you are getting _very_ close to the limits. However, that rather depends on what your numbers were.

My HAL file has "reset" active on the step pins, and a step-space of zero, is this good.

That's good.

captain chaos wrote:

That is 26660 steps per second
...
this looks like I am aiming way too high?

For software step generation, yes.

There is a more subtle effect at play here. You have a system that can manage 28kHz step rate. What is the next slowest that the motors can spin? The answer is 14kHz, 2 base-periods per step. This means that your system is probably alternately doubling and halving the speed of the motor. And that simply isn't possible.

Now, the software has no idea what the motors are doing, there is no feedback, but the step generator might well be getting in a bit of a mess with the doubling and halving of step rate every mS (servo thread time), because that exceeds the stepgen accell limits.

One very simple thing to try is reducing the microstepping factor. 4x microstepping is as much as you can really expect to do accurate positioning. My opinion is that any more is a gimmick (though that is opinion, not experimentally validated fact).

You could also consider swapping to hardware step generation. Pico, Mesa, Pluto, Motenc and others all make suitable hardware. Though calling Pluto "suitable" might be stretching a point. Those offer MHz step rates, which are no practical use, but do mean that you have very small "granularity" at 10kHz step rate.

captain chaos wrote:

And Big John T made the comment in #9009
"The 540 is a pint sized 203v and both are fixed at 10x".
Is he saying that it is fixed at 10 micro steps which is why I still cant get it moving reasonably without following joint errors?

That sounds to be what he is saying, but you seemed to say that you have been changing the microstepping. Where were you changing it?