Advanced Search

Problem is here:

Note: Using POSIX realtime
./custom.hal:5: execv(stepgen): No such file or directory
./custom.hal:5: waitpid failed stepgen stepgen
./custom.hal:5: stepgen exited without becoming ready

RNZ wrote:

I ran my RPi 5 and 7i96s overnight and completed 40 million pings with zero errors.

sudo chrt 99 ping -i .001 10.10.10.10 -c 40000000

At the same time in the background, I ran Latency Histogram and two Glxgears. I have attached photos in case anybody is interested in seeing the results.

I’m not sure what to make of the maximum ping time of just over 10 ms.

It seems that "hardware-irq-coalesce-rx-usecs 0" has fixed the issues I was having (aside from the 10 ms issue) at least on RPi 5 * GB with LinuxCNC 2.9.2.

======================================

What is this "coalesce" thing?

Interrupt coalesce settings (access.redhat.com/documentation/en-us/re...ing_networking/index)

"By using interrupt coalescing, the system collects network packets and generates a single interrupt for multiple packets. This increases the amount of data sent to the kernel with one hardware interrupt, which reduces the interrupt load, and maximizes the throughput."

=====================================

My /etc/network/interfaces looks like this:

=============================

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 10.10.10.11
hardware-irq-coalesce-rx-usecs 0

===========================
 

There's no need to test with a base thread when using Mesa hardware.

Even with 4GB ram you wont come close to running out of memory when using the Linuxcnc image.

RNZ wrote:

I ran my RPi 5 and 7i96s overnight and completed 40 million pings with zero errors.

sudo chrt 99 ping -i .001 10.10.10.10 -c 40000000

At the same time in the background, I ran Latency Histogram and two Glxgears. I have attached photos in case anybody is interested in seeing the results.

I’m not sure what to make of the maximum ping time of just over 10 ms.

It seems that "hardware-irq-coalesce-rx-usecs 0" has fixed the issues I was having (aside from the 10 ms issue) at least on RPi 5 * GB with LinuxCNC 2.9.2.

======================================

What is this "coalesce" thing?

Interrupt coalesce settings (access.redhat.com/documentation/en-us/re...ing_networking/index)

"By using interrupt coalescing, the system collects network packets and generates a single interrupt for multiple packets. This increases the amount of data sent to the kernel with one hardware interrupt, which reduces the interrupt load, and maximizes the throughput."

=====================================

My /etc/network/interfaces looks like this:

=============================

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 10.10.10.11
hardware-irq-coalesce-rx-usecs 0

===========================

Why are you running a base thread for a latency test when using mesa hardware ?

I often run programs, but sometimes, like today, I am hacking at a rough bar that I cast in an open face sand mold. The exact size is not as important as it is that the surfaces clean up. Then once all sides are cleaned up, then, and only then, I concern myself with size. One side might be much more pitted or something then the other side, so I can not say that I want to take 2mm off of all sides. Maybe one side is pretty good, so 0.5mm cleans it up, but the other side has a pit and takes all that can be spared to clean it up. I judge this on the fly. And while I could write a tiny program to take one pass, then stop, it is also very easy, or used to be, to use MDI, typically G1 in X, G0 in Y followed by X, by Y, back at start, asses, maybe drop Z by some amount, repeat. This cuts the part in only one direction, as that cuts a better finish, moves out around the bar and returns to the start. Z moves are what ever amount looks correct for that pass, no set amount. So a sort of hybrid of CNC and manual machining. With a queue I can stack the four moves, often add an M5 on the end, go do something else and when I hear the spindle stop I know I need to go look at it and decide what next. Once the bars are all trimmed to overall size, then I have a program to make something out of them.

Had an idea, dangerous I know!
I put a buck converter on the 24VDC supply to get me 10VDC for a ref voltage for the spindle output. Tested with the buck converter and of course had the same problem but it allowed for another test. Note the spindle out was at 5V then 0V when the spindle stopped.

I powered off the breaker for the VFD and put my meter on the Spindle Out/Gnd. The M3 S9000 (5V) held with no reset. I tried a few different speeds and all worked. It is some type of EMI problem.

Any suggestions on how to resolve this? I have a EMI filter on the VFD. I tried moving the VFD further away from the 7i96s and no effect.

The index signal sent to the encoder input to LCNC must be 1:1 with the spindle. My encoder is on my motor. But, I get the index signal from the sensor on my spindle. If the gearing of the motor to the spindle was exactly 1:1 you could attached the encoder to either the motor or spindle. But if the gearing is anything other than 1:1 you must get the index signal from the spindle. My gearing is 1:1.8 and the A/B encoder signals come from the motor side, but my Z (index) signal comes from the spindle side.