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

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.

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.)

 

tommylight wrote:

Did you test with reset time of 5000?
 
 

 My understanding is that the .ini and .hal files are accessed when LinuxCNC starts, which I haven't risked trying until I get the latency straightened out.

I'm misunderstanding something. 
Uppermost is what you mean by testing with the parport reset time of 5000.
Secondly, does the latency-test access the .ini or .hal file or both?
Is it possible to run LinuxCNC and to test various settings independently of latency-test? That is, can I just start up a custom G-code to send it around and around for hours and see if it still has its zero at the end?

I tried creating a new machine config from scratch with stepconf where I entered the desired step, dir, and jitter values, while copying pin, axis, and spindle values from one that had worked before. However I could not test run it because stepconf didn't or couldn't find the parallel port on the card and insisted on overwriting the address in the .hal to '0 out' every time I edited it to 'dce8 out' which works in other .hal files--and which files stepconf strangely does not overwrite.

When I use one of those other configs, and change the Steplen/Stepspace/Dirhold/Dirsetup/Jitter settings to 5000/5000/8000/5000/50000 ns, all 3 axes perform acceptably when tested in stepconf.  Stepconf reports using a base period of 65000 ns.

But they tested well in stepconf's Runs before the initial problem showed up too.

@tommylight

Okay, I get 'stepconf' now. The pins, axes and spindle settings passed.

I'm well-acquainted with using 'vi' and have edited .ini, and the .hal file less often in the past.

By "test", the only thing I know to do at this point is load up a G-code project and give it a try.

I am supposing that increasing the parport reset time from 1500 to 5000, and raising the jitter time to 50000 (which stepconf dutifully translated into 65000 dirhold and dirsetup times in the .hal) will 'slow' the controller's command stream down sufficiently so commands will be less likely to be missed.

I'm off to do that. Thank you.

clunc wrote:

@tommylight

I'm well-acquainted with using 'vi' and have edited .ini, and the .hal file less often in the past.
 

I can't believe people still use vi.
please try
sudo apt install geany
and give geany a try. You will never go back.

Tried a model. Failed. Lost steps.

I managed the rough cut which was relatively simple, with a 1/2" endmill @80ipm.
However the back-and-forth passes of a 1mm roundnose @120ipm lost steps after perhaps 2 dozen passes. I'd left the room after assuring myself that it seemed stable.

However, the first passes were also relatively smooth. As the majority of the model is carved relief text, there is much more acceleration/deceleration required in those parts and it appears that it failed as it entered that area. I discovered it after I returned to check on it.

After I shut it down, I "posed" the model in the AXIS GUI and snapped a picture and was attempting to jog the head out of the way so I could take a comparative picture of the model when LinuxCNC locked up and became unresponsive to the mouse and keyboard, and Ctrl-Cs in the terminal failed to interrupt it.  I had to force the terminal window closed to kill it.  Even at that, it said LinuxCNC was still running when I restarted it.

I've attached pictures.  The second is a terminal message about 16 latency excursions (I'd have expected 100s if not 1000s). "16" may correlate with the number of passes in the more complicated area of the model before I shut it down.

The finish pass begins from the lower-left of the model and then cuts left-to-right (+X), then steps up (+Y) a fragment of the width of the 1mm cutter, then cuts right-to-left (-X), steps up (+Y), etc.

Axis accelerations and velocities are copied from the last setup, and the CNC itself is capable of executing them, and each axis performed acceptably with those accelerations in stepconf.

I'll attach .ini and .hal files for completeness sake.

The lockup makes it appear to more serious a problem than losing steps.