Search Results (Searched for: )
- tykhon
04 Mar 2026 15:15 - 04 Mar 2026 16:46
chineese mesa 7i92 custom bit file was created by tykhon
I`m having some problems with customizing bit file to configure my mesa(clone) board. Previously I used effinity software but it seems that chineese boards running on xilinx base. Unfortunatelly I can`t download xilinx software. Could somebody help me with compiling custom bit? Pinout attached below in custom vhd file
- HM
04 Mar 2026 13:49
RPI5_7i80HDT_7i52s+7i49+7i44+BISS was created by HM
Hello from the new guy!
I want to equip a relatively large machine with LinuxCNC.
For this, I’ve got the 7i80HDT, 7i52s, 7i49, and 7i44 cards.
Unfortunately, I’m struggling to create a suitable PIN file in Efinity.
Is there a description of what a PIN file should look like?
For example, something like “this block is for the 7i52s, … and the following parameters need to be adjusted.”
I would like to work with two configurations.
If possible, I’d prefer both configurations to be achievable with a single PIN file.
RPI5 to 7I80HDT to
- 7I52S Port 3 only needet in configuration 1
o 6xStep/Dir (output)
o 6xEncoder A/B/Z (input)
- 7I49 Port 2 only needet in configuration 2
- 7I44 Port 1
o 4xSS
o 4xBISS-C with 32Bit Port 5-8
Could it be that the FPGA chip on the 7i80HDT is too small for a configuration where all the mentioned cards are addressed?
Wich one should i choose?
Can someone help me with a PIN-File and/or a description?
That way, I might be able to spot my mistakes as a beginner and learn from them.
What is the meaning of "Unassignet Core Pins [2]" in Efinity (in red) is this important?
What is the meaning of "Missing Interface Pins [1]" is this important?
Best regards,
Michael from Austria
I also strugled with the Errors:
ERROR : C:\Efinity\2024.2\project\7i80hdt-alround-7i52-7i49-7i44\configs\hostmot2\source\7i80hdt-hm2\hostmot2_efx.vhd(1623): index 2 is out of array constraint 0 downto 0 for target 'muxedindex' [VHDL-1123]
Filename.hal:24: parameter or pin `hm2_7i80.0.dpll.01.timer-us`not found 2067
solution: www.forum.linuxcnc.org/27-driver-boards/...1-timer-us-not-found
Problem with locale in PNC-Config
solution: forum.linuxcnc.org/39-pncconf/56472-lc-2...n-unsupported-locale
I want to equip a relatively large machine with LinuxCNC.
For this, I’ve got the 7i80HDT, 7i52s, 7i49, and 7i44 cards.
Unfortunately, I’m struggling to create a suitable PIN file in Efinity.
Is there a description of what a PIN file should look like?
For example, something like “this block is for the 7i52s, … and the following parameters need to be adjusted.”
I would like to work with two configurations.
If possible, I’d prefer both configurations to be achievable with a single PIN file.
RPI5 to 7I80HDT to
- 7I52S Port 3 only needet in configuration 1
o 6xStep/Dir (output)
o 6xEncoder A/B/Z (input)
- 7I49 Port 2 only needet in configuration 2
- 7I44 Port 1
o 4xSS
o 4xBISS-C with 32Bit Port 5-8
Could it be that the FPGA chip on the 7i80HDT is too small for a configuration where all the mentioned cards are addressed?
Wich one should i choose?
Can someone help me with a PIN-File and/or a description?
That way, I might be able to spot my mistakes as a beginner and learn from them.
What is the meaning of "Unassignet Core Pins [2]" in Efinity (in red) is this important?
What is the meaning of "Missing Interface Pins [1]" is this important?
Best regards,
Michael from Austria
I also strugled with the Errors:
ERROR : C:\Efinity\2024.2\project\7i80hdt-alround-7i52-7i49-7i44\configs\hostmot2\source\7i80hdt-hm2\hostmot2_efx.vhd(1623): index 2 is out of array constraint 0 downto 0 for target 'muxedindex' [VHDL-1123]
Filename.hal:24: parameter or pin `hm2_7i80.0.dpll.01.timer-us`not found 2067
solution: www.forum.linuxcnc.org/27-driver-boards/...1-timer-us-not-found
Problem with locale in PNC-Config
solution: forum.linuxcnc.org/39-pncconf/56472-lc-2...n-unsupported-locale
- jrstokka
04 Mar 2026 13:48
Replied by jrstokka on topic Catch 22 - PP 2.0.0 thumbdrive does not support MESA 7i92T, PP update blocked
Would love to compare notes. I'm about to do this exact thing. I have an old style PC running Mach 3 on a pcnc 1100-3 conversion. I am buying a standalone pc and ordered the PP usb stick. I tried to find the 7I92 and directed to the 7i92TF only to find out noone has them in stock, about to order the 7i92TM and use a gender bender like you mentioned.
- tommylight
-

