Odd mesa 5i25 stuttering

Hello everyone,
so far i was a silent reader of this forum. But since 2 days I am sitting at a problem where I can't seem to get any further. I have a 6040 CNC with slightly different electronics (no change that could cause this behaviour). More precisely, they are open loop stepper motors. The machine has been running fine for 1 year with linuxcnc and a mesa 5i25 without any adapter board. Because i finally want to mount limit switches, i created a suitable bitfile for the mesa card and also set up the computer fresh. In pncconf i entered my readhmid output in debug mode and configured everything. The machine runs fine in the test modes of pncconf.


Unfortunately this is not the case when i start linuxcnc.




The motors stutter relatively unevenly regardless of speed, acceleration or position. What I have tested so far are different servo thread clocks, maximum speeds and accelerations. All these things did not change anything. What has strangely caused a change is the p value of the pid controller. If I understand the documentation correctly, the p value should be set to 1/(servo thread in s) when using open loop configurations. The controller is then only used as feedback from the mesa card. I could disable the whole pid control and write a configuration without it but that doesn't sound like the right way as I already read in other threads (and also makes a lot more sense).

What I already found via the search apart from the less relevant or tested stuff:
forum.linuxcnc.org/38-general-linuxcnc-q...pen-loop-stepper-pid

Maybe someone already had such a problem and can push me in the right direction...

I also attached my configurations for better understanding.

Thanks a lot
Stefan

Maybe double your step times?

Thanks for your reply!
That is something, I already did in some way. I've reduced it to half because I thought maybe the stepgen has not enough time left to generate the long pulses. But if this is the problem it would also show up in test mode (I think?).

With your current scale you could go up to about 75000 ns on both steplen and stepspace
without impacting the maximum speed, so I would double the times or just use
10000 ns (10 usec)

I've just tried both 10 and 20us. Still stuttering... I would like to know what causes linuxcnc to drop the velocity as shown in the video. If I drive the card harder than it is able to follow I would get joint following errors as per normal. So I really don't know what causes this...

Sounds electrical (step/dir signals) to me
How are these connected to the drives?


You can verify if the LinuxCNC side is doing the right thing by
plotting the following error with halscope

I don't see why it should work in test mode but not in linuxcnc afterwards if it is an electrical issue. So far there is no change made to the drives. There is a TX14175 Board inside which then forewards the signals to the actual drives. The mesa card ist actually generating these stuttering pulses on demand of linuxcnc!

Just as a clarification: I can switch between working and not working by using either linuxcnc or pncconf to move the machine. There is no difference to the machine itself for that to happen.

I've attached a scope shot as well.

Looks like there are some relatively huge latency spikes
when LinuxCNC is running. Did you run a latency test?

Possible work-arounds if you cannot fix the host latency issues are:

1. Make the maxerror smaller so the maximum velocity modulation
range due to latency is reduced (if you go too small the PID loop will lose
control since it will not have enough range to correct for LinuxCNC <->
5I25 timebase differences)

2. Make a bitfile with the DPLL module and use it to re-time the stepgen
position sampling.

3. Lower the servo thread rate to 500Hz or so

Are you seeing this while jogging with the keyboard?

As a test try jogging clicking the on screen buttons with a mouse instead of the keyboard keys.

Test using MDI move commands.

Does it still do this when moving with those ways?

BTW if you do the plot scaled so that the PID error peaks are on screen
(and the velocity is shown), the latency can be calcuated