module ring (id, wt, h)
{
  difference () {
    cylinder (d=id+2*wt, h);
    down (1) cylinder (d=id, h=h+2);
  }
}

rr = 45/2;
r2 = 60/2;

module b1 (i)  translate ([rr*sin(i),rr*cos(i),0]) sphere (d=5);
module b2 (i)  up (40) rot_y (-40) translate ([r2*sin(i),r2*cos(i),0]) sphere (d=5);

output = 0;

if (output == 0) {

  down (50) ring (40,5,50);
  s = 10;
  for (i=[0:s:180]) {
    hull () {
      b1 (i);
      b2 (i);
      b2 (i+s);
      b1 (i+s);
    }
  }
}

De "handige dingen" die ik gebruik zal je "even" zelf moeten schrijven. Is minder dan 60 sec werk.

Op maandag 24 augustus 2026 23:34:27 schreef rew:
De "handige dingen" die ik gebruik zal je "even" zelf moeten schrijven. Is minder dan 60 sec werk.

Misschien wel, als je weet wat 'up' en 'down' exact doen... ;)
(zullen wel 'iets' bij 'iets' optellen of aftrekken...)

Bovenstaande file renderen duurt zo'n 2.5 minuten in Openscad. Wat maakt 't zo traag?
(kan ik daar voortaan rekening mee houden)

Bij mij Total rendering time: 0:00:00.040
Openscad 2021.01

[Bericht gewijzigd door Retirado op (18%)]

Trage computer? :)

$fn op een kleinere waarde zetten als je een preview wil doen.
Misschien zoiets aan't begin van je file zetten:

$fn= $preview ? 30 : 100;

Bij preview cirkel in 30 "bogen", bij render 100.

En "preview" is een stuk sneller dan "render".

Op woensdag 26 augustus 2026 16:50:34 schreef Arco:
Bovenstaande file renderen duurt zo'n 2.5 minuten in Openscad. Wat maakt 't zo traag?
(kan ik daar voortaan rekening mee houden)

Zoals als vaker gezegd, stap over op de laatste Nightly versie 2026.08.23. Render in nog geen seconde.
https://openscad.org/downloads.html#snapshots

Scheelt inderdaad serieus in snelheid:

Op woensdag 26 augustus 2026 16:50:34 schreef Arco:
Bovenstaande file renderen duurt zo'n 2.5 minuten in Openscad. Wat maakt 't zo traag?
(kan ik daar voortaan rekening mee houden)

Dat je CGAL gebruikt ipv manifold. Er zijn een paar versies geweest waarbij je manifold als test kon proberen (nooit problemen mee gehad), maar CGAL nog default was. Volgens mij is manifold dus de default vandaar dat marcob en ese roepen dat nieuwere versie veel sneller is.

Minkovski is traag. Ook in manifold. Gewoon niet gebruiken in serieuze projecten.

"intersection" was in mijn waarneming ook traag. Toen ik dat van de week op de mailinglist liet horen (*), riep iemand: Dat is alleen voor de "preview". Tja, tijdens het ontwikkelen gebruik je die preview dus enorm veel.

Dat getal van 0.146 sec aan rendering tijd zie ik ook regelmatig. Maar ik kijk daar nooit naar tenzij het langzaam aanvoelt. Ik kan als mens waarnemen dat die 0.146 sec niet kan kloppen. Hij meet niet datgene wat wij als mens willen weten. (van openen file totdat het "af" op het scherm staat).

(*) Iemand had een ding wat ie met twee keer "intersection () { ding (); cube (...); }" in twee stukken had gesplitst. Toen maakte ik dus de opmerking dat ik de difference met de /andere/ cube doe omdat intersection traag is.

[Bericht gewijzigd door rew op (13%)]

Die nieuwe versie had ik geinstalleerd maar is schijnbaar 'zoekgeraakt' bij overstap op een andere computer... ;)
Minkowski loopt ook vaak vast (cpu blijft dan druk bezig maar er gebeurt niks meer, heb hem na een paar uur maar beeindigd...)

Ik ga die nieuwe versie maar weer eens opduiken, bedankt!...
En daarna eerst mijn K1Max printer even upgraden; de default extruder transporter loopt zeer (veel te) regelmatig vast...

