Advanced Search

ok there is a freight train at the end of the tunnel!
It worked sort of. Not stable but it did show what is happening.
I put the setp on all inputs.
The EStop I now see toggles which it should not. The EStop is not actually wired yet and will be normally closed so there is always a 24V. Would this stop noise? The limits send 24V when detected but the spindle is not running. Will a limit triggering while operating cause any issue?

No need for a base thread with an external motion controller.
I run mine with a NVMe drive, yeah boot is really fast, I've been playing a around with custom hardware and hostmot2 firmware over SPI. ATM I'm working on a ethernet board to replace the SPI\EPP board that mates with the fpga board I'm using.

If you could add your Etherent mods to the thread linked below it would be great, trying to have a one stop place for all issues/suggestions and such.
forum.linuxcnc.org/9-installing-linuxcnc...official-images-only

Cheers
Rob

I think the raspberry pie five and Mesa set up is really quite brilliant. It’s very compact, and boots up really fast. The only negative i have found is that it’s difficult to put an external Wi-Fi antenna on the pie. If the pie is inside a metal box, it won’t connect easily to a Wi-Fi router. You can get around this by using an external Wi-Fi dongle. Or move the excess point and pie closer together.

The reason I was running that test was because packets were being lost between the raspberry pie and the Mesa board. I couldn’t figure out why. It was suggested to change a setting (I forget which one, but it is documented on The Forum) and after that there was zero packet loss.

Yes. I don't always trust over seas items so even if they don't have a ground lug they are grounded. All wire has grounded drains, 7i96s frame ground, emi filter, spindle, machine frame, stepper drivers are all grounded to earth ground

Looking at the hal file, I would suspect the estop input so you might try adding:

setp hm2_7i96s.0.inm.00.input-06-slow true

(the noise may also affect the other inputs so you might try with all)
 

Does the machine and PC have proper grounding?

Here are the files, axis are not tuned only tested for basic motion.
I added Ferrite cores to the UVW of the spindle, checked all wires are grounded properly. They are all foil wrapped with drain. All drains are grounded. I even moved the EMI filter and VFD to as far away as I could (6 feet) without having to completely rewire. Same issue if I turn off the VFD breaker the M3 command holds with no reset, with the breaker on it resets in a second or 2. I removed the xboxctrl.hal but included it here. 
Thanks for all your assistance.

pgf wrote:

Secondary question: I don't have a Z+ limit switch. My mill is so slow I'd really have to not be paying attention for the carriage to get close to the stepper. A lower limit would be nice, but I really don't understand how that could work. My spindle is a router, so the bit length varies a lot. Is there any way to configure this to work? I see people say that they don't bother with a lower Z limit, and just rely on a soft limit there, but what would you set it to? Is there something about "real" spindles that I don't know? Are the bits always the same length?

No need for lower limit switch, LinuxCNC is very good at obeying soft limits, and you set it to the actual hardware limit, so if say Z is able to move 200mm it is set at -200mm in the ini file as the min_limit.
Upper limit switch is nice to have as it is also used as the home switch in LinuxCNC, so the top of the Z becomes 0 in G53 coordinates, then you put the tool in, jog till the tip of the tool touches the surface of the material and you do a touch off in G54, jog up a bit to avoid hitting something and press run.
All the usual CAM software outputs gcode where 0 it the top of the material and everything below it is negative values, hence the above -200 example.
As for tools, no they are not the same length, and above is how to deal with them.
The thing with hardware limits is, no matter what G54 is set to, LinuxCNC will not allow the machine to move beyond what limits are set in G53.
And then there is G55...

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.