Advanced Search

Are you sure that you were on 2.8.2? The big update was 2.8.x to 2.8.x
(but I don't think that the update script changes it's warning depending on the actual versions)

[TRAJ] AXES has always been there, so I am not sure what the updater has done to make it apparently disappear. Do you perhaps now have _two_ [TRAJ] sections in the INI?

Getting closer
 

JT

I can think of a few ways that you might be able to "reset" the A axis, but I don't know if any would work properly.

Firstly, you can't run the actual homing sequence in "Auto" mode. That's a pretty fundamental limitation that prevents homing while a G-code program is running.
If you don't need that (though I think that you probably do) then there are ways such as G-code remaps or custom-Mcodes that could do that.

You could try using the G10 command to reset the A-axis position, though.
Asuming that the A axis is calibrated in degrees:Will "unwrap" all the full-turns that have happened in spidle mode.
However you need to keep in mind that all the full turns are still there, and at some point there will be enough full turns that you will lose precision in the partial turns. The spindle position is a double-precision float, with about 14 significant digits, so this will take some time but you would probably still want to re-home the A axis manually between every few dozen jobs.

 
I am working on a LinuxCNC configuration for a CNC machine with EtherCAT-based servo drives (Delta ASDA-A2-E). The machine has 5 axes (`X`, `Z`, `A`, `C`, `W`), and I am experiencing an issue with the `W` axis during the homing process. Here are the details:

1. **System Overview:**
   - EtherCAT master is configured in ethercat-conf.xml.
   - The `W` axis corresponds to `slave idx="4"`.
   - The drive uses the CiA 402 profile, and homing mode is set to `02 00` (Homing Mode 2).
   - The `W` axis is not on its limit switches, and the `in-home` signal is not falsely triggered.

2. **Observed Behavior:**
   - When I click "Home All" or "Home W" in LinuxCNC:
     - `joint.4.homing` turns `TRUE` briefly and then turns `FALSE`.
     - `cia402.4.stat-homing` turns `TRUE` and remains `TRUE`.
     - `joint.4.homed` turns `TRUE`, indicating LinuxCNC believes the homing process is complete.
     - However, the servo does not move at all during this process.
     - The `opmode` for the `W` axis remains at `8` (Cyclic Synchronous Position) instead of switching to `6` (Homing Mode).

3. **What I Have Checked:**
   - EtherCAT communication is operational (`ethercat slaves` shows all slaves in the `OP` state).
   - HAL connections for the `W` axis are identical to the working `X` and `Z` axes:
     ```plaintext
     net w-home-index <= joint.4.index-enable  => cia402.4.home
     net w-enable     <= joint.4.amp-enable-out => cia402.4.enable
     net w-amp-fault  => joint.4.amp-fault-in   <= cia402.4.drv-fault
     net w-pos-cmd    <= joint.4.motor-pos-cmd  => cia402.4.pos-cmd
     net w-pos-fb     <= joint.4.motor-pos-fb   <= cia402.4.pos-fb
     ```
   - The `in-home` and `zpulse` signals are mapped in ethercat-conf.xml but do not seem to trigger during homing.
   - Homing speeds (`6099`) and other SDO configurations are consistent with the working axes.
   - The `statusword` (`cia402.4.statusword`) does not indicate any faults, and the drive is in the "Operation Enabled" state.

4. **What I Need Help With:**
   - Why is the `W` axis not initiating the homing process, even though LinuxCNC believes it has completed?
   - Why does the `opmode` not switch to `6` (Homing Mode) during the homing process?
   - Are there any additional checks or configurations I should perform in ethercat-conf.xml, lathe.hal, or the drive itself?

5. **Additional Context:**
   - The `W` axis used to home successfully in the past but stopped working recently.
   - The `Z` axis occasionally exhibits similar behavior but eventually completes homing after several attempts.

Please provide detailed troubleshooting steps or suggestions to resolve this issue.

 

When i try run usergenserkins in terminal by typing genserkins to test something, i got this error:
HAL: ERROR: duplicate component name 'usergenserkins'
HAL: ERROR: component -22 not found
Segmentation fault
I'm running linuxcnc 2.9.4

Grotius wrote:

Hi,

the latency debian 13 is very bad.
We have to come up with an idea to
solve this.

 

Latency or network latency?

The URL posted to the mailing list was
chat.openai.com/g/g-vfeQnX43z-linuxcnc-assistant
but I can't check that from work as they are worried I will ask questions that leak data.

Thanks Rod, I found it there eventually.

To OP:

The notch is a good idea.

Very nice job with the notch, by the way, but perhaps 2 notches would be better, due to being perfectly balanced.

Have you seen the previous threads on converting this machine?
forum.linuxcnc.org/38-general-linuxcnc-q...dx540-rebuild#253265

Like what if your smulation is catually different than the real-world machne and in real life, the machine ends up being destroyed due to a 1mm difference or something.

Try out the debug port.

Maybe it can lead you to the bottom of this strange behavior.

Your driver is obviously broken.

So like changing switches #1-4 does nothing?

Does the output feel different?

If your drives use resolvers than your Mesa card choice is pretty simple, it has to be the 7i49 .
That card needs a 50-pin header FPGA card. I would suggest the 6i24 if your PC has PCIe. The 6i24 can be mounted at the end of a PCIe extension cable if that makes things easier (my own mill does this)
Or, if you prefer an Ethernet connected FPGA card, then perhaps the 7i93 would work (but check with Mesa)