Sneller printen door G-code compressie

Hier kunnen de nieuwste ontwikkelingen en zelfbouw printers besproken worden

Moderator: Moderators

Plaats reactie
Gebruikersavatar
Markus
Donateur
Berichten: 1004
Lid geworden op: 01 sep 2007 22:43
Locatie: Aduard, Groningen
Contacteer:

Sneller printen door G-code compressie

Bericht door Markus »

Door wat in te leveren op nauwkeurigheid op krommen (arc's) kun je G-code files korter maken



Greezt,

Markus
hardy
Berichten: 27
Lid geworden op: 10 jul 2011 14:27

Re: Sneller printen door G-code compressie

Bericht door hardy »

Maar pas wel op met Arc-welder, gebruik het alleen maar bij ronde voorwerpen zoals hier getoond en vergeet het nier weer uit te schakelen bij normale printen, want daar werkt het averechts met erg oneffen oppervlakten.
Gebruikersavatar
serum
Berichten: 5396
Lid geworden op: 08 mar 2008 20:37
Locatie: Zwolle

Re: Sneller printen door G-code compressie

Bericht door serum »

Sinds ik klipper gebruik geen stotteringetje meer gehad met printen, die trajectplanning icm wat meer rekenkracht is toch wel erg prettig.
hardy
Berichten: 27
Lid geworden op: 10 jul 2011 14:27

Re: Sneller printen door G-code compressie

Bericht door hardy »

serum schreef: 08 mei 2022 08:20 Sinds ik klipper gebruik geen stotteringetje meer gehad met printen, die trajectplanning icm wat meer rekenkracht is toch wel erg prettig.
Daarvoor wel??
Welke stotteringetjes moet ik mij daarbij voorstellen, ik merk geen verschil met Marlin vs Klipper, het enige voordeel wat ik tot nu toe met klipper heb is het gemak van het direct kunnen aanpassen van parameters in de firmware, de 32 bit van een standaard board is ruim voldoende, theoretisch heb je natuurlijk meer rekenkracht van de Raspberry, maar in de praktijk heb je daar nu zo veel aan volgens mij, ja hogere printsnelheden met alle negatieve gevolgen voor de mechaniek en print kwaliteit.
Gebruikersavatar
serum
Berichten: 5396
Lid geworden op: 08 mar 2008 20:37
Locatie: Zwolle

Re: Sneller printen door G-code compressie

Bericht door serum »

Ja, ook met marlin. Ook met een 32b controller.

zeg maar gebrek aan de G64 smoothing. Directe resultaat van een gcode bestand genereren vanaf een STL, waarbij je geen mooie curves en splines hebt maar met relatief korte coordinaten werkt. (waarbij splines alweer lastiger zijn). Kreeg ik met de S-curve in marlin niet lekker voor elkaar. Lineair advance werkte voor mij destijds ook meer slecht dan goed.

Ik heb met diverse firmwares getest. (smoothieware, marlin, repetier en sinds een jaar oid klipper)

Die ringing compensatie welke je kan tunen met de adxl845 werkt uber, Pressure advance idem. Voorspelbaar en herhaaldeijk goede resultaten. Ik print ondertussen de kleinste onderdeeltjes op 160mm/s met een kwaliteit waar ik voorheen niet aan kwam op 60mm/s. Misschien heb je het over veel hogere snelheden, maar qua souplesse is de combinatie klipper met de resonantie compensatie toch ongeevenaard tav marlin op hogere snelheid/acceleratie. De printer nu op 10000mm/s2 acceleratie maar door de demping van de resonanties beweegt het nog opmerkelijk rustig. Met marlin zonder de ringing compensatie beweegt het op die snelheden minder stil door het gebrek aan die resonantiedemping. (wat een grotere belasting voor je mechanica is)

Los daarvan; de slicer gaf mij bij marlin altijd een tijd weer die ongeveer X1,5 moest, en ondertussen is dat X0,7

Ik ben geen fanboy, maar ik erken wel wanneer iets beter werkt voor mij. Ik zou geen printer meer bouwen zonder klipper. Net zoals dat ik geen CNC meer zou maken zonder servomotoren, waar ook niet iedereen het mee eens is. Voortschrijdend inzicht, opgedaan door eigen ervaring.

Negatieve gevolgen voor de mechaniek; dat is afhankelijk van de gekozen hardware en opbouw van de printer en de gekozen printsnelheid. die resonantiedemping helpt je mechanica ook op een vriendelijke wijze.

Voor de X as heb ik nu nog een MGN9 rails ipv de MGN12 en een 20x20 carbon koker ipv het 2020 aluminium profiel zodat de acceleratie zonder nadelige gevolgen, nog wat omhoog kan.

https://www.youtube.com/watch?v=JZVolLQ1axE
hardy
Berichten: 27
Lid geworden op: 10 jul 2011 14:27

Re: Sneller printen door G-code compressie

Bericht door hardy »

serum schreef: 08 mei 2022 14:47 Die ringing compensatie welke je kan tunen met de adxl845 werkt uber, Pressure advance idem. Voorspelbaar en herhaaldeijk goede resultaten.
O.K.
De adxl845 heb ik ook nog liggen om te proberen, misschien denk ik er dan ook wel anders over, ik heb overigens verder ook geen speciale onderdelen gebruikt op m'n DIY Core-X/Y.
diepchess
Berichten: 1430
Lid geworden op: 02 jul 2013 11:02
Locatie: Veenendaal
Contacteer:

Re: Sneller printen door G-code compressie

Bericht door diepchess »

Markus schreef: 01 mei 2022 13:48 Door wat in te leveren op nauwkeurigheid op krommen (arc's) kun je G-code files korter maken



Greezt,

Markus
Welke 3d printer software produceert dan gcodes van krommes? In werkelijkheid zeggen ze toch gewoon X en Y coordinaat - hoegenaamd geen krommesturing. Het is met name zo van ga naar X en Y toe en volgend X en Y coordinaat ligt dan paar honderdste verder hooguit.

Dus ze produceren al enorme lappen text daar qua gcode en herkennen rondingen simpelweg niet als dusdanig.

Snelheid van parseren van die texten is echter compleet verwaarloosbaar zo lang de software maar buffering gebruikt en wel een buffer die binnen de caches van de clockprocessor in kwestie passen.

In theorie kun je de zwaarste machine op de hoogste snelheden met 8 bits processortje aansturen - no problem - en ook 7 motoren tegelijk ofzo.

NO PROBLEM.

Dit waar 32 bits clockprocessortjes wel veel wenselijker zijn.

Echter zodra je dus de hele gcode file lokaal op zo'n klein hoofdletter K processortje wilt hebben dan zit je ook met read latencies naar de i/o.
In geval dat pokketrage i/o is zonder DMA dan hang je natuurlijk.

Wat meeste vertraagt is altijd van die python interpreters die overal roet in eten gooien en dan vooral de memory defragmentation (intern zijn die interpreters altijd bezig met vrijgegeven geheugen weer aan elkaar te bouten wat 1 van de meest trage operaties is). Dan nog een niet-realtime kernel erbij en je hangt.

Ook in C++ kun je problemen krijgen. Allocatie en deallocatie van objecten is takketraag tenslotte. Herinner me daar in de adobe source code waar dus templates gebruikt worden om hele objecten bij elkaar te smijten en als je paar objecten bij elkaar smijt dan heb je dus photoshop en paar andere templates erbij en hop je hebt indesign ineens. Dat alloceert echter geheugen en dealloceert geheugen, wat de traagste operaties zijn. Dat is waarom die starttijden zo takketraag zijn van die software, terwijl dat binnen fractie van seconde zou moeten starten als het netter was geprogrammeerd.

Maar puur de gcode die gevoerd wordt aan de CAM software - al ram je er miljoenen regels doorheen - dat HOOR je niet op te merken qua vertraging.

Hoe je redelijk veilig kunt 3d printen is vanaf een computertje de printer aansturen. Niks memory card erin dus. Dus de grafische software draait op je computer. Dan kabeltje naar printer toe. De code op het 3d printer bordje hoeft dan niet meer i/o te doen richting opslag. Die buffert enkel en alleen wat vanaf een usb kabeltje komt. We kunnen bewijzen dat je dan geen haperingen meer kunt krijgen in theorie, anders dan als er software of spyware is die je computertje trasht.

Zelfs een ouderwetse pronterface (windows) of printrun (linux versie) ga je nooit problemen mee krijgen ongeacht de printsnelheid. 40mm/s versus 400mm/s dat zijn lachwekkende snelheden t.o.v. de processoren aankunnen.

Zo'n 8 bits ATmega2560 draait op 16 Mhz. Dan is het nog handige clockprocessor ook zo'n arduinootje. Dus als je puur kijkt naar hoeveel clocks per instructie aansturing kost. Dat is echt lachwekkend weinig ten opzichte van wat je nodig hebt. De meeste clocks raak je dan kwijt omdat coordinaat systeem niet 8 bits is maar 16 of 32 bits.

Dus zodra je 32 bits clockprocessortje hebt en met 32 bits floats de zaak aanstuurt dan kun je dus vele miljoenen regels per seconde uitvoeren in theorie. Zo'n 3d print snelheid halen ze zelfs in startrek niet met warpdrive ingeschakeld :)

Dus als je weet te bepalen hoe weinig clocks per instructie nodig zijn op de clockprocessor om 't af te handelen dan snappen we allemaal dat daar de vertraging 'm niet in zit.
Plaats reactie