emc-developers — Developer specific. For issues of interest to users see emc-users list (below)

Re: [Emc-developers] Canceled: Video Developer Meeting Sunday 2026-08-30 20:00 CEST

[Bertho S. <lc...@va...>]

The video meeting has been canceled because the bbb server is under 
maintenence. It is unclear when it will be online again. Probably not in 
time today.


On 8/28/26 3:19 PM, Bertho Stultiens wrote:
> Hi,
> 
> It's been another two weeks and this is a reminder/invitation.
> 
> Agenda: https://github.com/LinuxCNC/linuxcnc/discussions/4389
> 
> According to our bi-weekly schedule alternating between "early" and 
> "late", this video meeting is this Sunday 2026-Aug-30 at 20:00 CEST.
> 
> https://greenlight.bbb.uni-rostock.de/b/ste-c4d-brs-3k6
> Access code: 869782
> 
> https://www.timeanddate.com/worldclock/meetingdetails.html? 
> year=2026&month=8&day=30&hour=18&min=0&sec=0&p1=319&p2=236&p3=240&p4=136



-- 
Greetings Bertho

(disclaimers are disclaimed)

[Emc-developers] Video Developer Meeting Sunday 2026-08-30 20:00 CEST

[Bertho S. <lc...@va...>]

Hi,

It's been another two weeks and this is a reminder/invitation.

Agenda: https://github.com/LinuxCNC/linuxcnc/discussions/4389

According to our bi-weekly schedule alternating between "early" and 
"late", this video meeting is this Sunday 2026-Aug-30 at 20:00 CEST.

https://greenlight.bbb.uni-rostock.de/b/ste-c4d-brs-3k6
Access code: 869782

https://www.timeanddate.com/worldclock/meetingdetails.html?year=2026&month=8&day=30&hour=18&min=0&sec=0&p1=319&p2=236&p3=240&p4=136


-- 
Greetings Bertho

(disclaimers are disclaimed)

[Emc-developers] Video Developer Meeting Sunday 2026-08-16 10:00 CEST

[Bertho S. <lc...@va...>]

Hi,

It's been another two weeks and this is a reminder/invitation.

Agenda:
- We need to create a public agenda for these meetings to smooth things
- HAL 32->64 migration progress
- PRs
- Anything else


According to our bi-weekly schedule alternating between "early" and
"late", next video meeting is this sunday at 10:00 CEST.

https://greenlight.bbb.uni-rostock.de/b/ste-c4d-brs-3k6
Access code: 869782

https://www.timeanddate.com/worldclock/meetingdetails.html?year=2026&month=8&day=16&hour=8&min=0&sec=0&p1=319&p2=236&p3=240&p4=136

See you there and then.

-- 
Greetings Bertho

(disclaimers are disclaimed)

[Emc-developers] Early Sunday meeting

[Luca T. <lu...@ai...>]

Are we still on schedule? Who's going to be present? I'll try to make it if others are going to be present...

Re: [Emc-developers] Moving HAL from 32-bit to 64-bit - status

[Titus N. <nw...@ma...>]

+1

[Emc-developers] Moving HAL from 32-bit to 64-bit - status

[Bertho S. <lc...@va...>]

Hello All,

The future upcoming 2.10 release will be seeing quite a few changes. 
Some of them will real breaking changes, requiring you to update 
components, drivers, INI-files and VCPs. The changes are necessary to 
improve both operation and the code base.

The goal of the current changes are: Replacing 32-bit HAL 
pins/params/signals with 64-bit and dropping 32-bit pins/params/signal 
completely.

The goal sounds simple, but there are many technical details that needed 
to be solved before a viable progression plan could be established. For 
discussions of how we got here you can start with #3286 for the 
background and #4099 for the start of the implementation. Fair warning: 
these are very lengthy discussions with a tremendous amount of 
information and detail.

What has happened and will be happening:
1. Replacing direct HAL pins/params/signals access and moving to 
getter/setter
Moving all pins/params/signals to a larger size has consequences 
throughout the code. Many places have hard-coded assumptions about sizes 
and require manual inspection and conversion.
To ease the transition, it was decided to move all access to pins and 
parameters to use a getter/setter approach. Such system hides the 
underlying access to shared memory and protects it in an abstraction 
layer without loss of performance. The user only needs to know that the 
data is accessed properly, not how the underlying system works. The 
second point in the getter/setter approach was to ensure both a smooth 
transition and the continued proper functionality with 32-bit compatibility.
An advantage of the getter/setter change has been that both pins and 
parameters now have a similar structure and use the same access methods. 
This change did expose several bugs where parameters were used wrongly 
or inappropriately.
The current status is that most code has been converted. Only waiting on 
the hostmot2 update. Everything else has been updated, with most of you 
never noticing the change. However, the next step will be a) deprecate 
the old HAL API and b) break the HAL API by removing the old API and use 
the new one exclusively.

2. HAL library isolation and better abstraction
The HAL library internals were being used by other code that should have 
accessed using a defined user-facing API. As with the INI-file update, 
the HAL API update was required to unify, standardize and abstract. All 
of HAL's internals have now been isolated and a new query API has been 
established for all needs to get information about HAL, pins, params, 
signals, components, functions and threads. The last part is to update 
halmodule to add the query API (in the pipeline). The next step is a) to 
deprecate the old access modalities and b) break the API by removing 
access to HAL's internal API completely.

