Advanced Search

Thank you for taking the time to look at that.

I will clean that up.

Now that I'm using my ethercat machine daily, I'm seeing some odd issues. Sometimes on startup it will trigger error b2 on the drives rapidly. this is apparently a timing conflict with modbus. Happens every dozen start ups.

Today i had a new one. I homed that machine, and then it began triggering joint errors and limits exceeded despite being nowhere near limits. i had to reboot the computer, and then it was fine.

If the machine starts "fine", it stays fine, but there is some flakeyness with the start up sequence.

Another thing I notice is when I tune my servos perfectly in the omron (usb) software, when they start under linux they are resonating, vibrating like 1 micron in travel. I don't know if that's a linuxcnc thing, and ethercat thing, or just a stupid omron thing.

Other than these quirks though, its great and I would not switch back for anything haha.

need that jerk control......

Hello everyone,sorry for posting a year later. I had a lot going on and put my 5-axis milling machine project on hold.Yesterday I finally managed to recover the 7i95T. Since I’m definitely not the first – and won’t be the last – to flash the wrong firmware, I’ve put together a small guide describing how it worked for me.Thanks, PCW, for describing the procedure — it helped me a lot.Now I’m a bit more familiar with the Mesa cards. Nothing comes from nothing.

Best regards!   

I like the text and button hi lights. I just prefer a darker main background. Very Nice. 

You should not need ui changes for these pins to work.
There is a description on the pins on the page before this one.

Hi Rod,

I think there is a small misunderstanding about what I was trying to say. I’m not claiming that EtherCAT needs heavy tweaking to run at 1 kHz — I fully agree that with decent hardware, a 1 ms servo thread often works out of the box, and EtherCAT as a protocol is designed for that class of cycle times.

My comment was specifically aimed at the earlier “8 kHz on the host” remark. That kind of statement mixes three different layers: the drive’s internal loops (which indeed run at several kHz), the EtherCAT communication cycle, and the LinuxCNC host servo thread. Once you start talking about pushing the host loop into the few-hundred-microsecond range, things like DC setup, cycle stability, NIC behavior (EEE, IRQ coalescing, etc.) and jitter stop being details and become the main engineering problem. That was the point I wanted to make.

When I said Mesa tends to be more “KISS”, I meant it in an architectural sense, not as a value judgment. EtherCAT is a full industrial fieldbus: multi-vendor, DC, flexible topologies, designed for distributed systems — that’s a big strength. The hm2-eth approach is intentionally simpler and focused on talking to the card, with the time-critical I/O timing living in the FPGA. Different tools, different trade-offs.

I also don’t think a fully centralized-in-one-panel setup is where EtherCAT really shines. It still works perfectly fine that way, and in fact I think it’s great that many people run it like this today, because that’s exactly how the LinuxCNC + EtherCAT integration gets exercised, debugged and improved in practice. Its main advantages just show up much more in distributed architectures, with drives and I/O spread across the machine and synchronized via DC.

For context, I’m actually looking at EtherCAT for my own project because it’s a modular machine (about 2 m per module, ~16 m total), where a distributed setup makes a lot of sense. That’s exactly the kind of case where EtherCAT really shines. So my comments are not “against EtherCAT”, but about keeping the architectural layers clear and not mixing up internal drive loops with very high host loop rates.

So yes, EtherCAT at 1 kHz on LinuxCNC works fine in many setups, as you said. My concern was only about the conceptual jump to “8 kHz on the host”, which is a very different class of problem.

Hi,NWE,

That’s a fair point, and I agree: EtherCAT (and the lcec stack) has a much richer network/state model and clearly handles link loss and recovery more gracefully than hm2-eth. That kind of supervision and recovery is a real advantage of EtherCAT as an industrial fieldbus.

My earlier comment wasn’t about network robustness or error recovery, but about where the time-critical control loop lives when people start talking about very high host rates (like “8 kHz on the PC”). Those are somewhat orthogonal aspects: EtherCAT is stronger as a fieldbus and in fault handling, while the Mesa approach keeps the tight I/O timing in the FPGA and is more “KISS” on the host side. Different strengths, different trade-offs.

Thanks for the discussion, and all the best to everyone doing the hard work in the trenches.

