Advanced Search

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!

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...
 

Thanks Tommy.

FWIW I've been digging into isolcpus and becoming convinced it's not a good idea on this 2 core CPU at least. Maybe it helps on CPUs with more cores but I am finding very bad results with it here.

I discovered even tho I have isolcpus=1 and I locked the NIC IRQ to CPU 1 rtapi_app was running on CPU 0 during the latency measurements above. When I ran latency-histogram using taskset to lock it on CPU 1 I got horrible latency spikes.

I also found that *all* the IRQs are on CPU 1 which defeats the whole purpose of isolating it.

So I'm going to remove all the CPU isolation optimizations and just run this 2 core setup with the CPU scheduler left to do whatever it decides to do and see what happens. Of course I'll keep all the other optimizations. i.e. power management disabled, governor on performance, etc.

Ich habe inzwischen meinen A6-Servo 750 W EtherCAT von Stepperonline in einer kleinen Sondermaschine zum Laufen gebracht, in der sich ausschließlich dieser Motor befindet.

Dazu lese ich das Drehmoment aus und lasse mir das höchste Drehmoment anzeigen und mitloggen. Außerdem habe ich den Signalstatus der wenigen Pins, die der Motor hat, auf den Monitor gelegt. Sollte der Motor einen Fehler werfen, wird dieser ebenfalls angezeigt.


Was ich nicht verstehe, ist: Ich kann die Maschine freigeben, entriegeln etc. Wenn ich den Motor dann drehen lassen möchte, passiert jedoch nichts. Erst beim zweiten Mal (manuell auf Dauerbetrieb) beginnt er, sich zu drehen. Das finde ich etwas merkwürdig, aber so ist es eben.

Als Nächstes werde ich diesen einzelnen Motor durch einen Schrittmotor ersetzen. Das wird spannend, da alle anderen Schalter und Motoren (Schrittmotoren) über eine Mesacarte kommunizieren.

In der Anlage habe ich euch meine komplette Konfiguration beigelegt – für den Fall, dass jemand Interesse hat, darin zu stöbern.

Diese Nachricht ist als kurzes Feedback gedacht und nicht als Fragestellung der nächsten Schritte.


Was für mich bei der Installation von EtherCAT Master etwas verwirrend war, ist, dass nicht LinuxCNC der Master ist, sondern dass man auf dem Rechner noch weitere Dienste und Programme installieren muss, die man natürlich dann auch laden muss. Es ist also keine Erweiterung von LinuxCNC, sondern ein weiteres „Tool” auf dem Rechner, auf das LinuxCNC zugreift. Zumindest habe ich mir das so zurechtgelegt.

Gruß Mücke 

Hi Andy,The tool changer uses two motors: one to rotate the carousel into position and the other to actuate the tool change mechanism.The carousel rotation has a proximity sensor fitted, which could be used to establish a reference or home position. Once the correct tool position has been indexed, the second motor drives the tool in and out to allow the machine to perform the tool change.I’ve added a video link below showing an example of the system running on Mach4. It should give a better idea of how the sequence operates.


thanks for the help !

man pages built-in.

Now working on real hal files import/export.

Es riecht stark nach zu hoher Latenz. Wie sind die Werte vom Base und Servo-thread?

I don't think moving back to the original position after an M6 is standard practice, all post should have safe move inserted after a tool change, this is not something dealt with on the machine side IMO
If your post expects the tool change to happen and the machine to not have moved and does not give you a way to implement safety moves to re-approach the work-piece after a tool change, this is just bad design of the CAM/Post the fix should be there IMO