Advanced Search

I have the first probe connected to the signal and the second probe connected to the mesa ground and the electrical box ground.

Here is a picture of our oscilloscope readings

Hi Tommy and PCW,

Tommy, I will grab our scope and let you know what the signal looks like as soon as possible. I commented out the acceleration fraction line. 

PCW, when I changed the control type to 1. In order to get any motion afterwards, I had to change 

net x-output   <= [HMOT](CARD0).stepgen.00.postion-cmd

to

net x-output   <=[HMOT](CARD0).stepgen.00.velocity-cmd

Then, no matter what value I change the P value to, as soon as an input is put in, the motor starts and doesn't stop. If I add more inputs going in the same direction, the motor speeds up. If I add them in the other direction, the motor slows down. 

Thanks,

jblanscett

Understood. I have stated - my Stepconf [before 7i92] setup has run for more than ten years. My setup has limit switches at both ends of travel on all axis, and used a shared home/limits setup.EG - old setup:#*** AXIS_X *******************************
MIN_LIMIT = -0.25
MAX_LIMIT = 36.5
[JOINT_0]
HOME = 0.0
MIN_LIMIT = -0.25
MAX_LIMIT = 36.5
HOME_OFFSET = -0.750000
HOME_SEARCH_VEL = -1.100000
HOME_LATCH_VEL = -0.40000
HOME_IGNORE_LIMITS = YES
HOME_SEQUENCE = 1
#******************************************

NEW setup:

#******************************************
[AXIS_X]
MAX_VELOCITY = 3.0
MAX_ACCELERATION = 2.0
# MAX_VELOCITY = 5.0
# MAX_ACCELERATION = 7.0
MIN_LIMIT = 0.00
MAX_LIMIT = 32.0

[JOINT_0]
TYPE = LINEAR
# increased home position to get it for sure out of too close to switch
HOME = 1.0
FERROR = 10.0
MIN_FERROR = 0.05
MAX_VELOCITY = 3.0
MAX_ACCELERATION = 2.0
# MAX_VELOCITY = 5.0
# MAX_ACCELERATION = 7.0
# The values below should be 25% larger than MAX_VELOCITY and MAX_ACCELERATION
# If using BACKLASH compensation STEPGEN_MAXACCEL should be 100% larger.
STEPGEN_MAXVEL = 6.25
STEPGEN_MAXACCEL = 8.75
P = 1000.0
I = 0.0
D = 0.0
FF0 = 0.0
FF1 = 1.0
FF2 = 0.0
BIAS = 0.0
DEADBAND = 0.0
MAX_OUTPUT = 0.0
# these are in nanoseconds
DIRSETUP   = 10000
DIRHOLD    = 10000
STEPLEN    = 5000
STEPSPACE  = 5000
STEP_SCALE = -1016.0030642800001
MIN_LIMIT = 0.0
# note here I have limited the travel just to keep the far limit out of the picture
MAX_LIMIT = 32.0
HOME_OFFSET = -0.118
HOME_SEARCH_VEL = .5
HOME_LATCH_VEL = .5
HOME_FINAL_VEL = .5
HOME_USE_INDEX = NO
HOME_IGNORE_LIMITS = YES
HOME_SEQUENCE = 2
#******************************************

Still get an error "joint out....." AFTER homing

 I have setup / changed the numbers per instruction - such as the negative 0.118 [comparable to the 3mm mentioned I should use] and so on following the Linuxcnc diagram below as always.

  I may be thick here - which is why I am asking for help. Feel like I am just missing something or something is missing me! I just don't get it. Willing to do anything. I would have thought this would be simple compared to everything else, but here I am weeks later getting ready to go back to parallel port as a last gasp.Still do not have feedback from the ESTOP either - wired to the mx3660 in NC config - same as limit switches.Sorry - but ?

$100 to anyone that can solve my ESTOP & Shared/home limits else I need to jump back to parallel port or some other os. After all - this should be the simple part - right?  

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.