Advanced Search

I’ve added a rotary axis to my machine (the workpiece rotates like on a lathe), but I’m running into a problem when performing helical milling along the full length of the part. During the operation, the rotary axis accumulates a large number of degrees. Then, when the next operation commands the rotary axis to return to 0°, the machine tries to unwind all those rotations.What is the common solution for this issue? I can modify the post‑processor if necessary.

Hi Endian, first of all, thanks for replying.

Your comments make a lot of sense, although I think you're mixing up issues, haha. In the GitHub discussion, I was talking with Grandiximo about the EL7342 module and wanting to use it in velocity mode to use the internal PID to control speed and close position in Linux CNC. I've tested this, and it works quite well, I should add. On the other hand, I mentioned that after testing it on the machine, it's too small for my needs because my motor consumes too much power, hence the need to migrate to an AM8131 servo motor with an EL7221-9014 driver.

The envelope and card analogy was a good one. I'm not an Ethercat expert; my knowledge is more intermediate/basic. I've only tried a few things that have worked quite well so far, so I need to read your GitHub reply very carefully, hehe.

You asked me about my main problem. In my previous post, I asked a few questions, and from four to what I need, I'd now reduce them to three:

1- Is the EL7221-9014 module actually compatible with 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?

3- Does anyone have experience with an EL7221-9014 module who could offer some help?

To further describe the architecture I want to use, I'd like the module to handle the speed loop and close the position loop in Linux CNC. From what I've read, I believe the lcec_el7211.c driver practically works this way; I see that the command pins are for speed and provide speed and position feedback.

From your response on GitHub, I gather it would be best to close both loops in LinuxCNC. I'd have to test it, however, my experience with this architecture and the modifications made to the EL7342 module worked quite well. I plan to perform the homing using LinuxCNC.

I saw that in a previous post on this forum you mentioned wanting to try an EL7221 module. I'd like to know:
-- Which driver did you use, lcec_el7211.c?
-- Do you have the same hardware, EL7221-9014?

I always greatly appreciate the help I've received from this forum, so thank you very much in advance. Best regards.

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!