Jittery stepper pulses with mesa 7i76E [SOLVED]

More
09 Jul 2022 06:13 #246930 by paw
That's very helpful. I like to understand how it works.
Thanks again for your help.

Please Log in or Create an account to join the conversation.

More
07 Nov 2022 16:22 #256151 by mwiktowy
Thank you for the solutions posted here

I think that I may be experiencing the same problems. I was having periodic "grinding" noise that would show up whether I was Jogging or the machine was following gcode that was independent of travel speed that would eventually fade away. I increased the DPLL pre-sample time to 100 and it seemed to go away. But recently it came back (possibly a system update or something changed the network behavior).

My question is if there is a practical upper limit to the DPLL pre-sample time which you shouldn't exceed as it will just end up making things run rough again or trigger other errors or bad cuts?

I am running a Mesa 7i92 card that is connected to a Gecko g540 control box that is all driven by a Raspberry Pi 400.

Please Log in or Create an account to join the conversation.

More
07 Nov 2022 16:34 - 07 Nov 2022 16:40 #256153 by PCW
I would say -250 usec would be a pretty reasonable upper limit for a 1 ms servo thread

You may need to tweak the FF2 term in the PID tuning to get the best following
error if you use a large pre-sample time (add the pres-ample time in seconds to FF2
so for 250 usec add 0.00025)

If it needs to be that high , it does indicate that the network latency is quite poor
(50 usec is usually OK on PCs)


I should add that you need to use ntpd on the RPI rather than timesyncd, as timesyncd
makes step adjustments in the clock that sets the servo thread rate, leading to
loss of DPLL sync
Last edit: 07 Nov 2022 16:40 by PCW.
The following user(s) said Thank You: mwiktowy

Please Log in or Create an account to join the conversation.

More
07 Nov 2022 18:47 - 08 Nov 2022 03:30 #256157 by mwiktowy
Thanks for the feedback. I have -100 right now and a FF2 of 0.0001. I had temporarily changed it to 200 and 0.0002 on one of the axes to see if that made a difference (and it didn't) so thank you for giving me a sense of whether I had gone far enough or not.

The different time server slewing methodologies is something I hadn't considered. I grabbed an updated RPi image from the forums here but have no idea which time sync daemon was used. Thank you for pointing me to something that seems to fit the facts of the problem:
1) restarting after some time with the RPi powered off
2) speed independence
3) periodic but goes away after 15-20 seconds
4) axis independence

Hopefully that is the issue as it is a fairly easy thing to check just by turning off the deamon. Do you see any harm in just keeping the timesyncd/ntpd off while running the CNC machine?

Thanks again!
/Mike
Last edit: 08 Nov 2022 03:30 by mwiktowy. Reason: Added forum link to where I downloaded RPi image from

Please Log in or Create an account to join the conversation.

More
07 Nov 2022 18:55 #256158 by PCW
Yes, you could just disable the demon (if you don't care about correct TOD)

The error usually shows up when running timesyncd with a flaky internet
connection (so large timebase adjustments are made)

ntpd always slews corrections slowly so doesn't cause the issue
The following user(s) said Thank You: mwiktowy

Please Log in or Create an account to join the conversation.

More
15 Nov 2022 04:35 #256752 by mwiktowy
Just to follow up ...
The command:

timedatectl set-ntp 0

eliminated the jittery motion. That seemed to be the source of the issue.

Thanks again for the suggestion.
/Mike

Please Log in or Create an account to join the conversation.

Time to create page: 0.155 seconds
Powered by Kunena Forum