3. Components now requiring a set method to assign values to pins and 
parameters
The way components are build needed to change to enable transitioning 
from 32-bit to 64-bit. There have been created a new set of HAL types 
(HAL_BOOL, HAL_REAL, HAL_SINT, HAL_UINT) that replace the old types. The 
new types are used in halcompile in conjunction with the getter/setter 
system for ease of transitioning.
Also the C/C++ code will see a new set of HAL types:
- hal_bool_t - HAL_BOOL - boolean
- hal_real_t - HAL_REAL - floating point
- hal_sint_t - HAL_SINT - 64-bit (minimum) signed integer
- hal_uint_t - HAL_UINT - 64-bit (minimum) unsigned integer
To accommodate both the old and the new API, we had to add new types to 
halcompile. Changing pin/param type will automatically use the new API. 
The types must change from bit->bool, float->real, s32->si32, u32->ui32, 
s64->sint, u64->uint, unsigned->ui32 and signed->si32. Note that there 
are still 32-bit versions available to halcompile. The 32-bit versions 
are required for compatibility. However, the _underlying_ type is 64-bit 
and the getter/setter infrastructure ensures that it works in a 
compatible way.
The new types in halcompile require a conversion of the component. 
Assigning values to a pin/param can no longer be performed using a 
simple assignment, but is now a macro expanding the setter paradigm. 
That means, 'pin = 123' needs to be rewritten as 'pin_set(123)' and 
'pin++' becomes 'pin_set(pin + 1)'. Please note that adding to pins and 
parameters is an expensive operation. The getter/setter change makes 
that even more clear. [And, no, the getter/setter change does not make 
it slower because the compiler had to perform the exact operation that 
is now written in full.] A PR is in the pipeline (#4256) to perform the 
component update automatically, as much as possible.
All in-tree components and drivers have already been updated, except 
we're waiting for hostmot2. When that is done, then we can a) deprecate 
the old types in halcompile and b) break the API.

4. Making components and drivers work properly in a 64-bit regime
The last issue in the HAL changes is to ensure that all components and 
drivers will continue to work when HAL_S32/HAL_S64 and HAL_U32/HAL_U64 
are all merged into HAL_SINT/HAL_UINT and all the user will see are the 
new 64-bit pin/param/signal types.
This step is the "64-bit clean" step, where code must be reviewed to 
drop inappropriate internal 32-bit truncation in both components and 
drivers. Also supporting code must be reviewed to ensure no truncation 
is happening when it shouldn't.
Then, when the actual merge happens, then the user needs to update 
configurations, code and HAL-files. If they use their own code, then it 
must be reviewed too to be 64-bit clean and interoperable with the rest 
of the system.
Merging types should not really be a breaking step as seen from the code 
internally. However, the user will need to do some work (conversion 
tools may be created by that time). Also, when the old HAL types are 
merged into the new ones, then it may be discovered that some values get 
truncated improperly. These may break some user's setup, although no 
such breakage is expected. It needs some testing time to find the hidden 
32-bit dependencies and properly update them.


We still have some (smaller) changes to go before we start with 
deprecating the old API. There will be a deprecation period before the 
actual API break will happen. Also, some upgrade documentation must be 
prepared when the deprecation hits. The actual deprecation time, until 
we break the API, must still be agreed upon. This should be discussed in 
one of the coming video meetings.

-- 
Greetings Bertho

(disclaimers are disclaimed)

[Emc-developers] Deprecating the old mesa_modbus / modcompile driver

[Luca T. <lu...@ai...>]

The Mesa hostmot2 tree currently carries two Modbus drivers.

The older one lives in src/hal/drivers/mesa-hostmot2/modbus. You write a
.mod file describing your device, run modcompile on it, and it generates
and compiles a bespoke realtime component from mesa_modbus.c.tmpl for
that device. Documented in docs/src/drivers/mesa_modbus.adoc and
modcompile(1).

The newer one is hm2_modbus, written to replace it. It is a single
loadable driver configured with binary MBCCB files built by mesambccc(1),
so there is no per-device compile step. Documented in hm2_modbus(9) and
mesambccc(1).

Keeping both has a concrete cost beyond the duplication. The old driver
is the reason hostmot2-serial.h is an exported public header, which
constrains work on the hostmot2 headers generally. The only other user is
the mesa-pktgyro-test component, which is easy to adjust.

So, two questions.

To users: is anyone still running a mesa_modbus setup built with
modcompile? If so, is there something it does for you that hm2_modbus
does not, or is it simply that the configuration has not been migrated?

To developers: any objection to deprecating the old driver now, with a
note in the docs and a runtime warning, and removing it after a release?

If there is a feature gap, I would rather hear it now and see it closed in
hm2_modbus than remove something people depend on.

-- 

*Luca Toniolo*

Re: [Emc-developers] PR #4318 enables MTconnect, an open standard for machine data

[Marius L. <ma...@ma...>]

I support Rod on this one. Brad had an online demonstration to our 
SA-CNC club, and we all agreed that this is a very good step forward for 
LinuxCnc to becoming an even stronger contender to be used in 
professional machine shops and production shops. He has done very 
impressive work on this.

