Python ile SolidWorks Otomasyonu: Nereden Başlanır

SolidWorks'ün otomasyon arayüzü COM üzerinden çalışıyor. COM, Windows'un uygulamaların birbiriyle konuşması için kullandığı eski ama hâlâ çok yaygın bir mekanizma. Python tarafında bu köprüyü pywin32 kütüphanesi kuruyor.

Bağlantı üç satırlık bir iş: SolidWorks'ün COM adını verirsiniz, Windows sizin için ya çalışan bir oturum bulur ya da yenisini başlatır, ve elinize uygulama nesnesi geçer. Ondan sonrası API'nin kendi dünyası — nesne hiyerarşisi aynen geçerli.

Ama burada baştan bilmeniz gereken üç şey var:

Bağlantı açık oturumu bulur. Eğer SolidWorks zaten açıksa ona bağlanırsınız. Açık değilse yeni bir oturum başlar — ve bu, arka planda görünmez bir SolidWorks açmak anlamına gelebilir. Görünürlüğü açıkça ayarlamak iyi bir alışkanlık; yoksa "hiçbir şey olmuyor" derken aslında ekranda görünmeyen bir SolidWorks'te her şey olup bitiyordur.

Aktif belge boş dönebilir. Hiç dosya açık değilse elinize hiçbir şey geçmez. Betiğin ilk kontrolü bu olmalı, tıpkı makrolarda olduğu gibi.

Belge türü işin geri kalanını belirler. Parça, montaj ve teknik resim farklı dünyalar. Betik hangi türle çalıştığını baştan öğrenmeli; montaja parça mantığı uygulamak en sık yapılan hata.

Kurulumda takıldığınız yer muhtemelen burası

Python tarafında en çok vakit kaybettiren şey kodun kendisi değil, mimari uyumu. 64-bit SolidWorks'e 32-bit Python'dan bağlanmaya çalışırsanız COM köprüsü kurulmaz ve aldığınız hata mesajı size bunu söylemez. Kural basit: SolidWorks 64-bit ise Python da 64-bit olmalı.

İkinci sık sorun, ilk çalıştırmada COM tip kütüphanesinin oluşturulmamış olması. pywin32'nin sabitleri (swDocPART gibi) ilk erişimde önbelleğe alınır; o önbellek yoksa sabitler tanınmaz. Çözüm, sabitleri isimle kullanmak yerine sayısal karşılıklarını yazmak ya da tip kütüphanesini bir kez oluşturmak.

Otomasyonun büyük kısmı aslında tek bir işe indirgeniyor: ölçüleri değiştir, modeli yeniden kur, çıktıyı al. İşin püf noktası ilk adımda.

Ölçüleri tek tek özellik (feature) üzerinden çekip değiştirmek çalışır ama kırılgandır: özelliğin adı değişince betik susar, hata bile vermez. Çok daha dayanıklı yol, tasarımı global değişkenler üzerinden sürmektir.

Global değişken, SolidWorks'ün denklem tablosunda tanımladığınız isimli bir sayıdır — "Genislik", "Yukseklik" gibi. Modeldeki ölçüler bu değişkenlere bağlanır. Betiğiniz artık geometriye değil, tek bir isme dokunuyor. Model içindeki feature adları değişse bile otomasyon çalışmaya devam eder.

Bir de birim meselesi var ve bu, Python tarafında en sık düşülen tuzak: SolidWorks API'si uzunlukları metre olarak işler. Belgeniz ekranda milimetre gösterse de, koda yazdığınız sayı metre kabul edilir. 2400 mm yazmak istediğinizde 2.4 yazmanız gerekir. Bunu unuttuğunuzda model bin kat büyür ve bazen bu gözle bile fark edilmez — özellikle toplu işlemde.

Yeniden kurmayı (rebuild) doğru yerde çağırın

Parametreleri değiştirdikten sonra modelin yeniden kurulması gerekir. Ama bu pahalı bir işlemdir.

Yaygın hata, her parametreden sonra yeniden kurmak. Yirmi parametre değiştiriyorsanız bu, yirmi kez tam yeniden kurma demek — ve süre saniyelerden dakikalara çıkar. Doğrusu, tüm parametreleri yazıp sonra bir kez yeniden kurmak.

