Hallo, Ik kom weer terug op het probleem van het vooraf invullen van MS-body eigenschappen uit bibliotheken. We maken mechanisch gelaste PRT's met behulp van de MS-carrosserieën en hun eigenschappen om plannen te maken van elke debietsnelheid en materiaallijst voor aankopen. Deze MS-lichamen worden op 3 manieren gecreëerd: 1- Klassieke functies (extrusie, materiaalverwijdering, boren) voor laser-type stromingssnelheden. Er kunnen ook plaatmetaalfuncties zijn voor onderdelen die zijn gemaakt door laser+buigen 2- " Mechanisch gelaste element"-functies voor alle H, I, enzovoort. Ze zijn gemaakt van de sldlfp-bestanden 3- Functies via de Design Library voor functies die samen in de bibliotheek zijn gegroepeerd.
Dus maken we de PRT in 3D en vullen we de eigenschappen van de MS-lichamen in met Smart Properties In het eerste geval moeten we elke keer alles invullen. Normaal creëren we uit " niets "
In het tweede geval bevatten de configuraties van de sldlfp-bestanden eigenschappen die automatisch in de MS-body worden gevonden, dat is top!
Hallo; Dit lijkt mij een normaal gedrag van Smartproperties; het geeft de voorkeur aan het schrijven van eigenschappen in plaats van ze te lezen. En tenzij de eigenschappen al in je documenttemplates zijn opgenomen (de eigenschappen, niet de waarden), is het normaal dat ze, zonder de Smartproperties te starten, niet in je Solidworks-documenten worden aangemaakt...
Wees voorzichtig: in de tweede case Beschrijving (voor de gelaste monteur), in de derde BESCHRIJVING (voor de functie) voor Smartproperties is het niet hetzelfde (en in de Smartpropertie (BESCHRIJVING). Zou jouw probleem daar niet vandaan komen? Anders zien we niet hoe je de Beschrijving-eigenschap van de mechanisch gelaste in je BESCHRIJVING-eigenschap van de smart krijgt.
Hallo, Dank je voor je reacties Ik wil erop wijzen dat: In geval 2 heeft het sldlfp-bestand dat de schets van de profielen bevat in zijn eigenschappen (gekoppeld aan de configuratie) de eigenschappen die in de weergave worden weergegeven: Beschrijving (HEA100), Standaard (NF EN...), en MODE_OBTENTION. Bij gebruik van de functie " MS Element" bevat het gemaakte MS-lichaam automatisch de Beschrijving, Standaard en MODE_OBT.) en ze worden gevuld met de bijbehorende waarden. De Smart leest deze waarden alleen opnieuw en je kunt de andere waarden invoeren: REPMS, de keuze of je plan is of niet, enzovoort
en SW maakt geen onderscheid tussen een hoofd- of kleinletter-eigenschapsnaam
Dit is normaal gedrag: het invoegen van een bibliotheekfunctie werkt niet op dezelfde manier als de mechanisch gelaste elementfunctie, omdat het geen van de eigenschappen van het bestand meebrengt. De functie Mechanisch Gelaste Element zal de eigenschappen van het bestand invoegen dat het profiel definieert als een eigenschap van het gelaste element. Dit gedrag komt voor in de Insert Part functie, waar het mogelijk is om, in de te overgedragen elementen, de aangepaste eigenschappen te kiezen, hetzij als een persoonlijke eigenschap van het bestemmingsbestand, hetzij als eigenschap van het gelaste element:
Daarom is de enige manier om te krijgen wat je wilt, bijvoorbeeld je kabeltrayondersteuning als onderdeel te beheren en deze via de Insert Part functie in je gelaste constructie te plaatsen door deze transferopties te kiezen.
Dit defect in de bibliotheekfuncties is al vele jaren onderwerp van een verzoek om verbetering.
Bedankt voor de feedback. Ik hoopte dat ik iets gemist had, maar dat was wat ik vreesde. Is er een mogelijkheid om een extra stuk toe te voegen ter ondersteuning van het verzoek?
Ja, natuurlijk. Maak je account aan en verbind je met de SOLIDWORKS Enhancement Ideas publieke community op het Dassault Système 3DSwym-platform : HIER Onderzoek je idee (of Enhancement Request, ER): Misschien ben je niet de enige die erover heeft nagedacht, dus je moet controleren of het nog niet is ingediend.
Gebruik Current Page Search met Engelse zoekwoorden.
Als je het vindt, kun je op dit idee stemmen door een " LIKE" toe te voegen.
Als ik mezelf toch kan toestaan om 2-3 dingen te verduidelijken over dit gedrag en het daaruit voortvloeiende verzoek om verbetering... en wat in sommige SWUG's felle debatten heeft veroorzaakt. Zoals ik al zei, is het heel goed mogelijk om de eigenschappen van een bestand terug te halen als een eigenschap van een mechanisch gelast element via de Insert Part functie. Als deze oplossing niet aan een groot aantal gebruikers voldoen, is dat om de volgende redenen:
We genereren een externe referentie... deze beroemde links die door de meerderheid worden gedemoniseerd (waarvan ik er zelf niet één ben!)
Deze functie is op zichzelf niet voldoende: het is vaak nodig om extra functies stroomopwaarts en/of stroomafwaarts te gebruiken, al is het maar om het ingevoegde onderdeellichaam op de gewenste locatie te plaatsen.
De referentie wordt vervangen wanneer het document wordt geopend, niet vanuit de PropertyManager van de Insert-functie.
Aan de andere kant heeft het een aanzienlijk voordeel: de gebruiksscenario's. Het is mogelijk om in een PDM de leads te visualiseren.
En we kunnen voordelen en nadelen voor bibliotheekfuncties omkeren! Voordelen:
Geen externe referenties aangemaakt, dan kopiëren we de functies (hoewel... je moet nog steeds voorzichtig zijn met de constructie)
Staat op zichzelf
Zolang het niet is opgelost, is het heel eenvoudig om het te verwijderen en te vervangen door een andere functie.
Nadelen:
Geen importerende eigenschappen
Geen zicht op de use cases.
We staan dus op een kruispunt: verbeter de onderdeel invoegfunctie of verbeter de bibliotheekfuncties.
Persoonlijk ben ik meer voorstander van een verbetering van de onderdeel invoegen-functie (Ik heb geen fobe neurose ontwikkeld tegenover externe referenties):
Maak het mogelijk om de slimme functies van de ene kamer te gebruiken wanneer deze in een andere wordt geplaatst.
Maak het mogelijk om de referentie te wijzigen vanuit de PropertyManager van de functie
Het materiaal van het onderdeel dat op het niveau van het lichaam in het afgeleide deel is ingebracht, kunnen terugwinnen.
Ik vraag me af of het niet mogelijk is om de informatie uit het mechanisch gelaste te halen als we de bibliotheekfunctie in de constructieboom " Decomponeren "... (rechterklik op functie => Decomponeer). Ik heb het niet getest, maar het is het proberen waard, toch?
Hallo, Dank je wel voor dit duidelijke en kalme antwoord Inderdaad, zonder extreem te zijn, vermijd ik externe verwijzingen. Maar een assemblage, of een tekening, is per se een bestand met externe referenties! Het draait dus allemaal om compromissen. Je moet de cursor op de juiste plek plaatsen. Het nadeel dat ik zie bij ingevoegde delen zijn de versies: als je een bibliotheekonderdeel moet aanpassen, pas je alles eronder aan... Dus ja, de EMO kan de use cases zien, en we zouden de juiste elementen moeten hebben om hierop te reageren. Maar de mogelijkheid geven om eigendommen over te dragen zou aan bepaalde eisen voldoen, zonder andere gebruikers te straffen.
Zorg ervoor dat de overgedragen schets volledig is gedefinieerd<
Ik heb het hier in een onderwerp gehad, off-topic Onderdelen die op deze manier zijn ingebracht, en schetsen in het bijzonder, die volledig beperkt zijn "of volledig gedefinieerd " zijn in het afgeleide onderdeel tijdens het invoegen, verliezen alle spanningen en afmetingen. Trouwens (was het een bug??), als je deze schets direct in een extrusie gebruikt (wat hier niet het geval is) en bij het bewerken van deze functie kun je met deze schets spelen. Het is niet langer beperkt! Let extra goed op deze methode.
Hallo, Ik heb het geprobeerd: we splitsen de bibliotheekfunctie op in verschillende basisfuncties, maar we hebben geen eigenschappen meer in de body's van de lijst met gesoldeerde onderdelen.
functie.