rodw wrote:

In fact, I believe that ethercat protocol is superior to the Mesa hm2-eth protocol.
 

My experiments with the hardware support that belief. Last I tried this, I could physically unplug the network cable; hm2-eth crashes, on the other hand, ethercat lcec properly reports the affected slaves as no longer responding, I reconnect the cable and all functions promptly recover without a restart.

the fact that you get a bad spi payload is good, keep it at 32 probably

This may sound forward of me, but how long is your cable?

a kernel trace also provides interesting data. when I did that on a 4 core i5, the servo thread was using about 200 usec and slept for 800 usec. Its the random incursions that take the servo-thread beyond 1000 usec that are the issue. I don't think Wireshark will show the full picture.

It's because:shows up in every line.

I could modify the g-code filter to remove it, but honestly your Post Processor needs to be modified, there's a lot of stuff that needs cleaned up in your cut file. That, G1 lines with no XY movements associated, G00 being separated from the corresponding XY moves, etc.

I am attaching your file, with all of those Feed rates removed, except for one at the top. That will let you do RFL to show you that is in fact the issue.

You should take a look at the nc_files/plasma folder to see examples of what's expected. metric_wrench.ngc is a good starting place.

I don't think its right to say Ethercat needs heavy tweaking to do 1 khz. My first ethercat machine worked straight out of the box. Ethercat is designed for 1 kHz and to imply its not suited to play with LinuxCNC's servo thread is just plain wrong! What it does internally is none of our business but many slaves run much higher sampling times and pulse trains than 1 kHz!

People just want to excessively complicate things for no reason.

However with later kernels, any RT system not just CNC needs careful tuning for optimised performance. This applies to space shuttles, Mesa cards and ethercat slaves. In fact, I believe that ethercat protocol is superior to the Mesa hm2-eth protocol. I have  a couple of videos about optimisations in a playlist. Here is the first of them.

 

My reply was specifically addressing the “8 kHz” comment earlier in the thread. That question mixes three different layers in one sentence:

The internal drive loops (current/velocity/position), which often run at several kHz inside the drive,

The EtherCAT communication cycle, and

The LinuxCNC host servo thread on the PC.

Many drives advertise 4–8 kHz internal loops, but that does not mean running the host servo thread at 8 kHz is either necessary or trivial. Once you start talking about pushing the PC/host loop to a few hundred microseconds, things like DC configuration, cycle stability, NIC behavior (EEE, IRQ coalescing, etc.) and jitter stop being “details” and become the main engineering problem.

So my point was not that EtherCAT needs heavy tweaking to work at 1 kHz — it usually doesn’t with decent hardware — but that when someone brings up “8 kHz on the host”, it’s important to make these fundamentals explicit, because that’s a completely different class of problem than the drive’s internal control loops.

Also, in the context of the original goal of “OEM-like” behavior: in most industrial controllers that does not mean an 8 kHz host loop. It usually means fast internal loops in the drive, a stable CNC/interpolator cycle (often 1–2 kHz), and good determinism with low cycle-to-cycle variation.

And just as an architectural note: even at 1 kHz, Mesa-based systems tend to be more “KISS”, because the time-critical I/O timing lives in the FPGA on the card, not in the PC and NIC. With EtherCAT on a PC, the host remains the time master, so platform details matter more — which is fine, just a different set of trade-offs.

Marcos wrote:

with PC-based EtherCAT it looks like you first have to make these fundamentals explicit (DC, cycle stability, NIC behavior, jitter) before worrying about pushing the servo thread frequency.

 

Probably depends on the hardware you choose.
I have installed 3 ethercat Linuxcnc systems in the past 12 mo. and have not needed to touch any of the above mentioned tweaks. Everything just worked and is being used daily with no glitches yet. All of them running stock servo-thread of 1 mS.

Now just recently bought a 4 axis ethercat stepper drive, this is the first ethercat hardware I've used that was not fully supported out of the box.

Plus I have two half finished LinuxCNC projects that don't count because they're not yet in use. The ethercat part went together easy enough but other aspects of these two projects are needing more work.

Thanks, it was just a file location error. The new pins are showing up now, but from what I understand, I need to modify the Qdragon UI to use them? Or how can I use these new pins?