Advanced Search

Have you reached out to Tormach for this? I know they had released updated servo configuration files for this issue at some point, I am unsure if it's after when this tread was created or not.

They haven't posted them but I have seen them on the FaceBook group(s) in the files section, also I made a pull request on their right to repair github to add all of them so people like yourself have access to them but they have not merged it as of yet.

Thankyou snowgoer, I really appreciate it. In the future, if you are ever fiddling with it, I have a few suggestions. One being the material list, it seems as tho I need to select material when going from a gcode part to conversational, instead of it simply remembering the last used cut chart, IDK if that is a bug or just the way it is. 2 I did have it freeze on a conversational drawn and nested part, no forward or reverse, however it may have been a conversational issue, I am not sure why it stopped in first place. It was on the last part and I was able to select and run from line then so not a big deal. 3 Another conversational thing, again this may not be practical to change, but if you ever rotate a part then the XY moves, say you have a part in on XY zero on bottom left corner, rotate it 90 degrees in conversational, the bottom left corner is now going to be a random -XY number. Again, not a big deal, we have used it this way several years, just FYI. If after a rotate it was bottom left XY0 that would be, well, you know! Thanks again for your efforts and for the great program!

Thanks — that's very helpful. Agreed on not mixing Intel's Ubuntu-built package into Debian; "installs but might be subtly unstable" is the worst case for a machine running multi-day jobs. I hadn't understood backports were already that far ahead. linux-image-rt-amd64 is there, so I'll stay on Debian 13 and take the kernel from backports.

That moves questions elsewhere:

Does the IgH master still build its native NIC drivers on a 6.18 or 7.x kernel? ec_igb and ec_e1000e are patched against specific kernel versions and have historically lagged mainline.

Do the native drivers still compile on a recent backports kernel, or is everyone on the generic driver now?
If generic — what does it cost in worst-case jitter at 1 kHz? and is generic-driver EtherCAT running in production machines, or is it considered bench-only?

Anyone here Amston Lake / Alder Lake-N (x7433RE, N97, N100) with LinuxCNC?

Some general information:
The RT kernel in Debian has a linux base, initramfs-tools, and kmod dependencies, all in appropriate versions. These dependencies have their dependencies, etc.
This means you can install a foreign kernel package, but something may work incorrectly or be unstable.
If sources are available, a better solution is to compile a new kernel, although this may not be possible, due a other causes...
6.18 itself shouldn't be a problem, because Trixie has kernel 7.1 in the backports, so you can try.

Hello all,I'm specifying the controller for LinuxCNC as EtherCAT master via IgH/EtherLab, CiA 402 servo drives, 1 kHz servo loop.. Two industrial box PCs are shortlisted, both built on Intel Atom x7433RE (Amston Lake / Alder Lake-N):

• ASRock Industrial iEP-5020G — 2 × i210-IT + 1 × i226-IT
• IBASE AGS104T — 2 × i226-IT

One of the vendors has just told me that Intel specifies kernel 6.18 or later for the Amston Lake platform, and points at Intel's RT kernel overlay (linux-image-6.18rt-intel) which targets Ubuntu. Debian 13 ships 6.12, and as far as I can tell so does the LinuxCNC Debian 13 PREEMPT_RT ISO. Before I commit to hardware I'd rather learn from people who've actually done this than find out on the bench.Questions:

1. Is anyone running LinuxCNC + IgH EtherCAT on Amston Lake or Alder Lake-N (x7433RE, x7835RE, N97, N100, N150)? Which distro and kernel?
2. Does the "6.18 or later" requirement actually bite on a 6.12 RT kernel, or is the gap mainly graphics/TCC/TSN enablement rather than boot, Ethernet and serial? I'd expect the i210/i226 drivers to be long-since mainline, but I don't want to assume.
3. IgH native NIC drivers vs generic — On a recent kernel, do ec_igb / ec_e1000e still build, or are people falling back to the generic driver? If generic, what did it cost in worst-case jitter?
4. i210-IT vs i226-IT for the master port. I've seen the i210 preferred here for worst-case timing. With both available on the same box, is that still the recommendation, or has the i226 situation improved?
5. Real latency numbers welcome — latency-histogram max on the servo thread, under load, at 1 kHz, on any Alder Lake-N class machine.
6. If you did run a newer RT kernel on Debian, did you build it yourself or use a repo, and did anything in the LinuxCNC/IgH build need patching?

