Hallo rodw
I hadn't installed THC until now . And have found that it is better if you use metallsheet with about 2 mm
With a cutting height 1.8 mm 22 amp nozzle 0.9 I measured 103 volts
And nice cutting results .
Now that the intermediate sizes of the resistors are very bad to get, I go to 200 V

King regarde
Juergen

Follow the progress at : www.practicalmachinist.com/forum/threads...444018/#post-4425274

Has this always been the case, usually the write function is the last one in the list.

Unknown:
I am very sure the .ini file was added in the first post, but I don't see it anymore?
Here again.
And yes I mentioned BACKLASH in the JOINT_1 section of the Y-AXIS, otherwise there wouldn't be any difference between 1, 2 and 3 in the picture?  There the backlash was set to 1, 2 and 3.
Why does the picture get bigger (higher) instead of doing the backlash?

langdons:
After some years I thought it would be good idea to be 'up to date'.
What I always do with all my other Linux machines here, regularly
 

There is not much point upgrading from THCAD5 or THCAD10 to THCAD to THCAD2 as it is functionally identical except you can select 0-5v or 0-10 volt scales.

I personally think 150v is a bit low given cutting volts can be up around 130-140 volts. I would set to 180 to 200 volts.

I've been working on using a new build system for Raspberry images based on the utilities that are used on the official images. No custom kernel as RPi does provide pre-built RT kernels, but the 6.12.47 version has had reports of crashing. And yes raspi-config is included.
Benefits include being able to use Raspberry Pi Imager to preconfigure user name & password, local, all other things Raspberry Imager enable you to configure. There is now a single image for the 4 & 5 models. These are the only models supported. No there is no wayland, so don't try to changes this via raspi-config. The desktop environment is xfce.

I haven't included vnc as that brings in all the CUPS (printing) software and the associated services.

Only one browser is included, Firefox-esr.
Some simple screensver & power management items have been configured.
There is a network applet near the clock to simplify configuring a wired network. Please take note that the Raspberry's network address should not be that same as your mesa card, ie the last number in the address should differ. (sorry for those that are aware, but it pops up from time to time)
I have also included a fix for the CNC items appearing under multiple categories. This will survive upgrades. Due to the way Debian runs these "hooks" it will run after every time apt, apt-get or dpkg is run. Changes will only be made when it is required. No isolcpus has been added to the commandline, but this can be added by the usual methods.

Downloads are here - currently waiting to be updated 09 Dec 2025;


Please note the image on the Linuxcnc downloads page is missing a browser and a pdf reader, but will still run Linuxcnc itself fine. I apologise but so far I've been "on my own" building and testing.

If anyone is willing to test and point out any glaring errors it would be most welcome.
Rob

Any issues please raise here
github.com/ozzyrob/linuxcnc-rpi-2.9.7-image-issues/tree/main

Hallo PCW my thankˋs
Ok. Then I'll check on the weekend

King regarde
Juergen

In case anyone was wondering I think I found the thread where i havenofish pulled the xml file from
forum.linuxcnc.org/ethercat/54975-omron-...s-synch-error#329216 by tpa58
It uses a generic type.
If anyone understands that xml and could explain it that would be great. I do not know how he maps to a fixed SM with different addresses, but it does seem to work. I still get some "unrelated errors" but that's probably more of my particular hardware setup.

Any luck on the "how to" and files you used to make it work?

I struggled with the linuxcnc-ethercat Omron slave type in the XML configuration, it seems highly dependent on the linuxcnc-ethercat version, so that is why I am really curious of your xml setup. Did you goto a generic type maybe for that reason? Even the example in the repo is incorrect or not up-to-date, I don't know what version type="R88D-KN04H-ECT" will work in. It should be type="OmrG5_KN04H".

Also for anyone reading if you want to enable DC sync its worth noting the difference in versions
refClockSyncCycles = "-1" for older versions of linuxcnc_ethercat ( i.e. lcec ) syncToRefClock="true" works for newer versions.

I mention this because if you scour ( like most of us ) the posts you will see many different flavors of xml files.

I used the linuxcnc ISO image version 2.9.3 and that has an older version of linuxcnc-ethercat.

Also the OmrG5_KNxx does not expose all of the PDO's available on that syncManager. So doing a generic and manually building it might be a better option. Supposedly the drive has variable PDO SM but I have no clue how to set that up.

Other lessons learned, DO NOT use the ethercat pdos info to setup your XML. For some reason some of those value can be incorrect. If you have access to the ESI files use that as the golden standard, that is available from omrons website if you goto the specific product page.

I tried it like 2 weeks ago for the first time, it was on 2.9.6
I upgraded to 2.9.7 this week.
Both version had the same problem.

I am glad you got this working.
What version of linuxcnc are you using?
I feel we had this or a similar problem a while back.

wrote:

Use AXIS at first; there's a reason it's the default.

It is easy for inexperienced users.

What version are you using?
 

Please quit giving this advice.
If there are bugs in other screens we want to know so we can fix them.

Tonight I asked chatGPT (not my first reflex).

It proposed to try running "LIBGL_ALWAYS_SOFTWARE=1 linuxcnc" to disable the GPU rendering (use software rendering) from what I understand.

And you know what... it worked!

To make the change permanent, I added "export LIBGL_ALWAYS_SOFTWARE=1" to the usr/bin/linuxcnc

Unless somebody has an idea of the real root cause. Now it is working. Probably not exploiting my GPU, but don't seems to cause problem.

Thanks!

glxgears works perfectly. That was part of the validation I made for the latency.