Late respons stappenmotoren

[emperor-nld]

Net nieuw hier en meteen een probleem posten.
Hoop op de juiste plek. Anders graag verplaatsen
Ik bouw mijn eigen CNC machine op basis van nema 23 close loop stappenmotoren, CL57T drivers, Arduino Uno met GRBL 1.1h
Alles aangesloten volgens de specificaties.
De drivers worden gevoed door een 36V 400W 11A voeding.
Wanneer de drivers spanning krijgen dan zijn de assen niet met de hand te verdraaien. Zoals het hoort.
Wanneer de Arduino middels USB wordt gevoed zijn de assen te verdraaien. ook normaal.
Indien ik UGS opstart en een connectie maak, hetgeen lukt, want de GRBL is uit te lezen middels $$, blijven de assen met de hand verdraaibaar. Hoort naar mijn mening niet.
Wanneer ik een verplaats opdracht geef over b.v. 100mm dan hoor ik de stappenmotor, gebeurt er een paar tellen niets en dan draait de as.
Maakt niet uit welke as. Gedurende die korte pauze zie ik in UGS dat de coördinaten wel wijzigen. Er is dus feedback dat de as verdraaid.

Wat heb ik zelf al geprobeerd:
Elke as (X-Y-Z) afzonderlijk getest met wissen van stappenmotoren en drivers.
De arduino een op externe voeding aangesloten (9V) > Geen resultaat
De enable pin in GRBL inverted > assen zijn niet meer te verdraaien, maar verdraaien ook niet na opdracht

Het moet iets zijn met GRBL, want wanneer ik EstlCam gebruik, na de instellingen te hebben geflashed dan werkt alles perfect.
Ik weet dat EstlCam eigen firmware gebruikt.
Na terug flashen van GRBL zijn de problemen weer terug. Hetzelfde geldt voor LaserGRBL en LightBurn. Hier wordt hetzelfde gedrag vertoond.

Een heel verhaal, maar ik begrijp niet waar het aan kan liggen.
Mogelijk heeft iemand van jullie een zelfde ervaring gehad?
Indien er meer info nodig is hoor ik het graag.

Alvast bedankt
Gr Ronald

[Bjornski1976]

Hoi en welkom,

Vergeet je niet voor te stellen, aan te geven waar je je ergens begeeft op deze aardkloot en post een paar leuk foto's van je machine.

Waar jij naar opzoek bent is "Idle / Holding current setting" in GRBL. Dit zit er namelijk ook niet in.

[emperor-nld]

Hoi Bjornski,
Voorgesteld had ik me eerder al

Kun je jezelf wat meer verduidelijken t.a.v. je antwoord.
Als het een setting is waar zit het dan wel?

[Bjornski1976]

Het is geen setting maar een functie waarbij er stroom door de motoren blijft lopen en zodoende op positie blijft staan.

Het wordt vanuit de software aangestuurd zoals ik weet van Mach3 bijvoorbeeld.

Ik heb hierop gegoogled in grbl en kom het niet tegen. Ook was een ander jou aldoor met dezelfde vraag ergen op het grote web en kreeg hetzelfde antwoord danwel conclusie.

[Bjornski1976]

Op het arduino forum lees is $1=255

Hmmmm kijk hier eens naar en dan $1

https://www.google.com/url?sa=t&source= ... WUVo0ayhkl

[hfjbuis]

Op het arduino forum lees is $1=255
Hmmmm kijk hier eens naar en dan $1

$1 is de step idle delay. grbl stuurt pas pulsen na een $1 ms vertraging. Drivers hebben tijd nodig om het enable signaal te verwerken. Mijn Lichuan servo 100 ms, een TB6600 5 ms (dacht ik). Zet je deze waarde te laag, dan kun je stappen missen. Veel snelheid win je niet, een paar ms bij het starten van een programma.
Wil je de enable altijd aan hebben (voor alle assen) dan kun je deze waarde op 255 zetten. Dan blijft er ook altijd stroom lopen door de motoren. Bij closed loop is dat verwaarloosbaar maar bij openloop stappenmotoren hangt het af hoe hoog de "hold torque=stop current" staat. Bij 100% loopt er de maximale waarde door de stepper, bij 30% nog maar 30%. Zo'n stepper kan bij 100% behoorlijk heet worden. Ik heb de hold torque op 30% staan.
Of en hoe je de hold torque kunt instellen is afhankelijk van de gebruikte driver. Een TB6600 kun je instellen op 30%, een TB6560 op 20 of 50%.
De hold torque wordt door de driver geactiveerd als er een "tijdje" geen pulsen worden ontvangen.
Ik moet mijn Lichuan servo driver altijd enabled laten anders gaat de positie verlopen (handmatig verdraaien van de as, etc)

