SolidWorks Makro ve API Arasındaki Fark Nedir?

Makro, SolidWorks içinde çalışan ve belirli bir görevi tek komuta indiren küçük bir programdır. İki yolla üretilir:

Kaydederek. Macro Recorder açıkken yaptığınız işlemler koda dökülür. Bu, API'yi öğrenmenin en hızlı yoludur: bir işlemi elle yapıp üretilen koda bakmak, hangi arayüzün hangi metodu çağırdığını doğrudan gösterir.

Yazarak. Kaydedilen kod nadiren üretime hazırdır — genelde seçime, aktif belgeye ve ekrandaki duruma bağımlı çıkar. Gerçek bir makro, bu kodun elle yeniden yazılmasıyla oluşur.

Makrolar VBA ile yazılır ve .swp dosyası olarak saklanır. Bu dosya hem çalıştırılabilir hem de kaynak kodun kendisidir; tek parça olması paylaşımı kolaylaştırır. SolidWorks ayrıca .NET tabanlı makroları da (.swb) destekler.

Makronun tanımlayıcı özelliği tek dosya olması değil, yaşam döngüsüdür: kullanıcı çağırdığında başlar, işini yapar, biter.

API (Uygulama Programlama Arayüzü), SolidWorks'ün nesne modeline dışarıdan erişim veren katmandır. Kod yazarken karşılaştığınız isimler bu modelin parçalarıdır:

• SldWorks — uygulamanın kendisi
• ModelDoc2 — açık belge (parça, montaj veya teknik resim)
• PartDoc, AssemblyDoc, DrawingDoc — belge türüne özel arayüzler
• CustomPropertyManager — özel özellikler (Custom Properties)
• ISwAddin — eklentilerin SolidWorks'e kaydolduğu arayüz

API COM tabanlıdır. Pratikte bunun anlamı şudur: aynı nesne modeline VBA'dan da, C#'tan da, C++'tan da, Python'un COM köprüsünden de erişilebilir. Erişilen şey değişmez; erişen program değişir.

Bu yüzden "API mi kullanmalıyım, makro mu" sorusu teknik olarak tam oturmaz. Doğru soru mimariyle ilgilidir.

Zihinsel model şöyle kurulur:

Zihinsel model şöyle kurulur — yukarıdan aşağıya beş katman:

1. SOLIDWORKS — uygulamanın kendisi.
2. SOLIDWORKS API — uygulamaya programla erişmenizi sağlayan katman (COM üzerinden çalışır).
3. Dil — o katmanı hangi dille çağırdığınız: VBA, C#, VB.NET, C++ ya da Python.
4. Biçim — yazdığınız şeyin hangi kapta durduğu: makro, eklenti (add-in) ya da bağımsız uygulama.
5. CAD otomasyonu — bütün bunların mühendislik sürecine uygulanmış hâli.

Karışıklığın kaynağı, üçüncü ve dördüncü katmanın sürekli birbirine karıştırılması. "Makro mu yazsam API mi kullansam" sorusu bu yüzden yanlış kurulmuş bir sorudur: makro yazdığınızda zaten API'yi kullanıyorsunuzdur. Doğru soru, dördüncü katmanla ilgilidir — hangi kap?

Alttan üçüncü satır, kararın verildiği yerdir. Üstündeki iki satır sabittir; altındaki satır ise işin gerçek karşılığıdır.

Tekrarlayan işlemleri tek komuta indirme

Bir mühendis her teknik resimde aynı 12–15 adımı yapıyorsa — görünüş yerleşimi, ölçek, antet alanlarının doldurulması, kaydetme, PDF çıktısı — bu akış tek düğmeye indirilebilir. Kazanç tek seferde küçüktür; tekrar sayısıyla çarpıldığında büyür.

Standartlaştırma

Makronun az konuşulan ama sahada en çok fark yaratan tarafı budur. Makro yalnızca işi hızlandırmaz, herkesin aynı işi aynı kuralla yapmasını sağlar. Dosya adlandırma, revizyon alanı, çıktı klasörü, katman eşlemesi — bunlar elle yapıldığında kişiden kişiye değişir. Kodda ise tek bir tanım vardır.

Bir otomasyon projesinin ölçülebilir kazancı çoğu zaman süreden değil, bu tutarlılıktan gelir. Yanlış adlandırılmış tek bir DXF, kazandırdığı dakikaların tamamını üretimde geri alır.

İnsan kaynaklı hata riskini azaltma

