Search Results (Searched for: )
- tar_san
17 Feb 2026 01:12 - 17 Feb 2026 02:02
Replied by tar_san on topic Ver 2.9.4 iso clean install Trouble when disabling EOE
Thank you so much.
Now I installed LinuxCNC to PC (HP Elite 800 G4 with Intel LAN) using 2.9.4 iso,
I did recompile EOE disable along to the procedure, I did not upgrade,
but I could not improve my bad situation in using Yaskawa Drive.
I found ...something strange.
Ethercat service starts automatically,and ethercat slaves works after reboot.( "ehtercat slaves " shows all servo drives )
But I have to do this command to execute LinuxCNC everytime after reboot.
chmod 666 /dev/EtherCAT0
but If I did this, LinuxCNC doesnot handle Yaskawa servo propery (A12).
And also, in Network Connection (in "TASKBAR on the top of Desktop") I could see a NIC Interface that I'm using for "EtherCAT".( see attachment jpeg image)
What am I missing ? What should I check ?
Now I installed LinuxCNC to PC (HP Elite 800 G4 with Intel LAN) using 2.9.4 iso,
I did recompile EOE disable along to the procedure, I did not upgrade,
but I could not improve my bad situation in using Yaskawa Drive.
I found ...something strange.
Ethercat service starts automatically,and ethercat slaves works after reboot.( "ehtercat slaves " shows all servo drives )
But I have to do this command to execute LinuxCNC everytime after reboot.
chmod 666 /dev/EtherCAT0
but If I did this, LinuxCNC doesnot handle Yaskawa servo propery (A12).
And also, in Network Connection (in "TASKBAR on the top of Desktop") I could see a NIC Interface that I'm using for "EtherCAT".( see attachment jpeg image)
What am I missing ? What should I check ?
- Lcvette
17 Feb 2026 00:47 - 17 Feb 2026 00:49
Replied by Lcvette on topic Add Buttons in Probe Basic
You can add to the user tab and turn it on in the initial file, this is covered in the docs
kcjengr.github.io/probe_basic/update_notes.html
kcjengr.github.io/probe_basic/update_notes.html
- tuxcnc
17 Feb 2026 00:06
Replied by tuxcnc on topic EtherCAT driver as simply positioner
I can't use PP mode, but I found solution for CSP mode:
Code:
#!/bin/bash
halcmd setp lcec.0.0.opmode 6
halcmd setp lcec.0.0.controlword 6
halcmd setp lcec.0.0.controlword 7
halcmd setp lcec.0.0.controlword 15
halcmd setp lcec.0.0.controlword 31
# sleep value must be greater than maximum homing time
sleep 5
halcmd setp lcec.0.0.target-position 0
halcmd setp lcec.0.0.opmode 8
halcmd setp lcec.0.0.controlword 6
halcmd setp lcec.0.0.controlword 7
halcmd setp lcec.0.0.controlword 15
for i in {1000..100000..1000}
do
halcmd setp lcec.0.0.target-position $i
sleep 0.01
done
exit 0
- Marcos DC
16 Feb 2026 23:40
Replied by Marcos DC on topic Technical questions about CIA402 and homecomp.comp on A6
@Andrax, first of all: thanks for sharing your examples — it’s clear you’re on the right track, especially by thinking in terms of watchdogs and by splitting the sequence into “start → run → done”. That’s already more than many integrations do.
Just for context: I come more from the Mechatrolink / Yaskawa world, but at the motion-control architecture level the concepts are the same (state machines, ACK semantics, watchdogs, reference sync, etc.), so I’m looking at this more from that angle than from any specific CiA-402 detail.
Looking at your two snippets together, it feels like each one gets an important part right:
In the cia402_homecomp (C) version you already have a proper state machine with timeouts (start_timeout / run_timeout), which is exactly the kind of safety supervision you want in an industrial setup to avoid waiting forever for a drive.
In the pseudo-PLC example you’re already trying to tie the logic to real drive signals (bits from 0x6041, speed, etc.), which is also exactly the right direction.
Where they still feel a bit “misaligned” to me is this:
The cia402_homecomp does have watchdogs, but it’s not really driven by the drive’s real status (it relies on cia-homed / cia-error coming from outside, and doesn’t directly check “started / motion / done” conditions itself).
The pseudo-PLC tries to use real status, but the start and motion proof parts are still fragile (e.g. setting bit 4 = 1 doesn’t guarantee a rising edge, and comparing target speed <> actual speed isn’t a very robust proof that motion really started).
From an industrial point of view, the sequence usually looks roughly like this (independent of whether it’s EtherCAT, Mechatrolink, Sercos, etc.):
Generate a start event (pulse or temporary level, depending on the drive), not just keep the bit stuck at 1 forever.
First watchdog: after start, wait for either a real “homing started” indication or a real proof of motion (position change / actual velocity > threshold). If that doesn’t happen within X seconds → fault.
Second watchdog (overall): while homing is running, wait for the real “done” indication from the drive. If it exceeds the overall timeout → fault.
On completion: clear the start and synchronize the reference (pos_cmd with pos_fb) to avoid jumps / following errors when going back to CSP.
So in a way, the idea in your first code (state machine + timeouts) is right, and the idea in your second one (looking at real 0x6041 bits / real behavior) is also right — what’s missing is bringing those two together: a state machine whose transitions are driven by real drive status and real motion, not only by logical external signals.
One small additional point from an industrial perspective: in your C example a homing fault ends up triggering a global E-STOP. In many systems we try to separate those two concepts: a homing/process fault usually leads to an axis fault or a controlled stop/disable of that axis, while E-STOP is reserved for real safety events. That separation often makes diagnostics and recovery much cleaner, while still keeping the safety chain intact.
This is not meant as criticism of what you’ve done — on the contrary, it’s pretty clear you’re already thinking in exactly the right direction (watchdogs, states, safety). It’s more about aligning it with what is usually done in industrial integrations:
start as an event → real confirmation that it started → real confirmation that it finished → reference synchronization.
If we can move cia402_homecomp more in that direction (even if via masks/config per drive), I think it would solve a big part of the homing and mode-switching issues people are running into.
Just for context: I come more from the Mechatrolink / Yaskawa world, but at the motion-control architecture level the concepts are the same (state machines, ACK semantics, watchdogs, reference sync, etc.), so I’m looking at this more from that angle than from any specific CiA-402 detail.
Looking at your two snippets together, it feels like each one gets an important part right:
In the cia402_homecomp (C) version you already have a proper state machine with timeouts (start_timeout / run_timeout), which is exactly the kind of safety supervision you want in an industrial setup to avoid waiting forever for a drive.
In the pseudo-PLC example you’re already trying to tie the logic to real drive signals (bits from 0x6041, speed, etc.), which is also exactly the right direction.
Where they still feel a bit “misaligned” to me is this:
The cia402_homecomp does have watchdogs, but it’s not really driven by the drive’s real status (it relies on cia-homed / cia-error coming from outside, and doesn’t directly check “started / motion / done” conditions itself).
The pseudo-PLC tries to use real status, but the start and motion proof parts are still fragile (e.g. setting bit 4 = 1 doesn’t guarantee a rising edge, and comparing target speed <> actual speed isn’t a very robust proof that motion really started).
From an industrial point of view, the sequence usually looks roughly like this (independent of whether it’s EtherCAT, Mechatrolink, Sercos, etc.):
Generate a start event (pulse or temporary level, depending on the drive), not just keep the bit stuck at 1 forever.
First watchdog: after start, wait for either a real “homing started” indication or a real proof of motion (position change / actual velocity > threshold). If that doesn’t happen within X seconds → fault.
Second watchdog (overall): while homing is running, wait for the real “done” indication from the drive. If it exceeds the overall timeout → fault.
On completion: clear the start and synchronize the reference (pos_cmd with pos_fb) to avoid jumps / following errors when going back to CSP.
So in a way, the idea in your first code (state machine + timeouts) is right, and the idea in your second one (looking at real 0x6041 bits / real behavior) is also right — what’s missing is bringing those two together: a state machine whose transitions are driven by real drive status and real motion, not only by logical external signals.
One small additional point from an industrial perspective: in your C example a homing fault ends up triggering a global E-STOP. In many systems we try to separate those two concepts: a homing/process fault usually leads to an axis fault or a controlled stop/disable of that axis, while E-STOP is reserved for real safety events. That separation often makes diagnostics and recovery much cleaner, while still keeping the safety chain intact.
This is not meant as criticism of what you’ve done — on the contrary, it’s pretty clear you’re already thinking in exactly the right direction (watchdogs, states, safety). It’s more about aligning it with what is usually done in industrial integrations:
start as an event → real confirmation that it started → real confirmation that it finished → reference synchronization.
If we can move cia402_homecomp more in that direction (even if via masks/config per drive), I think it would solve a big part of the homing and mode-switching issues people are running into.
- andrax
16 Feb 2026 21:42
Replied by andrax on topic Error combining cutter compensation (G41/42) with work offset (G55)
No, G40 must come first.A change is only possible without tool compensation.
G40
...
G52
G40
...
G52
- tuxcnc
16 Feb 2026 21:28
Now works.
(Not usable yet, but homing and moves).
XML config file:
Script:
And HAL only for testing:
No speed and acceleration control, it is to do...
Replied by tuxcnc on topic EtherCAT driver as simply positioner
It is it.Set controlword to 6, 7, 15 (op-enabled)
Now works.
(Not usable yet, but homing and moves).
XML config file:
Code:
<slave idx="0" type="generic" vid="0000ffff" pid="00000001" configPdos="true">
<!--
Distributed Clock Configuration
assignActivate: Activation time for DC in ms
sync0Cycle: Sync0 cycle multiplier (*1 = 1 ms)
sync0Shift: Phase shift for Sync0 event
-->
<dcConf assignActivate="300" sync0Cycle="*1" sync0Shift="0"/>
<sdoConfig idx="6098" subIdx="00"><sdoDataRaw data ="13 00"/></sdoConfig> <!-- Home mode 19 (use HOME-switch input)-->
<!--
Sync Manager for Output (Commands sent to drive)
idx: Sync Manager index (2 is standard for outputs)
dir: Direction (out = from master to slave)
-->
<syncManager idx="2" dir="out">
<!--
Process Data Object (PDO) for Output
idx: PDO index (1600h is standard for TxPDO)
-->
<pdo idx="1600">
<pdoEntry idx="6040" subIdx="00" bitLen="16" halPin="controlword" halType="u32"/>
<pdoEntry idx="6060" subIdx="00" bitLen="8" halPin="opmode" halType="s32"/>
<pdoEntry idx="607A" subIdx="00" bitLen="32" halPin="target-position" halType="s32"/>
<pdoEntry idx="60FF" subIdx="00" bitLen="32" halPin="target-speed" halType="s32"/>
</pdo>
</syncManager>
<!--
Sync Manager for Input (Status received from drive)
idx: Sync Manager index (3 is standard for inputs)
dir: Direction (in = from slave to master)
-->
<syncManager idx="3" dir="in">
<!--
Process Data Object (PDO) for Input
idx: PDO index (1A00h is standard for RxPDO)
-->
<pdo idx="1a00">
<pdoEntry idx="6041" subIdx="00" bitLen="16" halPin="statusword" halType="u32"/>
<pdoEntry idx="6061" subIdx="00" bitLen="8" halPin="opmode-display" halType="s32"/>
<pdoEntry idx="6064" subIdx="00" bitLen="32" halPin="actual-position" halType="s32"/>
<pdoEntry idx="606C" subIdx="00" bitLen="32" halPin="actual-velocity" halType="s32"/>
<pdoEntry idx="6077" subIdx="00" bitLen="16" halPin="actual-torque" halType="s32"/>
<!-- Digtial_inputs (cia402 compatible) -->
<pdoEntry idx="60FD" subIdx="0" bitLen="32" halType="complex">
<complexEntry bitLen="1" halPin="CW-limit" halType="bit"/>
<complexEntry bitLen="1" halPin="CCW-limit" halType="bit"/>
<complexEntry bitLen="1" halPin="HOME-switch" halType="bit"/>
<complexEntry bitLen="23"/>
<complexEntry bitLen="1" halPin="IN-4" halType="bit"/>
</pdoEntry>
</pdo>
</syncManager>
</slave>
Code:
#!/bin/bash
halcmd setp lcec.0.0.opmode 6
halcmd setp lcec.0.0.controlword 6
halcmd setp lcec.0.0.controlword 7
halcmd setp lcec.0.0.controlword 15
halcmd setp lcec.0.0.controlword 31
sleep 2
halcmd setp lcec.0.0.opmode 8
halcmd setp lcec.0.0.controlword 6
halcmd setp lcec.0.0.controlword 7
halcmd setp lcec.0.0.controlword 15
halcmd setp lcec.0.0.target-speed 1
halcmd setp lcec.0.0.target-position 4000
exit 0
Code:
loadrt [KINS]KINEMATICS
loadrt [EMCMOT]EMCMOT servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[KINS]JOINTS
loadusr -W lcec_conf ethercat-conf.xml
loadrt lcec
addf lcec.read-all servo-thread
addf motion-command-handler servo-thread
addf motion-controller servo-thread
addf lcec.write-all servo-thread
setp iocontrol.0.emc-enable-in 1
- Ismacr63
16 Feb 2026 21:27
Replied by Ismacr63 on topic Some problems with probe basic lathe
I changed the macro names, but I wasn’t able to get it to work.
I’m not sure if the names I saw in Qt Designer are the correct ones…
I’m not sure if the names I saw in Qt Designer are the correct ones…
- RotarySMP
16 Feb 2026 21:17
Replied by RotarySMP on topic Error combining cutter compensation (G41/42) with work offset (G55)
There is one at the end Should there be another?
- COFHAL
16 Feb 2026 20:34
Replied by COFHAL on topic qtdragon mod
I copied your file to the Screens folder, ran LCN, but no additional PINs appear in Show HAL. What am I doing wrong?
- meister
16 Feb 2026 20:22
Replied by meister on topic LinuxCNC-RIO - RealtimeIO for LinuxCNC based on FPGA (ICE40 / ECP5)
I'm currently revising the Modbus part so that it also includes individual plugins,
and I've expanded the flow frontend a bit.
Okay, maybe I'm overdoing it a bit, but who cares, it's fun ;P
This way, you can also use your configuration as documentation.
The coolest thing about it is that it generates a working configuration
and I've expanded the flow frontend a bit.
Okay, maybe I'm overdoing it a bit, but who cares, it's fun ;P
This way, you can also use your configuration as documentation.
The coolest thing about it is that it generates a working configuration
- PCW
16 Feb 2026 20:17 - 16 Feb 2026 20:39
Replied by PCW on topic 7i92T and mx3660 request for help
1. I would use pncconfs "Discovery" option so pncconf "knows" what the firmware options are.
2. Then set the number of stepgens, encoders, PWMgens actually used
If this is not done, the GPIO pins these functions use will be masked
and unavailable for limit/home switches etc
3. If you want to know stepgenN --> MX3660 mapping etc:
mesaflash --device 7i92T --addr 10.10.10.10 --dbname1 mx3660 --readhmid
2. Then set the number of stepgens, encoders, PWMgens actually used
If this is not done, the GPIO pins these functions use will be masked
and unavailable for limit/home switches etc
3. If you want to know stepgenN --> MX3660 mapping etc:
mesaflash --device 7i92T --addr 10.10.10.10 --dbname1 mx3660 --readhmid
- Red_D85
16 Feb 2026 20:03
Maho MH-400 Retofit was created by Red_D85
Hallo zusammen
gibt es hier jemanden der vielleicht schon mal eine Streckensteuerung mit LinuxCNC umgesetzt hat. Das bedeutet die Maschine hat nur 1 Antriebsmotor für alle 3 Achsen und muss erst die entsprechende Achse einkuppeln und sie dann mit dem Servomotor auf die Position fahren. Es darf allerdings niemals eine andere Achse neben der angewählten Achse eingekuppelt werden da sonst ein Getriebeschaden droht.
hat jemand eine idee wie ich das im LinuxCNC anstellen kann?
freundliche Grüsse und schöne Abend
gibt es hier jemanden der vielleicht schon mal eine Streckensteuerung mit LinuxCNC umgesetzt hat. Das bedeutet die Maschine hat nur 1 Antriebsmotor für alle 3 Achsen und muss erst die entsprechende Achse einkuppeln und sie dann mit dem Servomotor auf die Position fahren. Es darf allerdings niemals eine andere Achse neben der angewählten Achse eingekuppelt werden da sonst ein Getriebeschaden droht.
hat jemand eine idee wie ich das im LinuxCNC anstellen kann?
freundliche Grüsse und schöne Abend
- Hakan
16 Feb 2026 19:36
Replied by Hakan on topic EtherCAT driver as simply positioner
I think you want to use PP (Profile Position) mode.
It's a cia402 op-mode, with some luck your drive supports it.
You need to set Profile Velocity and Profile Accelerations, from that
the drive will move to the position you set with for example halcmd setp pin position
dbraun1981's cia402 component doesn't support pp mode but you can easily add it.
WIthout any detail, these are the steps.
Set controlword to 6, 7, 15 (op-enabled)
Set op-mode to 1 (pp)
Set pp accelerations and velocity
Set pp position
wait (optional check target_reached)
Set new pp position
wait ...
and so on.
It's a cia402 op-mode, with some luck your drive supports it.
You need to set Profile Velocity and Profile Accelerations, from that
the drive will move to the position you set with for example halcmd setp pin position
dbraun1981's cia402 component doesn't support pp mode but you can easily add it.
WIthout any detail, these are the steps.
Set controlword to 6, 7, 15 (op-enabled)
Set op-mode to 1 (pp)
Set pp accelerations and velocity
Set pp position
wait (optional check target_reached)
Set new pp position
wait ...
and so on.
- tuxcnc
16 Feb 2026 18:52
EtherCAT driver as simply positioner was created by tuxcnc
Hi.
I need configure closed loop EtherCAT driver as simply positioner (tools magazine).
There is no problem to use this as rotary axis, but i don't want waste resources.
I need only internally homing and go to some position.
Theoretically I need only some bash scripts with "halcmd setp somepin" running as custom M-codes, but this doesn't work.
My driver not responds for any controlwords.
I must do something wrong, because this same driver works properly as axis.
Can somebody help me ?
I need configure closed loop EtherCAT driver as simply positioner (tools magazine).
There is no problem to use this as rotary axis, but i don't want waste resources.
I need only internally homing and go to some position.
Theoretically I need only some bash scripts with "halcmd setp somepin" running as custom M-codes, but this doesn't work.
My driver not responds for any controlwords.
I must do something wrong, because this same driver works properly as axis.
Can somebody help me ?
- andrax
16 Feb 2026 18:43
Replied by andrax on topic Technical questions about CIA402 and homecomp.comp on A6
@rodw I'm sorry. You're doing a great job.
I understand PLC programming, control technology, and sensor technology myself. But when it comes to high-level languages like C, my brain says noooo, you're too stupid.
Nevertheless, I am still thinking about how to solve the problem and trying to contribute something. So I simply fed chatgpt with parameters and this is what came out. I don't think this code is usable, but maybe it will help someone come up with ideas.
I understand PLC programming, control technology, and sensor technology myself. But when it comes to high-level languages like C, my brain says noooo, you're too stupid.
Nevertheless, I am still thinking about how to solve the problem and trying to contribute something. So I simply fed chatgpt with parameters and this is what came out. I don't think this code is usable, but maybe it will help someone come up with ideas.
Code:
component cia402_homecomp "CIA402 homing module with safety watchdog + estop";
pin out bit is_module = 1;
pin out bit cia_estop_out; // GLOBAL EMERGENCY STOP OUTPUT
license "GPL";
option homemod;
#include "motion.h"
#include "homing.h"
/* ---------------- SAFETY PARAMETERS ---------------- */
param rw float start_timeout_s = 2.0;
param rw float run_timeout_s = 20.0;
/* ---------------- LOCAL DATA ---------------- */
typedef struct
{
bool request;
bool start;
bool homed;
bool error;
bool active;
} cia_local_t;
static cia_local_t ciaH[EMCMOT_MAX_JOINTS];
static double servo_dt;
/* ---------------- HAL PINS ---------------- */
typedef struct
{
hal_bit_t *request;
hal_bit_t *is_active;
hal_bit_t *start;
hal_bit_t *homed;
hal_bit_t *error;
} pins_t;
static pins_t *pins;
/* ---------------- PIN CREATION ---------------- */
static int cia_makepins(int id, int njoints)
{
int r = 0;
pins = hal_malloc(sizeof(pins_t) * njoints);
if (!pins) return -1;
for(int j=0;j<njoints;j++)
{
r += hal_pin_bit_newf(HAL_IN , &pins[j].request, id,
"joint.%d.request-cia-homing", j);
r += hal_pin_bit_newf(HAL_OUT, &pins[j].is_active, id,
"joint.%d.is-cia-homing", j);
r += hal_pin_bit_newf(HAL_OUT, &pins[j].start, id,
"joint.%d.start-cia-homing", j);
r += hal_pin_bit_newf(HAL_IN , &pins[j].homed, id,
"joint.%d.cia-homed", j);
r += hal_pin_bit_newf(HAL_IN , &pins[j].error, id,
"joint.%d.cia-error", j);
}
return r;
}
/* ---------------- IO ---------------- */
static void read_pins(int njoints)
{
for(int j=0;j<njoints;j++)
{
ciaH[j].request = *pins[j].request;
ciaH[j].homed = *pins[j].homed;
ciaH[j].error = *pins[j].error;
}
}
static void write_pins(int njoints)
{
for(int j=0;j<njoints;j++)
{
*pins[j].is_active = ciaH[j].active;
*pins[j].start = ciaH[j].start;
}
}
/* ---------------- GLOBAL ESTOP ---------------- */
static void global_estop(int njoints)
{
cia_estop_out = 1;
for(int j=0;j<njoints;j++)
{
ciaH[j].start = 0;
ciaH[j].active = 0;
H[j].homing = 0;
H[j].home_state = HOME_IDLE;
}
}
/* ---------------- SAFETY STATE MACHINE ---------------- */
static int cia_1joint_sm(int j)
{
typedef enum { IDLE, WAIT_START, RUN } st_t;
static st_t st[EMCMOT_MAX_JOINTS];
static double start_t[EMCMOT_MAX_JOINTS];
static double run_t[EMCMOT_MAX_JOINTS];
switch(st[j])
{
case IDLE:
if (H[j].home_state == HOME_START && ciaH[j].request)
{
ciaH[j].start = 1;
ciaH[j].active = 1;
H[j].homing = 1;
H[j].homed = 0;
start_t[j]=0;
run_t[j]=0;
st[j]=WAIT_START;
}
break;
case WAIT_START:
start_t[j]+=servo_dt;
if (ciaH[j].error)
{
rtapi_print_msg(RTAPI_MSG_ERR,"CIA start error joint %d\n",j);
return -1;
}
if (start_t[j] > start_timeout_s)
{
rtapi_print_msg(RTAPI_MSG_ERR,"CIA start timeout joint %d\n",j);
return -1;
}
if (!ciaH[j].request)
st[j]=RUN;
break;
case RUN:
run_t[j]+=servo_dt;
if (ciaH[j].error)
return -1;
if (ciaH[j].homed)
{
ciaH[j].start=0;
ciaH[j].active=0;
H[j].homing=0;
H[j].homed=1;
H[j].home_state=HOME_IDLE;
st[j]=IDLE;
return 0;
}
if (run_t[j] > run_timeout_s)
{
rtapi_print_msg(RTAPI_MSG_ERR,"CIA run timeout joint %d\n",j);
return -1;
}
break;
}
return 1;
}
/* ---------------- API ---------------- */
int homing_init(int id,
double servo_period,
int n_joints,
int n_extrajoints,
emcmot_joint_t *pjoints)
{
servo_dt = servo_period;
int r = base_homing_init(id, servo_period, n_joints, n_extrajoints, pjoints);
r += cia_makepins(id, n_joints);
return r;
}
void read_homing_in_pins(int njoints)
{
base_read_homing_in_pins(njoints);
read_pins(njoints);
}
void write_homing_out_pins(int njoints)
{
base_write_homing_out_pins(njoints);
write_pins(njoints);
}
bool do_homing(void)
{
int busy=0;
int fault=0;
do_homing_sequence();
for(int j=0;j<all_joints;j++)
{
if(!ciaH[j].request)
busy+=base_1joint_state_machine(j);
else
{
int r=cia_1joint_sm(j);
if(r<0) fault=1;
else busy+=r;
}
}
if(fault)
{
global_estop(all_joints);
return 0;
}
homing_active=(busy>0);
return 0;
}
Time to create page: 0.539 seconds