CNC begrundanden

[malman]

Beställdes kulskruvar och dylik mtrl igår….

Så nu borde man börja fräsa motorhus o lagerbockar….

Men snöade idag in på encoder interfacen igen….
( gillar iden med linjärskalor på axlarna för att se vad mekaniken håller på med efter servona)

Om man tittar på en NUCLEO-H753ZI (STM32-H753) så har den 4st 32bit counters….
Utv kortet kostar ~250+moms…

Har ett par microchip evm moduler på ingång… EVB-LAN9252-SPI, tillsammans med ovanstående kanske man skulle kunna plita ihop något lämpligt…. 4kanaligt…
(Ja jag är slö och bygger på moduler istället för att rita egna highspeed pcb’er… så slipper jag debugga dom delarna…

[hawkan]

Smidigt sätt att få ihop en EtherCAT slave, med moduler. Tur jag inte tänkte i de banorna.
Det kan dock vara bättre att undersöka om du kan koppla enkodrarna till servo-drivarna.
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.

Normalt kör man servona i CSP-läget, och ser till att tuna de så bra man kan.
Positions-feedback används bara för att se till så det inte spårar ur fullständigt
och i så fall stanna.

[malman]

Med dessa servo drivers var det ej möjligt… de som hade dessa möjligheter kostade lika mycket som mina 3 motorer o servondrivers ihop… (dvs bara en driver)
( encoder ingångarna på dessa lichuan drivers är något av otaliga seriella format… till vilken std linjär encoder quadratur ej passar direkt )

Jaja vi får se vad det blir..

[malman]

Om man vågar tro på vad perplexity hallucinerar ihop, så hävdar den att lcnc klarar av att hanterar denna typ av delayer.
’ LinuxCNC applies feedforward + lookahead (up to 10 cycles) to preempt feedback delays, keeping contour errors low even at 1kHz servo rates. ’

[hawkan]

Det var lustigt, inget jag vet något om. Finns det källa man kan kolla?

Normalt så är detta med fördröjning av feedback inget problem.
Men man ska undvika velocity loop som man brukar göra med analoga servon.
Istället använder man Cyclic Synchronous Position mode där linuxcnc skickar ny position
varje servocykel typ 1 kHz och så får servot lösa det. Därav bra tunat.
Det finns de som kör snabbare 2 och 4 kHz. Kommer in i annan problematik kring
realtid och linux.

[malman]

Tchadu… blev inte klokare av att följa de länkar perplexity hänvisade till…. Ingen av länkarna pratar om lcnc öht…
Undrar hur den kom fram till detta…..
Så här svarade den på min flummiga fråga:

In lcnc when running position feedback from linear scales connected through a ethercat encoder interface, is the two cycle delay an issue?

No, the two-cycle delay is typically not a significant issue in LinuxCNC with EtherCAT linear scale feedback.
​https://drives.novantamotion.com/kb/lat ... rvo-drives


Why It's Manageable
LinuxCNC's EtherCAT master (via IgH EtherCAT Master or SOEM) compensates for EtherCAT's inherent 2-frame latency (~2x cycle time) through Distributed Clocks (DC) sync and proper PDO timing configuration.
https://www.lenze.com/en-de/application ... e/295243/1
https://infosys.beckhoff.com/content/10 ... 18347.html

At 1ms cycle: Total feedback delay = ~2ms (acceptable for most motion control).

Scales report position via DC-synced sampling (not frame-triggered), minimizing jitter to <1µs.
https://infosys.beckhoff.com/content/10 ... 18347.html
https://www.ethercat.org/en/technology.html

LinuxCNC EtherCAT Config
In your linuxcnc/ethercat.conf or HAL:

text
# PDO mapping: position feedback in SM2 (process data)
# DC sync: align scale sampling to master clock
NETMASTER 0 {
...
DC_SO 1000 # Sync shift offset (µs)
}
LinuxCNC applies feedforward + lookahead (up to 10 cycles) to preempt feedback delays, keeping contour errors low even at 1kHz servo rates.
​https://www.lenze.com/de-de/application ... l/280013/1

When It Becomes Problematic
Scenario Delay Impact
High-speed contouring (>10m/s, accel >5g) Noticeable following error
1ms cycle + many nodes (>20 slaves) Propagation adds ~100ns/node
No DC sync Jitter >10µs ruins velocity calc
Practical Thresholds
<1ms cycle: Negligible (feedsync scales like Celera M-6000 work great).

2ms cycle: Fine for general CNC; tune PID gains down 20%.
https://www.lenze.com/en-de/application ... e/295243/1

4ms+ cycle: Only for low-bandwidth axes (Z, A).

For your SOES/LAN9252 + NUCLEO-H753ZI setup: Use 500µs-1ms cycles with DC sync. LinuxCNC's ethercat_dc component handles the 2-cycle offset transparently—your linear scales will track smoothly for CiA402 CSP mode.
https://drives.novantamotion.com/kb/lat ... rvo-drives



Såå njaee… var kanske trots allt halucination….. om nu inte distribuerad klocka (DC-sync) hjälper till att lösa detta åt en…
Teoretiskt kan man ju få servots position och encoder position avlästa samtidigt med hjälp av dc sync, men hur sen lcnc hanterar detta i sin reglering med någon cykels (2) försening är ju fortfarande den springande punkten

[H.O]

De där AI-svaren verkar tro att du ska köra dina servon antingen "open loop" eller i velocity mode och sluta postionsloopen, i LCNC, enbart via linjärskalorna. I sådant fall kan man tänka sig att 2ms fördröjning potentiellt kan vara ett problem men det är (väl?) inte det du ska göra.

Jag kan inget eller väldigt lite om hur LinuxCNC fungerar internt men tanken med dina skalor och EtherCAT-räknar-kort är väl att köra "dual-loop", dvs en inre motor/enkoder/servo loop som "omsluts" av en yttre korrigerande loop med indata från skalorna? Alternativet, som hawkan också skriver, är ju att inte enbart använda skalorna som "övervakning" att det inte går käpprätt åt skogen men den lösningen brukar vara förbehållen system med open loop stegmotorer för att undvika katastrofer om man överbelastar dom.

Kollade snabbt på din STM32, 4 räknare men kvadratur-interface men vad jag kunde se så var bara två av de 32bit, de andra två 16bit. Men det löses ju med lite kod.

[hawkan]

Alltså AI ... är inte så träffsäker med linuxcnc. Det där var ett hopkok av lite av varje.
Specifikt blandade den ihop din fråga med effekten av längre cykeltid rent generellt. Inte positionsfeedback.

Linjärskalor kan hjälpa om man har flexibilitet i axlarna. Mjuka skruvkopplingar, mjuk kullagring,
vändglapp i muttrarna o sånt. Med analoga servon tar man positions feedback från enkoder till velocity loop.
Pga 2 cykel fördröjning gör man inte det. Välj styva lösningar. Jag har t ex kopplingar med flexibla stycken i.
Borde bytas. Som övning för du räkna ut hur mycket en axel färdas under 2 cykler, 2 ms.

[malman]

Man får de svar man vill ha.... Eller nåt....

Linuxcnc controls an axis through a ethercat servocontroller. The servocontroller closes an inner control loop by csp commands from lcnc. Would an second outer loop in position mode feed from linear scales via another erhercat device be able to contribute to system performance, or would the 2cycle delay in the ethercat transactions cause a difficulty for the outerloop in the lcnc to compensate due to old position values?


A second, outer position loop in LinuxCNC using linear scales over EtherCAT can work, but the 2‑cycle delay does limit how aggressively you can tune it and how much performance you gain; it won’t behave like a truly “tight” direct‑scale loop in the drive.

What the extra loop can contribute
The outer loop can correct for static errors such as backlash, ballscrew pitch error, thermal drift, and servo drive following error, since it compares the commanded axis position to the “true” axis position from the linear scale.


At moderate speeds and with conservative gains, this can improve absolute positioning accuracy and reduce long‑term drift, even if the feedback is delayed by a couple of EtherCAT cycles.

Impact of the 2‑cycle EtherCAT delay
In many LinuxCNC + EtherCAT setups, the bus runs on the order of 1 kHz; a 2‑cycle delay means the outer loop works on position data that is roughly 2 ms old.

Control theory tells us that such loop delays reduce phase margin and therefore limit the achievable bandwidth; in practice this means you must keep the outer loop gains low, especially for high‑speed moves, to avoid oscillation or chatter.

Users have reported that a 2‑cycle EtherCAT delay shows up as measurable following error at high speeds, but if LinuxCNC only uses that feedback for supervision (following‑error monitoring) the delay is acceptable; turning it into an active PID loop just means you need gentler tuning.

Practical recommendations
Keep the tight inner loop in CSP inside the drive using the motor encoder; use the LinuxCNC outer loop more like a slow “trim” loop for accuracy, not as a high‑bandwidth motion controller.

Start with very low P and I in the LinuxCNC PID using the linear scale, verify stability during fast moves, and only increase gains until you start to see overshoot or oscillation, then back off.

If your servo drive can accept the linear scale directly and close the full position loop in the drive, that will generally give better high‑speed, high‑accuracy performance than closing that outer loop in LinuxCNC over EtherCAT.

So the 2‑cycle delay does not make the outer loop useless, but it does mean its role is mainly improving static accuracy and slow error correction, not high‑bandwidth dynamic performance.

[hawkan]

Men det var ett bra svar, det håller jag med om.

[malman]

Jag kan inget eller väldigt lite om hur LinuxCNC fungerar internt men tanken med dina skalor och EtherCAT-räknar-kort är väl att köra "dual-loop", dvs en inre motor/enkoder/servo loop som "omsluts" av en yttre korrigerande loop med indata från skalorna? Alternativet, som hawkan också skriver, är ju att inte enbart använda skalorna som "övervakning" att det inte går käpprätt åt skogen men den lösningen brukar vara förbehållen system med open loop stegmotorer för att undvika katastrofer om man överbelastar dom.

Väl formulerat....

Kollade snabbt på din STM32, 4 räknare men kvadratur-interface men vad jag kunde se så var bara två av de 32bit, de andra två 16bit. Men det löses ju med lite kod.

Som jag förstår det hade STM32 möjlighet att koppla 16bits räknare i master slave config, å få ut 32bit av två 16 bit räknare... Fanns vissst ett gäng att ta av...

2 native 32-bit (TIM2/TIM5)
2–3 chained 32-bit equivalents by pairing 16-bit timers (e.g., TIM1 master + TIM3 slave; TIM8 master + TIM4 slave)

[hawkan]

Så du är lite sugen på att göra en sån enkoder-slav. Men gör det, det är definitivt
ett kul sidospår. Jag har det mesta du behöver på github. Du behöver modifiera
koden för kvadraturinräkningen vilket kan vara väl så krångligt med STMs registersoppa.
Och så nya PDOer och kanske SDOer men den biten är en baggis. Modulerna du visat
kommer att fungera bra till detta.

[malman]

Jo, framförallt är det lite intressant att ha en sensor som ger en ett absoulut resultat att jämföra andra saker med…