FreeCAD Path vragen

[DaBit]

Hier zitten wel wat gebruikers, maar eens vragen..

Ik heb eigenlijk tot nu toe als ik in FreeCAD wat tekende met de CAM (en simulatie) gesmokkeld en Fusion daarvoor gebruikt. Opzich prima, maar bij een wijziging moet je dan wel weer STEP exporteren, importeren in F360, de bewerkingen herstellen, bla. Verder word ik wat moe van de geen-rapids beperking in de gratis variant, moet ik ook in F360 weer uitloggen en inloggen in de betaalde variant van het werk.

Nu kan de Path module in FreeCAD het meeste van mijn CAM-werk eigenlijk ook wel; het meeste van mijn freeswerk is aardig simpel (en zo niet dan is terug naar de tekentafel meestal nog de beste optie). Maarja, oude vertrouwde schoenen zitten zo lekker he?

Goed, we hebben dan een armpje van een racedrone, getekend in FreeCAD (0.20). Daar zijn er 4 van nodig per quad, en ze zijn knap simpel; een paar 3mm gaten boren en een contourtje frezen. Toch maar eens niet meteen naar Fusion rennen, want in dit geval vind ik het wel prettig als de CAM meegaat met verandering van de solid (als ze niet breken maak ik ze lichter totdat ze wel gaan breken, dan doe ik weer een stapje terug. En als ik in de blackboxlogging zie dat de achterste propellers teveel last hebben van de voorste moeten ze een paar mm verder uit elkaar. Is dat niet zo dan mogen ze dichter naar elkaar toe).



De lengte van de armen moet verticaal of horizontaal gefreesd worden vanwege de vezelrichting in de carbonplaat, maar zo is-ie (bewust) niet getekend. Daar kan Path gelukkig goed mee overweg.
Er 4 stuks van maken ook, met een Array.



Gaat in simulatie ook prima:



Enige wat niet helemaal soepel gaat is een Lead-in/Lead-out dressup ook mee-arrayen. Nouja, dat is ook niet zo nodig in dit geval.

Dan komt echter het hoofdstukje 'G-code export', en daar komen de vragen. Ik wil graag de G-code splitsen per tool, want ik heb geen ATC.
Daarvoor is een optie 'split output' met 'order by tool':



Maar wat ik volgens mij nou niet kan is verschillende filenames per gereedschapje toekennen?

Vragen dus:

- Hoe krijg ik verschillende filenames voor de verschillende tools voor elkaar, behalve door ze in verschillende Jobs te zetten, een spelletje enable/disable jobs te gaan spelen, of stiekum renamen in de explorer als FreeCAD de G-code preview laat zien?
- Dat splitsen per tool lijkt ook al niet lekker te werken met die array; er komt eerst G-code uit voor het eerste armpje, daarna voor de resterende 3 stuks. Is daar nog wat mee te doen?

En extra vragen:

- Radiuscompensatie in de machine (G41/G42) lijkt niet ondersteund te zijn. Klopt dat?
- Nesten met een simpel lineair array is in dit geval niet zo efficient kwa materiaalgebruik. De armpjes om en om 180 graden draaien komt gunstiger uit. Dan kan ik zelf wel, maar het is over het algemeen een mooiere klus voor een kabouter. Zit er ergens nesting in FreeCAD die werkt op bodies in plaats van alleen shapes (wat de Arch nest doet)?

[hfjbuis]

Dabit,

Ik heb geen CNC freesmachine en kan je niet verder helpen.

Ik zag dat jij versie 2.0 (daily build) gebruikt. Zo'n "voorlopige uitgave" had ik een tijdje terug al eens geprobeerd maar dat leverde alleen maar narigheid op. Vandaag nog maar eens geprobeerd en deze build (27422) is stabiel, veel minder problemen dan de laatste 19.3 release en ik heb het idee dat schroefdraad veel sneller gerenderd wordt. Misschien iets om te proberen!

[DaBit]

