Advanced Search

Thank you. This morning I started to realize the *.hal file(s) would be involved. I implemented your fix and it seems to work, at least for jogging and MDI. Thank you.

I'm still getting an "Unexpected real time delay". Also having some trouble with homing as I don't know the configuration in sim.axis. I could likely strip the homing out and fix the real time delay. However, trying to load a program file locks the simulator, infinite loop which eventually crashing VBox.

Poking at the MDI I found another problem for my use. This model rotates the spindle about X and what I need is to rotate the part around X. In the first case the part is fixed to the table and the tool tilts relative to both, tilting the spindle. In the second case the part rotates relative the the table and the XYZ cutting axes are fixed to the table, rotary table on X axis. I'm surprised as I suspect the rotary table on X is much more common that a tilting spindle (as a 5 axis machine would have).

I could likely dig thru the *.hal files and get a 4th axis working, time if the constraint here. But I doubt I could implement a new motion control model. I have it working on my mill but that was developed with PnCconf. I suppose I'll look for another way to test G-Code files.

Thank you for your help.

Sehr umfangreich.
Das muss ich mir morgen in Ruhe ansehen.
Heute bin ich an keinem Rechner mehr.
Zumindest vorab, schaue dass du ein CAT6 Kabel bekommst und die Netzwerk Karte sollte ein intel chip haben bzw. Ethercat kompatibel sein.
 

Hallo andrax,

danke für Deine Rückmeldung.

Ich habe die Infos jetzt noch einmal etwas sortiert, damit es nicht durcheinandergeht.

Auf dem neuen Rechner sind aktuell zwei Maschinenkonfigurationen vorhanden:

**Rechner:** neuer Debian 13 Rechner

**Maschine 1: A6-E-Drehmoment**
Beschreibung: Hier ist nur der EtherCAT-Servo hinterlegt, sonst nichts.
Status: Läuft sauber und stabil.

**Maschine 2: demo2023**
Beschreibung: Schrittmotoren ohne Encoder, über die Mesa-Karte verbunden.
Diese Konfiguration enthält kein EtherCAT. Es ist auch kein EtherCAT-Teil in der HAL/INI eingebunden.
Die vollständige Konfiguration hatte ich im ersten Beitrag bereits mit HAL und INI angehängt.

Status:

* Auf dem alten Debian-12-Rechner läuft diese Konfiguration stabil.
* Auf dem neuen Debian-13-Rechner läuft dieselbe Konfiguration nicht stabil.

Die Systeminformationen habe ich als Dateien angehängt:

* `systemreport_debian13_...`
* `systemreport_debian12_...`

Zusätzlich habe ich auf dem neuen Debian-13-Rechner noch `dmesg`-Ausgaben erstellt:

* `dmesg_debian13_20260608_191000_vor_dem_Start_von_LinuxCNC.txt`
→ erstellt, bevor ich LinuxCNC mit der Maschine `demo2023` gestartet habe.

* `dmesg_debian13_20260608_191000_nach_dem_Start_von_LinuxCNC.txt`
→ erstellt, nachdem ich LinuxCNC mit der Maschine `demo2023` gestartet und den Fehler reproduziert habe.

Ablauf auf dem neuen Debian-13-Rechner:

1. Maschine `demo2023` gestartet.
Diese Konfiguration hat kein EtherCAT und es war auch kein EtherCAT-Gerät angeschlossen.

2. Die Maschine ist ohne Fehlermeldung gestartet.

3. Alle Achsen konnten problemlos referenziert werden.

4. Sobald ich aber irgendeine Achse verfahren möchte, egal ob per Joystick oder über Axis, kommt sofort ein Positionsfehler.

5. Danach habe ich die zweite `dmesg`-Datei nach dem Start von LinuxCNC erstellt.

Da EtherCAT bei dieser Konfiguration aktuell nicht verwendet wird, habe ich danach noch nicht so genau geschaut. Hardwaremäßig ist der EtherCAT-Servo aber folgender:

Servo-Kit:
www.omc-stepperonline.com/de/750-w-ether...p67-a6-ec750h2a1-m17

Die Kabel zum Servo/Treiber sind die originalen Herstellerkabel.
Das Netzwerkkabel ist aktuell ca. 1 m lang und geht auf meinen Schreibtisch, wo auch der Motor mit Treiber steht. Der Servo ist im Moment aber nicht angeschlossen, da der Motor selbst gerade in der Werkstatt ist und ich noch den Flansch anpassen muss.

Das Netzwerkkabel ist ein normales Kabel, das ich noch von einem alten Router herumliegen hatte. Da EtherCAT in der aktuellen `demo2023`-Konfiguration aber nicht verwendet wird, sollte das für den aktuellen Fehler vermutlich erst einmal keine Rolle spielen.

Ein Bild vom Servotreiber habe ich ebenfalls angehängt.

