Wie weet wat hier gebeurt

[DirkSchipper]

Hallo,

Om te testen of mijn vorige probleem opgelost was, heb ik hem een stukje langdurig werk bezorgd: een contour frezen tot 5 mm diep in diepte-stapjes van 0,01 mm. En dan maar wachten tot je een ons weegt ...

Eerst een tijdje staan kijken, maar na rondje 100 heb je dat ook wel gezien. Ik kom strak nog wel eens kijken. Dooeeeiii.

En ja, na iets meer als 200 rondjes was het fout gegaan.
Later kwam ik erachter dat het een heel andere fout was. Nl. geen storing vanuit het electriciteitsnet, maar ??????? tja wat?

Oké, de contour (een DXF) was deze:

Dit zijn 2 identieke splines (boven en onder)waarbij de een gepunt-spiegeld is door de oorsprong (die precies in het midden staat)

Als ik die in CamBam (v0.98P) open en verschillende machining-paths bereken, krijg ik dit:

Alle 4 de routes zijn hier zichtbaar, en het ziet er goed uit.

Vervolgens elke 'machining' in een aparte .NC-file gesaved en in EdingCNC geopend:

Contour Outside


Contour Inside


Pocket


Engrave
https://test.sjippertjes.nl/RoutingErro ... ngrave.PNG

Conclusie: engrave is de enige die het goed doet.
Heeft iemand enig idee wat hiet gebeurd?
Waar komen die cirkels vandaan? en niet bij elke bewerking dezelfde?
Doe ik iets fout?

N.B.
Alle afbeeldingen, de DXF, de NC-files, en het CamBam-project kun je hier downloaden

[hugo stoutjesdijk]

Waarschijnlijk is de lengte van de boog te kort, dan denkt Eding dat het startpunt gelijk is aan het eindpunt en wordt het een volle cirkel.
Is wel een instelling in de PP van CamBam voor.

2022-03-30 17_28_46-CamBam+ Untitled.jpg

Zet je die op 0.2 of zo en als dat helpt kun je ook kleiner proberen, misschien is 0.01 ook al goed.

[DirkSchipper]

Hugo bedankt voor stap-1. Hiermee heb ik een deel kunnen oplossen, maar niet alles.
Ik heb de Minimum Arc Length aangepast van 0,0001 (default) naar 0,001 en vervolgens naar 0,01.
Groter lijkt me niet realistisch.

De kleine cirkels zijn weg:


Maar die twee grote zijn er nog.
Er bestaat ook nog een Maximum Arc Radius. Default stond die op 10000. Ik heb zowel kleiner als groter geprobeerd (2500 en 100000), maar dat veranderde niks.

[hfjbuis]

Ik gebruik grbl en die doet ook wel eens raar als je een hele cirkel probeert te maken met één gcode of als de dX en dY na afronding (0.001 mm is interne resolutie van grbl) op 0 uit komt. Ergens in de grbl Wiki staat dat je een cirkel beter kunt splitsen in 2 halve cirkels. Daarnaast controleer ik of de delta X en Y niet alle twee kleiner zijn dan 0.001 mm.

Volgens een CNC referentie https://www.cnccookbook.com/cnc-g-code- ... e-g02-g03/ (dacht ik) kun je ook beter de IJK notatie gebruiken om problemen te voorkomen.

Daarmee zijn bij mij alle problemen opgelost.

[hugo stoutjesdijk]

Hugo bedankt voor stap-1. Hiermee heb ik een deel kunnen oplossen, maar niet alles.
Ik heb de Minimum Arc Length aangepast van 0,0001 (default) naar 0,001 en vervolgens naar 0,01.
Groter lijkt me niet realistisch.

De kleine cirkels zijn weg:


Maar die twee grote zijn er nog.
Er bestaat ook nog een Maximum Arc Radius. Default stond die op 10000. Ik heb zowel kleiner als groter geprobeerd (2500 en 100000), maar dat veranderde niks.