Ja, stiekum knutselen ze daar bij FreeCAD aardig door en plakken ze er niet zo heel vaak een 'release' labeltje op. Ik snap wel waarom; als je een release wil doe staat je ontwikkeling effectief 2 maanden stil, want feature freeze, release candidates, bla.
Als je het aandurft ben je met zo af en toe de nightly build pakken beter af. Zowiezo al leuk om te kijken wat je weer aan kadootjes krijgt. Je kunt ze ook gewoon in aparte directories zetten, dus je kunt gewoon de 'oude' bewaren.

Ik hoopte dat er bij deze al een deel van RealThunder's werk rondom topological naming in zou zitten, maar nog niet.

Met rendersnelheid heb ik trouwens absoluut geen problemen; ik vind FreeCAD het in dat opzicht heel prima tot excellent doen. Het loont wel de moeite om bij Edit->Preferences->Display de optie 'Use OpenGL VBO (Vertex Buffer Object)' aan te zetten, zeker als je grafische kaart genoeg geheugen heeft voor wat je ermee doet. Dan gaan alle data het geheugen van de grafische kaart in en hoeft het niet telkens uit het systeemgeheugen te komen maar blijft het daar waar het nodig is.

Dat geheugen op de GPU heb je al gauw genoeg. De complete assembly van de racequad inclusief een veel te gedetailleerde mesh (Blender..) heeft 200-300MB nodig:


Daar heeft een instapmodelletje grafische kaart ook nog geen problemen mee.

Met een bergje fijne elektronicaprintplaten met een paar duizend componenten per stuk en wat koper erbij (zeg 800-1500MB aan STEP) of hele asociale meshes krijg ik FreeCAD wel irritant sloom (als-ie het al binnen een halve dag geimporteerd krijgt; dat gaat wel traag), maar tegen die tijd is het in Fusion360 ook niet beter en heeft Solidworks het allang opgegeven. Magoed, dat soort dingen moet je ook niet willen.

[hfjbuis]

Met rendersnelheid heb ik trouwens absoluut geen problemen; ik vind FreeCAD het in dat opzicht heel prima tot excellent doen. Het loont wel de moeite om bij Edit->Preferences->Display de optie 'Use OpenGL VBO (Vertex Buffer Object)' aan te zetten, zeker als je grafische kaart genoeg geheugen heeft voor wat je ermee doet. Dan gaan alle data het geheugen van de grafische kaart in en hoeft het niet telkens uit het systeemgeheugen te komen maar blijft het daar waar het nodig is.

Heb ik geprobeerd, heeft geen effect. Had ik ook niet verwacht want ik heb geen losse grafische kaart. Ik gebruik de in de processor ingebouwde gpu en die heeft shared memory met de processor.

Ik heb ook nog even "topological naming" getest maar daar is niets aan veranderd. Dat is toch wel de meest tijdrovende "bug" van het geheel, een echte showstopper. Dit komt overigens niet uit freecad maar uit de cad engine die ze gebruiken.

[DaBit]

Heb ik geprobeerd, heeft geen effect. Had ik ook niet verwacht want ik heb geen losse grafische kaart. Ik gebruik de in de processor ingebouwde gpu en die heeft shared memory met de processor.

Dan is de snelheid van renderen ook niet echt een FreeCAD 'probleem', maar meer eentje van de gebruikte hardware.

Ik heb ook nog even "topological naming" getest maar daar is niets aan veranderd. Dat is toch wel de meest tijdrovende "bug" van het geheel, een echte showstopper. Dit komt overigens niet uit freecad maar uit de cad engine die ze gebruiken.

Ja, daarom is het ook zo lastig op te lossen.

In sommige opzichten heeft die topological naming problematiek me wel geholpen. Je word gedwongen om je modellen en assemblies op een robuuste manier op te zetten want het gaat veel eerder fout dan bij de commerciele software. Maar die is er ook niet ongevoelig voor; royaal meer dan de helft van de Fusion/Solidworks designs afkomstig van niet-beroepstekenaars die ik zie hebben de halve feature tree roodoranje en ontploffen als je er een wijziging aan uit probeert te voeren.
Maar mij bijt het ook wel eens. Laatst nog; paar gaten extra, boem, alle fillets en chamfers kloppen niet meer.

