[UPDATE]Open dag Eding CNC op 16 juli 2022

[Kjelt]

Andere nadeel is dan nog wel de relatief lage stap frequentie die de bordjes kunnen uitsturen

Puur uit interesse, bij wat voor snelheden en ppr wordt 400kHz de begrenzende factor ?

[DaBit]

want je servos staan dan continu te hunten ook tijdens de beweging.

Waarom zou dat?
Mijn linealen op de frees doen positiecorrectie via voornamelijk I-term. Dat is conceptueel simpel, hunt niet, is ongevoeling voor trillingen, werkt bovenop een bestaande positioneringslus in vrijwel alle situaties, en bied naast correctie ook extra detectie voor bewegingsproblemen.

Puur uit interesse, bij wat voor snelheden en ppr wordt 400kHz de begrenzende factor ?

3000rpm servo, 2500-lijns encoder, gearing 1:1 heeft al 500kHz steprate nodig, en zo bijzonder highend is die configuratie niet. 1-op-1 gekoppeld aan een 5mm KO is dat goed voor 15m/min. Niet sloom, maar ook niet echt kwijl-waardig.

Die 500kHz wil je dan ook nog met weinig jitter doen, en dat word voor Eding zowiezo wel problematisch.

[Kjelt]

Puur uit interesse, bij wat voor snelheden en ppr wordt 400kHz de begrenzende factor ?

3000rpm servo, 2500-lijns encoder, gearing 1:1 heeft al 500kHz steprate nodig, en zo bijzonder highend is die configuratie niet. 1-op-1 gekoppeld aan een 5mm KO is dat goed voor 15m/min.

Het is warm, misschien maak ik een denkfout.
Een 2500 lijns encoder geeft 10000 pulsjes per rot. maar dat wil niet zeggen dat deze 10000 pulsjes nodig heeft voor een rotatie.
Delta A2 servo bv bv 3000rpm 2500ppr dus 125kHz.

[DaBit]

Nee, dat kun je met de gearing instellen bij de meeste drives. Zet die op 1:4 en je hebt inderdaad aan 125kHz genoeg. Maar het blijft zo dat hoe hoger de informatiedichtheid, hoe beter die servodrive snapt wat je eigenlijk wil want het arme ding moet het allemaal maar uit de pulstrein afleiden.

[P1-Engineering]

Puur uit interesse, bij wat voor snelheden en ppr wordt 400kHz de begrenzende factor ?

3000rpm servo, 2500-lijns encoder, gearing 1:1 heeft al 500kHz steprate nodig, en zo bijzonder highend is die configuratie niet. 1-op-1 gekoppeld aan een 5mm KO is dat goed voor 15m/min.

Het is warm, misschien maak ik een denkfout.
Een 2500 lijns encoder geeft 10000 pulsjes per rot. maar dat wil niet zeggen dat deze 10000 pulsjes nodig heeft voor een rotatie.
Delta A2 servo bv bv 3000rpm 2500ppr dus 125kHz.

1280000ppr, 20bit encoder voor de A2. De A3 zelfs met een 24bit encoder.
Met 10000 pulsen per mm zit je al op 1,6mhz met een max snelheid van 10m/min. Dan is het toch fijn dat de controller tot 4mhz aan kan.

[Kjelt]

It does not compute zoals de amerikanen mooi zeggen.
Waarom zou je met 40m/min met een nauwkeurigheid van 0,1u willen aansturen?
Als je zo rap wilt frezen zal de nauwkeurigheid ook niet zo hoog liggen en kun je beter een grotere spoed nemen, of nog beter helemaal geen KO spindel want die vinden dat soort snelheden ook niet dag in dag uit leuk en kun je beter voor een lineaire motor gaan.
Als je toch op die weg gaat dan wil je helemaal geen step/dir meer maar digital control via ethercat of nog betere digitale protocollen.
Hoe dan ook dan zit je in een segment waar een paar mille voor een pro besturing ook niet meer uitmaakt, een ander soort segment dan Eding nu bediend

Maar er zal ook vanuit de Eding keuken tzt wel aan een nieuwe generatie controllers gewerkt worden.

[P1-Engineering]

Wie heeft het over 40m/min?

Het gaat niet om de snelheden of de theoretische nauwkeurigheid van 0,1mu, maar om zoveel mogelijk input naar je servo-drive sturen zodat deze zo goed mogelijk z'n werk kan doen. Zeker als deze ook nog s-curve acceleratie ondersteunt en resonantie-compensatie. Dit komt allemaal ten goede van je afwerking en nauwkeurigheid.

Goed voorbeeld daarvan is de moderne Heidenhain besturing. Die wil je vanuit je CAM pakket zoveel mogelijk datapunten geven, dus in bijvoorbeeld Fusion geen tolerantie en geen smoothing etc. Waar een andere besturing hierop vast loopt is de Heidenhain besturing instaat deze punten te verwerken en daardoor een zo accuraat en vloeiend mogelijk traject af te leggen.

