Beginners help with latency error / loosing steps

Hey People,

Im new to LinuxCNC, an while I've been digging into it for a few weeks and getting quite far on my own, now im stuck - And would love some professional eyes on my case.

I bought a pre-bulit 3 axis from a hobbyist a while ago. Machine is wonderfully configured, very sound construction. Software... well, i don't know.
Now after some minor adjustments and finally (!) getting my tool probe working properly, i have had two occurrences of loosing steps on Y axis, which is moving the heavy gantry. Simultaneously, i always get a latency warning on startup ("RTAPI: ERROR: Unexpected real time delay on task 1"). Wich also manifests itself in a short freeze of the PC when loading larger gcodes (10 mb and up). At least i guess those issues might be connected - Im a little out of my depth here.
Im running of an old Dell Optiplex 960, sporting a E8000 Processor. I did all the BIOs settings as recommended. So what else could i do? Stepper tuning? (Is that even related to latency issues?) Any ideas?

Looking forward to your help!

All the very best,

Raph.

Parallel port ? Or Mesa ?
If parallel, edit the ini file found in the machine configuration folder and set the Base_period higher, test several times till you get no more warnings.
Beware that that will limit the velocity and might cause joint errors, so the joint/axis velocities will have to be lowered for each axis.

Im on Parallel port.
As a bloody beginner Im hesitant to change any values without knowing what they actually do. Im still reading the manual and sereral posts, and lets just say: it's not a concept that comes naturally to me.
I did a few latency tests, usually around 16000, highest ever recorded was 18000.
The BASE_PERIOD is set to 16666, MAX_VELOCITY set to 140. Does that look about right?

-Try base period at 50000,
-test for at least 1 hour of air cutting, copy files, watch youtube, etc
-if no latency warning, set to 45000
-rinse and repeat.
If you do get warnings at 50000, try 55000 and up, in 5K increments.

Run the latency test, what are the results? (Some things to check, dead/weak CMOS batteries can cause the BIOS to be reset to default settings that might wreck latency where it had been good, also dying hardware (such as a failing HD) can also cause latency problems.)

What is the current base thread speed? (Will need to be some amount less than your worst case latency.)

What is the current step scale, max velocity, max acceleration, and step timing? (All of the scale and speed info is in the ini file.)

Alright, thats something i can work with. Thank you so much!
But would a change of base period in that range affect any other settings that id have to adjust? Just to be sure...

Raph wrote: Im on Parallel port.
As a bloody beginner Im hesitant to change any values without knowing what they actually do. Im still reading the manual and sereral posts, and lets just say: it's not a concept that comes naturally to me.
I did a few latency tests, usually around 16000, highest ever recorded was 18000.
The BASE_PERIOD is set to 16666, MAX_VELOCITY set to 140. Does that look about right?

If you are getting latency peaks around 18000, then the fastest you should probably consider running the base-thread should probably be about 25000. Even then you might still get some real time warnings.

Okay, it starts to make sense to me. But as i already have your attention, please let me dig a little further and eliminate any confusion. (I'd like to someday truly understand what im doing..)
So min. base period is my latency (18us) + min. required hold time (2us im my case), and a little extra wiggle room. Which is how you arrived at the base period of about 25000, right?

If i further examine the Stepper Tuning manual, it starts to get weird. Either i don't get this (likely) or my predecessor just messed things up. My drives datasheet is a little vague with only defining min. of all timing requirements at 2 us.
So Stepconf looks like this atm:

setp stepgen.0.steplen 1
setp stepgen.0.stepspace 0
setp stepgen.0.dirhold 7630
setp stepgen.0.dirsetup 7630

But the results of the Step timing Calculator suggests something completely different.
I know my drive needs at least one period before a direction change, so dirhold should be 18us latency + 2us min from the dive = at least 20000 ns?! No? And then there is stepspace (which i don't fully understand yet), but having it at 0 seems suspicions.

Id love your comment and advice on this. I hope it makes sense to you, and sonn will to me. Heads up!

Cheers,

Raph.

EDIT: One more thing that i cant seem to find out on my own: which parameter sets the signal output at either rising or falling edge? My drives like the rising variant, and i'd like to make sure LinuxCNC does exactly that. But where to check?

Raph wrote: setp stepgen.0.steplen 1
setp stepgen.0.stepspace 0
setp stepgen.0.dirhold 7630
setp stepgen.0.dirsetup 7630

If i remember correctly:
Those are not timing settings, those are intervals of base period used for software stepping/parallel port, usually in hal there is an entry that resets the parallel port pins at a set interval,
The timings are usually in the ini file, or if they are not present, the above mentioned reset time will set the timings.
Eg.
loadrt hal_parport cfg="0x378 out"
setp parport.0.reset-time 5000

steplen 0 / stepspace 1 indicates that your config is using the "reset" function, which runs after parport.0.write, waits a little while, then resets any pins configured as step pulses back to zero. This means that the system can step every base thread rather than every second base thread.

But make sure that you can see evidence of a reset function being loaded in the HAL.

dihold and dirsetup are rarely, if ever, critical and there is very little penalty for them being too long as the motors are always moving at zero steps per second when a reversal happens.