Falls noch etwas fehlt oder ich etwas Bestimmtes zusätzlich auslesen soll, bitte einfach kurz sagen. Dann liefere ich das noch nach.

Gruß
Mücke

Debian issue, not LinuxCNC, so might be better to post this on their forums, if you feel like it.

 I've seen some other people posting similar issues, did these problems start with the switch to GTK3 or might it be closer connected to the switch to Preempt RT or a later Debian version?

I'm not really competent to determine exactly what's going on, but I did look through old GH issues - and there are a number of similar reports over the years.  They go back to 2.7.

However, there may be two (or more) underlying problems which present the same - more or less - undesired behavior.

I get the sense that one of the scenarios involves switching tabs or otherwise changing window focus during a continuous jog.  At the very least, something other than just pressing/releasing a keyboard key is happening.

The other scenario is what the OP reports - no change in window focus, no pop-ups, nothing but a continuous jog even though the key is released.

The two scenarios may not have anything to do with each other beyond the end result.

My suggestion for the OP would be to turn off keyboard auto-repeat in Debian settings and see if the problem continues.  If the problem goes away this may point to a Debian change rather than an LCNC change.

This is becoming useful for debugging a running LinuxCNC instance. I still have some features to add and bugs to fix before releasing an installer.
Up-to-date source code is available at the link on my first post.

video:
git.disroot.org/nwe/halflow/src/branch/m...a/halflow-tour-1.mp4

Ja, erstmal die bestehende Konfiguration auf den neuen Rechner nehmen (ohne Ethercat)
Bei Problemen die dmesg posten (immer sehr aufschlussreich)
Wenn es keine Probleme gibt, dann ethercat mit rein.
Bei Problemen wieder die dmegs posten. 

I haven't tried it, I'll try it tonight, so I'll let you know, thanks a lot

    If you have kept up in the news of what has been going on with 3D printing then you know it concerns more 
then just putting plastic on a plate with a computer. It concerns anything CNC additive or subtractive. 
Well now at least in the the USA there seems to be a name to at least one of the ones responsible. To be clear I
am not making this accusation , but it sure feels reminiscent of the 1920s alcohol prohibition. 

Ok, du meinst ich soll den Ethercat Treiber nicjt laden ? 

Ich suche alles raus wenn ich heute abend zuhause bin. 

Da ich die Maschine aktuell noch ohne servo erstenmal zum laufen bekommen mochte habe ich diesen noch garnicht eingebunden. 
Noch ist nur die mesa Karte und die sxhrittmororen angeschlossen. 

 

I'm running the standard Axis UI, with a Glade VCP side panel and a tab. (But I'm sure I was not using or touching the mouse at the time that the key sticking occurred, because I press the jog keys with the same hand that I use the mouse with.)

PS.  This really has the feel of a bug to me.  The older versions of LinuxCNC I had been using (2.7) running on RTAI kernel versions of Debian and Ubuntu, had never exhibited this kind of dangerous behavior.  I've seen some other people posting similar issues, did these problems start with the switch to GTK3 or might it be closer connected to the switch to Preempt RT or a later Debian version?

I will look at the config but that is actually a separate application
Did u try axis 2 on a small screen it should fit I think it removes a slider or 2 for convenience

Doing my first steps and trying to configure and understans how this works and seems found one tiny BUG:
Debian Bookworm
NIC card configuret for 2 VLANs native for data, .20 for MESA with Layer3 switch.

# The loopback network interface
auto lo
iface lo inet loopback

# Management interface
auto eno1
iface eno1 inet static
    address 192.168.4.50
    netmask 255.255.255.0
    gateway 192.168.4.1
    dns-nameservers 8.8.8.8 1.1.1.1

# MESA P2P interface (.120-.121)
auto eno1.20
iface eno1.20 inet static
    address 192.168.1.122
    netmask 255.255.255.252
    post-up sysctl -w net.ipv6.conf.eno1/20.disable_ipv6=1

Seems like its trying to reach a wrong folder during startup..
Note: Using POSIX realtime
sysctl: cannot stat /proc/sys/net/ipv6/conf/eno1/20/disable_ipv6: No such file or directory

the right place is: /proc/sys/net/ipv6/conf/eno1.20/disable_ipv6

Be careful with the set/clear model, your idea is M6 sets extended limits to be able to reach the tool change? That means in normal conditions your limits are not including the tool change area, this could be a problem if you want to jog there to verify anything, could even prevent you from loading gcode without errors if preview sees the tool change moves, also think about emergency stopping during an M6, you will not get to run the clear command. Just pointing those things out, I would consider having open limits and only restrict them when running and not doing a tool change, that should get you what you are looking for, without any drawbacks.

Build errors? Can you share your current code? Not many people will have the time to read 10 pages of an 8 years old thread...
Be more specific about what you are struggling with.