Advanced Search

yeah it';s MIT licensed, not doing the bike shedding thing, if you have PR's for the repo or language lmk !

Heads up this is ALPHA only CODE !!!!! ALPHA !!!!!!!!!! . I sat down this morning and rewrote my initial post. I was tired so here is the edited post containing all my thoughts. NO WARRANTY OR FITNESS IS IMPLIED OR GIVEN USE AT YOUR OWN RISK !!!!! AiLang & Microkernel Architecture for LinuxCNC – License Grant & Technical OverviewBackground & Motivation

What is Ailang ? 

Ailang is a bijective x86 direct to assembler compiled language. It emits elf files directly, does not depend on LLVM GCC CLANG etc. 

github.com/AiLang-Author/AiLang
github.com/AiLang-Author/CoreUtils-

Background & Motivation

I originally built AiLang for my internal AGI and LLM research—it was designed  for low-level systems programming. The problem it solves for LinuxCNC is simple: writing complex HAL components in C with the current RTAPI is a nightmare. You can't use normal control structures (while, sleep, delay, etc.) or blocking calls without risking realtime violations or outright kernel crashes. Anything beyond trivial I/O explodes into hundreds or thousands of lines of manual state counters, one-shot flags, hand-rolled timers, and flood-controlled error messages.The  toolchanger.comp I had to write is the perfect example. Here's what that looks like in practice:Old way (classic .comp):

•  C with manual state counters (count1, count2_5, count4_55...)
• Dozens of separate timers that must be manually reset
• Runs in realtime thread → one mistake crashes the machine
• No sleep(), no while(), no normal control structures
• Debugging = watching 40 cryptic count pins in halscope
• Copy-paste nightmare for every different turret design

New way (AiLang + microkernel):

• Readable, low-level syntax that reads like high level code
• Normal while loops, proper delays, readable state machines
• Runs as normal userspace process → segfault only kills itself
• Full debugging with printf() and standard tools
• Runs in hard realtime with zero Python-style latency penalty
• LLMs can actually generate correct code from the manual + examples

Why AiLang Works Where Others Fail for LLM's and reasoning as a first class design intent not terseness and typing optimization

AiLang was designed from day one with explicit, verbose syntax that's unambiguous for both humans and LLMs—no operator precedence mysteries, no implicit type coercion, no hidden control flow. Every operation is a named function call or a parenthesized infix expression, which means code generation is deterministic and debuggable. That verbosity is the entire point: when an LLM seesAdd(a, b)
or(a + b)
, there's zero ambiguity about what's happening. When you're debugging a toolchanger at 2 AM, that clarity matters. The compiler generates native x86-64 assembly with zero runtime overhead—no interpreter, no VM, no garbage collection. Early benchmarks show AiLang-compiled utilities outperforming GNU coreutils in typical use cases (100-5000 line files, the sweet spot for source code and config files), and this is before any serious optimization work or SSE vectorization. The toolchanger microkernel compiles to an 18 kB binary that runs for days without issues.


Microkernel Architecture for Hal Components The solution: move everything that isn't cycle-critical into normal Linux userspace processes, leaving only a tiny shim in the realtime thread. Here's what's actually running on my bench right now:


HAL_Microkernel daemon (~600 lines AiLang → ~18 kB binary)

• Single persistent userspace process that owns shared memory (/tmp/hal_pins.shm, 4 KB expandable)
• Provides atomic register/read/write of pins from any process with optional change-detection for debugging
• Runs at 1 kHz when idle, 100 µs when active
• No root needed—runs as the linuxcnc user

Realtime shim (~150 lines C, currently in alpha testing)

• Classic LinuxCNC realtime component whose only job is copying HAL pins to/from the microkernel's shared memory at servo-thread rate
• Zero allocation, zero syscalls, zero blocking—completely safe for hard realtime
• Once loaded, the rest of the system can forget RTAPI even exists

Userspace services (normal processes)

• Each complex component (toolchanger, PLC, probe routines, THC, etc.) runs as a normal binary
• Uses standard while(), sleep_us(), timers, file I/O, networking—anything Linux allows
• Communicates with HAL only via shared memory → realtime violations are impossible
• Can be written in AiLang, C, Rust, Python—whatever you want
• Crash recovery: if a service dies, the microkernel and realtime shim keep running; just restart the dead service

