Advanced Search

Hallo zusammen,

ich bin im Moment etwas ratlos und weiß nicht einmal genau, wo ich mit der Fehlersuche anfangen soll.

Ich habe eine bestehende LinuxCNC-Maschine mit der Achskonfiguration **ZZXYC**. Diese läuft schon seit längerer Zeit auf **Rechner A**. Das ist eine sehr alte Kiste, aber die Maschine funktioniert darauf zuverlässig.

Die Maschine arbeitet aktuell mit **Schrittmotoren ohne Encoder** und einer **Mesa-Karte**. Die Achsen laufen ohne Fehlermeldungen, sowohl beim Starten als auch beim Bearbeiten. Ich verfahre die Maschine zu ca. 90 % mit dem Joystick, auch das funktioniert auf Rechner A problemlos.

Jetzt habe ich mir zusätzlich einen neuen **220-V-AC-Servo mit EtherCAT** zugelegt. Da ich nicht immer im Keller an der Maschine sitzen wollte, habe ich dafür einen zweiten Rechner verwendet.

Auf **Rechner B** war vorher Windows 10 installiert. Der Rechner hat eine etwas bessere Grafikkarte. Ich habe darauf das neue **Debian-13-ISO von LinuxCNC** installiert und dort erste Tests mit dem neuen EtherCAT-Motor gemacht.

In Rechner B sind jetzt drei Netzwerkkarten verbaut:

1. Internet
2. EtherCAT
3. MesaCARD

Die Testmaschine **„EtherCAT-Test 750W“** läuft inzwischen mit dem EtherCAT-Motor recht gut.

Wichtig:
Den EtherCAT-Motor wollte ich in meine bestehende Maschinenkonfiguration noch nicht einmal ansatzweise einbinden. Die echte Maschine, die Verkabelung, die Mesa-Karte und die bisherige LinuxCNC-Konfiguration sind unverändert. Es geht aktuell nur darum, die vorhandene Mesa-/Schrittmotor-Konfiguration auf Rechner B laufen zu lassen.

Danach habe ich meine bestehende Konfiguration von Rechner A auf Rechner B kopiert. Die Konfiguration hängt hier im Anhang. Die Netzwerkkarte für die Mesa-Karte habe ich entsprechend eingerichtet.

Die Maschine startet auf Rechner B ohne Fehlermeldung. Wenn ich die Achsen jedoch referenzieren möchte, gehen sporadisch irgendwelche Motoren von Joint/Achse 0 bis 4 auf **Positionsfehler**. Alle Achsen außer Y haben Referenzschalter.

Teilweise passiert der Positionsfehler schon beim Referenzieren. Wenn er dort noch nicht auftritt, kommt er recht schnell im laufenden Betrieb.

Wenn ich zwischendurch wieder von Rechner B auf Rechner A zurückwechsle, läuft die Maschine sofort wieder ohne diese Fehler. Deshalb gehe ich aktuell davon aus, dass die echte Verkabelung und die Maschine selbst nicht das Problem sind.

Die LinuxCNC-Konfiguration ist im Grunde eine 1:1-Kopie von Rechner A. Auf Rechner A läuft sie stabil, auf Rechner B bekomme ich sporadische Positionsfehler.

Ich weiß gerade nicht, wo ich mit der Fehlersuche sinnvoll anfangen soll.

Könnte mir jemand weiterhelfen oder einen Hinweis geben, woran so etwas liegen kann?

Besonders interessieren würde mich:

* Kann so etwas durch die Netzwerkkarten-Konfiguration zur Mesa-Karte entstehen?
* Könnte das mit Latenz/Jitter auf dem neuen Rechner zusammenhängen?
* Gibt es typische Einstellungen, die beim Umzug einer Mesa-Konfiguration auf einen anderen Rechner angepasst werden müssen?
* Kann die zusätzliche EtherCAT-Installation oder eine weitere Netzwerkkarte hier Einfluss haben, obwohl EtherCAT in dieser Konfiguration noch nicht eingebunden ist?
* Welche Werte oder HAL-/INI-Einstellungen sollte ich als Erstes prüfen?

