Inderdaad, na het wijzigen en bijwerken van de originele schets, wordt de relatie die is toegevoegd om de afgeleide schets volledig te definiëren, gewist en bevinden we ons opnieuw met het oorspronkelijke probleem.
Met uw oplossing is het hetzelfde: als de afgeleide schets beweegt, zullen de geprojecteerde elementen ook bewegen!
Uiteindelijk is de enige haalbare oplossing het gebruik van de blokkeerbalk.
Hallo Silver-S
Ja, het vormt een probleem om opnieuw te beoordelen. Dan is hier de Taff die het werk twee keer doet.
Aan de andere kant is de projectieoplossing goed. Als u een dimensie wijzigt, volgen de entiteiten. Tenzij je een element verwijdert en vervangt, maar dat geldt voor alle ontwerpmethoden.
Wat je met deze bug moet begrijpen, is dat je geen informatie hebt wanneer je een element verplaatst, wat je normaal niet zou moeten doen. Kortom, het is niet betrouwbaar. De projectiemethode maakt gebruik van de klassieke methoden die je zou kunnen hebben in een assemblage met externe verwijzingen tussen twee delen.
Een ander punt waarvoor ik deze oplossing niet aanbeveel, is de pack and Go of bewegende delen die aan een skelet zijn bevestigd.
Inpakken en gaan, je moet het skelet van elk stuk opnieuw voegen, als je er twee hebt, is dat geen probleem. Ik werk aan een project waar ik meer dan honderd stukjes heb en ik heb de koffer gehad. Het is een gekke klus omdat de software je niet waarschuwt dat de link is verbroken. En het is omslachtig, de updates kosten veel tijd.
De oplossing die ik voorstel is om het skelet als onderdeel in een assembly te integreren en nieuwe lege onderdelen te integreren, de onderdelen te bewerken en door externe verwijzing doe je hetzelfde. Minder skelet om te verwijzen, de software waarschuwt u wanneer de link is kwijtgeraakt, of dat u deze naar een andere plaats verwijst nadat u bijvoorbeeld uw mappen hebt verplaatst.
We moeten dit soort methoden integreren als we feedback krijgen. Of kies voor Inventor, dat een meer geavanceerd management heeft op dit gebied. Of hebben PDM die ik adviseer zodra je wilt samenwerken en technische van dit soort.
Gefokt is dat slechts mijn mening, anderen hebben niet naar me geluisterd over dit onderwerp, en ze zijn er niet meer om hun werk van m...
Hallo FRED78,
Ik ben het met je eens over de skeletten, op Solidworks vind ik het niet leuk, maar in sommige gevallen is het beter om maar één skelet te hebben. Inderdaad, op Inventor is het geavanceerder, ik vond het leuk voor mechanisch gelast (Inventor).
=>Solidworks Skeletten=>https://www.youtube.com/watch?v=j-qViam3fkg&t=183
=>Uitvinder skeletten =>https://www.youtube.com/watch?v=TIgz3Yg-zkY
Dat is alleen voor de goede orde.
@+.
AR.
Hallo
Ik gebruik het overal.
Het uiteindelijke doel is om composities te kunnen maken voor je tekeningen.
Je moet goed nadenken over de samenstellingen van je assemblages en subassemblages. Als al uw onderdelen op deze methode zijn gebouwd, kunt u assemblages opnieuw samenstellen zonder beperkingen (gewicht, mantel en fouten). Mogelijkheid om werktijd en betrouwbaarheid te kwantificeren.
Uitvinder over dit onderwerp is stijlvol.
SolidWorks - Ik geef er de voorkeur aan om een assembly te maken en als externe referentie te werken, zelfs voor een deel is het verrassend, maar het werkt zonder al te veel latentie.
Als je deze methode rigoureus hebt toegepast op complexe concepten, doe je het daarna niet meer zonder.
Het werk aan het skelet lijkt lang, zwaar, maar uiteindelijk zijn de mogelijkheden tussen de ambachten en andere ontwerpers in samenwerking zeer effectief als het goed wordt gedaan. En voor samenwerking met een PLM zoals Vault of PDM.
Verschillende skeletten, waarom, hoe!
Een skelet op een eenvoudige structuur met een paar onderdelen ok.
Maar als je duizend onderdelen hebt op verschillende subsets van je mechanisme, dan is het logisch om meerdere skeletten te hebben.
1/ Je moet deze skeletten ontwerpen door naar beneden te gaan
2/ Uitgesplitst naar subset of naar beroep, maar gekoppeld aan gemeenschappelijke referenties.
3/ De updates gelden enkel voor het betreffende skelet, dus tot een minimum aan onderdelen. Het openen gaat sneller (wanneer u een wijziging toepast).
4/ Makkelijker als je maar een dertigtal schetsen hebt
En geloof me, bij grote assemblages is de tijdsbesparing enorm, vooral als je skelet intern is voor de onderdelen en niet voor een assemblage zoals ik aanbeveel bij SW.
Nogmaals, mijn mening en mijn ervaring, en de huidige, hebben me heel goede dingen geleerd 
Je moet de verschillende methoden testen (zie bijlage)
02-methode.7z (678.1 KB)
Hartelijk dank voor uw voorbeelden.
@+.
AR.
Persoonlijk gebruik ik de 2B-methode.
Aan de andere kant begrijp ik je opmerking over ongedwongen schetsen. In uw voorbeeld is dat het geval, maar in mijn geval is het skelet altijd beperkt. De (-) die je op mijn model kunt zien, is alleen dat er symmetrie-assen zijn die geen gedefinieerde lengte hebben, dit is handig voor mij om een schetsspiegel te bedienen, zodat ik de lengte vaak niet dimensioneer. Niettemin blijft de logica hetzelfde en is ze vrij stabiel, in tegenstelling tot de publicatie van een toneelstuk in de context. Na deze techniek een tijdje te hebben geoefend, weet ik dat het na een tijdje altijd verknoeit.
Hallo Ronathan
Skelet geïntegreerd in een kamer:
Mogelijk voor de assen die ik niet heb gecontroleerd, heb ik geen tijd om te besteden aan de problemen die onfeilbaar zijn voor deze methode. Maar het feit is dat bij het bewerken van een functie om de schetsen te kunnen uitrekken zonder beperking of dimensie, is een probleem lijkt mij. Dat zelfs een optie deze mogelijkheid zou blokkeren, lijkt mij een probleem op zich. Maar misschien begrijp ik de logica niet.
We moeten in staat zijn om schetsen te maken, gedreven door de dimensies waarop we reageren. Als deze zonder verzekering of controle kunnen worden gewijzigd, is dit niet normaal.
Afgezien van dit probleem, vereist het identificeren van latenties als gevolg van lange updates, en soms zelfs zonder reden, bronnen die niet altijd gemakkelijk te verkrijgen zijn met een pc zonder stroom en RAM, wat in mijn geval is. Maar ik ben geen computerwetenschapper.
De shit na een tijdje? Wordt uitgelegd?