lcec_conf error (newest lcnc 2.10 and debian 13)

Some time ago I configured and launched a machine with ethercat drives.
Everything was working fine and would probably still work, but I had to update LinuxCNC.
I simply configure the machine with xyzab-tdr-kins kinematics.
I reached the point when the machine was correctly based, but then it turned out that LinuxCNC compiled a few months ago did not support the G12.1 and G13.1 codes, which are absolutely necessary.
So I compiled 2.10 from the latest sources downloaded from Github today.
After installing the new LinuxCNC, the machine cannot be started.I have tried various methods and I have the impression that it cannot be a problem with the configuration or the xml file, because even calling lcec_conf in the terminal gives the same error.I upgraded linuxcnc-ethercat ethercat-master libethercat-dev. Nothing helped.
I have not tried compiling lcec from sources, because there is no compilation environment on the computer controlling the machine, and the laptop on which I am compiling does not have a network card.

I've run out of ideas what this could be about and how to deal with it...

The machine appears to be working, xyzab-tdr-kins kinematics as well.

I came up with the idea to look for the hal_pin_u32_newf string in my LinuxCNC sources.
And bingo!
The latest ones don't have this string in any files (except old translations files), but I found it in sources with file dates between July 14 and September 26, 2026.
I installed LinuxCNC compiled from those sources and everything works as it should, although there is still a lot of work ahead of me.

From the above, the following conclusions should be drawn:
1. If LinuxCNC developers don't come to their senses, everything will soon stop working...
2.Never delete old files, even if newer works.
3. If someone works with 2.10.0~pre1, don't try to switch to pre2, because it will hurt.

I can share the deb packages I have 2.10.0~pre1 compiled on September 26, 2026 (so I guess the latest pre1), but not here due to size. I could send it to some server, but I have no idea which one.

I seem to recall reading a recent message somewhere that talked about replacing all 32 bit hal code with 64 bit versions in Master. This might be your problem. I suspect that the new command your code needs to use might be "hal_pin_new_uint" instead of "hal_pin_u32_newf"

Todd wrote:

I seem to recall reading a recent message somewhere that talked about replacing all 32 bit hal code with 64 bit versions in Master. This might be your problem. I suspect that the new command your code needs to use might be "hal_pin_new_uint" instead of "hal_pin_u32_newf"
 

You're absolutely right, that's exactly the point.
I created an issue on github linuxcnc-ethercat and received information that the problem was not only known to the authors, but had been solved long ago. You just need to download the deb package from the getset branch instead of main, or set a different source in the apt settings (I haven't checked it yet, but I believe it works).
But how is an average user who is not a LinuxCNC developer supposed to know about this?
He'll just do exactly what I did - update what he has installed, find out it doesn't work and start swearing...

I'm sorry, I'm just a user like you. But that sort of thing is not unexpected when running the development branch (currently 2.10) and not the stable release version (2.9). The development branch is where changes are introduced and those changes are often undocumented or not fully documented. And things do occasionally get broken.

While I would not hesitate to use the Master branch to run a machine if a needed feature was only found there. I would want to thoroughly test it on that machine before releasing it to a production environment. And I would be extremely hesitant to update the version of said working machine without further rigorous testing. Personally I will stick to the general release branches whenever possible for machinery others might use. Master is for testing.

"Stable" does not mean that the program is really stable and bugs-free.
It just means that it's old and there's something missing.
For example, Debian is released every three years and Ubuntu every six months. People prefer Ubuntu because they probably don't know it's unstable and should use Debian...
Coming back to LinuxCNC, I use version 2.10 because I don't want to wait a few years for functionality that I can have today.
And you must always be careful, even if something is called stable.

Yes, Stable does not necessarily mean bug free. But it also does not mean that there are not bug fixes when bugs are found. This isn't Debian. In the case of Linuxcnc, it only means that it is no longer getting new features and major changes, and it will be much more bug free than the development branch. The Master development branch in Linuxcnc is more analogous to Sid in Debian. Linuxcnc does not have a Testing stabilizing branch like Debian.

And yet, it still doesn't work...
Versions 1.46 and 1.47 can be installed, but they refuse to run because they fail to detect a library that is, in fact, already installed—and I haven't been able to find a newer version anywhere.

Version 1.45 installs and appears to work, but then it’s impossible to install `cia402` (another round of "congratulations" to the LinuxCNC developers).
I tried using the source code from the repository github.com/rodw-au/cia402_homecomp, which works with the `pre1` release...
I haven't been able to find any newer versions either.
Compillation returns many "lvalue required as left operand of assignment" errors, that say nothing.

I'm sorry, you lost me. Versions 1.45, 1.46 and 1.47 of what software?

Ok, I looked at the page you linked to of the comp of Rodw, and I'm not sure it is even necessary. The same function could be probably achieved with just a few lines of hal logic using ordinary hal components, rather than writing a custom comp. Simply use a mux hal component to connect the commanded position to the feedback while the homing pin is true. (But there could be an issue if there is a large step in the FB position when homing is completed. I don't think that will happen but...)

Some of these guys get a little carried away writing custom hal comps for their nich uses when existing standard components are more than adequate. Which is fine and good for their own personal uses. But I don't always agree with them posting their "this is how it has to be done" tutorials and linking to their custom comp that is out of tree, which doesn't follow updates of the main system that may break them.

Todd wrote:

I'm sorry, you lost me. Versions 1.45, 1.46 and 1.47 of what software?

Ok, I looked at the page you linked to of the comp of Rodw, and I'm not sure it is even necessary. The same function could be probably achieved with just a few lines of hal logic using ordinary hal components, rather than writing a custom comp. Simply use a mux hal component to connect the commanded position to the feedback while the homing pin is true. (But there could be an issue if there is a large step in the FB position when homing is completed. I don't think that will happen but...)

Some of these guys get a little carried away writing custom hal comps for their nich uses when existing standard components are more than adequate. Which is fine and good for their own personal uses. But I don't always agree with them posting their "this is how it has to be done" tutorials and linking to their custom comp that is out of tree, which doesn't follow updates of the main system that may break them.

Homecomps are part of the LinuxCNC design and are intended to avoid (complex) custom coding in homing.c. The code in question is not designed for general use and has not been tested. But the changes made by the developers  in 2.10 has broken every out of tree component. There is a lot of pain across many users to come......