JMC JASM Ac Servomotoren

[chimaerion]

Ah op die manier. Er zijn servocontroller die dat dus doen, de positie in een apart register opslaan voor spanningsuitval bijvoorbeeld.
Maar dan heb je inderdaad dat bijvoorbeeld onze hobby systemen controllers dat daarom nog niet weten.

[bartL]

Dank voor de reacties, ik wist inderdaad wel dat met absolute encoders de exacte positie te bepalen is. Maar dat de bits nog gereserveerd worden voor bepaalde doeleinden is geheel nieuw voor me en maakt het er voor een leek niet duidelijker op.
Als ik dit zo lees dan denk ik dat Eding hier waarschijnlijk niet mee overweg kan. Die moet sowieso altijd Homen na een spanningsuitval oid.

Nu vraag ik mij af of zo'n absolute encoder dan wel zin heeft aangezien de servo niet direct op de as komt maar door middel van een 4:1 vertraging met een tandriem. Wat zouden jullie adviseren?
Als dit geen toegevoegde waarde heeft kan ik namelijk beter voor de A4 driver kiezen ivm de extra kosten die dan overbodig zullen zijn.

[DaBit]

Ik denk dat het met Eding inderdaad niet zo heel veel zin heeft, zo'n absolute encoder.

[Kjelt]

Ik denk dat het met Eding inderdaad niet zo heel veel zin heeft, zo'n absolute encoder.

Even ter zijde bij welke controller dan wel? Linuxcnc ?

[bartL]

Ik denk dat het met Eding inderdaad niet zo heel veel zin heeft, zo'n absolute encoder.

En heeft een 17bit incrementele encoder dan wel zin of kan ik dan beter gewoon voor de 2500ppr gaan?

Overigens zit op de originele machine de encoder niet op de motor maar direct op de KO. Dus na de vertraging. Op zich lijkt me dit de beste oplossing maar zo'n geïntegreerde encoder met passende driver zie ik (ivm beperkte electro kennis) wel meer zitten. Zijn er hier meer die de encoder op de motor gebruiken en daarna nog een riemoverbrenging hebben? En zo ja, gaat dit goed?

[chimaerion]

Die 2500 ppr vs de 17bit is een afweging die jij moet maken afhankelijk van jouw gewenste minimale nauwkeurigheid.
Met 2500 ppr heb je een hoekresolutie van 0,144 graden (voor vertraging) met de 17bit (14bit voor positie bv) heb je een hoekresolutie van 0,02 graden (voor vertraging).

Encoder hoeft niet perse aan de motoras gekoppeld te zijn maar het is wel heel gangbaar en het gemakkelijkst in mijn ogen. Wil niet zeggen dat ze niet ontvankelijk gemonteerd kunnen worden, maar er moet dan al dan niet een conversie gebeuren afhankelijk van de vertraging.

Bij mijn servomotors met geïntegreerde drivers zit de encoder rechtstreeks geïntegreerd op erin op de motoras, alsook bij bijna alle closedloos stepper motoren.

Maar bij de meeste servodrives kun je gewoon de encoder signalen erop aansluiten en maakt het niet uit of de encoder op de motor zit of niet, je moet dan gewoon wat parameters invullen naargelang de mechanische constructie en vertraging.
De rest vogelt de servodrives wel zelf uit.

[DaBit]

Even ter zijde bij welke controller dan wel? Linuxcnc ?

Ja, LinuxCNC kan overweg met absolute encoders en resolvers.
Of LinuxCNC dat ook kan met de JMC encoders weet ik niet; die encoder moet natuurlijk wel zijn absolute positie aan LinuxCNC doorgeven, en daarvoor moeten ze hetzelfde taaltje spreken. Ik weet dat het werkt met SSI/BiSS encoders.

Als EdingCNC trouwens bij afsluiten de machinepositie opslaat, bij opstarten weer inleest, en de drive zorgt ervoor dat de as bij opstarten weer op dezelfde plek terecht komt als waar-ie was bij het afsluiten dan zou het kunnen werken.

En heeft een 17bit incrementele encoder dan wel zin of kan ik dan beter gewoon voor de 2500ppr gaan?

Jazeker. Kennis is macht. Hoe hoger de resolutie van de encoder, hoe beter de drive weet wat-ie aan de motor moet voeren om exact op tijd op exact de juiste positie uit te komen.

Aan de andere kant moet je resolutie en nauwkeurigheid niet verwarren. Ik vraag me af hoe het daarmee zit.

[bartL]

Maar bij de meeste servodrives kun je gewoon de encoder signalen erop aansluiten en maakt het niet uit of de encoder op de motor zit of niet, je moet dan gewoon wat parameters invullen naargelang de mechanische constructie en vertraging.
De rest vogelt de servodrives wel zelf uit.

In mijn geval is het dan het handigst gewoon de encoder op de motor te gebruiken en eerst eens zien hoe het werkt. Ik kan me haast niet voorstellen dat het voor mijn toepassing niet nauwkeurig genoeg is. En mocht het dan toch niet goed werken kan ik altijd een encoder op de KO zetten, deze is er immers al op voorbereid.

Ja, LinuxCNC kan overweg met absolute encoders en resolvers.

Kan Linux dan wel rigid tappen?

Aan de andere kant moet je resolutie en nauwkeurigheid niet verwarren. Ik vraag me af hoe het daarmee zit.