Toplu işlemlerde bu tek karar, sürenin birkaç katına çıkmasıyla makul kalması arasındaki farkı yaratıyor.

Python betiklerinin üretimde patlamasının bir numaralı sebebi, SolidWorks'ün açtığı modal diyaloglar. Bir uyarı penceresi açılır, betik cevap bekler ve işlem sonsuza kadar asılı kalır. Sabah geldiğinizde gece çalışsın diye başlattığınız betik, üçüncü dosyada bir pencereyle sizi bekliyordur.

Çözüm, işlem başında kullanıcı denetimini kapatmak: dosya açma ve kaydetme için sessiz mod, genel uyarı bastırma. İşlem bitince geri açmayı unutmayın — yoksa SolidWorks'ü kapatana kadar hiç uyarı görmezsiniz.

Ama sessizliği kayda dönüştürün: bastırdığınız her uyarı size bir şey söylüyordu. Betik sonunda "şu dosyalarda şu uyarı çıktı" diyen bir liste üretsin.

COM'un `ByRef` tuzağı

Python tarafında en çok zaman kaybettiren teknik ayrıntı bu. SolidWorks API'sindeki birçok metot, sonucu dönüş değeri olarak değil, kendisine verdiğiniz değişkenlerin içine yazarak döndürür. C# ve VBA'da bu doğal; Python'da özel bir sarmalayıcı gerektiriyor.

Pratik sonucu şu: kaydetme, dışa aktarma gibi işlemlerin hata kodunu okumak için o sarmalayıcıları doğru kurmanız gerekir. Kurmazsanız işlem yine çalışır ama hata kodunu hiç göremezsiniz — yani sessiz başarısızlığa kapı açarsınız.

Kural her zaman aynı: hata kodunu kontrol etmeden bir sonraki adıma geçmeyin. Sessiz kaydetme, kontrol edilmediğinde sessiz veri kaybı demektir.

Tek komutla PDF, DWG, DXF ve büküm resimlerini üretmek, otomasyonun kullanıcı tarafında en çok karşılık bulan kısmı. Sebebi basit: sonucu anında görülüyor ve kimse "bu gerçekten kazandırdı mı" diye sormuyor.

Burada dikkat edilecek üç şey var:

Adlandırma kuralı otomasyonun parçası olmalı. Proje kodu, parça numarası, revizyon — hepsi kurala bağlansın. Aksi hâlde dosyalar üretilir ama kimse hangi revizyonun hangi klasörde olduğunu bilmez ve kazanılan zaman arama zamanında geri gider.

Klasör yapısını betik kursun. Hedef klasör yoksa oluşturulsun. "Klasör yok" hatası, gece çalışan bir betiği durduran en aptalca sebeptir.

Her formatın sonucu ayrı kontrol edilsin. PDF üretildi diye DXF de üretildi sanmayın. Üç formatın üçü de kendi sonuç kodunu döndürür.

Bu, en sık gelen soru. Cevabım net: Python bu işin keşif dili, C# üretim dili.

Python'un gerçekten parladığı yer, bir fikri yarım saatte deneyip çalışıp çalışmadığını görmek. Yeniden başlatma yok, derleme yok, proje kurulumu yok. Bir hipoteziniz varsa — "bu ürün ailesini parametreden sürebilir miyim" gibi — cevabı en hızlı Python verir.

Ama üretime giden bir eklenti yazacaksanız C# / .NET'i üç sebeple tercih ediyorum:

Dağıtım. Kullanıcının makinesine Python yorumlayıcısı ve bağımlılık kurmak, tek bir imzalı eklenti dosyası kurmaktan çok daha kırılgan. Ve o kırılganlığın bedelini siz değil, destek isteyen kullanıcı öder.

Performans. COM çağrı sayısı yükseldiğinde — yüzlerce parçalı bir montajda — yönetilen kodun doğrudan API bağlaması belirgin biçimde hızlı. Her COM çağrısının bir maliyeti var ve Python tarafında bu maliyet daha yüksek.

Arayüz. SolidWorks görev bölmesine (Task Pane) gömülü bir panel, kullanıcı için harici bir betik penceresinden kıyaslanamayacak kadar doğal. Kullanıcı otomasyonu SolidWorks'ün bir parçası gibi hissediyorsa benimser; ayrı bir pencere açması gerekiyorsa çoğu zaman hiç kullanmaz.

