Advanced Search

Here are the .ini and .hal files.
The static IP of the RPi is 10.10.10.100 - I can ping the Mesa card from the terminal.
   

I am not sure if this is specific to qt_dragon or not.

However, when I try to rerun a tool because it broke or I need to adjust comps, the process makes me load and set tool length for each tool before it in the nc code.

I'm using versa probe and the Qt auto tool setter routine.

Is there any way to avoid changing each tool before rerunning the desired tool? Often times it's easier and quicker to just repost the single tool path as a separate program to avoid changing all the tools. I'd like to avoid that, if possible.

I'm using an RPi5 and a PCIe HAT with another NIC and some extra USB ports. Seems to work fine. It's the waveshare 27541. The setup needs the 5V 5A power supply to avoid voltage drops and hard resets. The 5V 3A power supply was not sufficient. I am using the official power supply in the control box as I had issues with other solutions. I'd also suggest a cooler for the cpu if you go this route.

From your error report:Usually means you have set the IP address on PC same as on Mesa card, the PC must have different last number for IP address, so
10.10.10.11 is OK for PC if Mesa is set at 10.10.10.10

What can you tell me about this program?

# --- Load the userspace for probe error manager ---
loadusr -Wn probe_error_mgr python3 probe_error_mgr.py

I have been running my machine in a kind of sketchy estop version, where LinuxCNC doesn´t really correlate with my physical estop hardware (which is running seperately).
Currently i am finally trying to implement feedback of my physical estop hardware (pilz estop relais that checks various inputs) into linuxCNC
Original hardware used two momentary switches connected to the main pilz relais to switch the main power on/-off. Once the machine is running i have a estop-ok signal 24V connected to my mesa inputs. 
Currently i have serious problems to synchronize GUI interface, linuxCNC and the main hardware. I have tried so many different versions of estop routing i am now totally confused what would be the best approach and like to have some directions for a new setup from scratch.
I would love to have it work like that:
- i connect my machine to power and the PC and mesahardware boots up, Estop Hardware is supplied 24V (works perfectly)
- once GUI is loaded (Gmoccapy) i press machine-on (which is currently not available to be pressed because the GUI is in estop)
- machine-on sends a 24V oneshot through mesa outputs to pilz e-stop relais, which switches on the rest of the hardware. (legacy function from the original setup)
- after a few seconds the estop hardware delivers a e-stop ok signal to linuxCNC which finally pulls the GUI estop button. halui estop is activated -> false

Main problems i have encountered so far are:
- halui estop is always actived. No matter what kind of reset functionality i have used in my main hal. 
- i can never use the GUI machine-is on button to actually start my machine. But i need to do so to recieve a estop ok signal from my hardware. So it needs to be usable before. Currently i use a jumper cable to start my machine and would love to get away with not have to implement a physical switch somewhere as the install with a big touchscreen doesn´t have anywhere to mount one.

Some direction would be much appreciated, thanks.