Just for curiosity: How much would one of those "surplus" cards cost?

Would it be manageable for someone who is only end user level?
Is it really easier to use than a MESA card?
(referring to the original complaint that the documentation and instructions were not sufficient)


Maybe in 2020 the complaint was more valid than it is today. Because some info and updates made it better since then.

In really already have IOs on stmbl drive , now add webui interface, all work on board 

meister wrote:

Thank you Tim,

Thanks very much for the details; I’ve entered the board’s details as best I could,
I hope it’s all correct so far – please do have a look over it.
What’s not quite clear to me yet is, how do you flash it? Are there any connectors on the back?

You’re also welcome to send me some text and a link for the description, and I’ll update it.

Dear meister:

Can I use this config?

Tim
 

Hallo, 
seit einigen Tagen verzweifle ich am Handrad XHC WHB04B-6 Funk. Kurz nach dem Start der Maschine erhalte ich in der Konsole folgende Fehlermeldung 
xhc-whb04b-6: hal/user_comps/xhc-whb04b-6/usb.cc:460: bool XhcWhb04b6::Usb::setupAsyncTransfer(): Assertion `0 == r' failed.

Nach dem was ich bisher herausgefunden konnte scheint es ein Problem auf USB-Ebene zu sein. Die einfachen Optionen (USB Port 2.0, *.rules Datei anpassen habe ich bereits versucht - leider ohne Erfolg. 

Auffällig häufig tritt der Fehler beim drehen am Handrad auf. Die Achsauswahl, diverse Tasten können mehrfach problemlos gedrückt werden und werden in der HALSHOW auch korrekt angezeigt. Beim drehen am Handrad tritt der Fehler relativ schnell auf. Deshalb bin ich nicht sicher ob es sich wirklich um ein USB Problem handelt. 

Meine Maschine läuft auf einem Pi5 8GB mit einer Mesa 7i96s und einer GMOCCAPY Oberfläche 2.9.10. Mechanisch ist es eine Gantry XYY2Z. 

Hat jemand dieses Handrad erfolgreich im Betrieb und kann mir eine "geprüfte" HAL Datei, *.rules Datei zur Verfügung stellen? Einfach um Fehler in meiner Konfiguration ausschließen zu können. 

Vielen Dank 

Grüße Erwin

 

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 image missing /media/kunena/emoticons/whistling.png

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.