On 02/08/2026 11:37, rodw wrote:
> Hi guys,
> It would be appreciated if you could review this PR and add your thoughts.
> https://github.com/LinuxCNC/linuxcnc/pull/4318  
> This PR has been prepared by Brad Collette, a Freecad Developer many of you will know.
> Brad and I ran a live stream podcast on MTconnect recently which outlines in more detail what MTconnect is, and Brad demonstrated a working system with LinuxCNC.
> https://youtube.com/live/b_S-p2nylr8  
> The video description includes a table of contents so you can jump to the demo if you are short on time.
>   
> It would be great if you could review this PR and provide some feedback about this feature. I believe the time has come for LinuxCNC to connect to the outside world and this is a safe read only industry standard used by most machine manufacturers. There is not really any valid reason not to include this in my vew after testing it myself.
>   
> Brad wanted to   email here before submitting this PR but when I asked around it was suggested it be submitted to kickoff the discussion so here we are.
>   
> Regards
>   
> Rod Webster
>
>
> _______________________________________________
> Emc-developers mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] keep an eye on weblate warnings

[Luca T. <lu...@ai...>]

We are also sooooooo very close on having a clean tree on the 
translations, if anyone looked the htmldocs broken link check warnings, 
there are way less broken links now, I think next cycle from weblate, if 
all goes well (finger crossed), the link checker shall return no 
warnings :tada:

Be aware warning will come back as translators mess it up, those 
warnings should only come at first in the weblate push to github, and we 
just have to go on weblate and fix them, merge with warnings, and wait 
for next push, I don't think there is an easy way to get rid of this 
janitorial work, would be nice if translators could also be aware and 
keep an eye out on the weblate CI pushes on github.

@smoe if your German is as fluent as your link messing, you must have 
done a great job with the translation ;-)

[Emc-developers] PR #4318 enables MTconnect, an open standard for machine data

[rodw <ro...@ve...>]

Hi guys,
It would be appreciated if you could review this PR and add your thoughts.
https://github.com/LinuxCNC/linuxcnc/pull/4318  
This PR has been prepared by Brad Collette, a Freecad Developer many of you will know.
Brad and I ran a live stream podcast on MTconnect recently which outlines in more detail what MTconnect is, and Brad demonstrated a working system with LinuxCNC.
https://youtube.com/live/b_S-p2nylr8  
The video description includes a table of contents so you can jump to the demo if you are short on time.
 
It would be great if you could review this PR and provide some feedback about this feature. I believe the time has come for LinuxCNC to connect to the outside world and this is a safe read only industry standard used by most machine manufacturers. There is not really any valid reason not to include this in my vew after testing it myself.  
 
Brad wanted to   email here before submitting this PR but when I asked around it was suggested it be submitted to kickoff the discussion so here we are.
 
Regards
 
Rod Webster  

[Emc-developers] Video Developer Meeting Sunday 2026-08-02 20:00 CEST

[Robert S. <rm...@un...>]

Hi,

it's been another two weeks and I wanted to send the reminder /
invitation


According to our bi-weekly schedule alternating between "early" and
"late", next video meeting is this sunday at 20:00 CEST.

https://greenlight.bbb.uni-rostock.de/b/ste-c4d-brs-3k6
Access code: 869782

https://www.timeanddate.com/worldclock/meetingdetails.html?year=2026&month=8&day=02&hour=18&min=0&sec=0&p1=319&p2=236&p3=240&p4=136

see you there and then

-- 
Robert Schöftner <rm...@un...>

[Emc-developers] Bug#1143333: linuxcnc: FTBFS: dh_auto_build: error: cd src && make -j2 docs returned exit code 2

[Santiago V. <sa...@de...>]

Package: src:linuxcnc
Version: 1:2.9.9-2
Severity: serious
Tags: ftbfs forky sid

Dear maintainer:

During a rebuild of all packages in unstable, this package failed to build.

Below you will find the last part of the build log (probably the most
relevant part, but not necessarily). If required, the full build log
is available here:

https://people.debian.org/~sanvila/build-logs/202608/

About the archive rebuild: The build was made on virtual machines from AWS,
using sbuild and a reduced chroot with only build-essential packages.

If you cannot reproduce the bug please contact me privately, as I
am willing to provide ssh access to a virtual machine where the bug is
fully reproducible.

If this is really a bug in one of the build-depends, please use
reassign and add an affects on src:linuxcnc, so that this is still
visible in the BTS web page for this package.

Thanks.

--------------------------------------------------------------------------------
[...]
 debian/rules build
dh build -D/<<PKGBUILDDIR>>/src
date: invalid date ‘@’
date: invalid date ‘@’
   dh_update_autotools_config -O-D/<<PKGBUILDDIR>>/src
   dh_autoreconf -O-D/<<PKGBUILDDIR>>/src
	find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*' -o -path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a  -type f -exec md5sum {} + -o -type l -printf "symlink  %p
" > debian/autoreconf.before
	grep -q ^XDT_ configure.ac
	autoreconf -f -i -v
autoreconf: export WARNINGS=
autoreconf: Entering directory '.'
autoreconf: configure.ac: no obvious need to run autopoint
autoreconf: running: aclocal --force 
autoreconf: configure.ac: tracing

[... snipped ...]

