Svenska ElektronikForumet

Har egentligen inte kommit någon vart ännu med EtherCat sw biten.... för mycket annat som händer i verkligheten......
Men tittat en del o försöker förstå helheten.... och kanske hitta mer dokumentation mm..

Men om jag fattat rätt är dina (Hawkan) SOES lib i grund o botten koden från OpenEtherCATsociety's SOES Git (https://github.com/OpenEtherCATsociety/SOES)
Men tolkar det som deras kod mest är adapterad mot linux maskiner mm... Vem har då gjort adaptionen mot Arduino frameworket (och STM plattformen)? dvs HAL/esc_hw biten mm... (Om jag nu inte är ute o cyklar på riktigt)
(sen hur rt-labs betal ethercat stack hänger ihop med OpenEtherCatSocietys variant med sin öppna källkod förstår jag inte riktigt, verkar iaf komma från samma kodbas någongång i världen...)

Försöker härleda var kod delarna kommer ifrån. ( och förstå gränsen mellan olika delar, vilket projekt som gjort vad i kod stacken osv. )
Har du Hawkan hackat nåt i SOES biblioteken? Eller är de tagna från någon mellanhand som gjort HAL biten?

Det kommer härifrån https://github.com/kubabuda/ecat_servo
Jag har varit på SPI-delarna, om det behövs. Pinnar, hastighet och polaritet behöver man kolla över.
De andra bitarna har klarat sej utan pillande och vad jag kan se, efter många timmar i drift, fungerar.
Det verkar som SOES och detta var aktuellt för kanske 10 år sedan, nu verkar det mest vara i dvala.
För övrigt har jag en EL5101, en enkoderräknare från Beckhoff i min svarv. Till spindeln.
Till det skulle man behöva en EK1100, kostnad ca 50 € (EK1100) + 100 € (EL5101). Köpelösningen.

Saken är att informationen om positionen från enkodrarna eller ja från alla EtherCAT-slavar
är fördröjd med två cykler innan de når in i linuxcnc. Det har inget med egna slavar
eller klantig programmering att göra. Utan det är så kedjan med information blir, mellan
två cykliska operationer som kommunicerar dubbelriktat en gång per cykel.

Är denna fördröjning lika om man läser in enkodrarna via Mesa eller något annat interface istället för Ethercat?
Jag funderar på om man kan köra servo i CSV-mode och återkoppla position med linjär skala, för maskinen jag har i tankarna drivs med kuggstång som inte har så hög precision (problemet med glapp har jag en lösning på så det lämnar vi utanför diskussionen tillsvidare)

Jag har inte det helt klart hur det blir med de andra mer än att jag tror rätt säkert att det är mindre fördröjning.
Försök återkoppla direkt till servo-driven. Linjärskala som input till servo-drivern går bra, givet rätt protokoll.

Jag gjorde en gammal fräs med analogservon där servona hade resolveråterkoppling till driven för hastighet men servona hade ingen positions loop så då satte jag enkodrar på kulskruvarna som jag kopplade till linuxcnc via Mesa och positions loopen låg i linuxcnc, jag tryckte det funkade rätt bra. Men det kanske blir bättre med analogservon så än med digitala buskopplade servo som kanske får en tydligare fördröjning.

Förresten, vilken cykeltid uppnår man på ethercat i linuxcnc?

EtherCAT har inte såna saker. Normalt kör man i CSP och skickar position varje cykel.
Tuna servot såklart. Så kör de allra flesta.
Edit. Normalt 1 ms, kanske 0.5 ms eller 1/4 ms om man anstränger sej.

Servona jag kollar på att använda, A6 från stepperonline, kan köra CSV cycle synchronous velocity, via Ethercat, om man vill (finns även csp).
Det blir väl kanske att prova båda varianterna...

Det har inte fungerat bra med csv för de som provat.
Jag ställde ner tiden till 250 mikrosekunder men efter nån minut fick jag "unexpected realtime error".
Med 500 mikrosekunder gick den hela natten utan att klaga.
Och då har jag inte ens den mest fundamentala anpassningen för RT, som isolcpus på denna datorn.
Så 250 mikrosekunder verkar uppnåeligt utan större problem.