Advanced Search

I'm preparing a small repository for this. The current README draft describes the structure I'm experimenting with.
# linuxcnc-cia402-layer

Vendor-agnostic CiA402 (DS402) semantic layer for LinuxCNC.

Status: experimental reference implementation
Target: LinuxCNC HAL architecture
Focus: deterministic CiA402 semantic separation
License: MIT

This project provides a clean separation between drive semantics,
machine policy and fieldbus transport for CiA402 devices in LinuxCNC.


---

# Overview

This project implements a deterministic HAL architecture that separates:

- Power Drive System (PDS) state machine (6040 / 6041)
- Procedure layer (homing / operation handshake)
- Deterministic controlword composition
- Machine-level safety policy
- Fieldbus adapters (EtherCAT / CANopen / etc.)

The goal is to validate CiA402 semantics in a clean and deterministic way
before involving real fieldbus hardware.

The semantic layer is designed to remain:

- drive-agnostic
- fieldbus-agnostic
- reusable across different servo drives


---

# Motivation

Many CiA402 integrations inside LinuxCNC mix together:

- fieldbus communication
- drive state logic
- machine safety policy
- procedure logic

inside a single component.

This makes systems harder to:

- debug
- validate
- reuse
- maintain

This project separates these responsibilities into clear HAL layers.


---

# Safety Notice

This project provides software-level safety behavior such as:

- controlword gating
- quick stop policy
- fault handling
- machine enable supervision

However, it **does NOT replace hardware safety systems** such as:

- physical E-stop circuits
- STO (Safe Torque Off)
- safety PLC
- certified safety devices

Always implement proper hardware safety according to applicable safety standards.


---

# Architecture Overview

The architecture ensures that machine-level safety always has authority
over drive-level state machines.


Machine Safety Policy
│
▼
safety_gate.comp
│
▼
pds_manager.comp
│
▼
procedure layer (c402hu)
│
▼
cw_compose.comp
│
▼
Fieldbus Adapter (LCEC / CANopen)
│
▼
Drive


LinuxCNC motion interacts with the drive through the semantic layer.


---

# Core Components (Drive-Agnostic)

## safety_gate.comp

Machine-level safety policy.

Responsibilities:

- integrates with halui
- supervises machine enable state
- supervises E-stop state
- blocks procedures when unsafe
- overrides controlword when required

Typical policies:

- Machine OFF → Disable Voltage
- E-stop → Quick Stop
- Fault → block enable until reset

The safety gate sits **above the PDS layer** to guarantee machine authority.


---

## pds_manager.comp

Implements the CiA402 Power Drive System state machine.

Responsibilities:

- decode statusword (6041)
- generate base controlword (6040)
- track DS402 states
- expose HAL signals

Outputs include:

- op_enabled
- fault
- decoded state
- debug mask patterns
- cw_pds


---

## c402hu.comp (Procedure Layer)

Procedure management for CiA402 operations.

Handles:

- mode request (6060)
- mode confirmation (6061)
- homing start generation
- completion detection
- error detection

Responsibilities:

- manage operation sequences
- latch completion states
- detect abnormal conditions

All procedures are gated by:


ut.enable


which is typically controlled by the safety gate.


---

## cw_compose.comp

Single source of truth for the final controlword (6040).

Responsibilities:

- combine PDS controlword
- combine procedure bits
- apply safety overrides

Typical composition:


cw_final = cw_pds | procedure_bits


Safety overrides may replace this value when required.


---

# Coupler (Decouple / Recouple)

Planned component:


coupler.comp


Purpose:

Allow drives to perform internal motion (such as homing)
without creating position jumps in LinuxCNC.

Responsibilities:

- temporarily decouple motion feedback
- follow drive position during internal motion
- recouple after completion

Typical use cases:

- drive-based homing
- drive internal motion procedures
- avoiding position discontinuities


---

# Gantry Support

Future component:


gantry_manager.comp


Possible responsibilities:

- synchronized homing of multiple drives
- gantry squaring
- position difference monitoring
- safe recoupling after homing

This allows coordination of multiple CiA402 drives
in gantry machines.


---

# Fieldbus Adapters

Adapters are intentionally simple.

Example:


adapters/adapter_TEMPLATE.hal


Responsibilities:

- map fieldbus objects to semantic layer pins

Typical mapping:

- 6040 → drive controlword
- 6041 → statusword
- 6060 → mode of operation
- 6061 → mode display
- 6064 → position actual
- 607A → position command

Adapters should contain **no logic**.

They only wire fieldbus data to the semantic layer.


---

# Repository Layout


src/
safety/
safety_gate.comp

pds/
pds_manager.comp

procedure/
c402hu.comp

controlword/
cw_compose.comp

coupler/
coupler.comp

gantry/
gantry_manager.comp

adapters/
adapter_TEMPLATE.hal

sim/
cia402_stub.comp
opc_validation.hal

docs/
architecture.md



---

# Validation Approach

The semantic layer was initially validated using LinuxCNC AXIS simulation.

Simulation includes:

- CiA402 stub drive
- statusword generation
- homing procedure testing
- fault injection