Pixel unit not handled (replaced by pt)
Pixel unit not handled (replaced by pt)
Pixel unit not handled (replaced by pt)
Pixel unit not handled (replaced by pt)
Pixel unit not handled (replaced by pt)
Pixel unit not handled (replaced by pt)
Pixel unit not handled (replaced by pt)
Pixel unit not handled (replaced by pt)
Pixel unit not handled (replaced by pt)
Pixel unit not handled (replaced by pt)
Pixel unit not handled (replaced by pt)
Pixel unit not handled (replaced by pt)
Pixel unit not handled (replaced by pt)
Pixel unit not handled (replaced by pt)
Pixel unit not handled (replaced by pt)
Pixel unit not handled (replaced by pt)
Pixel unit not handled (replaced by pt)
Pixel unit not handled (replaced by pt)
Pixel unit not handled (replaced by pt)
Pixel unit not handled (replaced by pt)
Section level > 6 not well supported for bibliodiv
inkscape -D --export-filename=fig0.png /<<PKGBUILDDIR>>/docs/src/es/user/images/mill-diagram_en.svg

** (inkscape:89658): WARNING **: 21:01:13.359: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.

** (inkscape:89658): WARNING **: 21:01:13.563: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
item_to_outline: fill path has no segments!
inkscape -D --export-filename=fig1.png /<<PKGBUILDDIR>>/docs/src/es/user/images/lathe-diagram_en.svg

** (inkscape:89666): WARNING **: 21:01:13.645: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.

** (inkscape:89666): WARNING **: 21:01:13.843: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
inkscape -D --export-filename=fig2.png /<<PKGBUILDDIR>>/docs/src/es/lathe/images/tool-positions_en.svg

** (inkscape:89674): WARNING **: 21:01:13.926: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.

** (inkscape:89674): WARNING **: 21:01:14.121: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
inkscape -D --export-filename=fig3.png /<<PKGBUILDDIR>>/docs/src/es/lathe/images/tool-pos-1_en.svg

** (inkscape:89682): WARNING **: 21:01:14.195: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.

** (inkscape:89682): WARNING **: 21:01:14.386: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
inkscape -D --export-filename=fig4.png /<<PKGBUILDDIR>>/docs/src/es/lathe/images/tool-pos-2_en.svg

** (inkscape:89690): WARNING **: 21:01:14.449: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.

** (inkscape:89690): WARNING **: 21:01:14.641: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
inkscape -D --export-filename=fig5.png /<<PKGBUILDDIR>>/docs/src/es/lathe/images/tool-pos-3_en.svg

** (inkscape:89698): WARNING **: 21:01:14.702: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.

** (inkscape:89698): WARNING **: 21:01:14.892: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
inkscape -D --export-filename=fig6.png /<<PKGBUILDDIR>>/docs/src/es/lathe/images/tool-pos-4_en.svg

** (inkscape:89706): WARNING **: 21:01:14.962: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.

** (inkscape:89706): WARNING **: 21:01:15.151: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
inkscape -D --export-filename=fig7.png /<<PKGBUILDDIR>>/docs/src/es/lathe/images/tool-pos-5_en.svg

** (inkscape:89714): WARNING **: 21:01:15.214: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.

** (inkscape:89714): WARNING **: 21:01:15.403: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
inkscape -D --export-filename=fig8.png /<<PKGBUILDDIR>>/docs/src/es/lathe/images/tool-pos-6_en.svg

** (inkscape:89722): WARNING **: 21:01:15.473: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.

** (inkscape:89722): WARNING **: 21:01:15.662: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
inkscape -D --export-filename=fig9.png /<<PKGBUILDDIR>>/docs/src/es/lathe/images/tool-pos-7_en.svg

** (inkscape:89730): WARNING **: 21:01:15.724: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.

** (inkscape:89730): WARNING **: 21:01:15.913: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
inkscape -D --export-filename=fig10.png /<<PKGBUILDDIR>>/docs/src/es/lathe/images/tool-pos-8_en.svg

** (inkscape:89738): WARNING **: 21:01:15.977: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.

** (inkscape:89738): WARNING **: 21:01:16.166: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
inkscape -D --export-filename=fig11.png /<<PKGBUILDDIR>>/docs/src/es/lathe/images/control-point_en.svg

** (inkscape:89746): WARNING **: 21:01:16.229: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.

** (inkscape:89746): WARNING **: 21:01:16.418: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
inkscape -D --export-filename=fig12.png /<<PKGBUILDDIR>>/docs/src/es/lathe/images/ramp-entry_en.svg

** (inkscape:89754): WARNING **: 21:01:16.487: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.

** (inkscape:89754): WARNING **: 21:01:16.678: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
inkscape -D --export-filename=fig13.png /<<PKGBUILDDIR>>/docs/src/es/lathe/images/ramp-cut_en.svg

** (inkscape:89762): WARNING **: 21:01:16.747: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.

** (inkscape:89762): WARNING **: 21:01:16.937: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
inkscape -D --export-filename=fig14.png /<<PKGBUILDDIR>>/docs/src/es/lathe/images/radius-1_en.svg

** (inkscape:89770): WARNING **: 21:01:17.010: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.

** (inkscape:89770): WARNING **: 21:01:17.199: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
inkscape -D --export-filename=fig15.png /<<PKGBUILDDIR>>/docs/src/es/lathe/images/radius-2_en.svg

** (inkscape:89778): WARNING **: 21:01:17.274: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.

** (inkscape:89778): WARNING **: 21:01:17.464: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
inkscape -D --export-filename=fig16.png /<<PKGBUILDDIR>>/docs/src/es/lathe/images/radius-3_en.svg

** (inkscape:89786): WARNING **: 21:01:17.554: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.