Wanneer ik een verplaats opdracht geef over b.v. 100mm dan hoor ik de stappenmotor, gebeurt er een paar tellen niets en dan draait de as.
Maakt niet uit welke as. Gedurende die korte pauze zie ik in UGS dat de coördinaten wel wijzigen.

Als een closed loop motor traag reageert, kan dat ook aan de instellingen (tunen) van de motor liggen zeker op lage stap frequenties. Als UGS een wijziging in de coordinaten laat zien, heeft grbl de stappen ook gestuurd. De motor volgt dan te traag!
Ook een lage acceleratie kan lijken op een traag reageren. De acceleratie wordt primair door grbl geregeld ($120..$122). Daar boven op komt bij close loop motoren ook nog een regeling van de acceleratie. Als de closedloop driver lager staat ingesteld dan de controller, kan dat bij het frezen problemen geven omdat de controller (grbl) verwacht dat de motoren op positie zijn.

Het moet iets zijn met GRBL, want wanneer ik EstlCam gebruik, na de instellingen te hebben geflashed dan werkt alles perfect.
Ik weet dat EstlCam eigen firmware gebruikt

Je kunt kijken welke instellingen EstlCam gebruikt

Indien ik UGS opstart en een connectie maak, hetgeen lukt, want de GRBL is uit te lezen middels $$, blijven de assen met de hand verdraaibaar. Hoort naar mijn mening niet.

Dat is zoals het moet. Grbl is idle en blijft na de verbinding met UGS ook idle

Hoe nu verder:
Als eerste kun je de enable pin van de arduino los koppelen en de driver(s) op enabled zetten. Dan kan de enable delay van de driver geen kwaad meer.
Zet de $1 op de default waarde van 10 ms, dan kan alles met een goede response reageren.

Vervolgens kun je alle motoren los koppelen m.u.v de te testen motor (As).
Dan kun je een as joggen en controleren of 100 joggen ook echt 100 mm is. De resolutie moet eerst goed staan.
Daarna kun je 100 mm joggen met een lage snelheid in één richting en dan 100 mm terug in de andere richting met de halve snelheid. Als het goed is, treed er geen stapverlies op. Als je dit een keer of 10 herhaald hebt weet je of je stap verlies hebt en hoe goed/slecht de herhaalnauwkeurigheid is. Op de closeloop driver zit een controle lampje (ledje) dat aangaat als de driver het signaal van de controller niet meer (binnen grenzen) kan volgen. Dat moet je goed in de gaten houden omdat closedloop drivers uiteindelijk stapverlies corrigeren.

Vervolgens kun je een opdracht geven die beide eerdere opdrachten achterelkaar uitvoert. Daarbij kun je de snelheid verhogen totdat je stapverlies krijgt. Reduceer vervolgens de snelheid met 20%.
Hierna kun je de acceleratie verhogen en bij stapverlies ook weer met 20% reduceren. Dan heb je een basis instelling voor één as.
Dit moet je per as uitvoeren (ook al heb je closed loop).
De gevonden max waarden zijn bij onbelaste bewegingen. Bij belasting kan het zijn dat je toch stapverlies hebt. Dat ledje is belangrijk om te monitoren.

[emperor-nld]

Als eerste iedereen bedankt voor het meedenken.
De $1=255 did the job.

Bij mijn vorige cnc machientje was de standaard waarde goed en wist niet dat bij een close loop deze op 255 moest staan. Weer wat geleerd.

Blij dat het opgelost is. Kunnen we weer verder!