What This Means for the LinuxCNC Ecosystem


This isn't just about toolchangers. The microkernel architecture fundamentally changes what's possible:

• Complex logic becomes maintainable - Write a 2000-line component without fear of taking down motion
• Multiple independent services - Run toolchanger + PLC + remote panel + logging simultaneously without fighting over the realtime thread
• LLM code generation - The deliberately verbose syntax means modern LLMs can actually generate correct, working components when fed the manual and examples
• Built-in debugging - AiLang has native debug primitives (Debug, DebugPerf, the other debug features are not yet fully implemented in the compiler) that compile to zero overhead in production but give you full visibility during development
• Easier debugging - Standard printf(), gdb, valgrind—all the normal tools work
• Safer experimentation - Userspace crashes don't kill the machine
• Performance - Native compiled code with minimal overhead; typical operations faster than scripting languages by orders of magnitude
• Long-term vision - Once this is proven stable, the motion backend itself could be rewritten in this architecture

Test code is running on my bench simulating my  Cincinnati 6-position turret that previously required A nightmare C now runs in  readable AiLang as a normal userspace service, with a reactive hardware simulator driving full bidirectional cycles with realistic timing and fault injection.


Documentation:

AiLang ships with 22 full reference manuals covering roughly 90% of language features. If you can read normal programming docs, you can start writing useful LinuxCNC components on day one. Here's what's covered:

Core Language Features:

• Arithmetic & Math Operations - Dual syntax support (both function calls and infix operators), full bitwise operations, compiler-level math primitives (ISqrt, Abs, Min/Max) implemented as optimized assembly
• Flow Control - Three-tier documentation from beginner to advanced, proven patterns for 30-level deep recursion at 3 million calls, state machines, pipelines, and ring buffers
• Functions & SubRoutines - Clear distinction between value-returning Functions and side-effect SubRoutines, full calling convention docs, performance considerations

Memory & Data:

• Memory Management - Four specialized pool types (FixedPool for globals, DynamicPool for growable collections, TemporalPool for scoped allocations, LinkagePool for structured data), direct heap control with Allocate/Deallocate, zero garbage collection overhead
• Arrays - Built-in fixed-size arrays as compiler primitives with O(1) access, detailed memory layout documentation, plus library dynamic arrays when you need auto-resize
• LinkagePool (Structured Data) - Type-safe field-based access, automatic null-checking, supports integers and strings, perfect for passing complex data between functions

System Programming:

• Unix/Linux Syscall API - Complete coverage of process management (fork, exec, wait, kill), IPC (pipes), time functions, with real syscall numbers and register usage documented
• Advanced Patterns - Working examples of ring buffers, state machines, producer-consumer, memory pools, all tested in production code

Developer Experience:

• Built-in Debugging - Native debug primitives compile conditionally (zero overhead when disabled), DebugAssert for safety, DebugTrace for execution flow, DebugPerf for performance profiling, DebugMemory for leak detection
• Getting Started Guide - Practical introduction with working examples, common patterns, compilation instructions

The manuals aren't just API references—they include exact byte layouts, register allocations, assembly patterns, performance characteristics, and real-world examples. Flow-control docs alone span beginner guides through stress-test documentation proving 30-level recursion at three million calls. Memory docs provide exact byte layouts for every pool type plus decision matrices for choosing the right one.License Grant

Git hub page, all linuxcnc specific code is MIT licensed

github.com/AiLang-Author/LinuxCNC-HAL-Component-Redesign


Effective immediately, the LinuxCNC project has a perpetual, irrevocable, royalty-free license to AiLang and the entire compiler toolchain for use in LinuxCNC and related open-source efforts. If anyone needs a signed/notarized hard copy for official records, let me know the correct contact channel.For individual use: hobby, education, private, and non-commercial use is freely permitted. Non-profits and research institutions are welcome—contact me for a written license to keep everything clear (copyright remains with my estate).Current Status