** (inkscape:89786): WARNING **: 21:01:17.744: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
inkscape -D --export-filename=fig17.png /<<PKGBUILDDIR>>/docs/src/es/lathe/images/radius-4_en.svg

** (inkscape:89794): WARNING **: 21:01:17.814: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.

** (inkscape:89794): WARNING **: 21:01:18.004: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
inkscape -D --export-filename=fig18.png /<<PKGBUILDDIR>>/docs/src/es/config/images/switch-nc-series_en.svg

** (inkscape:89802): WARNING **: 21:01:18.085: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.

** (inkscape:89802): WARNING **: 21:01:18.273: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
item_to_outline: fill path has no segments!
inkscape -D --export-filename=fig19.png /<<PKGBUILDDIR>>/docs/src/es/config/images/switch-no-parallel_en.svg

** (inkscape:89810): WARNING **: 21:01:18.338: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.

** (inkscape:89810): WARNING **: 21:01:18.527: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
item_to_outline: fill path has no segments!
Image 'config/images/p-term.png' not found
Image 'config/images/i-term.png' not found
Image 'config/images/i-term.png' not found
Image 'config/images/p-term.png' not found
Image 'config/images/i-term.png' not found
Image 'config/images/ff2.png' not found
Image 'config/images/output-offset.png' not found
Image 'config/images/calibration-1.png' not found
Image 'config/images/calibration-2.png' not found
Image 'config/images/calibration-3.png' not found
Image 'hal/:images/stepgen-type2-4.png' not found
Image 'hal/:images/stepgen-type5-10.png' not found
Image 'hal/:images/stepgen-type11-14.png' not found
Image 'drivers/images/pico-ppmc-math.png' not found
Image 'drivers/:images/pluto-pinout.png' not found
Image 'ladder/images/ladder_action_load.png' not found
Image 'ladder/images/ladder_action_loadbar.png' not found
Image 'ladder/images/ladder_action_out.png' not found
Image 'ladder/images/ladder_action_load.png' not found
Image 'ladder/images/ladder_action_loadbar.png' not found
Cannot convert 'motion/rv-6sl/rv-6sl-001.jpg' to png
Cannot convert 'motion/rv-6sl/rv-6sl-002.jpg' to png
Cannot convert 'motion/rv-6sl/rv-6sl-003.jpg' to png
Cannot convert 'motion/rv-6sl/rv-6sl-004.jpg' to png
Cannot convert 'motion/rv-6sl/rv-6sl-005.jpg' to png
Cannot convert 'motion/rv-6sl/rv-6sl-006.jpg' to png
Cannot convert 'motion/rv-6sl/rv-6sl-007.jpg' to png
Cannot convert 'motion/rv-6sl/rv-6sl-008.jpg' to png
Cannot convert 'motion/rv-6sl/rv-6sl-009.jpg' to png
Cannot convert 'motion/rv-6sl/rv-6sl-010.jpg' to png
Cannot convert 'motion/rv-6sl/rv-6sl-011.jpg' to png
Cannot convert 'motion/rv-6sl/rv-6sl-012.jpg' to png
Cannot convert 'motion/rv-6sl/rv-6sl-013.jpg' to png
Cannot convert 'motion/rv-6sl/rv-6sl-014.jpg' to png
Cannot convert 'motion/rv-6sl/rv-6sl-015.jpg' to png
Cannot convert 'motion/rv-6sl/rv-6sl-016.jpg' to png
Cannot convert 'motion/rv-6sl/rv-6sl-017.jpg' to png
Cannot convert 'motion/rv-6sl/rv-6sl-018.jpg' to png
Image 'gui/images/tool_estop.png' not found
Image 'gui/images/tool_power.png' not found
Image 'gui/images/tool_open.png' not found
Image 'gui/images/tool_reload.png' not found
Image 'gui/images/tool_run.png' not found
Image 'gui/images/tool_step.png' not found
Image 'gui/images/tool_pause.png' not found
Image 'gui/images/tool_stop.png' not found
Image 'gui/images/tool_optpause.png' not found
Image 'gui/images/tool_zoomin.png' not found
Image 'gui/images/tool_zoomout.png' not found
Image 'gui/images/tool_axis_z.png' not found
Image 'gui/images/tool_axis_z2.png' not found
Image 'gui/images/tool_axis_x.png' not found
Image 'gui/images/tool_axis_y.png' not found
Image 'gui/images/tool_axis_p.png' not found
Image 'gui/images/tool_rotate.png' not found
Image 'gui/images/tool_clear.png' not found
Image 'gui/images/axis-homed.png' not found
Image 'gui/images/axis-limit.png' not found
Image 'gui/images/axis-machineorigin.png' not found
Image 'gui/images/gmoccapy_settings_button.png' not found
Image 'gui/images/tool_estop.png' not found
Image 'gui/images/tool_power.png' not found
Image 'gui/images/tool_run.png' not found
inkscape -D --export-filename=fig20.png /<<PKGBUILDDIR>>/docs/src/es/gcode/images/comp-path_en.svg

** (inkscape:89818): WARNING **: 21:01:18.881: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.

** (inkscape:89818): WARNING **: 21:01:19.070: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
inkscape -D --export-filename=fig21.png /<<PKGBUILDDIR>>/docs/src/es/gcode/images/comp02_en.svg

** (inkscape:89826): WARNING **: 21:01:19.144: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.