04 Mar 2026 13:35
Replied by tommylight on topic 5I20 replacement
No worries, you are welcomed, always.
- billykid
04 Mar 2026 13:14 - 04 Mar 2026 13:21
Replied by billykid on topic 5I20 replacement
Thanks Tom, but I had already seen that they only have three ports and you need four like the 5i20. With the binary switches and tool changer we used three 7i37s and a 7i33 for the analog spindle.
My fault! I wasn't close to the lathe so I couldn't see the model. It's actually a four-port 5i22. Sorry again.
My fault! I wasn't close to the lathe so I couldn't see the model. It's actually a four-port 5i22. Sorry again.
- ClarkSavage
04 Mar 2026 12:42
Replied by ClarkSavage on topic 7i92T and mx3660 request for help
First come in order, we can take it offline or stay on - one at a time.
I am frustrated so will check later. Can go from there. Already ordered a parallel port card for the new computer so we will see. Got to do what I have to in order to get this running.
I am frustrated so will check later. Can go from there. Already ordered a parallel port card for the new computer so we will see. Got to do what I have to in order to get this running.
- jblanscett
04 Mar 2026 12:28
Replied by jblanscett on topic Trying to set up position control mode
I have the first probe connected to the signal and the second probe connected to the mesa ground and the electrical box ground.
- jblanscett
04 Mar 2026 12:14
Replied by jblanscett on topic Trying to set up position control mode
Here is a picture of our oscilloscope readings
- jblanscett
04 Mar 2026 11:39
Replied by jblanscett on topic Trying to set up position control mode
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
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
- ClarkSavage
04 Mar 2026 11:17
Replied by ClarkSavage on topic 7i92T and mx3660 request for help
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?
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?
- Marcos DC
04 Mar 2026 11:12
Replied by Marcos DC on topic Separating CiA402 Logic from EtherCAT (lcec): Modular Adapter + Drive Stub Valid
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
# 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
- Himarc3D
04 Mar 2026 11:07 - 04 Mar 2026 11:10
Replied by Himarc3D on topic Separating CiA402 Logic from EtherCAT (lcec): Modular Adapter + Drive Stub Valid
I have lichuan too
- my1987toyota
04 Mar 2026 10:38
Replied by my1987toyota on topic Just When You Couldn't Hate Government More
But wait there's more.
- DerKlotz
04 Mar 2026 09:03 - 04 Mar 2026 10:52
Replied by DerKlotz on topic Add Buttons in Probe Basic
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]
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]Debug file information:
....
/home/cnc/linuxcnc/configs/Fräse_Probe/probe_basic_postgui.hal:28: Pin 'qtpyvcp.licht.out' does not exist
Failed to load POSTGUI_HALFILE with error: 1
....
[code]
- Marcos DC
04 Mar 2026 06:12
Replied by Marcos DC on topic Separating CiA402 Logic from EtherCAT (lcec): Modular Adapter + Drive Stub Valid
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.
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.
Time to create page: 0.817 seconds