• Microkernel daemon: stable under load, runs for days without issues
• Toolchanger logic: Tech Demonstrator, full bidirectional cycles with fault injection pass in simulation
• Realtime shim: alpha testing (~150 lines C, nearly complete)
• Hardware validation: Next step is testing on actual machine hardware
• Known limitations: Pin collision detection not yet implemented (coming soon)

The userspace components (microkernel, toolchanger services) are running in simulation. The shim is one of many pieces being validated. Once sufficient testing is complete, any machine with a modern kernel (PREEMPT-RT or 6.1+ mainline) can run complex components with zero risk to motion. Examples (microkernel, toolchanger, and test harness) are all in the repo. The simulation works. Multiple component validation is the next milestone.

I have attached a zip file with my current working code, the ailang compiler is very easy to use. If you have any questions post them up this is the first public disclosure of the language I have made. Feedback welcome. 

It's more constructive trying to converse with an inanimate object than you Master Langdon's.

Design done, first one in the works, I put some limited earlybird preorders up, wont be too many of those. Just want to iron out the process before it goes full on for sale. This should be fun.

Hello Lcvette,
Thanks for your time and ideas!

The motor on the Y axis is a JMC iHSSC60-36-35-21-38-POCA. The manual says the pulse and pause should not be shorter than 2.5 µs; I have set this in the .ini file to 2,500 ns. This worked fine until now. Today, I changed this to 4000 ns, thinking it would be safer. After that change, an error occurred: 'stepgen.01.maxvel is too big for current step timings and position scale; clipping to maximum possible', so I reduced my Vel settings to 100 mm/s and 125 for overhead. This means that I cannot drive the axis at 7.5 m/min as before, but only at 6 m/min. I would accept this if the axis runs correctly afterwards. I will check this tomorrow.
Indeed, I change the motor-spindle gear in the X-axis a while ago to 20/32 teeth, which gives me a 640-step scale on the X-axis. This is not 1:2 as in the Y-axis, but 1:1.25.
My motor settings are 2000 steps/rev, which is not a problem for the motor or LCNC. The motor can run up to a frequency of 200 kHz, but I did tests with an oscillator and found the limit to be 180 kHz. So, 4000 ns will be safer.
Could the motor be losing steps at the shorter 2500 setting? I mean, it's a closed-loop motor that corrects lost steps. I changed to this motor from a 400 W OMC servo motor to check whether the motor and parametric settings were at fault with regard to my dimensions. That is not the case, as I can see. So I will go back to the servo if I get the problem solved.
The motor settings, especially the step scale, are correct; I measured them and found no deviations on a 400 mm straight line on a steel scale. Straight cuts were very accurate before. The problem was elliptical deviations when cutting circles.

OK, I will do another test cut tomorrow and report back.

Thanks, and have a good Friday!

Hanno

Isn't there a component that creates the command position = position read by the transducer?

LinuxCNC does this (sets commanded position to actual position) when motion is disabled, but it's global (all joints)
It might require a modification of LinuxCNCs motion component to do this correctly on a joint by joint basis

I haven't used my gmoccapy lathe installation for perhaps 18 months due to working on other machines. At last use I was having problems with Andy Pugh's macros (something to do with needing Python 3?) and I'd struggled to finally get it to the point of working as it was (some problem with the RT kernal, which I had to change).

Although I haven't changed anything in the meantime, when I try to run gmoccapy, I now get errors and it bombs out. It seems to be something to do with the 5i25 possibly not loading if I understand the error message.

I'm planning to install the latest version of Linuxcnc and gmoccapy, so I'm not actually focusing on trying to rectify the above problem but the report file lists some of the components installed in the current system.

My question is - if I create a fresh Linux / Linuxcnc installation, what else would I need to port across to get it running? I'm thinking the hal and ini files for starters but is there anything else? Furthermore, are there any additional entries I'd need to put in the files? I think I saw a post mentioning some graphics-related additions to the ini or hal files when I was trawling through the forum yesterday but obvs I can't find it again. It's possible it was actually in the Probe Basic area of the forum - a version I previously set up but decided to stick with gmoccapy.

I'd be very grateful for any guidance to point me in the right direction!


 

