Macro of tool om een assembly te hernoemen in SW + Windows-map + Excel

Hallo

Ik ben geen SolidWorks-gebruiker, dus mijn excuses als er onnauwkeurigheden zijn in wat ik u vraag.
Om snel de context uit te leggen: we hebben een groot aantal solidworks-assemblages en om commerciële redenen moeten we bepaalde productlijnen hernoemen en daarom willen we natuurlijk de benamingen van onze catalogus, onze ERP en onze plannen harmoniseren.
Ik vroeg dit aan ons ontwerpbureau, die me vertelde dat het een titanenwerk was omdat je voor een montage een andere naam moet geven:

  • Componenten in SW
  • Windows-mappen en -bestanden
  • De informatie van een excel die alle plannummers met hun aanduiding vermeldt
  • De URL die in deze Excel staat en die de regel van een bepaald plannummer verbindt met de Windows-locatie van de map.

Zou u mij kunnen vertellen of het inderdaad onmogelijk is om deze 4 bewerkingen uit te voeren door een geautomatiseerde actie of dat het volledig haalbaar is door een macro of een solidworks-tool?

Alvast bedankt voor je antwoorden!

Hallo etudes_44,
Ik bevestig dat het een titanentaak is, maar niets is onmogelijk voor degenen die het willen doen.
Succes.
AR.

1 like

Welkom @etudes_44

A priori kan de Solidworks Task Scheduler ten minste een deel van het werk doen met "bestanden bijwerken"/"bijbehorende bestanden bijwerken".

2 likes

Hallo

Typisch het soort 'tech debt'-onderwerp.
Het is zo omslachtig om de 3D- en 2D-info, de CAPM, de documentatie bij te werken... Dat doet uiteindelijk bijna niemand ooit.
Voor ons hebben de 3D-bestanden een nummer opgenomen in de naam van de configuratie (maar met extra letters/cijfers) en we hebben een molen die de configuratienamen in de CAPM injecteert om de nomenclaturen op te zetten. Wat u zou willen doen, is dat wij de volledige 2D/3D-database en alle CAPM overnemen :boom:
Dit is het soort dingen dat u kunt doen op de dag dat u besluit uw CAPM- en tekensoftware tegelijkertijd te wijzigen (een vrij zeldzame beslissing gezien de bijbehorende kosten).
Als u met dit probleem begint, moet u ook weten hoe u het dagelijks leven in de wijzigingsfase (half omgezette basis) kunt beheren.
De eenvoudigste manier is waarschijnlijk om uw database te dupliceren: u kunt gaandeweg nieuwe bestanden maken. U kunt eventueel verder werken aan de oude zolang de nieuwe niet compleet genoeg is om up and running te zijn.

In jouw geval (dat puur commercieel lijkt): een klein oud / nieuw naambord zou voldoende zijn om het bestaande te beheren. Het kan zijn dat u nieuwe klantplannen opnieuw maakt volgens deze nieuwe code (zelfs als dit betekent dat u naar de oude nummers moet verwijzen). En u kunt altijd nieuwe producten benoemen volgens uw nieuwe regels. Helaas zal dit een echte puinhoop van namen creëren en kan het het werk van iedereen op dagelijkse basis bemoeilijken.

4 likes

Hallo;
Om dit soort overgang mogelijk te maken, zou ik op advies van @froussel zijn:

Dit zal minder pijnlijk zijn voor uw ontwerpers... om een karikatuur te maken van dit lange en vervelende werk, zouden zij (Solidworks-gebruikers) " gewoon" "uw oude referenties vervangen door de nieuwe (onderdelen, assemblages)... Het voordeel van deze methode is ook dat het een geschiedenis bijhoudt van uw oude gegevens.

Vriendelijke groeten.

2 likes

Inderdaad, een (nog te ontwikkelen) programma zou het werk kunnen doen.
Ik zeg programma omdat we afstand nemen van de eenvoudige macro, omdat we Windows, Excel en SW moeten aanvallen.

Als de bestaande database perfect schoon is, kan het werken, maar aangezien het onwaarschijnlijk is, wordt het beheer van speciale gevallen een hel.

Als u iemand vindt die dit programma uitvoert (plan een aanzienlijk budget...), zou het ideaal zijn om het te starten tijdens een periode van sluiting (na het maken en testen van een back-up).

Ik voeg hieraan toe dat handelsnamen zelden compatibel zijn met de naamgevingsregels voor bestanden in BE.

Een ander punt dat specifiek is voor SW: het beheert geen bestandspaden, dus elke verandering van mapnaam zal een puinhoop maken bij het openen van assembly's (en plannen als de plannen niet in dezelfde directory staan als hun onderdeel/assembly). Bij de eerste opening van de asm zul je de weg moeten vrijmaken voor het onderdeel/SE, en dat zal gemakkelijk te automatiseren zijn.

Ik denk dat de door @froussel voorgestelde oplossing daarom de meest geschikte is.

1 like

Hallo

Kleine extra opmerking: EPDM stelt je in staat om de onderdeelbestanden te hernoemen (voor de configuraties ben ik minder bevestigend) zonder dat je per se de assemblage opnieuw hoeft te bewerken (het is EPDM die de naamsverandering regelt wanneer de assemblage wordt geopend).
WAARSCHUWING: het bovenstaande werkt NIET in virtuele assemblages (omdat SW/EPDM geen toegang heeft tot het virtuele bestand om referenties te wijzigen).
Het overschakelen van de database naar EPDM zou dus mogelijk tijd kunnen besparen (plan het budget dat bij EPDM hoort daarentegen: licentiekost + installatie/configuratiekost en vooral de jaarlijkse onderhoudskost)

1 like

Hallo, voor dit deel:

Een ander punt dat specifiek is voor SW: het beheert geen bestandspaden, dus elke verandering van mapnaam zal een puinhoop maken bij het openen van assembly's (en plannen als de plannen niet in dezelfde directory staan als hun onderdeel/assembly). Bij de eerste opening van de asm zul je de weg moeten vrijmaken voor het onderdeel/SE, en dat zal gemakkelijk te automatiseren zijn.

Het is mogelijk om met een Excel-macro de paden van ASM's en DRW's te wijzigen zonder zelfs maar de bestanden te openen (ik deed het op onze EPDM-database door de archiefdatabase rechtstreeks aan te vallen omdat we een probleem hadden tijdens een migratie dat een deel van de database beschadigde en de links worden niet langer bijgewerkt op de getroffen versies).
Gebruik daarna gewoon de taakplanner om de wijziging op te slaan (het voorkomt dat gebruikers dit hoeven te doen).
Voor het overige ben ik dezelfde mening toegedaan als @froussel , EPDM is het best in staat om dit soort situaties te beheren (we zijn een paar jaar geleden van ERP veranderd en daarom is de codering van onze bestanden veranderd).
Ik ben het ook eens met @stefbeno over de schone kant van de database, als dit niet het geval is, is geautomatiseerde verwerking meer dan gevaarlijk.