Realthunder heeft het in zijn Linkstage3/Assembly3 branch aardig opgelost, plus nog vele andere zaken (waaronder een betere renderer). Probleem is alleen dat mainline FreeCAD en Linkstage3 niet erg compatibel zijn met elkaar; wat je in mainline gemaakt hebt opent prima in de Realthunder variant, maar weer terug, meh. Ik vind het nog wat eng om maar naar die RT branch over te schakelen, ook al loopt die mijlenver voor op de reguliere FreeCAD.
En ook hier weer het aloude probleem. Realthunder wil best de patches in mainline brengen, maar die kerel is een belachelijk goede programmeur en heeft de capaciteit om met bloedgang complexe zaken te bouwen. De leeuwen op de hoogste rots bij FreeCAD kunnen niet mee in dat tempo en die complexiteit, dus het moet allemaal in hapklare brokjes gevoerd worden waarbij je ook nog op moet passen om niet op lange tenen te gaan staan. Gaat nog wel even duren dus. Als het al komt, met dat politieke gesteggel....


Terug naar waar het mee begon:

- Radiuscompensatie in de machine snapt Path niet, en het komt voorlopig ook niet. Grmbl.
- Nog vervelender: als je de tool in de toolcrib een andere diameter geeft word dat niet overgenomen in de Job, en van de tool in de Job kun je de diameter niet wijzigen. Je moet de tool dus wegmikken, overnieuw toevoegen, en weer toekennen aan de operaties. Dubbel grmbl.
- Als je zelf een assembly maakt met 4x een link naar een component erin deze zelf in elkaar vouwt om het plaatmateriaal optimaal te gebruiken, dan kun je er in Path niks mee, want die snapt die links niet. Daarvoor moet je echt een kopie trekken van het component, maar dan worden wijzigingen ook niet meer meegenomen. Kan ik het net zo goed uploaden naar Fusion... Driedubbel grmbl.
- En die verschillende filenames per tool heb ik ook nog geen oplossing voor.

[hfjbuis]

Ik heb ook de overstap naar realthunder overwogen maar omdat er maar één ontwikkelaar aan werkt, is de kans groot dat het project voortijdig stopt. Als je dan je history kwijt bent bij de overstap naar een ander pakket, dan is dat super vervelend. Dat is voor mij ook de reden om niet naar F360 over te stappen. Voorlopig blijf ik bij freecad.

Ik heb de freesmachine nog niet naar CNC omgebouwd en maak daarom nog niet gebruik van tool paden. Tegen dat probleem loop ik pas over een tijdje aan al zou ik dat probleem heel graag nu al hebben.....

Verder maak ik maar eenvoudige dingen, enkel stuks en vrijwel uitsluitend voor mijzelf. Als het niet 3d geprint wordt, laat ik filet's, chamfers en schroefdraad zoveel mogelijk weg. Dat scheelt een hoop ergernis.

Dan is de snelheid van renderen ook niet echt een FreeCAD 'probleem', maar meer eentje van de gebruikte hardware.

Als ik naar de processor belasting kijk, dan heb ik geen enkel pakket dat de processor meer dan 45% belast (Winrar haalt 45%). Meestal is er maar één kern die op volle toeren draait. De Ryzen 5600G (nieuwe computer 6 cores, 4.4 Mhz) is bij wat ik doe, maar 50% sneller dan de Pentium G4400 (oude computer, 2 cores, 3.3 Mhz). Ook hier blijkt weer dat in het algemeen (spellen uitgezonderd) de single thread performance (Mhz) grotendeels de snelheid bepaald. Als ik naar alle grafieken kijk, dan denk ik dat de toegang tot het geheugen de echte bottleneck is. Daarnaast lijkt freecad schroefdraad maar op één thread (core) te renderen. Als ik de schroefdraad weg laat, dan is snelheid ook geen issue meer.

N.b. voor de topic lezers: Volgens informatie van Fusion360 renderen ze bij betalende gebruikers alles op hun eigen servers. Bij de gratis pakketten wordt dit op de PC van de gebruiker zelf uitgevoerd!!!!!

[hugo stoutjesdijk]

Daarnaast lijkt freecad schroefdraad maar op één thread (core) te renderen. Als ik de schroefdraad weg laat, dan is snelheid ook geen issue meer.