I'll post my own results back here once hardware is on the bench — latency histograms, IgH timing, and whatever I learn about the kernel question — in case it's useful to the next person choosing one of these boxes.

I'll be honest, AI is helping me build this machine. I am not as knowledgeable as this post makes me seem - but please dont hold that against me.  I really would like some assistance rather than spending hours on a new machine only to find out it won't work for me.

so I tried again with VFD connected and got still the same error (see attached image "error present")
what I did is cut out lines 24-28, saved and tried again and LinuxCNC did run! see attached image "error gone".
how do I proceed from here to actually get the VFD running? is it enough to set the correct HAL pin from 0 to 1 to mimic "run/stop" signal together with providing some frequency/speed value on second pin or does this process require any more steps?

a little update - it turns out that the EtherCAT adapter works better if it is enabled in VFD settings. so I did that and then "ethercat slaves" command does recognize it and also lcec-configgen creates a lot more meaningful xml file and installing cia402 component did the trick - now it complains about invalid modparam "enable VLAccel" but that is expected because I brought the laptop in house and left VFD in workshop

do not worry about classicladder - I am using a sample config with classicladder because I wanted to create some basic logic for carousel toolchanger

one step at a time. you need to get rid of the error messages. comment out classicladder.
I have never used it so on a starting config, why do you?
Why are you still showing us useless xml?
It seems you are not finding your xml file.
I can't see any relevant messages or that 2 line generated file. it may be correct.

I agree completely with what spumco said and would like to expand on it. I have seen some faceting caused by a combination of extreemly short linear segmented CAM generated code and poorly chosen G64 settings. If multiple very short linear segments are used to approximate a curve, and a large G64 Pn setting are combined, sometimes the result will give a faceted tool path because G64Pn will assume "n" also for the Q setting. If Qn is less than the length of multiple lines of linear code in a row the interpreter will turn them into a single line. The result will be a bunch facets of approximately n length. The answer is to specify a value for Q less than the sum of two of your CAM program's shortest line segments instead of letting the Q be assumed to be equal to P.

Ich habe aber noch was gefunden im Linuxcnc G-Code fehlt die G43 !
Das ist de Werzeuglängen Offset
zweites Bild wie es sein mueste
drittes Bild was vom Program erstellt wird 

king
regarde
Juergen

Ja Firefox-ESR Startet Webseiten lassen sich öffnen…

king
regarde
Juergen

ok, thank you!
I tried lcec_configgen and the result is xml file with 2 lines which, based on the error message, seem insufficient (please see attached image). note that it was before I tried adding cia402 module. Is that a mistake and is cia402 module mandatory? because the way I understand it now is that cia402 helps connecting HAL pins, but the VFD should be discovered over ethercat even without it. is that correct? one more thing is that cia402.comp in the comments contains suggested HAL file lines and there lcec_conf is loaded in line 50 before cia402 in line 52:
github.com/dbraun1981/hal-cia402/blob/main/cia402.comp#L50
so I think that it should work like it is, the problem most probably is the XML file
I was expecting at least some kind of output from "ethercat slaves" command - there was totally nothing. is that ok? I was expecting some message that shows discovered slave device or a message that no devices were found

The provided xml is useless for our purposes.Its for twincat on windows You could try typing: lcec_configgen to generate an xml file
cia402 is a standard for drives (and vfds). It essentially uses the cia402 state machine to safely power drives on. so for ethercat drives, we load the lcec driver then for each drive we load the cia402 state machine. Then at the end of our servo thread cycle, we write cia402 back to the ethercat layer and  then write everything back to the ethercat bus

zjjxxsh wrote:

I turned off all the turbo mode, C-state,etc. But the latency test shows the jitter is 50-60us. Is it enough for Ethercat control? Is there anything else I need to do with.
 

Your PC sounds fine. Just make sure coalescing is turned off on your NIC. type man hm2_eth for some details on this.

BSAT wrote:

I have used the Teknic software and run an auto tune and it helped but the problem still exits.

I havent changed the step input resolution settings(which is 3200 steps/rev) because other folks have no problem nor should I. I can see a tuning change being needed per machine but not a reconfig of input vs resolution.
 

Do the other folks you're talking about also have 1100MX's?  Just making sure it's an apples-to-apples comparison.

Assuming you and they have the same pitch ballscrews, the next thing to check is the actual gcode.

Is this a CAM-generated toolpath with lots of linear segments, or are the facets present on G2/G3 moves?

Are you using G64 in the problem code?  If so, what is it set to?