Advanced Search

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?

Many thanks for the reply. Just SSH'd onto the machine - yes, Intel Ethernet controller. I'll wait for morning (and for the icicles to disappear) and try the recommended settings in that link, and report back.

Have you looked in the bottom beside the battery. its a normal place for the upgrade modules ?

Probably Intel network card, so have a look here for use of ethtool to set the rx to 0
forum.linuxcnc.org/27-driver-boards/4750...i96s-a-little-jitter

Here are the complete files

I've ended up fighting the hal loader.

#

---

# M19 ORIENT – single driver / multi‑sink form
#

---

loadrt orient count=1
addf orient.0 servo-thread

loadrt pid names=pid.o
addf pid.o.do-pid-calcs servo-thread

loadrt mux2 count=1
addf mux2.0 servo-thread
loadrt or2 count=1
addf or2.0 servo-thread

# --- Orient PID tuning ---
setp pid.o.Pgain 0.05
setp pid.o.Igain 0.0005
setp pid.o.Dgain 0.0002
setp pid.o.maxoutput 60
setp pid.o.error-previous-target true
setp orient.0.tolerance 0.05
setp orient.0.angle 0

# --- One signal name, declared once and fanned out ---
net orient-bit spindle.0.orient => orient.0.enable
net orient-bit => or2.0.in1
net orient-bit => mux2.0.sel
# separate signal drives the encoder’s index enable input
net orient-arm-index orient-bit => hm2_7i92.0.encoder.05.index-enable

# --- Run enable OR gate ---
net run-enable or2.0.out => hm2_7i92.0.7i77.0.1.spinena
net spindle-enable => or2.0.in0

# --- Orient angle / feedback wiring ---
net orient-angle spindle.0.orient-angle => orient.0.angle
net spindle-revs hm2_7i92.0.encoder.05.position => orient.0.position

# --- Orient PID loop ---
net orient-cmd orient.0.command => pid.o.command
net orient-fb hm2_7i92.0.encoder.05.velocity-rpm => pid.o.feedback
net orient-out pid.o.output => mux2.0.in1

# --- Normal spindle path and output switch ---
net spindle-output pid.s.output => mux2.0.in0
net spindle-vfd-out mux2.0.out => hm2_7i92.0.7i77.0.1.analogout5

# --- Completion flag back to controller ---
net orient-done orient.0.is-oriented => spindle.0.is-oriented

#Error in file ./spindlecontrol.hal:
# Pin 'orient-bit' does not exist
#Shutting down and cleaning up LinuxCNC…

New Update from my MainUI, would like to hear some opinions.Thanks

I'll hijack this thread, as my use-case is a "mini PC" NUC gen-11 i3, modest performance but which should more than adequate for LinuxCNC. Running 2.9.0 (though able to update... however same behaviour verified with another user here with standard desktop and 2.9.8).

With a Mesa 7i76e (other user: 7i92) - just observing HAL pins, whilst rebuilding an old Boxford 160 set-up I noticed that the HAL Write.Time pin was bubbling around 10,000-12,000 (so, 10us-12us) - which looked quite respectable given that the HM2 is scheduled on servo thread at 1ms. The hm2.read, however, was around 800,000-900,000 (verified on other user's 7i92 also), That, to my uneducated mind is getting a bit close to the limits of the 1ms servo thread. Do other people see similar performance / behaviour with Mesa cards?

I'll dig deeper and Wireshark the set-up. I should say that my particular environment the NUC wired interface is hooked to the Mesa, and I use WiFi for internet. Other user is dedicated wired interface to the machine without internet.

I just realised I still had SPI_clk_div set to 16, after setting it back to 32 or 64, the errors are gone, but i'm at square one again, no error on e-stop deactivate.

Witam kupiłem taką samą kartę i czekam na przesyłkę.
Moje pytanie to jakim napięciem zasilasz tą kartę , w opisie podają 24V max i czy tylko to wystarczy ?

Ja es ist Hobby aber viel Material abnehmen auf einmal das erfordert ein stabile Maschiene das Endschen ist mehr was für kleine Teile .
Alu zu fräsen kann auch zu einer Heraufforderung werden Alu ist nicht gleich Alu .
Egal welch Fräsmotor man nimmt man lehrnt dazu.
Wenn das Hobby größe Teile erfordert kommt man um eine Fräse zb Deckel FP 1 nicht drum herum.

Gruß
Jürgen