Advanced Search

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.

JPeters wrote:

Hello scotta,

thank you for your quick reply. Yes, that is exactly what I thought myself.

The EC500 is powered by an external power supply. From the 6 pin header, GND, SCK and SDO have been connected to one of the probes.

I don´t have any kind of schematic on hands for the EC500. So I am not shure, why the header pin is labeled SDO. I would expect SDIO for a sufficient SWD connector. Is your header labeled with a SDO too?

My EC500 is labeled with IMXR_EC500 2023-05-18

Up to now, there has not been a single successful flash. From within MCUExpresso, I am at least able to build your application.

If this is not going to be successful: do you think, your actual project with W5500 and raspberry pi pico is as powerful as the 1052 solution and could be a viable alternative?

Thank you very much. I will try to give more details tomorrow.

Cheers Julius


 

I'll need to check the labelling on my boards. With MCUExpressoIDE does it report an error when trying to connect. It may give some clues.
Remora supports quite a number of 3D printer boards. The EC300/500 being 24V IO is more suited when using industrial hardware.

Yes. Good catch.
I would still appreciate knowing how to call anyone of these routines without going through the entire program. Also how to set the Z after the tool change.

Thank you

Aren't you missing a 'CALL' in line N15082:
 

I have attached my progam with subroutines and cut out much of the program inbetween.  I begin by "homing, clearing all offsets (G10 L2 P1,2,3,4,5,6), G92.1.
Then I load my program which contains 3 subroutines.  My tool position at start is program 0,0,N) N being the top of work what ever the program subroutine calls for.
Hit run and it works beautifully.
Next Engrave operation calls for a tool change and change of Z offset.
This is where it all gets lost.  I change the tool and position it, set g54 Z offset and it takes off for the last G57 position.
Don't honestly know what I am missing.
Also would like to be able to call one of the subroutines out of order and be able to run it.

Thanks for any help in advance
I am determined to get a handle of these subroutines.  I know I'm missing something here.