Advanced Search

If you want help, you will have to upload your hal & ini files, otherwise no one knows exactly what you are doing.

Heh. It's as if you actually know a lot about this, and have been doing it a long time.

I changed hm2_7i96.0.dpll.01.timer-us from -50 to -250, and the symptom went away. (First try, I changed all 4 dpll values by -200, but it turned out changing the others wasn't needed. I'm guessing they're not used?)

Thanks! Oh -- also, hm2_7i96.0.packet-error-total stays 0.

paul
p.s. Best tech support ever...

ok so i made it out to the shop and have a rudimentary pwm signal running. but i am sill having some problems with it. it works ok from the mesa to the pwm module, i get 2.5v-4.5v when i run the spindle. my min speed is 12k and my max is 24k, so those numbers make sense, although is there a way to get closer to 5v out for max speed?

on my module, i get a constant 8.5v out which i think might be a bad module so i have one on the he way, supposed to be here to tomorrow. 

but i still cant get either the spindle on, flood, or mist pins to work.  in hal meter, it shows the pins toggling, but physically nothing happens. out of curiosity the three of them map to gpio.00.out etc, which gpio.[00-09].in are all of my inputs. is this right on a mesa? when i changed all of them to 10-12, i get error saying pin not found. 

Hi Andy... I am muddling my way through this and have things working really well, except inputs. Gpio reads gpio13 fine in python, hal_gpio always shows high in hal scope, meter etc. Any ideas? Is there a way to set gpio characteristics with hal?

I would first try setting the DPLL read time earlier, say -200 usec

If the host has a lot of latency issues, the servo thread invocation
time can be delayed quite a bit from its nominal time and this can
cause enough baseline wander in the DPLL tracking to read before
the the DPLL trigger latch time when the delay goes away.

Also make sure that:

hm2_7i96.0.packet-error-total

is 0 (If not, the network latency is so bad that packets are being dropped)

 

And one more data point: running up to 5 glxgears while the motors are moving doesn't cause the problem. But if I drag those windows around? Lots of bad noises from the motors. I've run that many glxgears, and dragged them around, many times when doing the latency test. There's never been an effect. But there is on the actual motors.

Another data point: as mentioned in another thread recently, I've had to bump my SERVO_PERIOD up to 2ms to avoid runtime errors. Perhaps related, I'm guessing.

I think I've probably been having this problem since I first started using a raspberry pi to drive my mill.  I noticed some CPU-related "hiccups" from the motors early on, and got rid of some background processes that were causing them, and didn't think anything more about it.  But today I noticed some new stutters/hiccups from the motors, and while trying to reproduce, started dragging the Axis window around on the screen.

Well, hoo boy...  the mill sure didn't like that!  Obviously, system load is affecting LinuxCNC in ways that it shouldn't.

So.  I must be doing something wrong, because I assume other people run X11 on their RPi HDMI monitor, and don't have this symptom?

I'm running the RPi 2.9.4 .iso (kernel was built 1/27/2025).

It's driving a Mesa 7i96.  I don't use wireless.  One ethernet is the built-in Pi interface, the other is a reliable USB/Ethernet dongle.  It doesn't matter which drives the Mesa, the symptom remains.

My cmdline.txt looks like this:
Most of that cmdline came from other posts on the forum.

I tried adjusting the IRQ affinity for the Mesa ethernet, to move those interrupts onto core 3 along with the rest of the real-time stuff, but that didn't help.

I'm sure I can find a PC that will work (I did some tests today on an older Thinkpad, with surprisingly good results), but I use the RPi gpio pins to help work around a LinuxCNC shortcoming, and I'd rather not lose that.  I will if I have to, though.

Any ideas, suggestions for things to try?

 

Is dist-upgrade ever a good idea?

Really?!

Cool!

But does it have enhanced switches?

Coding is not about speed, it's about the journey.

Weird.

Often with programming, huge problems are caused by like 3 wrong characters.

Perhaps it was some temporary fix that was not removed as it should have been?

C is a good language, better than Python IMO.

(Python always complains about not converting tabs to spaces, which I despise)

Looks good, though probably needs a bit more FF1 tuning.

Are you using the "Calibrate" menu?

This makes it easy to adjust PID parameters while running.

If the following error is in the same direction as the velocity,
FF1 is too low, if the following error is in the opposite direction
of the error, FF1 is too high.

Hi Tommy and Peter. I took some time and tuned all three axis. Now i can jog continuously all three axes. I have attached halscope screenshots of all three axis. Can you please check whether the tuning is good or more need to be done ?

Thanks cakeslob! Analog inputs are ready for testing this coming weekend. Then I'll merge over your work.

I'd always recommend calculating the joint SCALE based on the hardware. ie steps per revolution of the stepper motor and then the leadscrew pitch etc. If the actual movement achieved is not correct I'd be suspicious of lost steps, especially if micro stepping.