Dat tekenen is toch alleen bedoelt om tot een uiteindelijk product te komen, ik neem niet eens de moeite om schroefdraden in te tekenen, of geboorde gaten met een 120 graden punt te tekenen. Allemaal werk waar ik niets voor terug krijg.
En echte renders zijn alleen nuttig als je als fabrikant een product presentatie moet doen is mijn mening, of als je zo nodig zelf wilt genieten van een mooi plaatje, en dan mag het ook wel even tijd kosten.
En afwerkingsdetails zoals afbramen moet je pas doen als je je onderdeel helemaal klaar hebt. Bij Cad tekenen moet je ook een soort van werkvoorbereiding en logische volgorde aanhouden als het wat complexer wordt.

[DaBit]

Ook hier blijkt weer dat in het algemeen (spellen uitgezonderd) de single thread performance (Mhz) grotendeels de snelheid bepaald.

Bij CAD-software: ja. Al kun je vandaag de dag de GHz-en niet vergelijken. Een 4e-generatie Core-i7 op 4GHz is beduidend slomer dan een 10e-generatie i7 op 4GHz, en idem voor een Zen1 Ryzen vs een Zen3 Ryzen.

Voor veel andere workloads geld dat niet. Een Linux-kernel compileren op mijn PC is tegenwoordig maar een paar minuten als het dat al haalt, dat was nog niet zo gek lang geleden een ur werk. Renderen en veel simulaties pakken alle cores. Drivers van grafische kaarten zijn ook niet gek en pakken cores als ze dat nodig hebben, alleen zie je dat niet in de taskmanager terug. Enzovoorts.

Maar wat de levensduur van een computer echt oprekt is een degelijke GPU. Liever een oude i5 met deuglijke grafische kaart dan de modernste processor met grafische kaart uit het jaar kruik.

N.b. voor de topic lezers: Volgens informatie van Fusion360 renderen ze bij betalende gebruikers alles op hun eigen servers. Bij de gratis pakketten wordt dit op de PC van de gebruiker zelf uitgevoerd!!!!!

De simpele simulaties (zoals een statische analyse) en rendering kun je kiezen of je het in de cloud of lokaal wil doen.
De ingewikkeldere simulaties zoals generative design, electronics cooling, nonlinear analyse, etc. draait alleen in de cloud.

Het verschil is dat je daar bij de gratis variant tegenwoordig niet eens meer de beschikking over hebt. En bij de betaalde variant begint Autodesk ook steeds meer richting 'manufacturing/simulation extensions' te verplaatsen. Voor die extensions moet je dik betalen.

FreeCAD interfaced trouwens best aardig met CalculiX, in ieder geval voor de mechanische analyses (stress/strain, modal, thermisch, etc.). Daar mis je niet zoveel aan.
Met OpenFOAM schijnt het ook goed te kunnen praten. Daar wil ik binnenkort ook wel eens mee spelen.

[DaBit]

Ook maar eens bij FreeCAD op het forum de vragen gesteld. Dat gaat prima daar.

Voor wat betreft de verschillende filenames per tool, die hebben ze zelf al ingeschoten als feature request: https://github.com/FreeCAD/FreeCAD/issues/6515
Netjes!

In-machine radiuscompensatie kijken ze ook naar hoe ze dat het beste op kunnen lossen.
En een setup-sheet die ik bij de G-code files kan bewaren zodat ik over 3 maanden nog weet hoe groot mijn ruwe materiaal moet zijn en waar het nulpunt lag kan ook: https://wiki.freecadweb.org/Path_Sanity

En voor wat ik het liefste doe: mijn onderdeel-document schoon houden (alleen de geometrie van het onderdeel erin en verder niks) en het CAM-deel inclusief eventueel repeteren in een los document zetten lijkt ook een goede oplossing te zijn met links en een compound. Je moet het alleen niet via een assembly spelen.

Snelle test: 2 armpjes in een arms_milling document gelinkt:



En als ik dan parameters in de master spreadsheet aanpas, bijvoorbeeld de afstand tussen de motoren vergroot naar 250x250mm:



Jaj! Daar word ik vrolijk van!