Aangezien ik dit deel super interessant vind van de hele CNC hobby ben ik een nieuwe besturing aan het bouwen waarmee ik met een aantal d-sub stekkers kan wisselen van LinuxCNC icm een Mesa kaart of de vrij nieuwe SIMCNC besturing met CSMIO controller.
Als het uitkomt wil ik ook nog wel de Eding controller erin zetten om te kijken of het ook op ons soort machines een meetbaar, zichtbaar verschil geeft.

[DaBit]

It does not compute zoals de amerikanen mooi zeggen.
Waarom zou je met 40m/min met een nauwkeurigheid van 0,1u willen aansturen?

Zoals P1-Engineering het al zegt: het heeft niks te maken met rap frezen of belachelijke nauwkeurigheden. Het gaat erom dat je de motordrives vertelt wanneer ze waar moeten zijn, en dat dat onderling over meerdere assen ook klopt.

Allereerst, step/dir als positiecommunicatie heeft maar 1 klein minuscuul voordeeltje: het is conceptueel simpel. Voor de rest is het een systeem dat door iemand met een IQ van 75 uitgevonden is die ten tijde van uitvinding nog stevig last had van de ziekte van Heineken ook. Zelfs voor unipolaire stappenmotoren in de tijd dat een enkele transistor 10 gulden kostte was een sin/cos quadratuursignaal (zoals gangbaar bij het merendeel van de incrementele encoders bijvoorbeeld) al verreweg de betere oplossing, want dat had naadloos bij de 90 graden electrische faseverschuiving tussen de windingen gepast. Halve bandbreedte op je datalijnen, geen setup/hold timingproblemen en storingsongevoeliger. De hele wereld deed al sinds het buizentijdperk netjes sin/cos, I/Q, quadratuur, geef het beestje een naam, alleen een of andere dombo moest weer zo nodig step/dir verzinnen en omdat mensen met meer verstand van verzekeren dat ook nog snappen werd het de defacto standaard. Magoed, we doen het maar met dat dronkenmansgelal; het voldoet.

Met puur step/dir heeft de motordrive geen idee of-ie moet coasten, accelereren of decelereren. Dat moet-ie uit de frequentie en verandering van frequentie van de pulstrein halen. Dat betekent ook dat-ie altijd achter de feiten aan holt. Zeg +/-10 encoderpulsen of microsteps in een dynamische situatie (met statisch positioneren krijg je geen werkstuk klaar), dan zit je niet heel ver naast de waarheid.

Dan moet je al minstens 10x zoveel pulsen uitsturen als de positioneringnauwkeurigheid en synchroniciteit die je wil halen. En dan is 400kHz opeens niet meer zoveel. En een specificatie die ook niet onbelangrijk is: de jitter op de pulsen. Als 100000 pulsen/sec betekent dat er eentje komt na 8usec en de volgende na 12usec dan klopt die 100000 wel, maar de velocity estimator in de motordrive heeft er een zware dobber aan, want veel ruis op het snelheidssignaal en nog meer ruis nadat je het gedifferentieerd hebt om er een motorstroom/koppelsignaal uit te destilleren. De laatste keer dat ik het bij Eding controleerde was die jitter best beroerd, maar eerlijk is eerlijk, dat is alweer een tijdje geleden (CPU5B/4.02 zo uit het blote bolletje)

Al met al: ik zeg niet dat die 400kHz voor de doelgroep van Eding onvoldoende is. Ik zeg alleen dat het een stuk minder royaal is dan jij denkt. Het zou voor de 30 jaar oude servos op mijn freesmachine onvoldoende zijn om ze ten volle te kunnen benutten.

[Kars-cnc]

1280000ppr, 20bit encoder voor de A2. De A3 zelfs met een 24bit encoder.

Je ziet dat soort dingen wel vaker, 20 of 24-bit resolutie encoders, maar die bestaan echt niet hoor! 20 bit betekend 1 miljoen stapjes per omwenteling en bij 24-bit is dit nog 16 keer meer. Dit wordt geproduceerd door gewoon te interpoleren tussen veeeel minder fysieke stapjes (zou zomaar 1024 stapjes kunnen zijn) van de encoder. De relatie van die bitjes met met de exacte mechanische positie is dan ook heel zwakjes. Vergelijk het met een stappenmotor met 16384 microsteps (14-bit), dat is echt niet nauwkeuriger dan 16 microsteps (4-bit).

De enige reden waarom je meer stapjes zou willen is om het regelcircuit wat fijnmaziger te maken waardoor het wat soepeler kan reageren. Maar dan nog zijn dit soort getallen een belachelijke overkill.

Het is gewoon marketing, voor de fabrikant kost het niets om naar meer bits te interpoleren. Hij weet dat dat helemaal niet nuttig is maar merkt ook dat de klant er op kikt. Als die, zonder enig kennis van zaken, moet kiezen uit 16-bit resolutie of 20-bit resolutie dan kies hij al snel 20 bit. Tja, als jij die dan niet maakt omdat je het onzinnig vindt maar je concurrent doet dat wel...

[Kjelt]

