Successfully configured with stepconf: but +Y-axis "stutters" running G-code

Not that I would expect it to necessarily make a difference, but 'fan control override' should be enabled not disabled. Removes the burden from the hw to monitor temp and control the fan.

I probably misunderstood. The fan runs on high all the time.

Found this thread about setting base period, as a last resort:
forum.linuxcnc.org/49-basic-configuratio...ges-without-stepconf

Excerpts:
@tommylight:

Stepconf is meant to make a usable config, and it does that perfectly.
For changing the timings and fine tuning, editing the .hal and .ini files in the config/ folder is the way to go.
In the .ini file there will be:

• BASE_PERIOD - set this depending on the jitter value plus 50% to be on the safe side
• steplen and stepspace- set this to 5000 and lower it gradually to where you are sure there are no missed steps from the drives, forget what drive manufacturers say about this
• dirsetup and dirhold- set this to 20000, it does not matter much if you go lower or higher, but to low can cause very strange missed steps

@BigJohnT:

Stepconf does have some limits and once you get a basic configuration editing the files is the way to go.

@andypugh:

There is no advantage in having dirhold and dirsetup short. The machine is by definition moving at zero speed at that point.

If you want shorter step lengths, then edit the .ini file.

The chances are that the max speeds that you have configured mean that stepconf sees no need to use a short step length, as the max required step rate can be achieved without.

It begs the question:
Q. What-in-the-world values did I copy over from the old computer/controller in the .hal and .ini files?

.ini/[EMCMOT] section:
BASE_PERIOD = 31500
SERVO_PERIOD = 1000000

.hal:
setp stepgen.0.steplen 1
setp stepgen.0.stepspace 0
setp stepgen.0.dirhold 31000
setp stepgen.0.dirsetup 28000

I recognize that the steplen/stepspace values contradict the instruction to set them to 5000 initially and, stunned, went back through all of my old .hal files (I made backups when I made edits) and grepped for the step settings, and every single one had the pair set to 1 and 0. I had apparently never set these values to 5000 (or worse, overwritten the defaults to 1 and 0).

I realize this can't be the explanation for the poor latency performance of the hardware, but at the least, it meant I had been operating the machine in unsupported territory.

Next step: change BASE_PERIOD to 50000 (maxjitter + 50%) and steplen/stepspace to 5000/5000 and test performance.

-step length and space are usually in the ini file, and there should be edited.
-in hal file the step space and length are in periods, not ns, so means the step length is 1 base period, depends on the parallel port reset time set in hal, usually 5000
and step space is 0 periods so it can push steps at every period.
--
Consequently, if there are no space length settings in the ini file, edit the hal file and set the parallel port reset time higher.

Tommy,

I do not have any of STEPLEN/STEPSPACE/STEP_SCALE variable definitions in my .ini file, which as I recall I have been carrying right along with upgrades from linuxcnc 2.6 through the current 2.9.0~pre0.

In the .hal file I found:
    setp parport.0.reset-time 1500
a far cry from the typical 5000.

Perhaps I need to give up trying to 'save time' by recycling files from the previous controller and go back and do a brand-new install following each instruction.

(I should say that I have s Raspberry Pi 4 8GB sitting here which I have unboxed one time, determined to start fresh, only to quickly get cold feet when I realized I'd be giving up parallel-port step generation, the only thing I've ever used, and I'd have to learn how to configure and use a Mesa board at the same time. It went quietly back into the box.)

 

Did you test with reset time of 5000?