** (inkscape:89826): WARNING **: 21:01:19.335: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
inkscape -D --export-filename=fig22.png /<<PKGBUILDDIR>>/docs/src/es/gcode/images/g2_en.svg

** (inkscape:89834): WARNING **: 21:01:19.421: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.

** (inkscape:89834): WARNING **: 21:01:19.612: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
inkscape -D --export-filename=fig23.png /<<PKGBUILDDIR>>/docs/src/es/gcode/images/g2-3_en.svg

** (inkscape:89842): WARNING **: 21:01:19.684: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.

** (inkscape:89842): WARNING **: 21:01:19.875: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
inkscape -D --export-filename=fig24.png /<<PKGBUILDDIR>>/docs/src/es/gcode/images/g76-threads_en.svg

** (inkscape:89850): WARNING **: 21:01:19.966: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.

** (inkscape:89850): WARNING **: 21:01:20.157: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
inkscape -D --export-filename=fig25.png /<<PKGBUILDDIR>>/docs/src/es/gcode/images/eight-holes_en.svg

** (inkscape:89858): WARNING **: 21:01:20.232: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.

** (inkscape:89858): WARNING **: 21:01:20.422: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
inkscape -D --export-filename=fig26.png /<<PKGBUILDDIR>>/docs/src/es/gcode/images/twelve-holes_en.svg

** (inkscape:89866): WARNING **: 21:01:20.501: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.

** (inkscape:89866): WARNING **: 21:01:20.695: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
inkscape -D --export-filename=fig27.png /<<PKGBUILDDIR>>/docs/src/es/gcode/images/g81mult_en.svg

** (inkscape:89874): WARNING **: 21:01:20.768: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.

** (inkscape:89874): WARNING **: 21:01:20.961: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
inkscape -D --export-filename=fig28.png /<<PKGBUILDDIR>>/docs/src/es/gcode/images/g81ex1_en.svg

** (inkscape:89882): WARNING **: 21:01:21.042: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.

** (inkscape:89882): WARNING **: 21:01:21.233: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
inkscape -D --export-filename=fig29.png /<<PKGBUILDDIR>>/docs/src/es/gcode/images/g81ex2_en.svg

** (inkscape:89890): WARNING **: 21:01:21.314: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.
WARNING: Glycin running without sandbox.

** (inkscape:89890): WARNING **: 21:01:21.524: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
inkscape -D --export-filename=fig30.png /<<PKGBUILDDIR>>/docs/src/es/gcode/images/g81_en.svg

** (inkscape:89908): WARNING **: 21:01:21.622: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.

** (inkscape:89908): WARNING **: 21:01:21.813: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
inkscape -D --export-filename=fig31.png /<<PKGBUILDDIR>>/docs/src/es/gcode/images/g81a_en.svg

** (inkscape:89916): WARNING **: 21:01:21.884: Failed to wrap object of type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call a library init() function.

** (inkscape:89916): WARNING **: 21:01:22.075: Failed to wrap object of type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call a library init() function.
Image 'gui/images/gremlin_extents_non-rotated_link.png' not found
Image 'gui/images/gremlin_extents_rotated_30_link.png' not found
Build Master_Documentation.pdf
built-in module xetex registered
building additional files...
checking if compiling is necessary...
the output file doesn't exist
xelatex -interaction=batchmode Master_Documentation.tex
running post-compilation scripts...
Master_Documentation.aux MD5 checksum changed
Master_Documentation.toc MD5 checksum changed
the /tmp/tmp22uk2mg6/Master_Documentation.aux file has changed
xelatex -interaction=batchmode Master_Documentation.tex
running post-compilation scripts...
Master_Documentation.aux MD5 checksum changed
the /tmp/tmp22uk2mg6/Master_Documentation.aux file has changed but no re-run required?
force recompilation (XeTeX engine)
xelatex -interaction=batchmode Master_Documentation.tex
running post-compilation scripts...
no new compilation is needed
running last-compilation scripts...
'Master_Documentation.pdf' successfully built

