Advanced Search

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.

This iso installation is more than 1 year old. The other day, there was an update for another software available, i did sudo apt update and sudo apt dist-upgrade. Some updates coming in, afterwards linuxcnc was 2.9.9
Since then, my long time working probing routines set z-offset somewhere (at least) above the part.
 

How did you install 2.9.9? The ISO installer is still a work in progress. Not that that should matter for internal code 

What version of linuxcnc are you using?

There are a couple issues here:

1. 7I90 J1 pinout has swapped TX/RX lines since its intended for use as a sserial remote, not a sserial host
(fixable with cable  wiring changes)

2. More serious: the current hostmot2 driver does not enumerate sserial ports on local I/O pins
and unfortunately the J1 serial interface on the 7I90 is on local IO (LIO) pins so will not be seen.

Easiest solution would be to add a SP491 etc to some GPIO pins
 

Can you please test the same conditions, but without using glade?
Thank you.