Riskin yoğunlaştığı yerler bellidir: dosya adları, revizyon numaraları, özel özellikler, çıktı klasörleri, katman ve renk eşlemesi, birim seçimi. Hepsi tekrarlayan ve dikkat gerektiren, yani insanın en kolay yanıldığı işlerdir.

Toplu işlem (batch processing)

100 teknik resmi tek tek açıp kaydetmek yerine klasörü baştan sona işlemek, makronun en görünür kazancıdır.

Burada Türkçe kaynaklarda sık atlanan bir ayrım var. Toplu PDF/DXF için genelde Görev Zamanlayıcı (Task Scheduler) veya PDM görevleri önerilir. İkisi de çalışır — ama ikisi de lisans seviyesine bağlıdır ve kuralları sabittir. Makro ya da API tabanlı bir çözüm, SolidWorks Standard üzerinde çalışır ve kuralı sizin süreçlerinize göre yazar: hangi konfigürasyon, hangi katman eşlemesi, hangi ad şablonu, hangi koşulda atla. Hazır araç "dosyayı çevirir"; kod "sizin kuralınızla çevirir".

Üretim çıktılarının otomasyonu

PDF, DXF, DWG, STEP, STL, BOM ve Excel çıktıları — tasarımın üretime geçtiği nokta burasıdır ve hataların en pahalı olduğu yer de burasıdır.

Parametrik modelle birleşince

Önemli bir ayrım: parametrik tasarım makro değildir. Parametrik model, geometrinin kurallara bağlanmasıdır; makro ise o kuralları dışarıdan sürebilen koddur. İkisi ayrı ayrı işe yarar, birleştiğinde otomasyonun sınıfı değişir: kullanıcı birkaç ölçü girer, model kendini kurar, teknik resim ve üretim çıktısı arkadan gelir.

Sahada en sık karşılaştığım kalemler:

• Özel özelliklerin (Custom Properties) toplu okunması, yazılması ve doğrulanması
• Teknik resimlerden toplu PDF / DXF / DWG üretimi
• Parçalardan STEP / STL çıktısı
• Dosya adlandırma ve revizyon alanlarının kurala bağlanması
• BOM'un dışa aktarılması ve Excel ile eşleştirilmesi
• Görünüş yerleşimi, ölçek ve antet doldurma
• Konfigürasyon üretimi ve tablo tabanlı varyant oluşturma
• Model ve resim üzerinde standart uygunluk denetimi

Bu listenin ortak yanı şu: hepsi kurala bağlanabilen işlerdir. Yargı gerektiren işler — hangi tasarımın doğru olduğu, hangi toleransın uygun olduğu — bu listede yoktur ve olmamalıdır.

Makro, aşağıdaki durumlarda genellikle doğru ve yeterli tercihtir:

• Aracı kullanan kişi sayısı az; çoğu zaman yazan kişinin kendisi
• İş tek bir komutla başlayıp biten bir akış
• Toplu dışa aktarma ya da özellik düzenleme gibi sınırlı kapsamlı bir görev
• Fikrin işe yarayıp yaramadığını hızlı doğrulamak gerekiyor (proof-of-concept)
• Süreç henüz oturmamış; kural haftadan haftaya değişiyor

Son madde önemlidir. Kuralı belirsiz bir sürecin üstüne eklenti mimarisi kurmak, en pahalı hatalardan biridir. Böyle durumlarda makro yalnızca hızlı çözüm değil, doğru çözümdür — çünkü ucuz atılabilir.

Buradaki dili özellikle dikkatli kuruyorum: makronun "yapamayacağı" işler listesi değil bu. VBA ile şaşırtıcı derecede çok şey yapılabilir. Sorun kabiliyet değil, sürdürülebilirliktir.

Sınır şu belirtiler görünmeye başladığında geçilmiştir:

