Advanced Search

Changing from F to 0 the output changes. The motor shaft is shaking as it doesnt have enough torque to spin the pulley. This is true until i get to 8. On 8 it comes alive and spins as it has been. The output seems to improve as i move past 8 but i have no data to confirm this.

I have the debug cord but once i get into the menus i have no idea what i am looking for.

HI Rod,

A tester send me this :
Debian 10 : jitter max 45200
Debian 12:jitter max 29000
Debian13:jitter max 522000

Ir looks very bad.

      My files

Thanks for your reply!

Indeed there is something clearly incorrect. I'm not sure that it's in code or documentation or a combination of both.

I've tried numerous times to fix this without success. I think that it goes without saying that if it's not working properly,
it should probably be removed. It's very annoying.

Moved the double post here as it had files attached.
Please refrain from double posting.
Thank you.

@mehdidadash

No double posting please.

Any more progress on this? It's a great idea.

When i try run usergenserkins in terminal by typing genserkins to test something

I'm not exactly sure what that means but looking at this note at the beginning of 'ugenserkins.c' makes me think that you might be trying to use something that is likely no longer working:

I have also implemented random toolchanger on my lathe. It works to remember the right tool in the machine. A problem that have occured quite a few times is that when I update tool offsets the tool number in use changes.

For instance, tool 7 is in use and I update tool 3's offset in the tool table. Save, reread, reload. Then tool 7 becomes tool 11 or 12. Well, some other random tool number. I could not deduce a specific pattern so far and it does not happen every time.

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?