Advanced Search

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?

 

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.

scotta wrote:

Warning: Spoiler!

DarkPhoinix post=328735 userid=35952 is there a way to download previously uploaded nvem-rt1052.txt from NVEM?   Unfortunately, no. It's a one way process.

Thanks a lot, I'll do some bck just to be safe.
Thank you for doing this amazing job and allowing me to use linuxcnc with my low budget hardware!

I'm testing tomorrow
Thank you

Spyderbreath wrote:

Warning: Spoiler!

At the risk of the blind leading the blind, to me that is not quite the right question. That chart is for your micro-stepping. Like the 800 is 4 microsteps, if you're using a 1.8 deg. stepper. I have always looked at it this way - What are you doing with the motor? If your opening a door or driving a ram, picking 800 would be fine, but using that on a belt or lead screw may very well end up leaving artifacts in the work due to the rougher movement between points. The downside is the more micro-steps you have the more torque you lose. 3200 (16 micro-steps) seams to be a reasonable middle ground that most use as standard. The controller will put out as many steps as directed by LinuxCNC to make a revolution, just a matter of how fast it can do it.

Whatever you chose, that gets figured out when you tell LinuxCNC in your .ini file how many pulses it takes to move one unit. That is set with the SCALE on each axis. Like for me, I have 16 micro-steps (3200) and a 5mm pitch screw, which works out to SCALE = 640 or -640 depending which way you need the motor to move.

I wanted to give it a high pulse/rev value to have a higher resolution, but I couldn't get precision in long movements. I put your values ​​and after a slight change of scale everything went well!

Thank you very much.

Isn't there a way to calculate SCALE in a precise way? Unfortunately the seller of my steppers and Drivers doesn't give me datasheets and it's really difficult to set them up properly, except trying random values. I also tried with math but nothing I couldn't get low error values ​​Scale=scale_set*Dist_measured/Dist_Insert

DarkPhoinix wrote:

is there a way to download previously uploaded nvem-rt1052.txt from NVEM?

 
Unfortunately, no. It's a one way process.