The are not Inovance, they are Jssmotors, as you can see in this link:

www.jssmotor.com/servo-system

That worked well. Currently, I'm just testing that the electronics are working; the hardware isn't connected yet, so scaling isn't realistic. What is working is the C-axis and the M commands for spindle movement. The stepper motors are also moving as they should. There are still problems with the M19 command (the servo might be trying to reach a position too quickly, which isn't possible). I'm also checking that the C-axis is working reliably. Currently, there are still problems switching from M3 to S500 for a short time after the C-axis. The servo goes into overload because it seems to be trying to reach a position too quickly, which isn't possible.

Can see the results but no way to vote as unknown said.

Is everything else the same? Same OS same kernel?

It wouldn't expect anything to have changed, the release notes are here, and I don't think that motion was touched.

github.com/LinuxCNC/linuxcnc/blob/2.9/debian/changelog

If you _could_ try 2.9.5 that would eliminate some changes from the list of possibilities.

now I deleted everything related to python, in the ini I only added remap=m6 modalgroup6 ngc=toolchange
subroutine path to the folder where my toolchange.ngc is, if I type in mdi T1 m6 or o<toolchange> call I get an error like in the picture- 

my ngc is:

o<toolchange> sub
M73

; --- unload current tool ---
IF [#<_current_pocket> GT 0] THEN

```
IF [#<_current_pocket> EQ 1] THEN G0 X0 Y-80 Z-120 ENDIF
IF [#<_current_pocket> EQ 2] THEN G0 X0 Y-191 Z-120 ENDIF
IF [#<_current_pocket> EQ 3] THEN G0 X0 Y-302 Z-120 ENDIF
IF [#<_current_pocket> EQ 4] THEN G0 X0 Y-619 Z-120 ENDIF
IF [#<_current_pocket> EQ 5] THEN G0 X0 Y-730 Z-120 ENDIF
IF [#<_current_pocket> EQ 6] THEN G0 X0 Y-841 Z-120 ENDIF

M62 P0       ; LOCK
M64 P1       ; CLAMP
G4 P0.5      ; lock dwell
M65 P1       ; unclamp
```

ENDIF

; --- load new tool ---
IF [#<_selected_pocket> EQ 1] THEN G0 X0 Y-80 Z-120 ENDIF
IF [#<_selected_pocket> EQ 2] THEN G0 X0 Y-191 Z-120 ENDIF
IF [#<_selected_pocket> EQ 3] THEN G0 X0 Y-302 Z-120 ENDIF
IF [#<_selected_pocket> EQ 4] THEN G0 X0 Y-619 Z-120 ENDIF
IF [#<_selected_pocket> EQ 5] THEN G0 X0 Y-730 Z-120 ENDIF
IF [#<_selected_pocket> EQ 6] THEN G0 X0 Y-841 Z-120 ENDIF

M64 P0
M64 P1
G4 P1.0
M65 P1
M65 P0
G4 P0.5

G0 X0 Y0 Z0

o<toolchange> endsub
M2

I, too, only see the results, the initial announcement, and a banner that says "You cannot reply to this topic".  I'm not a mod either.  I wonder if ability to reply is tied to ability to vote?
 

Hi Have 1995 Tsugami Swiss that I converted over to.
Linuxcnc, ClearPath, Mesa 6i25,7i76,7i85 closed loop on 1 micron scales.

LinuxCNC going back as far as 2.7 which was tested up to 300 inches a minute.
(Which was too fast for me.)

Never had a problem running 180 inches a minute until 2.9.7 update
Now I can't get more than 130 inches a minute without getting joint errors.
I get  180 inches a minute on LinuxCNC 2.10-pre0 on Mint 22.1 
LinuxCNC 2.9.4 runs  just fine as well.

I never upgraded to 2.9.5 or 2.9.6 but I have used the same config going back to 2.8
Anyone else seeing this?
 

Thanks for the replies.
The solution of increasing the tracking value and resetting the axis is impractical and technically incorrect.

The servos are analog and controlled by Mesa boards.
Isn't there a component that creates the command position = position read by the transducer?
Or is there a way to modify the Trivkins kinematics?