Zou er een methode of een manier zijn om meerdere stukken samen te voegen tot één? Een soort omzetting van de stukken in verschillende lichamen, die vervolgens worden samengebracht in een prt.
Simpel gezegd komt het neer op:
lichamen blijven lichamen,
de onderdelen worden lichamen (de lichamen nemen dan de posities van de onderdelen in het geheel aan),
De assemblage wordt een onderdeel.
Tot nu toe ga ik het tegenovergestelde te werk, d.w.z. ik modelleer en positioneer (zoveel mogelijk) alle elementen in PRT, en ik isoleer ze daarna om er onafhankelijke delen van te maken (en in een asm te eindigen). Maar soms anticiperen we niet, of is de installatie van een carrosserie veel ingewikkelder dan die van een onderdeel in een assemblage. Dus ik zou graag willen weten of ik anticipeer of dat ik een asm in lening kan halen.
Kijk of deze methode je kan helpen. Het onderdeel houdt een link met de assemblage, dus als je de assemblage wijzigt zal het onderdeel volgen omdat het een link heeft. https://www.lynkoa.com/contenu/créer-une-pièce-partir-dun-assemblage-pour-facilter-les-simulations Of anders kun je in een kamer werken en er alles in bouwen, maar als je de extrusie voor een nieuw lichaam doet, moet je het niet samenvoegen met de reeds gebouwde
Hallo Ik denk dat ik de vraag niet goed heb begrepen, maar om een assembly over te schakelen naar prt, hoef je alleen maar de assembly te "opslaan" en prt te kiezen. De stukken worden dan lichamen in de prt.
Het is een truc die ik vaak doe. In feite ontvang ik RWZI van klanten in de montagemodus (mechanisch gelast en plaatwerk): Ik open de stap in SW en ik doe "opslaan als", maar ik verander het formaat: ik forceer het naar SLDPRT. SW slaat daarom de assemblage op als een onderdeel en alle onderdelen van de assemblage als een body in mijn onderdeelbestand. Dit stelt me in staat om een plaatwerkfunctieherkenning uit te voeren en in één stap door de SheetMetalManufacturing-fabriek en anderen te gaan. Aan de andere kant is er geen link tussen het gemaakte onderdeelbestand en de originele assemblage.
Ik heb ook een bestand gemaakt dat is opgeslagen onder, maar het was shit bij het wijzigen van de assemblage, terwijl hier het onderdeel een link houdt met de assemblage en in het geval van het bijten van een onderdeel in de assemblage, wordt het bijgewerkt in het onderdeel dat uit de assemblage is gemaakt.
@Rim-B met een "geregistreerd onder PRT" delen worden solide zonder de functies. Ik wil graag de integriteit van het ontwerp van het stuk behouden. En wanneer ik de herkenning van functies valideer bij het openen, krijg ik een foutmelding van overlappende volumes... Het is echter niet abnormaal dat onderdelen in contact komen in een assemblage...
Uit nieuwsgierigheid; Wat is het doel? Voor mij was het om het gewicht van de eindassemblage te beperken door alle subassemblages om te zetten in onderdelen die tijd besparen bij de opening en in vloeibaarheid.
Ik bevestig ac-cobra, met welk doel? Het gebeurt eerder omgekeerd, en bovenal zal het de publicatie van de plannen bemoeilijken, anders is de top-down modellering niet genoeg!?
Ja, het verminderen van het gewicht maakt deel uit van het doel. Ik wil ook een onafhankelijk "compleet geassembleerd object" bestand hebben, compleet maar niet afhankelijk van externe referenties. Dit faciliteert, deelt, bewaart en zorgt er in ieder geval voor dat het object hoe dan ook kan worden geëxploiteerd.
In mijn ideale wereld zou ik een macro programmeren die gewoon een leeg PRT-bestand zou maken van een open assembly, de bomen van elk onderdeel in de assembly zou extraheren en ze naar de PRT zou kopiëren (items hernoemen indien nodig), maar de lokale oorsprong van elk onderdeel zou wijzigen door de oorsprong van de assembly, om ervoor te zorgen dat hun plaatsing overeenkomt met de assembly.
Dus allereerst bedankt voor de truc die ik niet kende en die op een dag onvermijdelijk nuttig voor me zal zijn. Helaas reageert het niet op het verzoek, maar ik begrijp de verwarring omdat het woord "samenvoegen" dat ik gebruikte niet het meest geschikt is. We moesten "groep" begrijpen.
Ik ben een beetje verloren, omdat ik niet echt begrijp of ik een deel met lichamen moet hebben of niet, omdat het niet kan worden gewijzigd en het visuele hetzelfde zal zijn als een bestand dat is opgeslagen in prt.
Dus allereerst wordt mijn fout bij het herkennen van functies veroorzaakt door de schroeven uit de gereedschapskist. Als ik ze uitsluit van de lening, gaat de erkenning goed. Het is jammer, maar ach, laten we zeggen dat het al niet slecht is. Behalve dan dat je blijkbaar voor elk geïmporteerd object handmatig een functieherkenning moet uitvoeren, het ene na het andere... We kunnen geen meervoudige erkenning doen??
Ik heb me waarschijnlijk slecht uitgedrukt, maar om duidelijker te zijn, laten we zeggen dat ik wil wat "ASM registreren als PRT" doet, behalve dat ik geen nutteloze reconversies van geometrieconversies wil moeten ondergaan, noch een (des!!) erkenning van functies. Ik wil functies, relaties, citaten, originele namen behouden. Een stomme klonen van de originele boom van elke kamer* in een andere gemeenschappelijke ruimte, weet je. (nog meer qd Ik zie de tijd die het kost om de functies te herkennen en dat je het opnieuw moet opstarten voor elk van de onderdelen..., en ze dan hernoemen...). In de gemeenschappelijke ruimteboom moeten de kamerbomen worden gehiërarchiseerd in afzonderlijke mappen van de kamernamen.
We zouden meer op de "join" tool zijn, maar zonder samen te voegen, gewoon een toevoeging van elke boom*, zoals het is, de een na de ander in het nieuwe doeldeel. Een aaneenschakeling zonder conversie dus. En altijd, idealiter, in aparte mappen (in de featureManager eh).
Het lijkt erop dat alleen een macro aan deze eisen kan voldoen
*Als ik het heb over "originele boom", bedoel ik "alle functies, plannen, enz. waaruit de kamer bestaat".
Wat je in feite wilt, is werken aan de meerdere functies van je onderdelen van de assemblage in een onderdeel, ik weet niet of ik me goed heb uitgedrukt
Sterker nog, ik zou willen dat alle onderdelen van een assemblage "ingebed" zijn, zoals ze in één PRT zitten. Het enige verschil dat zichtbaar is in de boom is dat het gele "deel" icoon overgaat in een blauw "map" icoon.
En inderdaad, het zou je in staat stellen om alle "onderdelen" (hun functies gegroepeerd in mappen) vanuit de gemeenschappelijke ruimte te bewerken.
Ik denk niet dat het mogelijk is om dat te doen De enige manier is om te anticiperen en te bouwen in een kamer met meerdere lichamen en het zal je niet helpen in termen van het lichter maken van het onderdeel in vergelijking met een montage, omdat het de functies zijn die zwaar zijn ... Veel succes, want je hebt wat nodig
Hallo Kortom, wat je zou willen doen is de functie " onderdeel invoegen " gebruiken, maar in plaats van een onderdeel zou het een assemblage zijn (onmogelijk met deze opdracht) en in staat zijn om de optie " voortplanten vanuit het originele onderdeel" te gebruiken. Ik geef aan dat je de link met het originele onderdeel moet verbreken om de bouwboom te herstellen.
Het hele probleem zit hem in deze twee woorden: uitpakken en kopiëren. Met andere woorden: copy/paste...
Het scannen van de assemblage componentenboom om de " bron " -onderdelen te identificeren is gemakkelijk denkbaar, maar voor zover ik weet is er geen kopieer- en plakprocedure van de build-boom van elk " bron " -onderdeel in hetzelfde " bestemmings " -onderdeel. De enige entiteiten die van het ene deel naar het andere kunnen worden " gekopieerd " zijn schetsen, rondingen, oppervlakken en lichamen, geen geometrische kenmerken.
Bij gebrek aan aaneenschakeling in een onderdeel kan een andere weg worden verkend, waardoor de back-up kan worden teruggebracht tot één enkel bestand: virtualiseer alle componenten, d.w.z. integreer ze in het assemblagedocument. De logica voldoet aan uw verwachtingen, zelfs als het uiteindelijke document een assemblage is en geen onderdeel. De functie " Virtueel maken" bestaat in de SolidWorks API's. De koppelingen van de gevirtualiseerde onderdelen naar de originele onderdelen worden verbroken, maar de build-boom blijft behouden.