• Sürekli çalışma gerekiyor. Makro çağrılınca başlar ve biter. SolidWorks açık olduğu sürece arka planda dinleyen bir davranış (belge açılınca kontrol et, kaydetmeden önce doğrula) makronun yaşam döngüsüne ters düşer.
• Olay yakalama gerekiyor. Kaydetme, açma, yeniden oluşturma olaylarına bağlanmak eklenti mimarisinin işidir.
• Arayüz büyüyor. Basit bir giriş kutusunun ötesine geçildiğinde — CommandManager sekmesi, TaskPane, PropertyManagerPage — VBA formları hızla yetersiz kalır.
• Ekip çapında dağıtım var. On kişinin makro dosyasını elle güncellemesi, ilk revizyona kadar çalışır.
• Merkezî güncelleme gerekiyor. Kimin hangi sürümü kullandığını bilemiyorsanız otomasyonun ürettiği çıktıya güvenemezsiniz.
• Hata yönetimi ve kayıt (logging) ciddiye alınmalı. "Çalışmadı" geri bildirimiyle sorun bulmak, log olmadan tahmin oyunudur.
• Sürüm kontrolü ve test gerekiyor. Tek dosyalık ikili biçim, kod incelemesi ve fark görüntüleme için elverişli değildir.
• Entegrasyon giriyor. PDM, ERP, veritabanı ya da dış servis bağlantısı, bağımlılık ve kimlik doğrulama yönetimi gerektirir.

Soruyu şöyle sormak daha verimli: "Teknik olarak yapılabilir mi?" değil, "Bu mimari bu iş için bir yıl sonra hâlâ ayakta kalır mı?"

Tablonun okunma biçimi önemli: sağ sütun "daha iyi" demek değildir. Sol sütun küçük ve belirsiz işlerde daha doğrudur — çünkü mimari maliyeti yoktur.

Karar üç soruya iner:

Kaç kişi kullanacak? Bir kişiyse VBA. Bir ekipse dağıtım ve güncelleme sorunu doğar; .NET tarafı bunun için var.

Ne kadar yaşayacak? Birkaç haftalık bir ihtiyaçsa VBA. Süreçle birlikte yıllarca yaşayacaksa, bakım maliyeti başlangıç maliyetini kısa sürede geçer.

SolidWorks ile ne kadar iç içe olacak? Kullanıcının çağırdığı tek bir komutsa VBA yeter. SolidWorks'ün davranışını değiştiriyorsa — arayüze sekme ekliyor, kaydetmeyi denetliyor, açılışta kontrol yapıyorsa — eklenti mimarisi gerekir.

Python bu tablonun dışında ayrı bir yerde durur: hızlı prototipleme, veri işleme ve COM üzerinden belirli otomasyon senaryoları için elverişlidir, ancak SolidWorks içine gömülü bir arayüz sunmaz. Sınırlarını SolidWorks otomasyonunda Python'un yeri yazısında ayrıca ele aldım.

1. Her teknik resimde aynı özel özellikler dolduruluyor. Yaklaşım: VBA makro. Tek komut, tek dosya, hızlı kazanç.

2. Yüzlerce parçanın PDF ve DXF çıktısı alınacak. Yaklaşım: Makro ya da API tabanlı toplu işlem. Kural karmaşıksa (konfigürasyona göre farklı katman eşlemesi, koşullu atlama) kod tarafı hazır araçtan üstündür.

3. Kullanıcı birkaç ölçü giriyor, komple montaj kuruluyor. Yaklaşım: Parametrik model + API. Burada asıl iş kodda değil, modelin kurallarının sağlam kurulmasındadır. Kötü kurulmuş bir parametrik model, en iyi kodu bile taşımaz.

4. Firma genelinde kullanılan özel bir SolidWorks arayüzü gerekiyor. Yaklaşım: C#/.NET eklenti. CommandManager sekmesi, merkezî güncelleme, kullanıcı ayarları.

5. SolidWorks ile ERP/PDM arasında veri alışverişi var. Yaklaşım: API + entegrasyon katmanı, gerektiğinde eklenti. Kritik nokta veri akışının tek yönlü mü çift yönlü mü olduğudur; çift yönlüyse çakışma çözümü baştan tasarlanmalıdır.

6. Kurallara göre 2B teknik resimlerden 3B model üretiliyor. Yaklaşım: Parametrik kurallar + API, gerektiğinde yapay zeka destekli yorumlama katmanı. Bu senaryoyu 2B teknik resimden 3B modele otomasyon yazısında ayrıntılandırdım.

Sıralama basittir ve tersine çevrilmemelidir:

1. Önce ölç. Hangi iş, ne sıklıkla, ne kadar sürede tekrarlanıyor? Bu ölçüm yoksa hangi aracı seçtiğinizin önemi yoktur. Yöntemi otomasyon projesine nasıl başlanır yazısında adım adım anlattım.
2. En küçük çalışan çözümle doğrula. Genelde bu bir makrodur.
3. Kullanımı izle. Kim kullanıyor, nerede tıkanıyor, hangi kural değişiyor?
4. Mimariyi ihtiyaç büyüdükçe büyüt. Eklenti kararı, makronun sınırına gerçekten vurulduğunda verilir — vurulacağı tahmin edildiğinde değil.

