Advanced Search

It's actually quite simple to install Flex GUI and use it if you read the well thought out docs.

On the other hand adding this to the already bloated LinuxCNC with many confusing GUI's seems to be a nightmare and quite complicated.

IMHO GUI's should not be included in the main repo except for Axis so as to not drag in a huge amount of dependencies for nothing. Especially when many of the GUI's are not supported any more as the authors have moved on.

JT

If you were to install Debian Forky (aka testing), you get the 7.1 kernel. You should be able to install Linuxcnc direct but it may not be the latest version. You can install the LinuxCNC repos by running a bash script mentioned in the docs here which would be preferred as it keeps you current
linuxcnc.org/docs/stable/html/getting-st...th_preempt_rt_kernel 

Then install Linuxcnc with 
sudo apt install linuxcnc-uspace linuxcnc-uspace-dev

Anyway, that is how I would do it. The pre-release versions of Debian are rock solid in my experience. I don't like using backports. Never have used them.

I came across this issue in QtPyVCP/Probe Basic because they share the same spindle_sim.hal as Gmoccapy.

It's really not ideal to have a simulated config be non-functional for spindle speeds ≥12500rpm at the default base period, I know it can be 'fixed', but ideally it should work by default, high speed spindles are not rare now.

Is there a reason why instead of modifying the base period, the value of sim_encoder_0.ppr (and therefore also encoder_0.position.scale) can't be decreased?
Is there actually a reason to sample this frequently in a simulated config?

I'm naively assuming that it is because this logic predates high speed spindles being easy to get hold of, so it wasn't seen as an issue at the time?

cutnweld wrote:

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.

I fired up my VM machine and tried this one, it pre-populates with whatever I had chosen on the MAIN screen. Whether or not a g-code file is loaded. I believe what you are saying, but if you could find the exact steps to reproduce it, that makes fixing it 10x easier.

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.

My first question is: Is this an old conversational file that perhaps you saved and run from time to time? The way we did conversational Block previously, I am not sure reverse run would have worked because it was variable based and used a lot of math, etc. I think it also used sub-routines. So reverse run may not have been possible in this instance. Before Phill stepped away from the project, he made V2 block which essentially spelled out the g-code instead of using the aforementioned method. I just tried and reverse run did work when I paused in the middle of a cut.

It did highlight a bug that I cant seem to array a circle for some reason, they all have the same origin, so I will have to take a look at that when I get some time. The other shapes seemed to array just fine.

Could you share the file you are referencing?

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!

I think it does what you're asking for. But again, without the g-code file it's tough for me to tell. I have a test file I use for a lot of things, and the origin stays the same. I put it at X0Y0, and then rotated about both Shape and Pattern, and the origin stayed at the same place. That said, how it rotates is different between Shape and Pattern. Which if you are just rotating one thing, it can be a bit confusing.

Conversational was made as a quick and dirty way to do simple things at the machine and wasn't really intended to be the end-all-be-all CAM solution. Just to temper expectations a bit, that's all; sometimes it's best to re-post the cut file from the native CAM.

All of that said, I'm happy to work through bugs and consider things like this as time allows.

Nobody knows  you VFD so you need to work it out yourself, it seems there is a syntax error in your xml and it reports the line number.
Sharing your xml file now you have  made some progress would be helpful. as we are flying blind
I suspect you will need to command it more like it was a servo except use a mode that commands RPM (velocity) not position 

Why don't you just add it to the master branch? The disjointedness of this project is baffling to me sometimes. Navigating this mess as a new user must be an absolute nightmare.

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.