(je moet dan de extruder opereren om filament te verwijderen, de nozzle vrijkrijgen, en een autolevel doen...
(dat gaat nogal vervelen... :( )

Komt nu een Phaetus DXC extruder in, die zou geen hitte en transportproblemen hebben.

https://ec3d.nl/cdn/shop/files/PhaetusDXCExtruder-PI2.jpg?v=1757615099&width=800

De extrudermotor wordt bij grote prints ook onaangenaam heet, iets van 80 graden!
Schijnt 'by design' zo te horen, maar ik vind het toch niet erg fris. (gelukkig verkopen ze daar clip-on koellichamen voor...)

Dat getal van 0.146 sec aan rendering tijd zie ik ook regelmatig. Maar ik kijk daar nooit naar tenzij het langzaam aanvoelt. Ik kan als mens waarnemen dat die 0.146 sec niet kan kloppen. Hij meet niet datgene wat wij als mens willen weten. (van openen file totdat het "af" op het scherm staat).

Maar die handelingen tellen voor beide versies.

Ik let daar zelf ook niet op, als mijn laptopje die tijd nodig heeft, dan is dat maar zo.

Het verschil is toch wel opmerkelijk.

Als het 0.3 sec duurt en hij rapporteert 0.146 sec, dan hoor je mij niet klagen. Het gaat om het geval dat ie 10sec aan het prutsen is en ik me afvraag waar dat door komt. En dan zegt ie dat ie 0.146s er over gedaan heeft. Dan helpt dat getal dus niet in het vinden, rapporteren van waar de traagheid vandaan komt. En dat is precies waar ie voor bedoeld is.

Developers kunenn dan zeggen: "Je hebt een model met 0.5 miljoen vlakjes, dat ie dan 10sec aan het rekenen is dat is normaal, hier doet ie er 20 sec over. Toffe computer heb je".

"hier duurt het ook best lang, maar hij rapporteert hier ook 0.146 sec " is veel minder productief.

Thingiverse stuurt mij nu mailtjes dat als ik betaal, ze de artificiële wachttijd op downloads verkorten en minder (of geen) reclames tonen...

Doet me toch denken aan een bepaald Noors filmpje... https://www.youtube.com/watch?v=T4Upf_B9RLQ

(Ik was al eerder vanwege dergelijke shit naar Printables overgelopen, maar met dergelijke "reclame" mailtjes ga ik er "iets over zeggen" ook.)

(“Keep … free by paying for …” is ook een beetje een vreemde constructie. Dat ze betaald willen worden is op zich prima, maar “betaal ons, anders kunnen we niet gratis blijven” is gek, en “we gaan extra moeite doen om een downloadvertrager te bouwen voor iedereen die niet betaald” is ook niet “we doen moeite voor de community, steun ons!” maar meer “we doen moeite tégen de community, pay or else”)

[Bericht gewijzigd door Lucky Luke op (37%)]

Ik krijg een nieuwe extruder, hot-end, en camera opgestuurd voor mijn K1Max via de dealer waar 'ie gekocht is.
Da's wel netjes, maar ik ben bang dat het niks oplost (het zijn dezelfde onderdelen tenslotte...)

Maar ze wilden toch dat ik het probeer, dus vooruit maar... (slechter kan 't niet worden (toch?)

Is wel storend dat Creality zegt de problemen niet te kennen. (terwijl hun forum vol staat met dezelfde klachten)
Schijnbaar lezen ze hun eigen forumberichten nooit...

LightMake L4 – interessante Kickstarter-printer

Ik heb de LightMake L4 gebackt. Technisch interessant omdat hij vier onafhankelijk bewegende printkoppen heeft, aangedreven door lineaire motoren. Dus geen AMS-achtige kleurwisselaar en ook geen klassieke toolchanger: de vier koppen kunnen echt parallel werken. Voor mij is dat vooral interessant voor verschillende nozzle-diameters en technische filamenten, met minder purge en een kortere doorlooptijd.

De softwarekant ziet er verrassend open uit. De slicer is een OrcaSlicer-fork en de printer draait op Linux, Klipper, Moonraker en Fluidd.

De motion-stack lijkt grofweg: Klipper → Modbus/UART → STM32 motorcontrollers → lineaire motoren

De hostkant is grotendeels leesbaar; de eigenlijke servo-control firmware op de STM32's is nog binair.

LightMake heeft toegezegd firmware en slicer rond massaproductie open source te publiceren. Dat vind ik belangrijk: voor € 1600 wil ik geen printer die over vijf jaar een zware smart-tv wordt zodra de fabrikant of de cloud verdwijnt.

Hardwarematig blijft de echte vraag natuurlijk: hoe goed werken vier koppen langdurig, wat betreft kalibratie, thermische drift en betrouwbaarheid? Daarvoor wacht ik vooral op onafhankelijke productie-hardwaretests.

Bambu blijft voor mij de benchmark voor “druk op Print en het werkt”.
De L4 moet daarnaast ook de “fabrikant verdwenen, printer werkt nog steeds”-test halen.

We waren hier in discussie over een 3d Printer probleem, specifiek gericht op de Creality.

Naar aanleiding van deze bijdrage, besloot ik me weer 's te verdiepen in mijn eigen 3d printer-ervaringen.

Op dinsdag 29 september 2026 10:17:20 schreef sanscorp
Bed leveling: je verplaatst de kop niet met de hand naar de 4 hoeken maar je bestuurd hem met de controls. Kop aanraken of (geforceerd) met de hand verplaatsen na homing is een absolute no-go. Na homen is het afblijven, twijfel is opnieuw homen.

Het bed maak je niet waterpas, hier denkt men snel aan letterlijk een waterpas, al zet je de printer 45 graden, het gaat om de afstand nozzle<->bed en die moet overal zo goed als gelijk zijn. We hebben het hier over binnen de tolerantie 0.05mm.

De z offset is het eerste wat je afstelt. Bed leveling komt daarna en daarna doe je nog een keer z offset.
Als je inderdaad je bed kunt stellen d.m.v. de draaiknoppen aan de onderzijde ben je rustig aan uur bezig om het echt goed te krijgen en de papier methode is nog grof en onbetrouwbaar.

Een bltouch of andere sensor kan helpen NA handmatig zo nauwkeurig mogelijk instellen en maakt toekomstige correcties makkelijker. Soms zijn er kleine programmaatjes (macro's) in de printer uit te voeren zoals bed leveling en z offset instellen. Die maken het je iets makkelijker en elimineren het papiertje, maar die moeten wel absoluut betrouwbaar zijn.

Ik ben ooit 's begonnen met het optimaliseren van een FLSun 3d printer, een goedkope Chinese 3D printer.
Daarmee heb ik me de techniek wat eigen gemaakt en kon ik best aardige dingetjes printen.

Toen besloot ik een wat geavanceerdere printer aan te schaffen, met 2 onafhankelijke printkoppen, zodat ik wateroplosbaar filament kon gaan gebruiken.
Dat werd de Kywoo 3d tycoon idex.

Nou daar héb ik me toch een hoop tijd in gestoken om dat bed vlak te krijgen. Dat bed stond namelijk een beetje bol. Ik kreeg m'n eerste laag maar niet goed.
Ik heb zelfs het bed proberen vlakker te schuren, wat een aardig monnikenwerkje was. Maar ook dat hielp niet afdoende.
Toen heb ik de boel maar aan de kant gegooid. Ik was het echt spuugzat toen.

Intussen staan er 2 3d printers al een paar jaar in de hoek te niksen. Weggooien is eigenlijk zonde.

Het gaat toch weer kriebelen om het 3D printen nu 's echt van de grond te krijgen, maar ik weet niet zo goed wat ik zal doen. Deze 2 printers wegkieperen en nog één keer een investering doen voor bijv. een Bambulab printer?

Of stap voor stap nog 's gaan kijken waarom ik die Kywoo niet netjes kan laten werken.

Ik las wel in de bijdrage van sanscorp dat je bij het levelen niet met de hand de kop moet verplaatsen.
Wat ik wel altijd deed (want: zo wordt het in de youtube video's uitgelegd). Dus dat is het eerste wat ik kan gaan uitproberen: of het beter gaat als ik de kop mbv de software laat bewegen.

/Edit
Vanavond de Kywoo maar 's afgestoft en aangezet.
Ik ben weer 's gaan testdraaien met een proefobject van 1 layer hoog.
Bij de eerste pogingen was de Z-offset te hoog (afstand te groot). Die stapsgewijs verlaagd, totdat het object er zo uitkwam.

En dat snap ik dan dus niet.
Je ziet een scherpe overgang van waar de Z-offset te hoog is, en dan opeens wel juist blijkt te zijn.