Vielen Dank schon einmal.

Gruß
Mücke

I like that idea better. I might write a custom HAL component to do the logic though, as my "no-go" zone is a bit too complicated for discrete HAL components to be "easier" (my valid work area is not a rectangle), and I might think about adding pins for "allow access" that I can set/clear in my M6 handler.
My paranoia here is that, when M6 finishes, the spindle is usually positioned over something expensive. A rapid on Z at that point would make expensive sounds.

Hi Axemas,

I now have a LinuxCNC lathe that is slowly but surely becoming productive, so I would be very interested in testing NativeCAM Lathe on a real machine. Especially the lathe polyline workflow would be highly interesting for me.

If there is already a test branch, an early package, or even just an intermediate state that is not fully polished yet, I would be happy to try it and give feedback. I can test with real turning jobs, report issues, and provide screenshots, generated G-code, or error messages if that helps.

I also think that sharing even a rough intermediate status could motivate more lathe users to test and maybe help move this part forward. NativeCAM Lathe with a working polyline function would be a very valuable tool for many LinuxCNC lathe users.

No pressure and no timeline expectations. I would just be glad to help testing when there is something available.

Best regards,
Tom

I replied at github post ... 

try to handle it and let me know what is yout root problem then 

Hello, can you make it fit for a 7-inch screen with a resolution of 800x480? I have a problem because only when I increase the resolution can I see everything in full screen, but it's very small.Thank you. This email address is being protected from spambots. You need JavaScript enabled to view it.

The latency with isolcpus=1 you show is fine. I ran with latency of 120 to 150 us for years and yours is half that!
Just move on for now. Come back if you get an error finishing read.

Gegen eine hohe Latenz habe ich nun schon ganz viele Einstellungen gemacht (u.a. alles, was Rodw empfohlen hat, inkl. EEE), aber ich habe derzeit keine Zeit mal einen richtigen Test zu machen, oder die Latenz zu messen. Die Goldene Regel, immer nur eine Änderung zur Zeit zu machen, habe ich auch schon gebrochen Sobald ich Zeit für meine Fräse finde, melde ich mich mit den Ergebnissen!

Vielen Dank an alle!

Your no-go zone idea is actually conceptually sound, the mechanism was just wrong. You can do this properly in HAL with mux2 and soft limits.

Add a second set of limits to your INI next to the existing ones, something like MAX_LIMIT_WORK and MIN_LIMIT_WORK, set them to exclude the tool change zone. MAX_LIMIT and MIN_LIMIT stay as the full machine envelope.

In HAL, setp the two mux2 inputs using the [JOINT_N]MAX_LIMIT and [JOINT_N]MAX_LIMIT_WORK bracket syntax, and net the mux2 output to ini.N.max_limit which drives the actual soft limit. The select input is program-is-running AND NOT motion.tool-change. Repeat for min limits and each axis that needs it.

When the select is true the mux feeds the WORK limits, cutting off the tool change zone. When false, for any reason including faults or mid-tool-change stops, the full limits are active and you get normal travel back automatically. No special recovery needed.

The built-in LinuxCNC tool change (TOOL_CHANGE_AT_G30, TOOL_CHANGE_POSITION, manual pause) does not restore X,Y. The machine stays at the tool change position and the program commands the next move.

The reason other users don't hit this problem is that they fix it where it belongs, in the CAM post or with a pre-run G-code filter that normalizes tool change behavior. Building the safety net into the M6 macro is the non-standard part, and the complexity you are hitting now is the natural consequence of that. The look-ahead problem, the M68 idea, the HAL logic, these are all workarounds layered on top of the first workaround. The root issue is inconsistent G-code from your various sources, and that is where the fix belongs.

If that is not practical, rodw's filter is the cleanest option: scan forward from each M6 at file load, and only insert a reposition if you see a Z-only move before any XY move.

Fixed for Master branch:

github.com/LinuxCNC/linuxcnc/commit/96c8...87e2dc0a4165d3fc095f

Thank you for the bug report!

QtPlasmaC updates - Master (v2.10):

• fix runaway jog when switching tabs while a jog key is held