Is dit niet hetzelfde dan? Een hogere resolutie betekent toch meer geregistreerde posities en dus een hogere nauwkeurigheid?

[DaBit]

Kan Linux dan wel rigid tappen?

Jawel.

Is dit niet hetzelfde dan? Een hogere resolutie betekent toch meer geregistreerde posities en dus een hogere nauwkeurigheid?

Nee. Een gewone digitale schuifmaat heeft een resolutie van 0,01mm; je leest op 2 cijfers achter de komma af.
De nauwkeurigheid is lager, die zal ergens 0,03-0,05mm zijn.

Met encoders en glaslinealen werkt het niet anders. En ik vermoed dat die 17-bits encoder heel zwaar geinterpoleerd word. Waar ansich niks mis mee is, zolang je maar niet denkt dat het ding op 360/2^17 = 0,0027 graad nauwkeurig is.

[bartL]

Kan Linux dan wel rigid tappen?

Jawel.

Misschien toch maar eens verder verdiepen in Linux dan, ik vind dit wel een misser bij de Eding.

zolang je maar niet denkt dat het ding op 360/2^17 = 0,0027 graad nauwkeurig is.

Ik denk ook niet dat ik die nauwkeurigheid nodig heb.

[serum]

Wij belasten demotoren redelijk dynamisch belasten met het freeswerk. (voor hobbywerk is dat misschien minder dynamisch dan wanneer je de machine echt gaat aanspreken) Een vaste tune is betrekkelijk 'inperfect'. Een goede drive met een een proper algoritme voor de aanpassingen van de instellingen (in run auto-tune) is in het voordeel bij een hogere resolutie van zijn positie tav het oorspronkelijke commando. Deze drives zijn volgens mij ook uitgerust met wat potentere rekenkracht om dit te bewerkstelligen.

De controller (dus niet de driver) staat in eding vast ingesteld hoe snel hij wil dat de as accelereert en hoe snel hij moet bewegen en naar welke positie ie moet. De controller is niet op de hoogte van de positie van de motor of welke andere variabele ook. Wat op zich prima werkt, als het allemaal een beetje op elkaar afgestemd is. Op mijn grotere machine loopt de feedback van de servo's weer door de controller. (de motoren gebruiken volgens mij een 24b encoder) Deze motoren staan o.a. ingesteld op de massatraagheid van de betreffende as en de yaskawa's regelen het verder zelf. that's it. Hier is die hoge resolutie optimaal voor. Ben in de weer geweest om het beter te krijgen met een auto-tune en daarna handmatig de instellingen te optimaliseren, maar uiteindelijk toch weer teruggegaan naar de standaard instellingen. (met een minimale aanpassing van de inertia en nog wat andere randzaken).

Dus de hogere resolutie wordt niet alleen gebruikt voor de positiebepaling/accuraatheid, maar deze wordt onder andere door de driver geanalyseerd en gebruikt als ad-hoc feedback.

Per saldo werk ik met beide systemen. Onderaan de streep vind ik mijn kleinere machine (met de simpele 180W JMC's, met harde tune, V5 geen auto-tune mogelijk) prima werken in 3d werk, omdat hij door Eding beter in staat is om wat complexere vormen (parabolen) soepeltjes te laten verlopen en hij accelereert ook vlotjes en soepel. Ook qua nauwkeurigheid heb ik hierover niets te klagen. Ik ben zeer goed te spreken over de prijsknallervariant.

Dacht dat je met eding wel kon rigid tappen? er kan toch een encoder op de spindel? Met een draaibank kan je er ook prima draad mee snijden, zou niet weten waarom rigid tapping hierin anders is?

[bartL]

Hoi Serum, bedankt voor je uitgebreide reactie. Overigens gaat het inmiddels niet meer over de JMC servos maar om de Lichuan motoren. Het lijkt erop dat het 80ST-M24030 750W motoren gaan worden met 17-bit incrementele encoders en type A6 drivers voor de X en de Z. En voor de spindel een 130ST-M15025 3.8KW servo met 2500ppr encoder en 3fase driver. A2, A4 of B2 drivers kunnen niet meer bij dat vermogen.

Dacht dat je met eding wel kon rigid tappen? er kan toch een encoder op de spindel? Met een draaibank kan je er ook prima draad mee snijden, zou niet weten waarom rigid tapping hierin anders is?

Dat dacht ik dus ook. Maar Eding kan niet met een encoder overweg alleen met een enkele puls. Draadsnijden met een beitel gaat wel maar rigid tapping waarbij de spindeldraairichting omgedraaid wordt gaat niet.

[serum]

Ik noemde JMC en Yaskwawa's.

Doelde erop dat de slechtste en goedkoopste servo's die te krijgen zijn, zonder notchfilters en geavanceerde auto-tune, mij persoonlijk prima voldoen tav duurder verkrijgbare exemplaren. (ik predik meer voor de servo in het algemeen). Ik had wel liever ook Yaskawa's op mijn kleinere machine gehad ivm de fraaie instelmogelijkheden. Maar, zoals gezegd, bevallen ze mij prima.

Ik weet dat er Chinese controllers bestaan die via een bus met alle betrokken drivers babbelen, de absolute encoders van de drivers ook kunnen gebruiken voor het 'nooit meer homen' principe en die ook rigid tapping onderteunen en waar je knappe macro's voor kan maken.