a2x: deleting /<<PKGBUILDDIR>>/docs/src/es/Master_Documentation.xml
make[2]: Leaving directory '/<<PKGBUILDDIR>>/src'
dh_auto_build: error: cd src && make -j2 docs returned exit code 2
make[1]: *** [debian/rules:61: override_dh_auto_build-indep] Error 25
make[1]: Leaving directory '/<<PKGBUILDDIR>>'
make: *** [debian/rules:43: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess failed with exit status 2
--------------------------------------------------------------------------------

Re: [Emc-developers] Linuxcnc docs search

[andy p. <bod...@gm...>]

On Sat, 1 Aug 2026 at 08:16, Luca Toniolo <lu...@ai...> wrote:
>
> I created a repo in
> https://github.com/LinuxCNC/doc-search as a possible home so the docs
> site can pull searchable docs from trusted org infra rather than my
> personal fork. I think having it under the LinuxCNC organization makes
> more sense, and keeps everything under the same umbrella, waiting for a
> thumbs up to move the project, and then I can hook everything up...

I have no objection.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912

[Emc-developers] Linuxcnc docs search

[Luca T. <lu...@ai...>]

In the https://github.com/LinuxCNC/linuxcnc/pull/4184 thread, Bertho 
directed me to keep the docs search as a separate project, which will 
hook onto an empty div in the current docs topbar, at the moment the 
search post-processor is working in my private repo at 
https://github.com/grandixximo/linuxcnc-doc-search. I created a repo in 
https://github.com/LinuxCNC/doc-search as a possible home so the docs 
site can pull searchable docs from trusted org infra rather than my 
personal fork. I think having it under the LinuxCNC organization makes 
more sense, and keeps everything under the same umbrella, waiting for a 
thumbs up to move the project, and then I can hook everything up...

Re: [Emc-developers] Halcompile constructable and rtapi_app newinst

[andy p. <bod...@gm...>]

On Sun, 26 Jul 2026 at 17:21, Bertho Stultiens <lc...@va...> wrote:

> If nobody is using the construct, then we can change the signature
> without repercussion. Otherwise, we need to have a deprecation period
> and announcement.

I would expect that if anyone is using it then they found it by
looking at the source code, so will probably also know how to fix any
problems.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912

[Emc-developers] [Hosted Weblate] New comment in LinuxCNC/LinuxCNC Documentation

[Américo M. <no...@we...>]

#  Comment added

[ a-monteiro](https://hosted.weblate.org/user/a-monteiro/ "Américo Monteiro"):
[Hosted Weblate](https://hosted.weblate.org) /
[LinuxCNC](https://hosted.weblate.org/projects/linuxcnc/) / [LinuxCNC
Documentation](https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/) /
[English](https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/en/)

## Source string

`DEFAULT_LINEAR_ACCELERATION = 2.0` - In machines with nontrivial kinematics,
the acceleration used for "teleop" (Cartesian space) jogs, in 'machine units'
per second per second.

## Source string description

type: Plain text

## Comment

per second per second.

[Edit this string](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-
docs/en/?checksum=b13ea56485688556#comments)

## Source string location

src/config/ini-config.adoc:860

## Translation Info

| All strings             |  [ 33,994 ](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-docs/en/)                      |                                                                                                 |
|-------------------------|---------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------|
| Translated strings      |  [ 33,994 ](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-docs/en/?q=state:>=translated) |  [ 100% ](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-docs/en/?q=state:>=translated) |
| Untranslated strings    |  [ 0 ](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-docs/en/?q=state:empty)             |  [ 0% ](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-docs/en/?q=state:empty)          |
| Unfinished strings      |  [ 0 ](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-docs/en/?q=state:<translated)       |  [ 0% ](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-docs/en/?q=state:<translated)    |
| Strings marked for edit |  [ 0 ](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-docs/en/?q=is:needs-editing)        |  [ 0% ](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-docs/en/?q=is:needs-editing)     |


[View](https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/en/)

  
[Weblate, the libre continuous localization system.](https://weblate.org/)

Generated on July 28, 2026, 12:03 a.m..

Re: [Emc-developers] [Hosted Weblate] New comment in LinuxCNC/LinuxCNC Documentation

[andy p. <bod...@gm...>]

On Fri, 24 Jul 2026 at 00:26, Américo Monteiro via Emc-developers
<emc...@li...> wrote:

> `MAX_SPINDLE_0_OVERRIDE = 1.0` - The maximum feed override the user may
> select. 1.2 means 120% of the programmed feed rate. On multi spindle machine
> there will be entries for each spindle number. Only used by the QtVCP based
> user interfaces.

Yes, clearly a copy-paste error.
Fixed by: https://github.com/LinuxCNC/linuxcnc/commit/18c5bb5b1cd9ac1e63cc5e40998db712ad8ff50d

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912

Re: [Emc-developers] LinuxCNC and MTconnect Live stream 27 July 2016 11:00am GMT+10:00 (tomorrow)

[Viesturs L. <vie...@gm...>]

svētd., 2026. g. 26. jūl., plkst. 14:40 — lietotājs andy pugh
(<bod...@gm...>) rakstīja:
>
> On Sun, 26 Jul 2026 at 09:37, rodw <ro...@ve...> wrote:
>
> > Brad Collette, Freecad Developer reached out to me and we are holding a podcast style discussion tomorrow about MTconnect which is a standards based method machine tools can share information with other systems. Some of you will know Brad and he has developed Loobric a tool library API discussed here recently.
> > Join us here.   27 July 2016 11:00am GMT+10:00 (tomorrow)
>
> 2026 rather than 2016 I assume?
>
> Unfortunately at 11am on a Monday I am very much at work.
>

It is 11:00AM at GMT+10, so should be 01:00AM at GMT, sounds way more
that very much at sleep around that time :))

Viesturs

Re: [Emc-developers] Halcompile constructable and rtapi_app newinst

[Bertho S. <lc...@va...>]

On 7/26/26 6:04 PM, Nicklas SB Karlsson wrote:
> Instantiate a component from an already loaded module may have some
> advantages.
Yes, but the question is whether someone is or has been using the 
current implementation.

The problem is that the constructor signature is wrong. It uses 'char *' 
instead of 'const char *'. A change ripples through several other files 
and may impact users /if/ the construct is in use.

If nobody is using the construct, then we can change the signature 
without repercussion. Otherwise, we need to have a deprecation period 
and announcement.

-- 
Greetings Bertho

(disclaimers are disclaimed)

Re: [Emc-developers] Halcompile constructable and rtapi_app newinst

[Nicklas SB K. <nk...@nk...>]

ons 2026-07-22 klockan 14:18 +0200 skrev Bertho Stultiens:
> Hi all,
> 
> There is a an option 'constructable' in halcompile that should make it 
> possible to instantiate a component from an already loaded module. The 
> halcmd instruction 'newinst' would then call down to the module via 
> rtapi_app and call the constructor.

Instantiate a component from an already loaded module may have some advantages.

Have several different machines with difference among other things in the number of joints. As is now have to
instantiate all then module is loaded.

If possible to instantiate after loaded and stuff specific for example for a joint is kept within a limited range
of the file preferably enclosed in comments so easy to find. Then I could instantiate components and add them to
a thread within the range specific for this joint.
This may make .hal files easier to read and in particularly to copy and reuse.


Nicklas  Karlsson

Re: [Emc-developers] LinuxCNC and MTconnect Live stream 27 July 2016 11:00am GMT+10:00 (tomorrow)

[andy p. <bod...@gm...>]

On Sun, 26 Jul 2026 at 09:37, rodw <ro...@ve...> wrote:

> Brad Collette, Freecad Developer reached out to me and we are holding a podcast style discussion tomorrow about MTconnect which is a standards based method machine tools can share information with other systems. Some of you will know Brad and he has developed Loobric a tool library API discussed here recently.
> Join us here.   27 July 2016 11:00am GMT+10:00 (tomorrow)

2026 rather than 2016 I assume?

Unfortunately at 11am on a Monday I am very much at work.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912

[Emc-developers] LinuxCNC and MTconnect Live stream 27 July 2016 11:00am GMT+10:00 (tomorrow)

[rodw <ro...@ve...>]

Hi all,
 
Brad Collette, Freecad Developer reached out to me and we are holding a podcast style discussion tomorrow about MTconnect which is a standards based method machine tools can share information with other systems. Some of you will know Brad and he has developed Loobric a tool library API discussed here recently.
Join us here.   27 July 2016 11:00am GMT+10:00 (tomorrow)
https://youtube.com/live/b_S-p2nylr8  
 
 
This is the first time I've done something like this, hopefully I've worked out the technology side.
 
Rod Webster  

[Emc-developers] [Hosted Weblate] New comment in LinuxCNC/LinuxCNC Documentation

[Américo M. <no...@we...>]

#  Comment added

[ a-monteiro](https://hosted.weblate.org/user/a-monteiro/ "Américo Monteiro"):
[Hosted Weblate](https://hosted.weblate.org) /
[LinuxCNC](https://hosted.weblate.org/projects/linuxcnc/) / [LinuxCNC
Documentation](https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/) /
[English](https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/en/)

## Source string

`MAX_SPINDLE_0_OVERRIDE = 1.0` - The maximum feed override the user may
select. 1.2 means 120% of the programmed feed rate. On multi spindle machine
there will be entries for each spindle number. Only used by the QtVCP based
user interfaces.

## Source string description

type: Plain text

## Comment

is this right ? looks to me it's mixing spindle speed with feed rate - some
copy/paste into the wrong string ??

[Edit this string](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-
docs/en/?checksum=c32fb971ba02e9b6#comments)

## Source string location

src/config/ini-config.adoc:266

## Translation Info

| All strings             |  [ 33,994 ](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-docs/en/)                      |                                                                                                 |
|-------------------------|---------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------|
| Translated strings      |  [ 33,994 ](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-docs/en/?q=state:>=translated) |  [ 100% ](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-docs/en/?q=state:>=translated) |
| Untranslated strings    |  [ 0 ](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-docs/en/?q=state:empty)             |  [ 0% ](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-docs/en/?q=state:empty)          |
| Unfinished strings      |  [ 0 ](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-docs/en/?q=state:<translated)       |  [ 0% ](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-docs/en/?q=state:<translated)    |
| Strings marked for edit |  [ 0 ](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-docs/en/?q=is:needs-editing)        |  [ 0% ](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-docs/en/?q=is:needs-editing)     |


[View](https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/en/)

  
[Weblate, the libre continuous localization system.](https://weblate.org/)

Generated on July 24, 2026, 12:40 a.m..

[Emc-developers] Halcompile constructable and rtapi_app newinst

[Bertho S. <lc...@va...>]

Hi all,

There is a an option 'constructable' in halcompile that should make it 
possible to instantiate a component from an already loaded module. The 
halcmd instruction 'newinst' would then call down to the module via 
rtapi_app and call the constructor.

However, the option 'constructable' is not documented in halcompile. The 
'newinst' option to halcmd has been commented out with an #if 0 with the 
comment "newinst deferred to version 2.2". The 'newinst' code is present 
in rtapi_app.


The problem is that the constructor signature is missing "const" in its 
arguments and the rtapi_app call down to HAL uses private internal 
functions. Both can be fixed easily and are already prepared to be 
fixed. There are no in-tree components or code using any of this.

However, out-of-tree code could potentially, however unlikely, use it. 
Therefore, changing any of it is a risk, however small it may be.


So, the question is: Does anybody use 'constructable' components and 
direct calls to rtapi_app with 'newinst' to instantiate components from 
the same module?

-- 
Greetings Bertho

(disclaimers are disclaimed)

Re: [Emc-developers] Or component with configurable number of inputs

[Robert S. <rm...@un...>]

Am Samstag, dem 18.07.2026 um 19:14 +0200 schrieb Nicklas SB Karlsson:
> Had need for an or component with more than two inputs and therefore
> spent most of the day implement one with configurable number of
> inputs
> for instances.

you can use lut5/lut6 to model any boolean function with 5/6 inputs and
one-bit output.


-- 
Robert Schöftner <rm...@un...>