Dan zou ik het toch ook nog even met 0.05 proberen, dat ga je echt niet terug zien. En weet je tenminste of het dan wel weg is.
Als je het regelnummer weet waar dit gebeurt kun je pas bepalen wie er ongelijk heeft, Eding of CamBam. Heeft alles met reken afrondingen te maken. (en sinus cosinus tabellen vermoed ik)

Ik zou juist eerder op R programmering overstappen ipv IJ, bij een R wordt een cirkel per definitie nooit groter dan 180 graden, en kan die dus geen
(bijna) volle cirkels doen,( er zijn besturingen die doen bij een negatie R waarde het segment groter dan 180 graden).
Het is dan weer wel zo dat R programmering weer andere effecten kan hebben bij bepaalde grensgevallen, maar dat is een beetje geneuzel wat je meestal alleen merkt met handmatig programmeren.

[DirkSchipper]

Het is gelukt. Eerst maar eens die Minimum Arc Length op 1 gezet. Toen waren alle problemen verdwenen. Vervolgens stap-voor-stap verkleind. 0,1 was te klein, maar 0.15 was goed.

Wel vraag ik me af wat de consequenties zin voor de nauwkeurigheid?
Als ik het goed begrijp wordt een 'Arc' vervangen door een 'line' als de 'Arc Length' minder dan 0,15 (mm) is.
Als het dan gaat om een een arc met straal 10000, is dat inderdaad een verwaarloosbaar verschil.
Maar als het gaat om een kleine straal (0,5 of 1) dan wordt het verschil groter.

Hoe kijken jullie daar tegen aan?

Gr. Dirk.

[hugo stoutjesdijk]

Tsja, iemand maakt natuurlijk een fatale afrondingsfout. En je zult er dus eerst achter moeten komen waar die fout zit.
Je zou die minimum boog lengte ook relatief tov de radius willen misschien. Of nog beter wanneer het verschil tussen koorde en boog kleiner dan een bepaalde waarde is.
Aan de andere kant die waarde weer op 0.01 zetten en de max radius terug zetten naar 1000 doet de truuc misschien ook al.
En zoals ik ook als vermeldde is een andere mogelijkheid om in plaats van IJ met R te werken volgens mij ook prima te doen.
Maar ik zou toch eerst die paar regels code willen zien waar het gebeurd, dan kun je ook iets beter verzinnen wat de juiste route is.
Misschien zit er in de dxf al een slordigheidje.
Programma even in een ander besturingssysteem bekijken, LinuxCNC of zo, is ook een mogelijkheid, als die hetzelfde doet.
Ik zit me trouwens af te vragen of je in een gegraveerde tekst (toch lekker priegelwerk) het gaat zien als je die Arc lengte op 0.2 zou zetten ipv. 0.01
Dan zou in het ergste geval de boog van 180 graden met een R van 0.2mm afgesneden worden met een lengte van 0.2mm. Evenwijdige lijnen met een afstand van 0.4 mm (anders kan die bocht er niet tussen) zie ik zo snel niet voorkomen. Dus wordt het hooguit een 90 graden bocht die afgesneden wordt, dat is een afwijking van de contour van 0.08 ik denk dat het allemaal een beetje spijkers op laag water is.

Maar als het gaat om een kleine straal (0,5 of 1) dan wordt het verschil groter.

Bij R0.5 en L0.2 slechts 0.01mm

[DirkSchipper]

Aan de andere kant die waarde weer op 0.01 zetten en de max radius terug zetten naar 1000 doet de truuc misschien ook al.

Daar ga ik naar kijken.

Maar ik zou toch eerst die paar regels code willen zien waar het gebeurd, dan kun je ook iets beter verzinnen wat de juiste route is.

Dit is de G-code (in regel3979 gaat het de 1e keer fout):

Misschien zit er in de dxf al een slordigheidje.

DXF

Bij R0.5 en L0.2 slechts 0.01mm

Dat is voor mij meer dan acceptabel. Ik werk in hout.

