Advanced Search

That did the trick, thanks.

It's working!

After reading through the Lichuan LC10E thread ( forum.linuxcnc.org/ethercat/52341-proble...ethercat-servo-drive ), where somebody discovered that the issue is around how the clock is setup, the key are these missing lines from my xml -

<syncManager idx="0" dir="out">
      </syncManager>
      <syncManager idx="1" dir="in">
      </syncManager>
     

Added those for each slave, and all the drives now intialise and activate when LCNC is opened.
Now to decide if I want to re-retrofit them to my little mill, or buy an extra drive and motor for the plasma table I have part built..

tested here on sim and everything is now working as it should be again! thanks for bringing it up to my attention both of you!

I think i have this resolved now and will be pushing out shortly today was a porting breakage that got missed one some other fixes.the object name user_main and user_sb this property determine the name displayed in the ui for the tab button text. so if you name it spumco_sb it will display SPUMCO SB in the ui.

I made a post regarding this thread in the QtPyVCP channel on Matrix and got a reply that it seems to be a bug in the latest version.

mwc wrote:

Start from the beginning (in reply to your first post)

If I power the drives up with the CAT/Network cable disconnected between drive 1 and 2 (aka drive 2 and 3 not linked to the master), load LinuxCNC, then connect the CAT cable (so drives 2 and 3 are now connected/linked to the master), drives 2 and 3 get configured and can be enabled and controlled by LinuxCNC (I can jog the Y and Z axis), but drive 1 still does nothing.

 

So after being away for a few days, I've read back through this thread to remind me what I had done previously, and I'm back to this point.

On the plus side, I realised why the drives were initialising in the wrong order. Apparently the cable to the computer should go in the ECAT IN port of the first drive, not the ECAT OUT port of the last drive 

In case I've done something stupid during the latest Linux install, how can I check that I'm using the latest built in EtherCAT libraries?

Nice!

Hi everyone,

I'm developing my own CNC controller in C using the IgH EtherCAT Master on real-time Linux. I'm not using LinuxCNC itself, but I know there are several people here with experience using Delta ASDA drives with IgH.

My setup is:
- 4x Delta ASDA-E3
- CSP mode
- 1 ms cycle / SYNC0
- Distributed Clocks enabled
- Intel I210
- Real-time Linux

I have a strange intermittent problem.
During constant motion, occasionally one drive's Actual Position (0x6064) does not update for exactly one cycle. On the next cycle it advances approximately twice the normal amount.

For example:
Cycle N-1:  +39000
Cycle N:         0   <-- one drive does not update
Cycle N+1:  +78000   <-- approximately 2x

At the same moment, another Delta drive in the same EtherCAT cycle continues updating normally.
WKC remains normal, DC stays synchronized, there are no drive alarms, and 0x1C32:0B / 0x1C32:0C remain zero.
The same drives, motors and EtherCAT wiring work smoothly with a Bochu CNC controller.
I have already spent a lot of time checking Linux RT jitter, SYNC0 shift, DC phase and packet timing without finding the cause.

Has anyone using Delta ASDA with IgH ever seen this exact one-cycle hold followed by a double update?
Is there any Delta-specific EtherCAT, DC, synchronization or servo parameter that I may be missing?
Any ideas would be greatly appreciated.

Thanks,
Fahreddin

Hello, I have built a new plasma cutting table. I am working with Linuxccnc 2.9, Qtplasmac, and an LPT board. A problem has arisen: the torch touches the metal on the floating platform, the sensor is triggered, the Z value on the DRO suddenly changes by 100+, the machine goes into an emergency due to exceeding the Z‑axis limit, then the Z‑axis moves away and the readings return to normal. Please help me solve this problem.

Hello all.

Just thought I'd share this little app I had ChatGPT write for me.  In a nutshell - it generates GCode for side operations on a standing cylinder using a lollipop style of cutter when you don't have a rotary axis available.  It's fairly limited in scope, but may prove useful from time to time.  True G2/G3 helices too.  I'll add some more features as and when.

groovecam.smallscalecnc.co.uk

Yes, I tested it and it works fine.
Thanks for reporting the issue.

nice, it's time to build an addon board with IO's

It all working now. Have to change tri-state block in vivad. Will be update on cloud project Vivado and so on

This should be fixed in master now.
Another Dev figured it out quick!

If the driver does not find a Sserial remote, it reverts the pins to GPIO
so that's expected if there is no remote connected/discovered.