Pratik kural: fikri Python ile doğrula, kalıcı olacak akışı C# ile yaz. Aradaki köprü, iki tarafın da aynı kural setini okumasıdır — kuralları koda değil, veriye koyun.

Bu geçişin nasıl yapılacağını ve eklenti mimarisinin nasıl kurulacağını SolidWorks add-in geliştirme yazısında ayrıntılı anlattım.

Somut bir öneri: ilk betiğiniz hiçbir şeyi değiştirmesin, sadece okusun.

Açık belgenin adını, türünü ve tasarım ağacındaki özellik adlarını ekrana yazan bir betik, yazması on dakika sürer ama size iki şeyi birden öğretir: bağlantının kurulduğunu ve nesne hiyerarşisinde nasıl gezildiğini. Ve hiçbir riski yoktur.

İkinci betiğiniz bir global değişkeni okusun. Üçüncüsü onu değiştirsin — ama kopya bir dosya üzerinde. Gerçek projede test etmek, en pahalı öğrenme yöntemidir.

Bu sırayla ilerlediğinizde bir hafta içinde çalışan bir otomasyonunuz olur. Ve daha önemlisi, onun neden çalıştığını biliyor olursunuz.

Python ile SolidWorks otomasyonu yapılabilir mi? Evet. SolidWorks'ün otomasyon arayüzü COM üzerinden çalışır ve Python'un pywin32 kütüphanesi bu köprüyü kurar. Aynı API'yi kullanırsınız, sadece farklı bir dilden çağırırsınız.

Python ile SolidWorks'e bağlanırken neden hata alıyorum? En yaygın sebep mimari uyumsuzluğu: 64-bit SolidWorks'e 32-bit Python'dan bağlanılamaz ve alınan hata mesajı bunu açıkça söylemez. İkinci sık sebep, COM tip kütüphanesinin oluşturulmamış olması nedeniyle sabitlerin tanınmamasıdır.

SolidWorks API'sinde ölçüler hangi birimde verilir? Sistem birimiyle, yani metre olarak. Belge ekranda milimetre gösterse bile koda yazdığınız sayı metre kabul edilir; 2400 mm için 2.4 yazmanız gerekir. Bu, otomasyonun en sinsi hatasıdır çünkü sonuç bazen gözle fark edilmez.

Parametreleri feature üzerinden mi global değişkenle mi güncellemeliyim? Global değişkenle. Feature adına bağlı güncelleme, model tarafında bir ad değiştiğinde sessizce çalışmaz hale gelir. Global değişken, betikle model arasında sabit bir sözleşme kurar.

Betiğim bir pencerede takılıp kalıyor, ne yapmalıyım? Sebep SolidWorks'ün açtığı modal uyarı penceresidir. İşlem başında dosya açma ve kaydetme için sessiz modu açın, sonunda geri kapatın; bastırdığınız uyarıları da betik sonunda bir rapor olarak yazdırın.

Python mı C# mı kullanmalıyım? Keşif ve fikir doğrulama için Python — hiçbir alternatif bu kadar hızlı değil. Üretime giden, ekibin kullanacağı ve SolidWorks içine gömülü çalışacak akışlar için C# / .NET; dağıtım, performans ve arayüz üçü de C# tarafını gerektirir.

Toplu işlemde betiğim çok yavaş, nasıl hızlandırırım? En yaygın sebep, her parametre değişikliğinden sonra modelin yeniden kurulmasıdır; tüm parametreler yazıldıktan sonra bir kez yeniden kurun. İkinci sebep ekran güncellemesinin açık kalmasıdır — toplu işlemlerde kapatmak belirgin hızlanma sağlar.

Python ile SolidWorks otomasyonu, bir fikri en hızlı test edeceğiniz yol. COM köprüsü kurulduktan sonra elinizde API'nin tamamı var.

Üç şeyi baştan doğru yapın: birimleri metre olarak düşünün, parametreleri global değişkenle sürün ve her sonucu kontrol edin. Bu üçü olmadan yazılmış bir betik, çalışıyor görünürken sessizce yanlış çıktı üretir.

Ve şunu unutmayın: Python'da hızla kurduğunuz o akış kalıcı olacaksa, bir noktada C# tarafına taşınması gerekecek. Bu bir başarısızlık değil, planlanmış bir adım.