[hfjbuis]

Dat is een (G3) cirkel met een delta X en Y van 0.02 en 0.1 mm met een radius (I,J) van meer dan 1000 mm. Daar maakt de controller (terecht) een rechte lijn van en dat spoort niet met de settings van de controller.

[DirkSchipper]

Daar maakt de controller (terecht) een rechte lijn van en dat spoort niet met de settings van de controller.

De controller doet iets wat niet volgens zijn instellingen is!
Dat snap ik niet.

[hugo stoutjesdijk]

Dat is een (G3) cirkel met een delta X en Y van 0.02 en 0.1 mm met een radius (I,J) van meer dan 1000 mm. Daar maakt de controller (terecht) een rechte lijn van en dat spoort niet met de settings van de controller.

Inderdaad, nog iets preciezer: een R van 1588 over een af te leggen weg van 0.108 dat is een hoekverschil van 0.004 graden, die trouwens wel correct in de G-code staat.

Maakte de controller daar maar een rechte lijn van, dan was er niets aan de hand. Het feit dat ie er een volle cirkel van maakt is gewoon niet goed te praten, geen idee of er in de instellingen van EdinCNC iets te doen is.
Dus zit er toch wel een wat ruimere afronding in EdingCNC waar je mee moet handelen zolang het niet gezien wordt als een bug en die ook nog niet verholpen is. Zal vast wel verklaarbaar zijn vanwege het verschil tussen rekenwerk op een microprocessor of op een computer CPU.
Het lastige is de gulden middenweg vinden van de instelwaarden.

[hfjbuis]

Voor een cirkel moet de motor 2 assen tegelijk besturen. Een stuur opdracht naar één motor bestaat uit een aantal stappen met een bepaalde snelheid, een rechte beweging. Om een cirkel te maken, deelt de controller de cirkel op in segmenten. Elke segment wordt als rechte lijn uitgevoerd. Hoe meer segmenten, hoe nauwkeuriger de cirkel gemaakt kan worden.

Nu kun je wel een een segment maken van 0.000001 mm, maar door de elastiek in machine en materiaal en de resolutie van de aandrijving, wordt de radius daardoor echt niet nauwkeuriger. Sterker, als de buffer van de controller vol loopt met veel minimalistische bewegingen, gaat de snelheid omlaag omdat het meer tijd kost om deze bewegingen te bereken en in de buffer te plaatsen dan om ze uit de buffer te lezen en ze uit te voeren.

Daarom kun je in je CAM pakket de max en min waarde van de radius en de chord (tool path) instellen om er voor te zorgen dat de controller dit foutloos kan verwerken.

In de controller kun je vast ergens iets instellen.

Voor mijn grbl controller:

$12 – Arc tolerance, mm

Grbl renders G2/G3 circles, arcs, and helices by subdividing them into teeny tiny lines, such that the arc tracing accuracy is never below this value. You will probably never need to adjust this setting, since 0.002mm is well below the accuracy of most all CNC machines. But if you find that your circles are too crude or arc tracing is performing slowly, adjust this setting. Lower values give higher precision but may lead to performance issues by overloading Grbl with too many tiny lines. Alternately, higher values traces to a lower precision, but can speed up arc performance since Grbl has fewer lines to deal with.

For the curious, arc tolerance is defined as the maximum perpendicular distance from a line segment with its end points lying on the arc, aka a chord. With some basic geometry, we solve for the length of the line segments to trace the arc that satisfies this setting. Modeling arcs in this way is great, because the arc line segments automatically adjust and scale with length to ensure optimum arc tracing performance, while never losing accuracy.

Hugo was weer sneller

[Floppy]

Ik begrijp even iets niet. Als ik jouw contouroutside in mijn edingcnc 4.04 inlees zie ik helemaal niet die rare cirkels. Wat ik wel zie is dat de contour dubbel is.

[hfjbuis]

Dan de eding instellingen naast elkaar leggen en de verschillen zoeken!