Mijn collega-fabrikanten klagen al geruime tijd dat hun virtuele componenten in een oudere versie zijn geladen, d.w.z. dat hun laatste wijzigingen niet zijn opgeslagen. De verschillende gemelde gevallen hebben betrekking op virtuele componenten op het eerste niveau en in virtuele of niet-virtuele subassemblages. Momenteel worden verschillende pistes onderzocht:
De tijdelijke map waarin de onderdelenbestanden van deze virtuele componenten zijn opgeslagen: voor een van de betrokken collega's is er een grote schoonmaak gedaan in de tijdelijke map die deze bestanden host en die zichzelf niet lijkt op te schonen (?), want geen zorgen... in de loop van de tijd te bevestigen.
De complexe assemblagemodus op een hoger niveau die problemen zal veroorzaken: de complexe montage-opties "Maak geen automatische back-uprecords", "Niet opnieuw opbouwen in het montagevenster" en "Automatisch opnieuw opbouwen onderbreken" zijn uitgeschakeld, maar het probleem blijft bestaan... We onderzoeken nu of het probleem zich opnieuw voordoet door systematisch de complexe assemblagemodus uit te schakelen bij het wijzigen van virtuele componenten (onderdeel of assemblage) en aan de andere kant door de virtuele componenten op te lossen.
Dat gezegd hebbende, doe ik een beroep op uw ervaring om erachter te komen of u een soortgelijk probleem heeft ondervonden... Iemand?
Ter informatie: SolidWorks versie 2017, SmarTeam add-in ingeschakeld, met een werkdirectory (opslag van uitgepakte bestanden) niet lokaal maar op een server.
Hallo; Mijn antwoord zal niet bevredigend zijn, maar hier is mijn expertise... →We gebruiken geen virtuele componenten meer sinds de versie van 2014... om de redenen die u noemde. (locatie van onregelmatige tijdelijke bestanden, updates die niet zijn uitgevoerd, enz. (Solidworks en Windows schuiven de verantwoordelijkheid door als het gaat om patches). → In dezelfde geest gebruiken we ook geen "Smart"-componenten meer … De meeste problemen die zich voordeden, werden veroorzaakt door de locaties van de tijdelijke bestanden die zeer slecht reageren op de kleinste wijziging (Solidworks-updates, maar vooral automatische Windows-updates). Ik denk dat dit probleem wordt versterkt door het gebruik van SmartTeam.
We maken al vele jaren intensief gebruik van virtuele componenten zonder echte problemen. Ons grootste probleem is EPDM, dat virtuele componenten zeer slecht beheert.
Aan de andere kant zijn onze assemblages over het algemeen niet enorm (normaal gesproken enkele tientallen stuks).
We werken alleen in de opgeloste modus (het is niet nodig om de andere modi te gebruiken gezien onze assemblages). Het gebruik van andere modi kan zelfs leiden tot problemen die we niet hebben geïdentificeerd.
Het beheer van openingsrechten is daarentegen een klassiek onderwerp: wijziging van een virtuele subassemblage (of deel) zonder de schrijfrechten van de hoofdassemblage te hebben, → werk dat opnieuw moet worden gedaan... Dit gebeurt heel vaak bij sommige gebruikers en nooit bij anderen. Werk je zonder EPDM maar in teamverband, dan kan de strijd om de schrijfrechten thuis al aan de gang zijn: alleen de eerste die de assembly opent, kan deze wijzigen, de anderen zijn alleen-lezen (het vergt maar een beetje onoplettendheid om te werken aan een bestand waarop je geen schrijfrechten hebt).
De complexe assemblagemodus, die alleen een grafische (en dus niet bijgewerkte) versie van de componenten weergeeft, zou het gebruik van virtuele componenten niet moeten helpen.
Ik merkte ook dat voorbij 2-3 niveaus van subsets, de virtuele componenten een vreemd gedrag vertoonden.
Van mijn kant, beperkt gebruik van virtuele componenten. Een bibliotheekengine is gevirtualiseerd om de snelheid en 2 of 3 andere elementen aan te passen. Dus simpel gebruik hier en daar één of 2 componenten, geen virtuele assemblage en andere en geen zorgen in onze manier van werken. Daarna moet je het recht hebben om het te schrijven om de wijziging goed uit te voeren.
Ik bevestig het probleem van virtuele componenten met Smarteam. Deze verdwijnen in sommige contexten uit assemblages omdat iets de toegang blokkeert tot de tijdelijke map waarin ze zich bevinden. Ik heb een groot vermoeden over een bug in de Smarteam integratie van solidworks Dit is een zeer ingewikkeld onderwerp om uit te leggen aan de redacteur die voor elk probleem om scenario's vraagt waarbij het probleem naar believen kan worden herhaald; HEEL, HEEL tijdrovend. Deze scenario's zijn afhankelijk van de chronologische volgorde van openen of schrijven en vervolgens een kind reserveren uit Solidworks (dus de Smarteam-integratie van Solid) of Smarteam