Allereerst, step/dir als positiecommunicatie heeft maar 1 klein minuscuul voordeeltje: het is conceptueel simpel.

Het grootste voordeel IMO is dat de driver/motor combinaties super voordelig zijn zodat hobbieisten / starters ze kunnen aanschaffen.
Dat het verre van perfect is ben ik helemaal met je eens.

Ik begrijp de snelheidswens wel beter nu maar zie dat dan inderdaad liever in een ander protocol dan step/dir.
Tja en welk nieuwe default protocol zou dat dan moeten worden ?

Ethercat lijkt leuk maar simpel voorbeeld in ons bedrijf zitten er al 3 man een maand te kijken waarom een bepaalde ethercat setup niet werkt zoals verwacht.
Wireshark is dan kennelijk niet echt voldoende meer als tool en een hardware network analyzer kost meer dan een nieuwe auto.
Hoe zit het met de onderlinge compatibiliteit, zeg maar duitse vs chinese drivers ? Gaat dat altijd werken ?
Om jitter bij ethercat te voorkomen zul je (tenminste zover als ik het begrijp) ook een gedistribueerd synchronisatie kloksignaal moeten hebben naar alle slaves. Wel veel mooier dan step/dir dat dan weer wel.

[Kars-cnc]

Om jitter bij ethercat te voorkomen zul je (tenminste zover als ik het begrijp) ook een gedistribueerd synchronisatie kloksignaal moeten hebben naar alle slaves. Wel veel mooier dan step/dir dat dan weer wel.

Klopt, ethernet zelf is niet voldoende real time maar die klok synchronisatie zit volgens mij al in het systeem in gebakken, hoef je je als gebruiker niet meer om te bekommeren.

Wat ik niet weet... hoe communiceert een CNC controller de uitvoer van G-code naar de ethercad drivers? Iemand die dat weet?

Overigens zou ik als ik Eding was prioriteit geven aan het ontwikkelen van ethercad ondersteuning boven al die user interface dingetjes waarover gebruikers toch altijd van mening zullen blijven verschillen. Deze persoonlijke mening is om nog een klein beetje on-topic input in te brengen

[Kjelt]

Wat ik niet weet... hoe communiceert een CNC controller de uitvoer van G-code naar de ethercad drivers? Iemand die dat weet?

Dat hangt van het ondersteunde profiel af.
Je kunt allerlei protocollen over Ethercat heensturen.

Ethercat is alleen OSI layer 1 en 2. Layer 3-6 worden geskipped en op layer 7 draait je applicatie protocol.
Een van de mogelijke protocollen is IEC 61800-7 (CiA 402) drive profile.

Alle google resultaten die ik daarvan vindt zitten achter een betaalmuur, wellicht dat jij ergens een kopie te pakken kunt krijgen dan hou ik me ook aanbevolen.

[keesfrees]

( ten overvloede ? / voor een ieder, ter info )

https://en.wikipedia.org/wiki/EtherCAT

[Kars-cnc]

( ten overvloede ? / voor een ieder, ter info )

https://en.wikipedia.org/wiki/EtherCAT

Kees, bedankt voor de link! Hier wordt ook verwezen naar het 'Precision Time Protocol' (IEEE 1588) voor het synchroniseren van de klokken. Dat herken ik dan wel weer. Jaren geleden eens betrokken geweest bij een project om (elektronische) meetinstrumenten te triggeren via Ethernet. Iedere unit (servo drive in dit geval) heeft z'n eigen precisie clock. Tijdens initialisatie worden die allemaal gelijk gezet en daarna heb je een bepaalde tijd voordat dat opnieuw moet. Die IEEE 1588 standaard was toen net bedacht en een van de mensen uit dat team vatte het grappig samen; het is net als in een actie-film, voor je de geheime operatie begint zet je allemaal je horloge gelijk.

Je kunt allerlei protocollen over Ethercat heensturen.

Als ik het Wiki artikel zo lees is het SERCOS (Servodrive-Profile over EtherCAT / IEC 61800-7-304) het meest waarschijnlijk voor een CNC machine. Ik heb dat nog niet bekeken maar het lijkt mij nog niet zo gemakkelijk.

Om bijvoorbeeld je X-as servo te vertellen dat hij van A naar B moet zal mooi compact kunnen met alleen de nieuwe positie en snelheid in een data pakketje. Maar nu heb je een X en een Y as die volledig synchroon moeten bewegen. Bijvoorbeeld je staat op 0,0 en doet een G1 X100 Y50. Je kunt de X servo naar 100 sturen met snelheid v en de Y servo naar 50 met snelheid v/2. Dan komen ze mooi tegelijk aan maar hoe vergrendel je nu de gelijkheid tijdens acceleratie en deceleratie. En dat is nog maar G1, hoe doe je dat bij een G2...

Je kunt natuurlijk alles in micro segmentjes opbreken maar ja, dan biedt het weinig meerwaarde t.o.v. een step/dir aansturing lijkt mij.

Goed, voor ik het al te moeilijk inzie zou ik eerst dat SERCOS protocol eens moeten bestuderen