Advanced Search

You don't need a gateway, and you certainly don't need DNS. You also don't need such a large mask. Just enter the IP address, for example, 10.10.10.20, and the mask. Depending on the format, either 24 or 255.255.255.0.

For testing, you can enter the IP address manually in the console.
#check the interface name (probably enp0s31f6)
sudo ip link show
#add address
sudo ip addr add 10.10.10.20/255.255.255.0 dev enp0s31f6
#test local address
ping -c 3 10.10.10.20
#test mesa card
ping -c 3 10.10.10.10

remove "require IPV4 addressing......."

I would leave the gateway and DNS server entries empty
as they are meaningless here.

I have made the changes that you suggested. Still the same message appears when I hover over the save button. That button never gets highlighted.

 

raul wrote:

Hi.

Did You have any luck fixing the card. I have the same exact problem.
s

Hi

Sorry for the very late reply... Yes, the cards got fixed. i bought the ethernet chips from mouser.de (about 6eur each) and a friend at work solderd them to the boards
 

I feel this is adequate but not sure if this is the right place, feel free to correct me.
-
As i read almost everything here, i keep noticing the same issue happening over and over, namely where users of LinuxCNC update/upgrade version for no particular reason and end up with broken machines.
This stems from the windows "update mentality" being forced upon us for the last 20 odd years... never mind.
-
[bold]In short, never update/upgrade a working machine, unless you explicitly need new features.[/bold]
-
It is Linux, and no matter how much money microsoft invests on youtubers to convince you that Linux is not secure, IT absolutely IS secure, the whole world uses Linux, all WORLD servers are running Linux (even microsoft's servers run Linux since 2000 with Red Hat), are on public IP so the whole world has access to them, yet very rarely anything happens to them.
STOP TYPING!
Even when something happens, almost always it is some running service/software that failed/got hacked, not LINUX, or some old server that was last updated 15 years ago.
And for those watching youtube about this, notice they never ever mention the comparison is being done for the web browser, NOT for the operating system.

OK, thank you Aciera.

IP 11 at the end, not 1
Gateway 1 at the end.

What version of LinuxCNC are you running?

Thanks for the reply. The jumpers on board are; W3 up, W15 up, W13 down, W14 up.

This change was made in response to a long standing bug report:
github.com/LinuxCNC/linuxcnc/issues/2994

I have opened an issue about this on GitHub:
github.com/LinuxCNC/linuxcnc/issues/4216

I'm now running into exactly the same problem and aren't at all keen on having to resort to a clean install.

Hopefully somebody has an explanation and an easier solution......

MaHa wrote:

Now found the error.

5401-5409 - Currently applied tool length offset for X, Y, Z, A, B, C, U, V & W. Set by G43/G43.1/G43.2, cleared by G49. Volatile.

So i don't have access to toollength #5403 anymore, except i use G43/G49 to load the variables.
Thats f*** crapy update

Why i am upset?
Since version 2.5 this parameter are in use, now it changed overnight, instead creating a new set of parameter, if someone needs that. Like that it breaks configurations with probing routines and parts, when offsets are set wrong, without warning. And i am not going to set G43/G49 in probing routines. The only place to do that is in gcode. Don't want this risk for crash, when unwanted, toollength is cancelled. 

Can anyone else confirm this?
And more importantly, if true, how this happened?

Now found the error.

5401-5409 - Currently applied tool length offset for X, Y, Z, A, B, C, U, V & W. Set by G43/G43.1/G43.2, cleared by G49. Volatile.

So i don't have access to toollength #5403 anymore, except i use G43/G49 to load the variables.
Thats f*** crapy update

Why i am upset?
Since version 2.5 this parameter are in use, now it changed overnight, instead creating a new set of parameter, if someone needs that. Like that it breaks configurations with probing routines and parts, when offsets are set wrong, without warning. And i am not going to set G43/G49 in probing routines. The only place to do that is in gcode. Don't want this risk for crash, when unwanted, toollength is cancelled. 

Thanks Benb, I did figure out the e stop input and did tie the input into my ui e stop.

I guess it’s not a true e stop as I’m only killing the enable, but everything does work the way I want it to.

I pasted all my configuration files into my build thread.