Advanced Search

I didn't try it, but I have a good experience with Gemini 2.5 pro to configure (text based) a midi controller with custom firmware just by uploading the manual and explain what I wanted. You could try the same with LinuxCNC, upload the right PDF and tell that this is the manual and explain what you want. If it doesn't give a good result try without the manual but add the right prompts.
In the PDF you can see the result with adding the manual, I didn't look at it throughout but it seems already make more sense. (If you indeed will use remora)

 

Switching to machine-off indicates LinuxCNC sensed something
and changed operating mode.

The question is what did it sense.

Can you post you hal/ini files?

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.

It had no effect removing the xbox.hal and disconnecting the controller.
Something I noticed this time is I changed to qtdragon (from qtdragon_hd) so I could see the terminal window behind. In that change I noticed the "At Speed" indicator beside the spindle controls turns green when I enter the M3 S9000 and when the motor stops the indicator flashes.
The other not so obvious item is the machine 95% of the time switches to "Machine Off" but not 100% of the time.
I also noticed the secure boot was enabled, I thought I had disabled that. It is now disabled in bios.

thank you for your help. I want to ask you a question. I have a mesa 7i96s card. stepgen.00 X axis, stepgen.01 Y axis, stepgen.02 Z axis, stepgen.03 spindle pwm speed control, stepgen.04 a axis. I use spindle speed mode. I turn the spindle with m3 command, then I stop the spindle with m5 command. I want the spindle tip to always stay at the same angle when I give the m5 command. How can I do this?

Nothing too obvious

I would try running without the XBOX controller
USB devices are notoriously sensitive to noise.
 

I bought the version with the most memory. I figured that it was safer to spend a little extra and never run out of memory (which could be fatal).

What this means?
That for rigid tapping encoder must be on spindle shaft
or must be on 1:1 ratio with spindle shaft?
Other ratio configurations can't work for rigid tapping ?

I've been asked not to post any images or videos of the machines publicly, but if you want me to send you some, email me at This email address is being protected from spambots. You need JavaScript enabled to view it..

Ah, I took a look at the actual wiring on my machine. I get the A/B signals from the simulated encode in the servo drive and the Z (index) signal from the sensor that is looking at the slot in the disc on my spindle. That is how mine is able to work.

Thanks Andy