This allows deterministic validation before connecting real hardware.


---

# Current Project Status

Validated:

- PDS state decoding
- deterministic controlword composition
- mode handshake (6060 / 6061)
- homing start/done detection
- fault handling behavior
- operation enabled gating

In progress:

- safety gate implementation
- drive motion decouple / recouple
- gantry synchronization logic
- EtherCAT adapter validation


---

# License

MIT License

Copyright (c) 2026
Marcos Duque Cesar


---

# Project Goal

Provide a clean reference implementation of CiA402 semantics for LinuxCNC HAL that is:

- deterministic
- reusable
- independent of fieldbus drivers
- suitable for different servo drives

I have lichuan too

But wait there's more.

After some days of trial and error i don´t know further

I created a button "Licht" in QtPyVCP. This light button should switch on my hm2_7i76e.0.7i76.0.0.output-02 from my Mesa 7i76e. In my probe_basic_postgui.hal and tried to implement this function with no success. See postgui Liine 28 and 29.

In addition it would be nice when the "Licht" button is read when off and turns into green when on. The Power on button in the basic GUI turns into green when on.
 

[/code][/code]

Hi nwe,

That would be extremely helpful, thank you for offering to test.

No rush at all if it takes a couple of days — I will actually be working in the field for the next two days doing maintenance for a client. When I get back, I plan to implement the safety gate component and the decouple/recouple logic, so the timing works out well.

To prepare proper adapter templates for your two drives (the Lichuan OL57E-4A and the Stepperonline A6-750EC), I just need a few details from your setup so I can map the HAL pins correctly.

If possible, could you share:
1. Your LCEC configuration
• lcec.conf (or equivalent configuration file)
• The EtherCAT XML/ENI if you have it
• Or a snippet of the HAL where the lcec.* pins for the drives appear
2. PDO mapping
I mainly need to confirm the HAL pins for the standard CiA402 objects:
• 6040 Controlword
• 6041 Statusword
• 6060 Modes of Operation (command)
• 6061 Modes of Operation Display
If available in PDO as well:
• 6064 Position Actual Value
• 607A Target Position
3. Homing
• Which homing method (object 6098) you plan to use
• Whether the homing/limit switches are connected to the drive inputs
• The HAL pin names for those inputs (for example lcec.*.din-*)
4. Quick Stop
• Is Quick Stop (Controlword 0x0002) configured and usable on these drives?
• Or do they require a different shutdown sequence?
5. Anything unusual
• Any known quirks with enable, fault reset, or homing behavior.

With that information I can prepare two adapter templates (one for each drive) that plug into the CiA402 semantic layer we validated in simulation.

Thanks again for offering to test — having real hardware feedback will be extremely valuable.

thats pretty negligible to what i have. mine is far far worse. will share as soon as i get to my shop.

This issue originated from LinuxCNC and occurred nine times within ~30 minutes.

not sooo bad

not knowing how you print your message but how much of your main loop taken up by printing your message? It might not be as bad as you think.
Maybe an exercise for halstreamer?

Ja der alte Motor ist bereits Entsorgt. Ich war Überrascht über seine Leichtgängigkeit und seinem geringen Gewicht. Für das Alter. Hab ich mir anders vorgestellt. Ja der neue Servo hat selbstverständlich einen Encoder. Ich werde mal sehen was das Umkehrspiel sagt. Aber Früher hat es ja auch funktioniert. Wieso jetzt nicht mehr? Für gröbere Arbeiten sollte es nach wie vor reichen.

The" bitslice" hal component is one way.

 

Is there a way to extract a specific bit from a hexadecimal value? The VFD I'm using indicates the state with a 16-bit hexadecimal value, and therefore I need to extract that bit to use it within my configuration.

So we have wound up with a simple little 3 axis cartesian robot. Robot basically has a spindle taper and air powered gripper, and then hands off to a switcher arm that will be moved by the little robot with a roller cam. 





I will probably build this in april, then we can see if it can live inside the master linuxcnc or needs a separate controller.

So the run down:

- X, Y, Z linear motion.
- gripper air cylinder.

1: Robot on its own goes to grab the next tool needed by the machine, and places it in the arm SLOT A
2: M6 Tx called
3: Robot uses cam to move arm out into position. Door opens on the same linkage (we could also do this with air)
4: Machine moves to tool change arm and places the tool in SLOT B
5: Then it grabs the tool in SLOT A and moves away from the arm

Basically the main control sees the atc as a stationary rack type with only 2 tools

6: The arm retracts in and door closes
7: Machine resumes cutting
8: The robot takes the tool from SLOT B and puts it back in the right pocket
9: Robot grabs the next tool in the program and we repeat everything again

Make sense?

The new version of qtdragon at github.com/persei802/QtDragon_hd has the ability to semi-automate tool measurements. I'm open to suggestions for improvements.
Jim

setp [HMOT](CARD0).stepgen.00.control-type 0

Is wrong, it should be:

setp [HMOT](CARD0).stepgen.00.control-type 1

(for all joints)

 

clem wrote:

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

www.jssmotor.com/servo-system

You are absolutely right.  Earlier post edited - thanks.