Ik heb geen soortgelijk onderwerp gevonden, stuur me alsjeblieft door als er al een onderwerp bestaat en sorry voor het duplicaat.
Ik heb een probleem met waarden die worden doorgegeven in tekenkaarten tijdens het kopiëren. Op de tekenkaart is de variabele alleen-lezen, omdat deze via $PRPSHEET uit de 3D wordt opgehaald. Ik merk dat alleen het tabblad "@" de 3D-informatie ophaalt en dat de andere tabbladen de waarden van het gekopieerde onderdeel behouden, ondanks dat "Alle configuraties bijwerken" is ingeschakeld. Ter informatie, de tabbladen van de bladen ("Blad1" in mijn geval) zijn ingevuld op het gekopieerde deel omdat de StarterPack herstelprocedure dit vereist via DataRecovery.
Dit is erg vervelend, omdat er valse informatie is in het tabblad "Blad1", en deze informatie lijkt willekeurig te worden gebruikt in de verkenner, in zoekopdrachten, in het PDM-paneel van SolidWorks, enz. Dus het is niet schoon en het stoort me.
Om dit te omzeilen, heb ik de instelling van de tekentafel veranderd. Ik kies ervoor om de standaardwaarde te vervangen en de bestaande waarde te verwijderen. Op deze manier wordt tijdens een archief de tekenkaart ingevuld via $PRPSHEET. Dit werkt door te kopiëren en te plakken in de lokale weergave (CTRL+C, CTRL+V), maar werkt niet door het gereedschap "Copy Tree" te gebruiken . Het lijkt alles wat op de kaart staat volledig te negeren.
Ik heb een beetje graven en het lijkt erop dat je het gedrag van de "Copy tree" -functie kunt instellen , maar al mijn pogingen werken niet.
U moet contact opnemen met uw wederverkoper, want voor zover ik weet, hebben de kaarten die aan de slddrw-bestanden zijn gekoppeld een bepaalde bewerking (of liever een bug) omdat de bladen geen aangepaste eigenschappen hebben die aan het bestand zijn gekoppeld.
Het is puur een kaartweergave. Uit het geheugen moet er ook een wijziging zijn in een vervolgkeuzemenu om de propagatie van het ene tabblad naar het andere van de kaart te doen.
De willekeurige weergave in de kluisinterfaces is ook een bug voor zover ik weet. Normaal gesproken geeft de kluis volgens de SW-specificaties de variabelen van de laatst gewijzigde configuratie weer. Thuis heb ik dit gedrag nog nooit gezien en het wordt niet hetzelfde weergegeven tussen de zoekresultaten en de Windows Verkenner. Voor de tekeningen daarentegen is het totaal onduidelijk.
Dank u voor uw antwoord. De reseller vroeg me om een supportticket te openen omdat hij geen oplossing had. Ik heb er spijt van dat ik al deze gedragingen niet beter heb getest tijdens de implementatiefase van het StarterPack.
Ik heb gemerkt dat de propagatie plaatsvindt als ik het alleen-lezen attribuut verwijder: als ik een waarde in een tekenkaart forceer, worden de gegevens op alle tabbladen doorgegeven. Aan de andere kant, wanneer de waarde wordt geërfd van 3D, wordt alleen het tabblad "@" op de tekentafel bijgewerkt. En het is erg vervelend, want het doel is niet om de waarden op de trekkingskaarten opnieuw in te hoeven voeren. Blijkbaar is dit gedrag gewijzigd in de versie van 2019 (ik ben in 2018).
Wat ik heel vreemd en onpraktisch vind, is dat het gedrag tussen een copy and paste en een boomkopie niet hetzelfde is. Het is voor mij onbegrijpelijk dat de boomkopie geen rekening houdt met de configuratie van de kaarten (vervang de standaard, enz.).
Ik ben bezig om al deze problemen te overwinnen via transities. Ik "schoon" mijn kaarten op tijdens de eerste overgang. Bijvoorbeeld, voor mijn probleem met residuen na kopieën, verwijder ik de waarden van de tekenkaarten, en dan vul ik alleen het tabblad "@" door de variabelen uit de 3D op te halen (zie bijgevoegde schermafbeelding, ik keten de 2 acties en dit voor alle variabelen die me problemen bezorgen). Dus ik eindig met een belangrijke lijst met acties, maar de kaarten zijn tenminste schoon en ik loop niet het risico om overal foutieve waarden te vinden (zoekopdrachten, Windows verkenner, SW-paneel, enz.).
Het probleem is dat Solidworks PDM net zoveel bugs heeft als Solidworks. Merk op dat de eerste versie uit 2009 stamt als ik het me goed herinner, en dat er veel ruimte voor verbetering is om het gedrag betrouwbaarder te maken.
Sommige instellingen die op een groep worden toegepast, zijn bijvoorbeeld niet van toepassing op gebruikers in de groep. Je moet de gebruiker direct instellen, wat in strijd is met de nominale werking van een groepsinstelling. Dus dat er verschillen zijn in gedrag tussen een copy/paste en een tree copy stoort me niet zo veel:)
Ik ben erg geïnteresseerd in uw onderwerp en de oplossingen die u voorstelt, omdat ik hetzelfde probleem opmerkte als u met de versie van 2018, helaas had ik niet de tijd om er aandacht aan te besteden.