Kazancın gerçekten oluşup oluşmadığını hesaplarken geliştirme ve bakım maliyetini de denkleme koymak gerekir; bunun için otomasyon kazancını ölçmek yazısındaki yaklaşımı kullanıyorum.

Kendi projelerimde neredeyse hiç eklentiyle başlamadım.

SolidWorks otomasyon çalışmalarında izlediğim sıra hep aynı oldu: önce tekrar eden işi ölçmek, sonra küçük bir makroyla kuralın doğru olduğunu doğrulamak, kural sahada oturduktan sonra mimariyi büyütmek. VBA'dan C#/.NET eklenti mimarisine geçişleri de bu şekilde yaptım — geçiş kararı bir tercih değil, biriken belirtilerin sonucuydu: ekip büyüdü, dağıtım sorun oldu, olay tabanlı davranış gerekti.

Bu yaklaşımın somut karşılığını iki yerde görebilirsiniz: SolidWorks CAD otomasyonu vaka çalışması makro seviyesinden eklenti mimarisine geçişi, ParametriX ise parametrik tasarım ile API otomasyonunun birleştiği noktayı anlatıyor.

Yapay zekayı bu süreçte kullanıyorum ama sınırlarını bilerek: iskelet kodda ve API keşfinde gerçekten hızlandırıyor, COM yaşam döngüsü ve sessiz hatalar konusunda kendinden emin biçimde yanılıyor. Ayrımı yapay zeka ile SolidWorks eklentisi yazmak yazısında ayrıntılandırdım.

SolidWorks makro ve API aynı şey mi? Hayır. API erişim katmanıdır, makro ise o katmanı kullanan uygulama biçimlerinden biridir. Makro yazarken zaten API kullanırsınız.

SolidWorks makro hangi dille yazılır? Öncelikle VBA. SolidWorks ayrıca .NET tabanlı makroları da destekler. Eklentiler ise C#, VB.NET veya C++ ile yazılır.

SolidWorks API ücretli mi? API, SolidWorks lisansının parçasıdır; ayrı bir ürün olarak satılmaz. Erişilebilen yetenekler kullandığınız SolidWorks sürümüne göre değişir.

Makro mu Add-in mi seçmeliyim? Kaç kişinin kullanacağına, ne kadar yaşayacağına ve SolidWorks ile ne kadar iç içe olacağına bakın. Tek kullanıcı ve tek komutsa makro; ekip, arayüz ve olay yakalama varsa eklenti.

SolidWorks API öğrenmek zor mu? Nesne modeli geniştir ama giriş eşiği düşüktür. Macro Recorder ile bir işlemi kaydedip üretilen koda bakmak, dokümantasyondan başlamaktan daha hızlı ilerletir.

Makro ne zaman yetersiz kalır? Sürekli çalışma, olay yakalama, ekip çapında dağıtım, merkezî güncelleme, gelişmiş hata yönetimi veya kurumsal entegrasyon gerektiğinde. Bu bir kabiliyet sınırı değil, sürdürülebilirlik sınırıdır.

Parametrik tasarım ile makro arasındaki fark nedir? Parametrik tasarım geometrinin kurallara bağlanmasıdır; makro o kuralları dışarıdan süren koddur. Birleştiklerinde çok daha güçlü bir otomasyon çıkar.

"Makro mu API mi" sorusu, cevaplanmayı değil düzeltilmeyi gerektiren bir sorudur. API zaten her yolun altındadır; seçim, o API'ye hangi mimariyle uzanacağınızdır.

Pratik özet:

• Küçük, tek kullanıcılı, kısa ömürlü iş → makro
• Ekip çapında, sürekli çalışan, arayüz ve entegrasyon gerektiren iş → C#/.NET eklenti
• İkisi arasındaki karar → mimari sürdürülebilirlik sorusu, kabiliyet sorusu değil
• Her durumda → önce ölç, sonra en küçük çözümle doğrula, sonra büyüt

Firmanızda her siparişte veya her projede aynı SolidWorks adımlarını tekrar ediyorsanız, sürecin makro, API ya da eklenti seviyesinde otomasyona uygun olup olmadığını birlikte değerlendirebiliriz — iletişim bölümünden yazabilirsiniz.