Advanced Search

 
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.

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

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)

It looks like your remap "magic" in in the "remap_m6.py" file.
Can you attach that too?

Hi,

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

Yes, mainly the UI does the gear size / depth calculations and gives you a span measurement to run a quick test that the tooth depth is correct.
It could be more aesthetic:

Where did you find engraver-1.py ? It doesn't seem to appear in this thread....

I think that using HAL to read the multiplexed inputs is likely to be the easier solution.

But, yes, you probably _could_ create a custom component that uses the hotmot2 raw interface to read register values directly and interpret those into HAL pins.
linuxcnc.org/docs/stable/html/man/man9/h...t2.9.html#Raw%20Mode

In fact, if it is a single address that needs to be read, it might be possible to do it all in HAL, by "setp" the register address to read from, and using "bitwise" on the read data to toggle individual HAL pins.

Not sure 'cutting edge' is the right term, but I understand if you're not interested in something slightly experimental.  You can always have a go at caxis.comp later.

As far as creating a second configuration goes, there are (at least) a couple ways.

First, you can simply make a copy of your current config and then hand-edit the INI and HAL files.  But you mentioned that HAL isn't clicking for you, so that may be a bit of a stretch.

Second method would be to use Mesact to create a new configuration from scratch, but this time you tell Mesact that your spindle is a step & direction type.  I think you've got the 4th axis connected to stepgen.04 and are using a 6:1 belt ratio, yes?  Include those values in the new config via Mesact, along with an appropriate max speed and estimated max accel for the 4th axis.

Leave out the 'real' spindle settings, and put everything else (axes & IO) the same as your existing config and then see what Mesact comes up with.

That should give you new INI and HAL files which you can use to create a merged/blended configuration that has both spindles and no 4th axis.

I find that using VSCode makes things easy to read/edit (there's a LCNC/HAL file plugin).  I'd set up all three HAL files across two monitors and look at the differences.  Things to look out for:

• Dont forget to comment out or delete the A-axis/joint 3 section
• The new spindle needs all pins to be named 'spindle.1.nnn', and the signal names need to be 'spindle1-vel-cmd-nnn' (or similar).

INI file must be edited, too, especially these:
[DISPLAY]
GEOMETRY = xyz

[KINS]
KINEMATICS = trivkins coordinates=XYZ
JOINTS = 3

[TRAJ]
COORDINATES = XYZ
SPINDLES=2

[AXIS_A] - remove this entire section
[JOINT_3] - remove this entire section

[SPINDLE_1]
(put the 4th axis spindle stuff here)

Have a go and see what you come up with.  Assuming it doesn't work - these things are rarely perfect the first time - and you get an error trying to start LCNC, make sure to screen capture the error and report back here.

Thanks for your reply.
The XYZ servo drives seem to use +/- 10V analog signal to control the DC motors.
The resolvers are the default Fadal resolvers.
For the VFD I don't know as I'm looking for a new VFD to replace the current Baldor VFD. I did see people succesfully replacing the Baldor either by Yaskawa GA500, Yaskawa V1000 or Hitachi WJ200 VFD.

Can the 7i97T output +/-10V signals and take the input of the resolvers?

Oh and a generic question: can someone share the Fadal Model 914 / VMC15 (1994) wiring diagrams / electrical schemetics?

I think you identified to problem By trade I'm a power electronics engineer... so my programming skills are... well they can only be improved