Yeah I guess I will stay with 2.7 forever now (or until PC dies).

Meantime I will start experimenting with ESP32 + FluidNC or grblHAL.

Thanks for answers.

copr.fedorainfracloud.org/coprs/ntulinux/linuxcnc

As simple as:


Please let me know if you have any questions or comments!

Cheers!

edit: Still ironing out a few minor bugs

Hello guys, it's been longer than I'd like since the last time...

Without further ado, I'll get to the point:

I want to try the EL7221 module. I've read some of the manual and I see that there are different versions depending on the profile:

EL7221-9014 --> MDP742 profile

EL7221-9015 --> DS402 (CIA402) profile
I've also seen that the lcec_el7211.c driver included in linuxcnc-ethercat supports the EL7221 module, although version 9014/15 isn't specified. The EL7201-9014 module is specified, and for the latter, a separate initialization function is used:

static lcec_typelist_t types[] = {

{"EL7201_9014", LCEC_BECKHOFF_VID, 0x1C213052, 0, NULL, lcec_el7201_9014_init}, 
{"EL7211", LCEC_BECKHOFF_VID, 0x1C2B3052, 0, NULL, lcec_el7211_init}, 
{"EL7221", LCEC_BECKHOFF_VID, 0x1C353052, 0, NULL, lcec_el7211_init}, 
{NULL},
};

Another thing I have noticed is that the "product code" for the EL7221 also does not match the one specified by the el72x1-901x_en.pdf manual:

1018:02 | Product code | Product code of the EtherCAT slave | UINT32 RO | 0x1C213052

The product code matches for the EL7201-9014.

Therefore, here are a couple of questions:

1- Is the EL7221-9014 module truly supported by the lcec_el7211.c driver?

2- Would I have to use the driver, configuring the ethercat_conf.xml file for the EL7201-9014 module, even though the actual module is the EL7221-9014?

The last question is based on the fact that the models EL7201-9014, EL7211-9014, and EL7221-9014 have the same PDOs/SDOs objects.

Another issue I see is that if the EL7221-9014/15 module is supported, the driver doesn't fully utilize its potential. However, using it in CSV mode and having position feedback is sufficient for LinuxCNC, so this shouldn't be a problem. Nevertheless, it excludes modes like CSP and homing procedures that the module could handle.

Now, after reading the el72x1-901x_en.pdf manual, it occurred to me that the module complies with the DS402/CIA402 standard. I could use lcec_class_cia402.c from the same repository, so I turned to the linuxcnc-ethercat documentation, specifically cia402.md, and found this:

"Notable non-Cia 402 devices are Beckhoff EL7xxx and AX5xxx series drives."

However, the manual states:

Terminal designation MDP742 and DS402 profile
Note that the servomotor terminal is given a different type designation in TwinCAT as a result of the profile change process described above.

The terminal then represents itself in the TwinCAT system manager as one of the following devices:
- Servomotor terminal with MDP742 profile: EL72x1-0010 or EL72x1-9014
- Servomotor terminal with DS402 profile: EL72x1-0011 or EL72x1-9015

So here's another question:

3- Does the lcec_class_cia402.c driver support the EL7221-9015 module with DS402/CIA402 profile?

In conclusion, I've seen that in the examples directory of the linuxcnc-ethercat repository there's a fairly practical example for an AM8121 motor using the EL7211 module, although the version isn't specified. From my reading and comparison between the manuals el72x1-901x_en.pdf and el72x1_en.pdf, I see that the SDO objects are quite similar.

4- Does anyone have experience with an EL7221-9014/15 module who could offer some assistance?

I haven't purchased my hardware yet, but I plan to use the EL7221-9014 module and the AM8131-0J00-0000 motor.

As always, I tend to elaborate in my explanations, so thank you in advance.

Two thoughts: first, what does the default "tool change at specified location" do ?  If it's been not returning all along for everyone, I suppose I could do the same
Second, I suppose I could have my tool change logic create a "no-go" zone under the spindle at the end of the change (using M68) and have some hal logic trigger a stop if the spindle enters that zone before it moves XY away from its existing position...