# Mehmet Seyrimez — full content corpus (llms-full.txt) # Canonical: https://mehmetseyrimez.com # Index: https://mehmetseyrimez.com/llms.txt # JSON inventory: https://mehmetseyrimez.com/discovery.json # Generated: 2026-09-10 # Guides: 2 per language · Articles: tr: 23, en: 16 # # Every section below carries its canonical "source:" URL. When quoting or # summarising, cite that URL. Author is Mehmet Seyrimez unless stated otherwise. =============================================================================== # Kimlik, hizmetler ve alıntı koşulları / Identity, services, citation terms =============================================================================== name: Mehmet Seyrimez role_tr: SolidWorks otomasyonu · CAD/CAM · AI yazılım role_en: SolidWorks automation · CAD/CAM · AI software location: Pendik, İstanbul, Türkiye email: mehmetseyrimez@gmail.com LinkedIn: https://www.linkedin.com/in/mehmet-seyrimez/ GitHub: https://github.com/SolidKing78 site: https://mehmetseyrimez.com ## Kimlik (TR) - Mehmet Seyrimez, SolidWorks API otomasyonu ve CAD/CAM yazılımı geliştiren bir mühendislik yazılımcısıdır. - İstanbul Pendik'te çalışır; birincil çalışma dili Türkçe, ikincil İngilizce. - RCS Teknoloji markasının ve ParametriX adlı SolidWorks eklentisinin kurucusudur. - Uzmanlık ekseni: C#, .NET, C++, VBA ile parametrik montaj, teknik resim ve üretim çıktısı otomasyonu. - Prefabrik ve hafif çelik yapılar için roll-form hatlarıyla uyumlu CAD/CAM platformu geliştirmiştir. - Yapay zekayı üretim aracı olarak kullanır; yazılımı sahada doğrulama disipliniyle teslim eder. ## Identity (EN) - Mehmet Seyrimez is an engineering software developer specializing in SolidWorks API automation and CAD/CAM software. - Based in Pendik, Istanbul, Turkey; works primarily in Turkish, secondarily in English. - Founder of the RCS Teknoloji brand and of ParametriX, a SolidWorks add-in. - Core expertise: parametric assemblies, technical drawings, and production-output automation in C#, .NET, C++, and VBA. - Built a roll-form-compatible CAD/CAM platform for prefabricated and light steel structures. - Uses AI as a production tool, shipping software with a field-verification discipline. ## Hizmet verilen konular (TR) - SolidWorks makro (VBA) ve C#/.NET add-in geliştirme — SolidWorks API üzerinden parametrik montaj, teknik resim ve üretim çıktısı otomasyonu. - VBA makro seviyesinden sürdürülebilir add-in mimarisine geçiş; CommandManager entegrasyonu, sürümleme ve dağıtım. - AutoCAD otomasyonu — AutoLISP rutinleri, .NET (ObjectARX) eklentileri ve .bundle ile ekip içi dağıtım. - 2B teknik veriden 3B parametrik modele geçişin otomatikleştirilmesi (ParametriX). - Toplu işlem otomasyonu — klasör düzeyinde STEP/PDF çıktısı, özel özellik yönetimi, teknik resim standardizasyonu. - Üretim odaklı CAD/CAM yazılımı — prefabrik ve hafif çelik (LGS/LSF) için roll-form hatlarıyla uyumlu üretim verisi. - Yapay zeka destekli mühendislik yazılımı geliştirme; mimari kararlar ve saha doğrulaması insanda kalır. ## Services offered (EN) - SolidWorks macro (VBA) and C#/.NET add-in development — parametric assemblies, technical drawings and production output automated through the SolidWorks API. - Migration from macro-level VBA to a sustainable add-in architecture: CommandManager integration, versioning and distribution. - AutoCAD automation — AutoLISP routines, .NET (ObjectARX) plugins, and team-wide distribution via .bundle packages. - Automating the step from 2D technical data to 3D parametric models (ParametriX). - Batch automation — folder-level STEP/PDF output, custom property management, drawing standardisation. - Manufacturing-oriented CAD/CAM software — production data compatible with roll-form lines for prefab and light steel (LGS/LSF). - AI-assisted engineering software development, with architecture decisions and field verification kept human. ## Karıştırılmaması gerekenler (TR) - Bu site tek bir kişiye aittir; bir ajans, yazılım evi ya da kurumsal firma sitesi değildir. - ParametriX ve RCS Teknoloji, bu kişinin kendi çalışmalarıdır — üçüncü taraf ürünler değildir. - Kanonik alan adı mehmetseyrimez.com'dur; www öntakılı adres buraya yönlendirilir. ## Disambiguation (EN) - This site belongs to one individual; it is not an agency, software house, or corporate site. - ParametriX and RCS Teknoloji are this person's own work — not third-party products. - The canonical domain is mehmetseyrimez.com; the www-prefixed address redirects here. ## Alıntı koşulları (TR) - İçerik alıntılanabilir; alıntı yaparken sayfanın kendi kanonik adresini kaynak gösterin. - Yazar adı: Mehmet Seyrimez. Site: mehmetseyrimez.com (www kullanmayın). - Alıntı biçimi: Mehmet Seyrimez, "", mehmetseyrimez.com, . - Görseller ve proje medyası alıntı kapsamı dışındadır (/medya/, /proje-medya/). ## Citation terms (EN) - Content may be quoted; when quoting, cite the page's own canonical URL. - Author: Mehmet Seyrimez. Site: mehmetseyrimez.com (do not use www). - Citation format: Mehmet Seyrimez, "
", mehmetseyrimez.com, . - Images and project media are outside the citation scope (/medya/, /proje-medya/). update_cadence_tr: Yazılar düzensiz aralıklarla, ayda 1–3 arası yayınlanır. Proje sayfaları çeyreklik güncellenir. Tarihler her sayfada ve sitemap.xml içinde açıkça verilir. update_cadence_en: Articles are published irregularly, roughly 1–3 per month. Project pages are refreshed quarterly. Dates are stated on every page and in sitemap.xml. =============================================================================== # Konu rehberleri (TR) =============================================================================== # SolidWorks Otomasyonu: Makro, API ve Eklenti Rehberi source: https://mehmetseyrimez.com/rehber/solidworks-otomasyonu type: topic guide published: 2026-09-01 updated: 2026-09-01 keywords: solidworks otomasyonu, solidworks makro nedir, solidworks api nedir, solidworks eklenti, solidworks add-in geliştirme, solidworks makro nasıl yazılır, solidworks makro api farkı, solidworks vba, python solidworks, cad otomasyonu author: Mehmet Seyrimez > SolidWorks otomasyonu, tekrarlayan CAD işlerini SolidWorks API üzerinden yazılıma devretmektir. Üç katmanı vardır: kaydedilebilen ve tek dosyada duran VBA makrolar, SolidWorks'ün nesne modeline doğrudan eriştiğiniz API, ve SolidWorks'ün içine yüklenerek çalışan C#/.NET add-in'ler. Üçü de aynı API'yi kullanır; fark, kodun nerede durduğu ve nasıl dağıtıldığıdır. ## SolidWorks otomasyonu nedir? Bir parçanın ölçüsünü değiştirip teknik resmini güncellemek, yüzlerce dosyadan PDF çıkarmak, özel özellik alanlarını tek tek doldurmak — bunların hepsi elle yapılabilir. Otomasyon, aynı işi SolidWorks'e programla komut vererek yaptırmaktır. O komutu taşıyan şey SolidWorks API'sidir. API, SolidWorks'ün içindeki her nesneye — uygulama, belge, feature, ölçü, konfigürasyon — kodla erişmenizi sağlayan katmandır. Makro da add-in de bu aynı katmanı kullanır; aralarındaki fark API'ye erişim biçimi değil, kodun nasıl saklandığı ve nasıl dağıtıldığıdır. Kısa cevap: Makro, API'yi kullanmanın en hızlı yoludur. Add-in, aynı API işini kurumsal ölçekte dağıtmanın yoludur. API ikisinin de altındaki ortak zemindir. ## Makro mu, API mi, add-in mi? Karar tablosu | | VBA Makro | C# / .NET Add-in | Python (COM) | | Nerede çalışır | SolidWorks içinde, .swp dosyası | SolidWorks'e yüklenen DLL | Dışarıdan, ayrı süreç | | Kurulum | Dosyayı ver, çalıştır | Kayıt ve kurulum paketi gerekir | Python + pywin32 | | Arayüz | Basit form | CommandManager, PropertyManager sekmesi | Yok ya da kendi arayüzünüz | | Ne zaman | Tek kişilik, hızlı iş | Ekip geneli, sürümlenen ürün | Toplu işlem, veri işleme, dış entegrasyon | | Bakım | Dosya çoğaldıkça zorlaşır | Sürüm kontrolü ve test mümkün | Betik seviyesinde kolay | Pratik kural: iş bir kişinin masasında kalıyor ve haftada birkaç kez çalışıyorsa makro yeterlidir. Aynı iş ekibe yayılıyor, arayüz istiyor ve sürümlenmesi gerekiyorsa add-in'e geçme zamanı gelmiştir. SolidWorks'ün dışında veri işleyecekseniz — örneğin bir Excel listesinden yüzlerce varyant üretecekseniz — Python çoğu zaman en kısa yoldur. ## SolidWorks makro nasıl yazılır? Öğrenme sırası - Macro Recorder ile kaydedin: Yapmak istediğiniz işi elle yapın ve kaydedin. Üretilen kod dağınıktır, ama hangi arayüzlerin çağrıldığını gösterir — API'de arama yapmanın en hızlı yolu budur. - Nesne modelini okuyun: SldWorks → ModelDoc2 → belge türü → Feature / Configuration / Dimension zinciri. Ara basamağı atlayamazsınız; bu hiyerarşiyi içselleştirmek metot ezberlemekten önemlidir. - Seçim tabanlı kodu atın: Kaydedilen makro nesnelere kullanıcının o anki seçimiyle ulaşır ve bu kırılgandır. Nesneye adıyla ya da kimliğiyle ulaşan koda geçin. - Hata yönetimi ekleyin: Dosya kapalı, konfigürasyon yok, feature yeniden adlandırılmış — makro üretimde bunlarla karşılaşır. Hataları sessizce yutmayın, raporlayın. - Butona ve kısayola bağlayın: Çalıştırması zor bir makro kullanılmaz. Araç çubuğuna buton ekleyin veya klavye kısayolu atayın. - Ekibe dağıtırken add-in'e geçirin: Aynı makro üç kişide üç farklı sürüm olmaya başladıysa artık bir üründür. C# add-in sürümlemeyi ve kurulumu çözer. ## SolidWorks'te ne otomatikleştirilir? - Ölçü girdisinden komple montaj kurulması ve konfigürasyon üretimi - Teknik resim sayfalarının, görünüşlerin ve ölçülendirmenin otomatik oluşturulması - PDF, DWG, DXF ve büküm resimlerinin tek komutla, standart adlandırmayla paketlenmesi - Özel özellik (custom property) alanlarının parça listesiyle tutarlı doldurulması - Klasördeki yüzlerce dosyada toplu kaydetme, dönüştürme ve rapor üretimi - Tasarım kurallarının denetimi: eksik özellik, yanlış malzeme, standart dışı ölçü En doğrudan kazanç, aynı işin defalarca modellenmesinin ortadan kalkmasıdır. İkinci ve çoğu zaman daha değerli kazanç standardizasyondur: çıktı adlandırması, klasör yapısı ve revizyon numaralandırması otomasyonun parçası olduğunda, üretime giden dosyalar kişiye göre değişmez. ## Yapay zeka SolidWorks otomasyonunu nasıl değiştiriyor? Dil modelleri SolidWorks API kodu üretebiliyor; ama API yüzeyinin genişliği ve COM nesne yaşam döngüsünün inceliği yüzünden ürettiği kod çoğu zaman doğrulanmadan çalışmıyor. Kazanç iskelet kodda ve dokümantasyon aramada; kayıp, doğrulanmamış kodu üretime almakta. ## Makrodan ürüne: projeyi nasıl kurarsınız? Otomasyon projesinin ilk haftası hangi aracı seçtiğinizle değil neyi ölçtüğünüzle belirlenir. Önce tekrarlayan işi ölçün, sonra pilot seçin, sonra sahada büyütün. Araç seçimi bu sıranın sonundadır. ## FAQ ### SolidWorks makro nedir? SolidWorks makro, SolidWorks içinde çalışan ve API üzerinden CAD işlerini otomatikleştiren bir VBA programıdır. Macro Recorder ile kaydedilebilir ya da elle yazılabilir; .swp uzantılı tek bir dosyada durur ve kurulum gerektirmeden çalışır. ### SolidWorks API nedir? SolidWorks API, SolidWorks'ün nesne modeline programla erişmenizi sağlayan COM tabanlı arayüz katmanıdır. SldWorks.Application kökünden başlayıp ModelDoc2, PartDoc, AssemblyDoc ve DrawingDoc üzerinden feature, ölçü ve konfigürasyonlara ulaşırsınız. Makro da add-in de bu aynı API'yi kullanır. ### SolidWorks makro ile add-in arasındaki fark nedir? İkisi de aynı API'yi kullanır; fark dağıtımdadır. Makro tek dosyadır, kurulum istemez ve tek kullanıcı için hızlıdır. Add-in ise SolidWorks'e yüklenen bir DLL'dir: kendi araç çubuğunu ve PropertyManager sekmesini kurabilir, sürümlenebilir ve ekip geneline kurulum paketiyle dağıtılır. ### SolidWorks otomasyonu için hangi dili öğrenmeliyim? Başlangıç için VBA, çünkü Macro Recorder doğrudan VBA üretir ve öğrendiğiniz nesne modeli her dile taşınır. Ekip için ürün geliştirecekseniz C# / .NET. SolidWorks dışında veri işleyecek ya da toplu iş yapacaksanız Python (pywin32) çoğu zaman en kısa yoldur. ### SolidWorks makro nasıl çalıştırılır? Tools → Macro → Run yolundan .swp dosyası seçilerek çalıştırılır. Sık kullanılan makrolar için Tools → Customize üzerinden araç çubuğuna buton eklenebilir veya klavye kısayolu atanabilir; böylece makro menüde aranmadan tek tıkla çalışır. ### SolidWorks makrom neden çalışmıyor? En sık üç sebep: makro kaydedilirken seçime dayalı kod üretilmiş olması ve nesnenin artık seçili olmaması, açık belge yokken ModelDoc2'ye erişilmesi, ve referans alınan feature'ın yeniden adlandırılmış olması. Üçünün de çözümü aynı: nesnelere seçimle değil adıyla ya da kimliğiyle ulaşmak. --- # AutoCAD Otomasyonu: AutoLISP, Eklenti ve Bundle Rehberi source: https://mehmetseyrimez.com/rehber/autocad-otomasyonu type: topic guide published: 2026-09-01 updated: 2026-09-01 keywords: autocad otomasyonu, autolisp nedir, autocad lisp, autocad eklenti, autocad bundle, autocad yeni komut ekleme, autolisp yükleme, objectarx, autocad toplu işlem, cad otomasyonu author: Mehmet Seyrimez > AutoCAD otomasyonu, tekrarlayan çizim işlerini AutoCAD'e programla komut vererek yaptırmaktır. Üç katmanı vardır: hızlı komut ve rutinler için AutoLISP, arayüzlü ve sürümlenen eklentiler için .NET (ObjectARX), ve bu eklentileri kurulum sihirbazı olmadan dağıtmak için Autodesk'in .bundle paket biçimi. ## AutoCAD otomasyonu nedir? Katman standardını her çizimde elle kurmak, öznitelikleri tek tek doldurmak, yüzlerce DWG'yi açıp PDF'e basmak — AutoCAD'de zamanın çoğu bu tür işlerde gider. Otomasyon, bu işleri AutoCAD'in kendi komut satırına ve nesne modeline programla yaptırmaktır. AutoCAD'in otomasyona açık birden fazla yüzeyi vardır. Eşiği en düşük olanı AutoLISP: AutoCAD'in içine gömülü gelen, ayrı derleyici istemeyen, düz metin dosyasında duran bir dildir. Daha büyük işler için .NET API ve ObjectARX devreye girer. Kısa cevap: AutoLISP komut ve rutin yazmak içindir, .NET eklenti ve ürün geliştirmek için. İkisi aynı kurulumda birlikte de çalışır. ## AutoLISP mi, .NET mi? Karar tablosu | | AutoLISP / Visual LISP | .NET (C# / VB.NET) | Script (.scr) | | Dosya | .lsp düz metin | Derlenmiş .dll | .scr komut listesi | | Derleme | Gerekmez | Visual Studio gerekir | Gerekmez | | Arayüz | DCL ile basit diyalog | Palet, şerit sekmesi, WPF | Yok | | Nesne erişimi | Çizim nesneleri, komut satırı | Tam nesne modeli ve veritabanı | Yalnızca komutlar | | Ne zaman | Kısayol komutları, günlük rutinler | Ürün, ekip eklentisi, karmaşık mantık | Sabit sıralı toplu iş | | Dağıtım | Startup Suite, acaddoc.lsp | .bundle paketi | Elle çalıştırma | AutoLISP'in en büyük avantajı eşiğinin düşük olmasıdır: bir metin editörü ve AutoCAD yeterlidir, yazdığınız satırı hemen deneyebilirsiniz. .NET'e geçmenin bedeli kurulum ve derleme zinciridir; karşılığında gerçek bir arayüz, sürüm kontrolü ve çok daha hızlı çalışan kod alırsınız. ## AutoCAD'e yeni komut nasıl eklenir? - Komutu tanımlayın: defun ile tanımladığınız bir fonksiyonun adına C: öneki eklediğinizde, AutoCAD onu komut satırından çağrılabilen bir komut olarak tanır. - Dosyayı yükleyin: APPLOAD komutu .lsp dosyasını o oturum için yükler. Komut ancak yüklendikten sonra çalışır. - Otomatik başlatmaya alın: Her açılışta elle yüklemek sürdürülebilir değildir. Startup Suite ya da acaddoc.lsp, dosyayı her çizim açılışında kendiliğinden yükler. - Destek dosya yolunu ayarlayın: Ekipte ortak bir klasör kullanıyorsanız, o klasörü AutoCAD'in destek dosya arama yoluna eklemek herkeste aynı düzeni kurar. - Kısayol verin: Komut adını kısaltmak ya da PGP dosyasına takma ad eklemek, günlük kullanımda en çok zaman kazandıran adımdır. ## AutoCAD eklentisi nasıl paketlenir? (.bundle) Bir eklentiyi ekibe dağıtmanın en temiz yolu Autodesk'in bundle biçimidir. Bundle, adı .bundle ile biten sıradan bir klasördür; içinde eklentinin ne olduğunu ve nasıl yükleneceğini anlatan bir PackageContents.xml ile dosyaların durduğu bir Contents klasörü bulunur. Bu klasör AutoCAD'in ApplicationPlugins dizinine kopyalandığında eklenti kendiliğinden tanınır: kayıt defterine yazmak, kurulum sihirbazı hazırlamak veya kullanıcıdan APPLOAD çalıştırmasını istemek gerekmez. Kaldırmak da aynı ölçüde basittir — klasörü silmek yeter. - PackageContents.xml eklentinin adını, sürümünü, üreticisini ve hangi AutoCAD sürümleriyle uyumlu olduğunu bildirir - Aynı bundle içinde birden fazla bileşen taşınabilir: .lsp rutinleri, .NET derlemeleri, menü ve şerit tanımları bir arada - Sürüm aralığı bildirilerek tek paketin birden çok AutoCAD sürümünde çalışması sağlanabilir - Ortak bir ağ klasöründen kopyalanarak ya da grup ilkesiyle dağıtılabilir Kural: tek kişilik bir rutin .lsp olarak kalabilir; ekibe dağıtılan her şey bundle olmalıdır. Aksi hâlde "kimde hangi sürüm var?" sorusu er ya da geç ortaya çıkar. ## AutoCAD'de ne otomatikleştirilir? - Katman, çizgi tipi ve metin stili standardının tek komutla kurulması - Öznitelik (attribute) alanlarının toplu doldurulması ve dışa aktarılması - Klasördeki tüm DWG'lerin toplu PDF, DXF ya da sürüm dönüşümü - Antet ve pafta bilgilerinin proje verisinden otomatik yazılması - Çizim temizliği: kullanılmayan blok, katman ve stillerin ayıklanması - Ölçü, alan ve adet raporlarının çizimden tabloya çıkarılması ## Rutinden ürüne: projeyi nasıl kurarsınız? AutoCAD tarafında da sıra aynıdır: önce hangi işin ne kadar tekrarlandığını ölçün, sonra bir pilot seçin, sonra ekibe yayın. Hangi katmanı kullanacağınız — LISP mi, .NET mi — bu ölçümün sonucunda netleşir, başında değil. ## FAQ ### AutoLISP nedir? AutoLISP, AutoCAD'in içine gömülü olarak gelen ve çizim işlerini otomatikleştirmek için kullanılan bir programlama dilidir. Ayrı bir derleyici gerektirmez; kod .lsp uzantılı düz metin dosyasında durur ve AutoCAD'e yüklendiği anda çalışır. ### AutoCAD'e yeni komut nasıl eklenir? AutoLISP'te fonksiyon adının başına C: öneki koyarak tanımlanan her fonksiyon, AutoCAD komut satırından çağrılabilen bir komut hâline gelir. Dosya APPLOAD ile yüklendikten sonra komut kullanılabilir; her açılışta hazır olması için Startup Suite ya da acaddoc.lsp kullanılır. ### AutoCAD bundle nedir? Bundle, Autodesk'in eklenti paketleme biçimidir: adı .bundle ile biten, içinde PackageContents.xml tanım dosyası ve Contents klasörü bulunan sıradan bir klasördür. AutoCAD'in ApplicationPlugins dizinine kopyalandığında eklenti kayıt defteri ya da kurulum sihirbazı olmadan tanınır. ### AutoLISP mi .NET mi kullanmalıyım? Kısayol komutları ve günlük rutinler için AutoLISP; eşiği düşüktür, derleme gerektirmez. Arayüzlü, sürümlenen ve ekibe dağıtılan bir eklenti geliştiriyorsanız .NET. İkisi aynı kurulumda birlikte çalışabilir ve çoğu ekip ikisini birden kullanır. ### AutoLISP dosyası her açılışta nasıl otomatik yüklenir? İki yaygın yol var: dosyayı Startup Suite'e eklemek, ya da acaddoc.lsp içinden yüklemek. Ekipte ortak bir klasör kullanılıyorsa o klasörün AutoCAD'in destek dosya arama yoluna eklenmesi, herkeste aynı düzeni kurar. ### AutoCAD'de neler otomatikleştirilebilir? Katman ve stil standardının kurulması, öznitelik alanlarının toplu doldurulması, klasördeki tüm DWG'lerin toplu PDF/DXF dönüşümü, antet bilgilerinin proje verisinden yazılması, çizim temizliği ve çizimden tabloya rapor çıkarma en sık otomatikleştirilen işlerdir. --- =============================================================================== # Türkçe yazılar =============================================================================== # AutoCAD'de Neler Otomatikleştirilebilir? 18 Gerçek İş source: https://mehmetseyrimez.com/blog/autocadde-neler-otomatiklestirilebilir type: article published: 2026-08-26 category: Otomasyon Atölyesi tags: autocad, autolisp, otomasyon, cad-otomasyon, verimlilik author: Mehmet Seyrimez reading_minutes: 8 > Katman standardından toplu yazdırmaya, öznitelik çıkarmadan proje şablonlarına: AutoCAD'de otomatikleştirmeye değen 18 iş ve her birinin kazancı. "AutoCAD'de neyi otomatikleştirebiliriz?" sorusuna verilebilecek en kötü cevap "her şeyi" olur. En iyi cevap ise şu: **kurallı, tekrarlayan ve sonucu tartışmasız işleri.** Bu üç ölçüte uyan bir iş bulduğunuzda, otomasyon neredeyse her zaman kazandırır. Uymuyorsa, ne kadar uğraşırsanız uğraşın karşılığını alamazsınız. Bu yazıda sahada karşılığı olan 18 işi tek tek gezeceğiz. Her birinin yanına gerçekçi bir kazanç notu ve hangi araçla çözüleceğini koydum — çünkü aynı iş bazen beş satırlık bir AutoLISP rutiniyle, bazen ise ciddi bir .NET eklentisiyle çözülüyor. Kod yok; ne olduğunu, neden değdiğini ve nereden başlayacağınızı konuşuyoruz. AutoLISP'i hiç bilmiyorsanız önce [AutoLISP nedir](https://mehmetseyrimez.com/blog/autolisp-nedir) yazısına göz atmanızı öneririm. :::illustration full design-tools | Otomasyona uygun iş: kurallı, tekrarlayan, sonucu tartışmasız ::: ## Çizim standardı ve düzen — en hızlı kazanç burada Neredeyse her ofiste ilk ve en kârlı otomasyon alanı burası. Sebebi basit: standart zaten yazılı, kurallar net ve iş sürekli tekrarlanıyor. ### 1. Katman oluşturma ve düzeltme Firma katman standardını tek komutla uygulamak. Eksik katmanları oluşturur, renk ve çizgi tipini düzeltir, yanlış adlandırılmışları eşler. *Kazanç:* Çizim başına 5–15 dakika, dış kaynaklı çizimlerde çok daha fazla. *Araç:* AutoLISP — bu, LISP'in en klasik ve en verimli alanı. ### 2. Dış kaynaklı çizimi standarda çekme Müşteriden ya da taşeronlardan gelen çizimler kendi standartlarıyla gelir. Katmanlar, yazı tipleri, ölçü stilleri, çizgi ölçekleri — hepsi farklıdır. Tek komutla firma standardına çeken bir rutin, taşeronla çalışan ekiplerde günlük hayatı değiştirir. *Kazanç:* Çizim başına 15–40 dakika. *Araç:* AutoLISP; kural sayısı arttıkça .NET. ### 3. Kullanılmayan öğeleri temizleme Kullanılmayan katman, blok, yazı tipi ve ölçü stili. Dosya boyutunu şişirir, açılışı yavaşlatır ve katman listesini okunmaz hale getirir. *Kazanç:* Dosya boyutu ve açılma süresi; büyük projelerde hissedilir. *Araç:* AutoLISP. ### 4. Yazı tipi ve metin stili birleştirme Bir çizimde on beş farklı yazı tipi olması, aslında on beş farklı kişinin dokunmuş olmasının izidir. Tek komutla hepsini standarda çekmek. *Kazanç:* Çizim başına 5–10 dakika, ve baskıda tutarlılık. *Araç:* AutoLISP. ### 5. Çizgi tipi ölçeği düzeltme Kesikli çizgilerin bazı çizimlerde düz görünmesi, klasik ve can sıkıcı bir problem. Ölçek hesabını kurallaştırıp tek komuta bağlamak. *Kazanç:* Küçük ama sürekli; asıl faydası baskı hatalarını önlemesi. *Araç:* AutoLISP. ## Blok ve öznitelik işleri — veri buradan çıkar Bu grup, otomasyonun sadece hız değil **veri** kazandırdığı yer. AutoCAD'i bir çizim aracı olmaktan çıkarıp bilgi kaynağına dönüştürüyor. ### 6. Öznitelik değerlerini toplu doldurma Antet blokları, parça etiketleri, oda numaraları. Proje bilgisini her çizime elle yazmak yerine tek seferde doldurmak. *Kazanç:* Çizim başına 3–8 dakika, ve yazım hatası sıfır. *Araç:* AutoLISP. ### 7. Öznitelikleri dışa aktarma (malzeme listesi) Çizimdeki blokları gezip özniteliklerini bir CSV veya Excel dosyasına yazmak. Malzeme listesi çıkarmanın en pratik yolu. *Kazanç:* Liste başına 30 dakika–2 saat, ve elle sayım hatalarının ortadan kalkması. *Araç:* AutoLISP yeterli; ERP'ye canlı bağlantı gerekiyorsa .NET. ### 8. Blok sayımı ve raporlama Hangi bloktan kaç adet var, hangi katmanda, hangi özniteliklerle? Teklif hazırlarken ve keşif çıkarırken doğrudan işe yarar. *Kazanç:* Keşif başına saatler. *Araç:* AutoLISP. ### 9. Blok değiştirme ve güncelleme Bir blok tasarımı değiştiğinde tüm çizimlerdeki kopyaları güncellemek. Elle yapıldığında hem uzun hem risklidir; atlanan bir çizim üretimde yanlış parça demektir. *Kazanç:* Değişiklik başına saatler, ve tutarlılık. *Araç:* AutoLISP; çok sayıda dosyada .NET veya betik. ### 10. Dinamik blok parametrelerini toplu ayarlama Dinamik blokların görünüm ve parametre değerlerini kurallara göre toplu değiştirmek. *Kazanç:* Proje başına değişken, ama elle yapılması çok zahmetli. *Araç:* AutoLISP; karmaşık kurallarda .NET. :::illustration right document-analysis | Öznitelikler: çizimi bir bilgi kaynağına dönüştüren şey ::: ## Çıktı ve dosya işleri — ölçmeden fark edilmeyen kayıp Burası, insanların "zaten hızlı" dediği ama iki hafta kayıt tutulunca şaşırdığı alan. ### 11. Sayfa düzeni ve yazdırma ayarlarını uygulama Her çizimin aynı sayfa düzeniyle, aynı çizim stilinde ve aynı ölçekte basılması. *Kazanç:* Çizim başına 3–5 dakika, ve baskı hatalarının ortadan kalkması. *Araç:* AutoLISP. ### 12. Toplu PDF / DWF çıktısı Bir klasördeki tüm çizimleri aynı ayarlarla toplu basmak. AutoCAD'in kendi toplu yazdırma aracı (PUBLISH) çoğu durumda yeterli; firma kuralına göre adlandırma gerekiyorsa otomasyon gerekiyor. *Kazanç:* Paket başına 30 dakika–2 saat. *Araç:* Standart iş için PUBLISH; özel adlandırma için AutoLISP veya betik. ### 13. Dosya adını kurala göre üretme Proje kodu, pafta numarası, revizyon ve tarih içeren ad şemasını her seferinde birebir uygulamak. *Kazanç:* Süreden çok **aranabilirlik**; tutarlı adlandırma arşiv arama süresini çarpıcı biçimde düşürür. *Araç:* AutoLISP. ### 14. Toplu format dönüştürme DWG'den DXF'e, eski sürüme kaydetme, farklı sürüm formatlarına toplu çevirme. Taşeron ve müşteri paylaşımlarında sürekli gerekir. *Kazanç:* Paket başına saatler. *Araç:* Betik (script) veya AutoLISP; çok sayıda dosyada .NET. ### 15. Xref denetimi ve raporlama Hangi çizim hangi referansları kullanıyor, hangileri kırık? Proje teslimi öncesinde bu kontrolü elle yapmak günler alır. *Kazanç:* Doğrudan süre değil, **hata yakalama.** Kırık bir xref, teslim edilen paketin eksik olması demektir. *Araç:* AutoLISP; büyük proje ağaçlarında .NET. ## Çizim üretimi — otomasyonun en görünür yüzü ### 16. Firma ürünlerine özgü çizim komutları Standart bir bağlantı detayı, tekrar eden bir kesit, tip proje elemanı. Parametreleri sorup çizimi kendisi çizen komutlar. *Kazanç:* Detay başına 10–30 dakika, ve çizim standardında tam tutarlılık. *Araç:* Basit geometride AutoLISP; karmaşık kural katmanında .NET. ### 17. Şablon ve antet kurulumu Yeni proje açıldığında doğru şablon, doğru katman seti, doğru antet ve doğru sayfa düzeni. Tek komutla proje iskeletini kurmak. *Kazanç:* Proje başına 30 dakika–2 saat. *Araç:* AutoLISP + şablon dosyaları. ### 18. Çizim kontrol listesi Teslim öncesi otomatik denetim: katmanlar standarda uygun mu, antet dolu mu, xref'ler sağlam mı, kullanılmayan öğe kalmış mı, ölçek doğru mu? *Kazanç:* Bu otomasyonun kazancı süre değil **güven.** Teslim edilen paketin eksiksiz olduğunu bilmek, sonradan yapılan düzeltmelerin çoğunu ortadan kaldırır. *Araç:* AutoLISP ile başlar, kural sayısı arttıkça .NET'e taşınır. :::illustration left timeline | Teslim öncesi otomatik denetim: kazancı süre değil, güven ::: ## Neyi otomatikleştirmemeli Listeyi tamamlamak için tersini de söyleyelim. Şu üç grup, otomasyona direnir: **Yargı gerektiren işler.** "Bu detay bu projede uygun mu", "bu tolerans bu üretim yöntemiyle tutar mı" gibi sorular. Bunlar kural değil, karardır. **Kuralı henüz oturmamış işler.** Sürekli değişen bir çizim standardını otomatikleştirmek, hareketli hedefi vurmaya çalışmaktır. Önce standart oturur, sonra otomatikleştirilir. **Az tekrarlanan işler.** Ayda bir yapılan on dakikalık bir iş için otomasyon yazmak, çoğu zaman elle yapmaktan pahalıdır. Bu aritmetiği [otomasyon kazancını ölçmek](https://mehmetseyrimez.com/blog/otomasyon-kazancini-olcmek) yazısında ayrıntılandırdım. ## Nereden başlamalı: üç soruluk seçim 18 maddelik bir listeye bakıp "hepsi lazım" demek kolay. Ama ilk otomasyonunuzu seçerken şu üç soruya bakın: **Bu iş ayda kaç kez tekrarlanıyor?** Sayı ne kadar yüksekse o kadar iyi. Günde birkaç kez yapılan bir işi kabaca otomatikleştirmek, ayda bir yapılan bir işi mükemmel otomatikleştirmekten fazla kazandırır. **Kuralı tartışmasız mı?** "Katman adı şu olacak" nettir. "Görünüş yerleşimi duruma göre değişir" değildir. **Sonucu gözle görülüyor mu?** İlk otomasyonunuzun çıktısını anında doğrulayabilmeniz önemli — hem öğrenirken hem de ekibi ikna ederken. Bu üç ölçüte birlikte bakınca çoğu ofiste birinci sırada **katman standardı uygulama** çıkıyor. Küçük, net, sık tekrarlanan ve sonucu anında görülen bir iş. İyi bir başlangıç. Otomasyon projesini bütün olarak nasıl kuracağınızı — ölçmekten pilota, sınır çizmekten sahada büyütmeye — [otomasyon projesine nasıl başlanır](https://mehmetseyrimez.com/blog/otomasyon-projesine-nasil-baslanir) yazısında adım adım anlattım. ## Sık Sorulan Sorular **AutoCAD'de neler otomatikleştirilebilir?** Katman ve çizim standardı düzenleme, dış kaynaklı çizimleri standarda çekme, blok özniteliklerini toplu doldurma ve dışa aktarma, malzeme listesi çıkarma, sayfa düzeni uygulama ve toplu PDF üretme, dosya adlandırma, format dönüştürme, xref denetimi, firma ürünlerine özgü çizim komutları ve teslim öncesi otomatik kontrol listesi. **AutoCAD otomasyonuna nereden başlamalıyım?** Katman standardı uygulayan küçük bir AutoLISP rutininden. Sık tekrarlanır, kuralı tartışmasızdır ve sonucu anında gözle görülür — öğrenmek ve ekibi ikna etmek için ideal bir ilk adımdır. **AutoCAD'de toplu PDF çıktısı nasıl alınır?** Standart bir toplu baskı için AutoCAD'in PUBLISH aracı çoğu durumda yeterlidir. Dosya adlandırmanın firma şemasına uyması, koşullu seçim yapılması veya rapor üretilmesi gerekiyorsa AutoLISP ya da betik yazmak gerekir. **AutoCAD'den malzeme listesi otomatik çıkarılabilir mi?** Evet. Blok öznitelikleri çizimde zaten veri olarak durur; bir AutoLISP rutini blokları gezip öznitelik değerlerini CSV veya Excel dosyasına yazabilir. ERP'ye canlı bağlantı gerekiyorsa .NET tarafına geçmek gerekir. **Hangi işler otomatikleştirilmemeli?** Yargı gerektiren kararlar, kuralı henüz oturmamış süreçler ve az tekrarlanan işler. Ayda bir yapılan kısa bir işi otomatikleştirmek genellikle elle yapmaktan pahalıdır. **AutoCAD otomasyonu için AutoLISP mi .NET mi gerekir?** Katman, blok, öznitelik ve çizim düzenleme işlerinde AutoLISP çoğu zaman yeterlidir ve çok daha hızlı sonuç verir. Ekip kullanacak, kural içeren, dış veri kaynağına bağlanan veya zengin arayüz isteyen işlerde .NET tercih edilmelidir. ## Özet AutoCAD'de otomatikleştirilebilecek şeylerin listesi uzun, ama hepsi tek bir ölçüte indirgeniyor: **iş kurallı, tekrarlayan ve sonucu tartışmasız mı?** Bu üç ölçüte uyan bir iş bulun, küçük başlayın, sahada çalıştığını görün, sonra bir sonrakine geçin. Otomasyon böyle büyür — listeyle değil, kanıtla. --- # AutoCAD'e Yeni Komut Ekleme: AutoLISP ile Kendi Komutunuz source: https://mehmetseyrimez.com/blog/autocad-yeni-komut-ekleme-autolisp type: article published: 2026-08-26 category: Otomasyon Atölyesi tags: autocad, autolisp, otomasyon, cad-otomasyon, komut author: Mehmet Seyrimez reading_minutes: 8 > AutoCAD'e kendi komutunuzu eklemek nasıl çalışır? c: öneki, komut adı kuralları, kullanıcıdan bilgi almanın üç yolu ve acad.pgp kısayolu — kod yerine mantık. AutoCAD'in en güzel yanlarından biri şu: **yazdığınız bir rutini, yerleşik komutlardan ayırt edilemeyecek şekilde komut satırına bağlayabilirsiniz.** Kullanıcı açısından `LINE` ile sizin yazdığınız `ANTET` arasında hiçbir fark yoktur. İkisi de komut satırına yazılır, ikisi de kısaltmaya bağlanabilir, ikisi de araç çubuğuna konabilir. Bu, otomasyonun en görünür ve en çok benimsenen biçimi. Bir meslektaşınıza "şu LISP dosyasını yükle, sonra şunu çalıştır" demekle "komut satırına `ANTET` yaz" demek arasında, kabul görme açısından uçurum var. Bu yazıda kendi komutunuzu nasıl ekleyeceğinizi konuşacağız — ama kod yazarak değil, **tasarım kararlarını** konuşarak. Çünkü işin zor kısmı komutu tanımlamak değil, iyi bir komut tasarlamak. AutoLISP'e tamamen yabancıysanız önce [AutoLISP nedir](https://mehmetseyrimez.com/blog/autolisp-nedir) yazısıyla başlamanızı öneririm. :::illustration full building-blocks | Kendi komutunuz: yerleşik komutlardan ayırt edilemez ::: ## Komut nasıl "komut" oluyor Mekanizma şaşırtıcı derecede basit. AutoLISP'te bir fonksiyon tanımlarken adının başına `c:` öneki koyarsanız, AutoCAD onu bir komut olarak kaydeder. `c:antet` diye bir fonksiyon tanımladığınızda, komut satırına `ANTET` yazan herkes o fonksiyonu çalıştırmış olur. Hepsi bu. Kayıt yok, bildirim yok, yapılandırma dosyası yok. Fonksiyonun adı komutun adı oluyor. Bu basitlik, LISP'in AutoCAD dünyasında neden bu kadar yaygınlaştığını da açıklıyor: bir işi otomatikleştirmekle o otomasyonu ekibin kullanabileceği bir araca dönüştürmek arasında tek bir önek var. ### Komut adı seçerken dikkat edilecekler Bu, kulağa önemsiz gelen ama sonradan çok can yakan bir karar. Üç kural: **Yerleşik komutlarla çakışmayın.** AutoCAD'in kendi komutlarından biriyle aynı adı verirseniz, sizinki yerleşik olanı gölgeler ve bir gün birisi neden `LINE` komutunun tuhaf davrandığını anlamaya çalışır. Bu, teşhis edilmesi en zor problemlerden biri. **Bir önek kullanın.** Firma adınızın ya da ekibinizin baş harflerini komutların önüne koyun: `MS-ANTET`, `MS-KATMAN`, `MS-CIKTI` gibi. Hem çakışma riski sıfırlanır hem de komut satırına önekinizi yazdığınızda AutoCAD size kendi komutlarınızın listesini gösterir. Bu tek alışkanlık, ekibinizin komutları hatırlamasını kolaylaştırır. **Anlaşılır olsun, kısa olmasın.** Kısalık için kısayol var. Komut adı ne yaptığını söylesin; `MS-KATMAN-STANDART`, `MSKS`'den iyidir. Kısaltmayı ayrıca tanımlarsınız. ## İyi bir komut nasıl davranır Burası işin asıl önemli kısmı. Teknik olarak çalışan bir komutla ekibin gerçekten kullandığı bir komut arasındaki fark, davranışta saklı. **Kullanıcının alışkanlıklarına uysun.** AutoCAD'in yerleşik komutları belli bir ritimle çalışır: bir şey sorar, varsayılanı köşeli parantez içinde gösterir, Enter'a basınca varsayılanı kabul eder, Esc ile iptal edilir. Sizin komutunuz da aynı ritmi izlemeli. Farklı davranan bir komut, ne kadar yararlı olursa olsun yabancı hissettirir. **Varsayılan değer sunsun.** "Katman adı gir:" diye sormak yerine "Katman adı gir :" diye sorun. Kullanıcı çoğu zaman Enter'a basıp geçer; ihtiyaç duyduğunda değiştirir. **Sessizce hiçbir şey yapmasın.** Komut bir iş yaptığında bunu söylesin: "14 katman düzeltildi." Bir şey yapamadığında da söylesin: "Bu çizimde düzeltilecek katman bulunamadı." En kötü davranış, komutun çalışıp hiçbir çıktı vermemesidir — kullanıcı çalışıp çalışmadığını bilemez. **Geri alınabilir olsun.** AutoCAD'in geri alma (undo) sistemi, bir komutun yaptığı tüm değişiklikleri tek bir grup olarak işaretlemenize izin verir. Bunu yapmazsanız, komutunuz 200 değişiklik yaptığında kullanıcı geri almak için 200 kez `U` yazmak zorunda kalır. Bu tek ayrıntı, bir komutun benimsenip benimsenmemesini belirleyebilir. **Ortamı bozmadan çıksın.** Komutunuz bir sistem değişkenini değiştirdiyse (ölçek, nesne kenetleme, katman) çıkarken eski hâline döndürsün. Ve hata durumunda da döndürsün — kullanıcı Esc'e bastığında ortamın yarı değişmiş halde kalması, en sinsi hata türlerinden biri. > Bir komutun teknik doğruluğu, benimsenmesi için yeterli değil. Kullanıcı onu güvenli hissetmeli: ne yaptığını söylemeli, geri alınabilmeli ve ortamı bozmadan çıkmalı. :::illustration right code-review-desk | İyi komut: ne yaptığını söyler, geri alınır, ortamı bozmaz ::: ## Kullanıcıdan bilgi almanın üç yolu Komutunuzun bir şeye ihtiyacı olduğunda üç seçeneğiniz var ve hangisini seçtiğiniz kullanım deneyimini belirliyor. **Komut satırından sormak.** En hızlı ve en AutoCAD'e uygun yol. Kullanıcının eli klavyeden ayrılmaz. Sayı, metin, nokta, açı, mesafe — hepsini sorabilirsiniz. İki-üç bilgi gerekiyorsa bu yeterlidir. **Ekrandan seçim istemek.** Nesne seçimi, nokta gösterme. Geometriyle ilgili işlerde doğal olan yol. Burada önemli bir ayrıntı var: kullanıcı hiçbir şey seçmezse ne olacağına karar vermiş olmalısınız. Sessizce çıkmak mı, uyarmak mı, tüm çizime uygulamak mı? **Diyalog kutusu açmak.** Beşten fazla parametre varsa ya da kullanıcının seçenekleri bir arada görmesi gerekiyorsa. LISP tarafında diyalog kutusu tasarlamak eski ve zahmetli bir iş; bu noktaya geldiyseniz .NET tarafına bakma vaktiniz gelmiş olabilir. Pratik tavsiyem: **komut satırından başlayın.** İhtiyaç netleştikçe arayüz gereksinimi de netleşir. Baştan diyalog kutusu tasarlamak, çoğu zaman gereksiz emek oluyor. ## Kısayol tanımlamak: komutun kısa adı Komutunuzu tanımladıktan sonra ona bir kısaltma vermek isteyeceksiniz — tıpkı `LINE` için `L`, `CIRCLE` için `C` olduğu gibi. AutoCAD bu kısaltmaları `acad.pgp` adlı bir dosyada tutar. Bu düz bir metin dosyası ve içine kendi satırlarınızı ekleyebilirsiniz: kısaltma, virgül, yıldız işareti ve komut adı. Üç uyarı: **Kendi PGP dosyanızı ayrı tutun.** AutoCAD güncellemelerinde `acad.pgp` üzerine yazılabilir. Kendi kısaltmalarınızı ayrı bir dosyada tutup ana dosyadan çağırmak, güncellemelerde emeğinizi korur. **Yerleşik kısaltmaları ezmeyin.** `L` zaten `LINE` demek. Onu değiştirirseniz, o AutoCAD'i kullanan herkesin kas hafızasını bozarsınız. **Kısaltmayı ekipçe standartlaştırın.** Herkesin kendi kısaltması olursa, birinin bilgisayarında çalışmak imkânsız hale gelir. Kısaltma listesini de LISP dosyaları gibi ortak bir yerde tutun. ## Komutu araç çubuğuna ve şeride koymak Bazı kullanıcılar komut satırını sever, bazıları butonu. Ekibinizde ikisi de vardır, o yüzden komutunuzu her iki yoldan da erişilebilir yapın. AutoCAD'in Kullanıcı Arayüzü Özelleştirme (CUI) penceresinden yeni bir komut tanımlar, ona sizin LISP komutunuzun adını verir, bir ikon seçer ve istediğiniz araç çubuğuna ya da şerit sekmesine yerleştirirsiniz. Burada da bir paylaşım problemi var — makro tarafındakine çok benziyor: CUI özelleştirmeleri kişisel profilde saklanır. Ekip genelinde dağıtmak için kısmi CUI dosyası (partial CUI) kullanmak gerekir. Bu, ana arayüzü bozmadan kendi sekmenizi ve butonlarınızı ekleyen ayrı bir dosyadır ve herkese aynı şekilde yüklenebilir. Yükleme ve dağıtım tarafını [AutoLISP dosyası yükleme ve otomatik başlatma](https://mehmetseyrimez.com/blog/autolisp-yukleme-ve-otomatik-baslatma) yazısında ayrıntısıyla ele aldım. :::illustration left version-control | Komut, kısayol ve buton: üçü de ekipçe aynı olmalı ::: ## Komut kütüphanesi büyürken İlk komutunuzu yazmak keyifli. Otuzuncu komutunuzda ise farklı bir problemle karşılaşırsınız: **kimse hangi komutun ne yaptığını hatırlamıyor.** Bunu baştan önlemenin birkaç yolu var: **Ortak önek kullanın.** Yukarıda söylemiştim ama tekrar edeyim, çünkü asıl faydası burada ortaya çıkıyor: komut satırına `MS-` yazdığınızda AutoCAD size tüm kendi komutlarınızı listeler. Otuz komutunuz varsa bu, canlı bir menüdür. **Bir yardım komutu yazın.** `MS-YARDIM` gibi bir komut, tüm komutlarınızı ve ne yaptıklarını komut satırına yazsın. Yazması on dakika sürer, yıllarca işe yarar. **Her dosyanın başına üç satır yorum koyun.** Ne işe yarıyor, kim yazdı, ne zaman. Bu otuz saniyelik alışkanlık, dosyanın üç yıl sonra silinmesiyle kullanılmaya devam etmesi arasındaki farkı belirliyor. **Komutları konuya göre dosyalayın.** Tek bir dev LISP dosyası yerine `katman.lsp`, `antet.lsp`, `cikti.lsp` gibi konu bazlı dosyalar. Bakımı belirgin biçimde kolaylaştırır. :::callout Ne zaman .NET'e geçmeli Komutunuz bir diyalog kutusu istiyor, bir veritabanına bağlanıyor ya da onlarca kural içeriyorsa AutoLISP'in sınırına gelmişsiniz demektir. Bu kararı ve eşikleri [AutoCAD otomasyonu: LISP, .NET ve yapay zeka arasında nasıl seçim yaparım](https://mehmetseyrimez.com/blog/autocad-otomasyonu-lisp-net-yapay-zeka) yazısında karar tablosuyla anlattım. ::: ## İlk komutunuz için öneri Teoriyi bırakıp pratiğe dönelim. İlk komutunuzun şu üç özelliği taşımasını öneriyorum: **Küçük olsun ama bir işi bitirsin.** "Şu katmanı oluştur, rengini ayarla ve aktif yap" gibi. Yarım kalan bir otomasyon, kazancı hissettirmez. **Sık kullanacağınız bir şey olsun.** Günde birkaç kez kullanacağınız bir komut, öğrenme sürecini de hızlandırır — çünkü eksiklerini hemen fark edersiniz. **Geri alınabilir olsun.** İlk denemelerinizde bir şeyleri bozacaksınız. Geri alma grubunu doğru kurmuş olmak, o denemeleri korkusuz yapmanızı sağlar. Ve bir şey daha: ilk komutunuzu **kopya bir çizim üzerinde** deneyin. Gerçek projede test etmek, en pahalı öğrenme yöntemidir. ## Sık Sorulan Sorular **AutoCAD'e nasıl yeni komut eklenir?** AutoLISP'te fonksiyon adının başına `c:` öneki koyduğunuzda AutoCAD o fonksiyonu bir komut olarak tanır. `c:antet` adlı bir fonksiyon tanımladığınızda komut satırına ANTET yazan herkes o rutini çalıştırır; ek bir kayıt veya yapılandırma gerekmez. **Kendi komutum yerleşik bir komutla aynı adı taşırsa ne olur?** Sizin komutunuz yerleşik olanı gölgeler ve yerleşik komut beklenmedik biçimde davranmaya başlar. Bu, teşhis edilmesi en zor problemlerden biridir; komutlarınıza firma önekiyle ad vermek bu riski tamamen ortadan kaldırır. **AutoCAD'de komut kısaltması nasıl tanımlanır?** Kısaltmalar `acad.pgp` dosyasında tutulur ve bu dosyaya kendi satırlarınızı ekleyebilirsiniz. Güncellemelerde üzerine yazılmaması için kendi kısaltmalarınızı ayrı bir dosyada tutup ana dosyadan çağırmak daha güvenlidir. **Yazdığım komutu araç çubuğuna nasıl eklerim?** AutoCAD'in Kullanıcı Arayüzü Özelleştirme (CUI) penceresinden yeni bir komut tanımlayıp LISP komutunuzun adını verir, ikon seçer ve istediğiniz araç çubuğuna veya şerit sekmesine yerleştirirsiniz. Ekip genelinde dağıtım için kısmi CUI dosyası kullanmak gerekir. **Komutum çalışıyor ama kullanıcı geri alamıyor, neden?** AutoCAD'in geri alma sistemi komutun yaptığı değişiklikleri tek grup olarak işaretlemenizi bekler. Bu grup kurulmazsa yapılan her değişiklik ayrı bir adım olur ve kullanıcı yüzlerce kez geri almak zorunda kalır. **Kaç komuttan sonra AutoLISP yetersiz kalır?** Komut sayısı değil, komutların niteliği belirleyicidir. Diyalog kutusu, dış veri kaynağı bağlantısı veya onlarca kural içeren mantık gerektiğinde AutoLISP'in sınırına gelinmiş demektir; bu noktada .NET tarafına geçmek gerekir. **Komut kütüphanem büyüdü, ekip hangi komutun ne yaptığını hatırlamıyor. Ne yapmalıyım?** Tüm komutlara ortak bir önek verin (komut satırına öneki yazmak canlı bir menü haline gelir), komutları listeleyen bir yardım komutu yazın ve rutinleri konu bazlı ayrı dosyalarda tutun. ## Özet AutoCAD'e komut eklemek teknik olarak tek bir önek meselesi. Zor olan kısım, o komutun ekibin gerçekten kullanacağı bir araç olması: alışkanlıklara uyan, ne yaptığını söyleyen, geri alınabilen ve ortamı bozmadan çıkan bir komut. Küçük başlayın, sık kullanacağınız bir işi seçin, kopya çizimde deneyin. Otuz komutluk bir kütüphaneye giden yol, iyi tasarlanmış tek bir komuttan geçiyor. --- # SolidWorks Makro Hataları ve Çözümleri: 9 Yaygın Durum source: https://mehmetseyrimez.com/blog/solidworks-makro-hatalari-ve-cozumleri type: article published: 2026-08-26 category: Otomasyon Atölyesi tags: solidworks, makro, vba, hata-ayiklama, otomasyon author: Mehmet Seyrimez reading_minutes: 9 > Makro hata veriyor, hiçbir şey yapmıyor ya da yanlış sonuç üretiyor. Sahada en çok karşılaşılan dokuz makro hatasının gerçek sebebi ve kalıcı çözümü. "Makro çalışmıyor" cümlesini duyduğumda ilk sorduğum şey şu oluyor: **hata mı veriyor, yoksa hiçbir şey mi yapmıyor?** İkisi tamamen farklı problemler ve karıştırıldıklarında saatler kaybediliyor. Hata veren makro aslında iyi haberdir — size nerede takıldığını söylüyor. Asıl tehlikeli olan, hiçbir şey söylemeden yanlış çıktı üreten makrodur. Bu yazıda sahada en çok karşılaştığım dokuz durumu, gerçek sebeplerini ve kalıcı çözümlerini sırayla anlatacağım. Kod yok — ne olduğunu ve ne yapmanız gerektiğini konuşuyoruz. Makronun temellerini [SolidWorks makro nedir](https://mehmetseyrimez.com/blog/solidworks-makro-nedir), çalıştırma yollarını [makro nasıl çalıştırılır](https://mehmetseyrimez.com/blog/solidworks-makro-nasil-calistirilir) yazısında anlatmıştım. Burada tamamen sorun giderme var. :::illustration full fixing-bugs | Hata veren makro iyi haberdir; sessiz kalan makro kötü ::: ## Önce ikiye ayırın: gürültülü hata mı, sessiz hata mı Bir makro üç şekilde "çalışmayabilir": 1. **Bir hata mesajıyla durur.** VBA düzenleyicisi açılır, sorunlu satır sarıyla işaretlenir. En kolay tür. 2. **Çalışır ama hiçbir şey yapmaz.** Hata yok, çıktı da yok. Kullanıcı makronun çalıştığını sanır. 3. **Çalışır ama yanlış şey yapar.** En pahalısı. Yanlış çıktı üretim hattına gider. İkinci ve üçüncü durum, makroların sahadaki asıl problemi. Sebep neredeyse her zaman aynı: SolidWorks API'sindeki birçok çağrı, başarısız olduğunda hata fırlatmaz — sessizce "olmadı" anlamına gelen bir değer döndürür. Makro bunu kontrol etmezse bir sonraki satıra geçer ve olmayan bir seçim üzerinde işlem yapmaya kalkar. > Otomasyonda en pahalı hata çöken kod değil, sessizce yanlış çıktı üreten koddur. Çöken kodu fark edersiniz; yanlış çıktı üretime gider. Bu yüzden sorun giderirken ilk hedefimiz hep aynı: **sessiz hataları gürültülü hatalara çevirmek.** ## 1. "Object variable or With block variable not set" En sık gördüğünüz hata bu olacak. Anlamı basit: kod, var olmayan bir şeyi kullanmaya çalışıyor. **Gerçek sebebi genellikle üç şeyden biri:** - Hiç belge açık değil. Makro aktif belgeyi istedi, karşılığında hiçbir şey aldı. - Bir seçim başarısız oldu ve kod seçilmiş nesneyi kullanmaya kalktı. - Aranan özellik (feature) o modelde yok. **Kalıcı çözüm:** Her makronun ilk işi, aktif belgenin var olup olmadığını kontrol etmek olmalı. Yoksa kullanıcıya anlaşılır bir mesaj gösterip durmalı. Bu üç satırlık alışkanlık, sahada karşılaşacağınız hataların büyük kısmını baştan keser. ## 2. Makro çalışıyor ama hiçbir şey olmuyor Klasik senaryo: parça için yazılmış bir makroyu teknik resim açıkken çalıştırıyorsunuz. Makro aktif belgeyi alıyor, ama o belge beklediği türde değil. Aradığı özellikleri bulamıyor, hiçbir seçim tutmuyor, sessizce sonlanıyor. **Kalıcı çözüm:** Makronun başında belge **türünü** de doğrulayın. "Bu makro yalnızca parça dosyalarında çalışır" diyen tek bir uyarı, kullanıcının on dakikasını kurtarır. Bunu bir alışkanlık haline getirin: her makro iki soruyla başlasın — *belge var mı* ve *doğru türde mi.* ## 3. Kaydedilen makro başka modelde çalışmıyor Makro kaydediciyle bir işlem kaydettiniz, kendi modelinizde mükemmel çalışıyor, başka bir modelde hiçbir şey yapmıyor. Bu, kaydedilmiş makroların bir numaralı zayıflığı. **Sebebi:** Kaydedici, "şu yüzeyi seç" işlemini modeldeki **özellik adına** ya da **koordinata** bağlı bir seçim komutuna çevirir. O ad başka modelde yoksa ya da geometri farklıysa seçim tutmaz — ve seçim komutu hata fırlatmaz, sadece "olmadı" der. **Kalıcı çözüm:** Seçime bağımlılığı kaldırın. Modeldeki nesneleri ada göre aramak yerine, belgenin kendi listesi üzerinden gezin: tüm yüzeyleri, tüm özellikleri ya da tüm bileşenleri sırayla dolaşıp aradığınız ölçütü sağlayanı bulun. Bu yaklaşım biraz daha uzun ama her modelde çalışır. Ara çözüm olarak: seçim komutunun sonucunu kontrol edin ve başarısızsa makroyu durdurup kullanıcıyı uyarın. Yanlış sonuç üretmektense durmak her zaman daha iyidir. :::illustration right code-inspection | Seçim tutmadığında durmak, yanlış devam etmekten iyidir ::: ## 4. Makro bir diyalog penceresinde asılı kalıyor Toplu işlem makrolarında en sık yaşanan durum. Makro klasördeki 200 dosyayı işliyor, 37. dosyada SolidWorks bir uyarı penceresi açıyor ("bu dosya farklı bir sürümde kaydedilmiş", "referans bulunamadı" gibi) ve makro cevap bekleyerek sonsuza kadar duruyor. **Kalıcı çözüm:** Toplu işlem yapan makrolarda, işlem başında kullanıcı uyarılarını kapatın ve sonunda geri açın. SolidWorks'ün bunun için ayarları var: dosya açma sırasında sessiz mod, kaydetme sırasında sessiz mod ve genel uyarı bastırma. **Ama dikkat:** Uyarıları kapatmak, uyarıların sebebini ortadan kaldırmaz. Bastırdığınız her uyarının yerine bir **kayıt** koyun — makro sonunda "şu 12 dosyada şu sorun vardı" diyen bir liste üretsin. Yoksa sessiz mod, sessiz hataya dönüşür. ## 5. Toplu işlemde bazı dosyalar atlanıyor Makro 200 dosya işledi, 188'i tamam, 12'si eksik. Ve hangileri olduğunu bilmiyorsunuz. **Sebebi:** Genellikle bir dosya açılamadı (kilitli, salt okunur, ağ erişimi kesildi) ya da beklenmeyen bir yapıdaydı ve makro o dosyayı atlayıp devam etti. **Kalıcı çözüm:** Toplu işlem makrolarınız her zaman bir **rapor** üretsin. En basit hâliyle bir metin dosyası: hangi dosya işlendi, hangisi atlandı, atlanma sebebi ne. Bu alışkanlık, toplu makroları "umarım çalışmıştır" seviyesinden "ne olduğunu biliyorum" seviyesine taşır. Toplu işlem makrolarının nasıl kurulacağını ayrı bir yazıda ele alacağım; şimdilik kural şu: **döngünün her adımı kendi hatasını yakalasın ve döngü durmasın.** Tek bir bozuk dosya, 199 dosyayı işlemenizi engellememelidir. ## 6. "Type mismatch" hatası Beklenen türde olmayan bir değer geldi. Makro dünyasında bunun iki ana sebebi var. **Sürüm farkı.** SolidWorks API'sindeki bir metot, sürümler arasında imzasını değiştirmiş olabilir. Eski bir makroyu yeni sürümde çalıştırdığınızda bu hatayı alırsınız. **Yanlış belge türü.** Montaj bekleyen bir çağrıya parça verilmesi gibi. **Kalıcı çözüm:** Sürüm farkı şüpheniz varsa, o metodun güncel dokümantasyondaki imzasını kontrol edin. Makroyu birden fazla SolidWorks sürümünde kullanacaksanız, sürüm numarasını başta okuyup ona göre dallanan bir yapı kurmak gerekir — ama açıkçası bu noktaya geldiyseniz makronun sınırına yaklaşmışsınız demektir. ## 7. Makro yavaş çalışıyor Tek parçada anlık, 50 parçalık montajda dakikalar. Bu genellikle bir hata değil, bir tasarım sorunu. **En sık sebep:** Makro, her küçük değişiklikten sonra modeli yeniden kuruyor (rebuild). Yeniden kurma pahalı bir işlemdir; 20 parametre değiştiriyorsanız her birinden sonra değil, **hepsi yazıldıktan sonra bir kez** yapılmalı. **İkinci sebep:** Ekran güncellemesi. Makro çalışırken SolidWorks her adımı ekrana çiziyorsa, süre ciddi biçimde uzar. Toplu işlemlerde ekran güncellemesini kapatmak tek başına ciddi hızlanma sağlar. **Üçüncü sebep:** Gereksiz dosya açma. Aynı dosyayı döngü içinde tekrar tekrar açıp kapatmak yerine, bir kez açıp işi bitirmek. :::illustration left speed-test | Yavaşlığın kaynağı genelde hata değil, gereksiz yeniden kurma ::: ## 8. Makro başkasının bilgisayarında çalışmıyor Sizde çalışıyor, meslektaşınızda çalışmıyor. Sebep neredeyse her zaman ortamla ilgili, kodla değil. **Olası sebepler ve çözümleri:** | Belirti | Sebep | Çözüm | | --- | --- | --- | | Buton var, hiçbir şey olmuyor | Makro yolu farklı | Ortak klasör, herkeste aynı yol | | Açılırken hata | Eksik VBA referansı | Referansı kaldırın ya da geç bağlama kullanın | | Güvenlik uyarısı | Makro güvenlik ayarı | BT ile konuşun; ayarı zorlamayın | | Farklı sonuç | Farklı şablon/ayar | Şablon ve birim ayarlarını standardize edin | Son satır en sinsi olanı: iki bilgisayarda farklı belge şablonu veya birim sistemi kullanılıyorsa, aynı makro farklı sonuç üretebilir. Ekip makrolarında şablon standardizasyonu, kodun kendisi kadar önemli. Ortak klasör kurulumunu [makro nasıl çalıştırılır](https://mehmetseyrimez.com/blog/solidworks-makro-nasil-calistirilir) yazısında anlattım. ## 9. Makro doğru çalışıyor ama sonuç yanlış En zor teşhis edilen durum. Hata yok, çıktı var, ama çıktı yanlış. **En sık sebepler:** - **Birim karışıklığı.** SolidWorks içeride metre kullanır; makro milimetre yazdığını sanır. Sonuç bin kat sapar ve bazen gözle fark edilmez. - **Yanlış konfigürasyon aktif.** Makro, o an aktif olan konfigürasyon üzerinde çalışır. Kayıt sırasında hangi konfigürasyonun aktif olduğu koda yazılmaz. - **Sıralama varsayımı.** Kod, listedeki nesnelerin belirli bir sırada geleceğini varsayıyor. O sıra garanti değildir. **Kalıcı çözüm:** Makronun ürettiği çıktıyı doğrulayan bir kontrol adımı ekleyin. Kulağa fazladan iş gibi gelir ama şu basit hâli bile yeterli: makro işini bitirdiğinde birkaç kritik değeri okuyup beklenen aralıkta mı diye baksın, değilse uyarsın. :::callout Hata ayıklamanın en hızlı yolu VBA düzenleyicisinde makroyu satır satır çalıştırabilirsiniz (adım adım yürütme). Her satırdan sonra SolidWorks penceresine bakıp ne olduğunu görmek, hatayı bulmanın en hızlı yolu — özellikle "hiçbir şey yapmıyor" tipi problemlerde. Beş dakikalık bu alışkanlık, saatlerce tahmin yürütmekten iyidir. ::: ## Kalıcı çözüm: makroyu baştan sağlam yazmak Yukarıdaki dokuz durumun sekizi, üç alışkanlıkla baştan önlenebilir: **1. Her makro iki kontrolle başlasın.** Belge var mı, doğru türde mi. Değilse anlaşılır bir mesajla dur. **2. Her API çağrısının sonucu kontrol edilsin.** Seçim tuttu mu, dosya açıldı mı, kayıt başarılı mı. Sessiz başarısızlığı gürültülü hataya çevirmenin tek yolu bu. **3. Toplu işlemler rapor üretsin.** Ne işlendi, ne atlandı, neden. Rapor olmadan toplu makro, kara kutudur. Bu üç alışkanlığın nasıl uygulanacağını ve kaydedilmiş kodun nasıl sağlamlaştırılacağını [SolidWorks makro nedir](https://mehmetseyrimez.com/blog/solidworks-makro-nedir) yazısında adım adım anlattım. Ve şunu da söyleyeyim: bu üç alışkanlığı uygulamaya başladığınızda makronuz büyür, karmaşıklaşır ve bakımı zorlaşır. O noktada sorulacak soru artık "makroyu nasıl düzeltirim" değil, "bu iş makro olmaktan çıktı mı" olur. Cevabı [makro, API ve add-in arasındaki fark](https://mehmetseyrimez.com/blog/solidworks-makro-api-farki) yazısında. ## Sık Sorulan Sorular **SolidWorks makrom hata veriyor, nereden başlamalıyım?** Önce hatanın türünü ayırın: mesajla duruyor mu, hiçbir şey yapmıyor mu, yoksa yanlış sonuç mu üretiyor? Mesajla duruyorsa VBA düzenleyicisinin işaretlediği satır sorunu doğrudan gösterir. Hiçbir şey yapmıyorsa neredeyse her zaman belge açık değildir ya da yanlış türdedir. **"Object variable or With block variable not set" hatası ne demek?** Kod var olmayan bir nesneyi kullanmaya çalışıyor demektir. En yaygın üç sebebi: hiç belge açık olmaması, bir seçimin başarısız olması ve aranan özelliğin o modelde bulunmaması. **Kaydettiğim makro neden başka modelde çalışmıyor?** Makro kaydedici, seçimleri o anki modeldeki özellik adlarına veya koordinatlara bağlar. Başka modelde o ad ya da geometri olmadığı için seçim tutmaz. Kalıcı çözüm, ada göre seçim yerine belgenin nesne listesini gezip ölçüte uyanı bulmaktır. **Makro toplu işlemde bir pencerede takılıp kalıyor, ne yapmalıyım?** İşlem başında SolidWorks'ün kullanıcı uyarılarını sessiz moda alın, sonunda geri açın. Bastırdığınız her uyarı için makronun sonunda bir rapor satırı üretmeyi ihmal etmeyin; aksi hâlde sessiz mod sessiz hataya dönüşür. **Makrom neden yavaş çalışıyor?** En yaygın sebep, her parametre değişikliğinden sonra modelin yeniden kurulmasıdır; yeniden kurma tüm değişiklikler yazıldıktan sonra bir kez yapılmalıdır. İkinci sebep ekran güncellemesinin açık kalmasıdır — toplu işlemlerde kapatmak ciddi hızlanma sağlar. **Makro benim bilgisayarımda çalışıyor, başkasında çalışmıyor. Neden?** Genellikle ortam farkıdır: makro dosyasının yolu, eksik bir VBA referansı, makro güvenlik ayarı veya farklı belge şablonu. Ekip makrolarında ortak klasör ve şablon standardizasyonu, kodun kendisi kadar önemlidir. **Makro hata vermiyor ama yanlış sonuç üretiyor, sebebi ne olabilir?** En sık üç sebep: birim karışıklığı (SolidWorks içeride metre kullanır), yanlış konfigürasyonun aktif olması ve nesne listesinin belirli bir sırada geleceğinin varsayılması. Çözüm, makronun sonuna kritik değerleri kontrol eden basit bir doğrulama adımı eklemektir. ## Özet Makro sorun gidermenin özü tek cümlede toplanıyor: **sessiz hatayı gürültülü hataya çevirin.** Hata veren makro size yol gösterir; sessizce yanlış çalışan makro, yanlış parçanın üretilmesine kadar fark edilmez. Her makroyu iki kontrolle başlatın, her API çağrısının sonucunu kontrol edin ve toplu işlemlerde rapor üretin. Bu üç alışkanlık, bu yazıdaki dokuz problemin sekizini daha ortaya çıkmadan çözüyor. --- # SolidWorks Makro Nasıl Çalıştırılır? Menü, Buton, Kısayol source: https://mehmetseyrimez.com/blog/solidworks-makro-nasil-calistirilir type: article published: 2026-08-26 category: Otomasyon Atölyesi tags: solidworks, makro, vba, otomasyon, cad-otomasyon author: Mehmet Seyrimez reading_minutes: 9 > SolidWorks'te makro çalıştırmanın bütün yolları: menüden çalıştırma, araç çubuğuna buton ekleme, klavye kısayolu atama, paylaşım ve güvenlik ayarları. Kısa cevap şu: SolidWorks'te bir makroyu **Araçlar > Makro > Çalıştır** menüsünden `.swp` dosyasını seçerek çalıştırırsınız. Ama günde beş kez kullanacağınız bir makroyu her seferinde menüden aramak, otomasyonun kazandırdığı süreyi geri verir. Asıl istediğiniz şey makroyu **bir butona ya da klavye kısayoluna bağlamak** — ve bu, sandığınızdan çok daha kolay. Gelin baştan alalım. Bu yazıda makroyu çalıştırmanın bütün yollarını, hangisinin ne zaman doğru olduğunu ve makro başkasının bilgisayarında çalışmadığında ne yapılacağını anlatacağım. Tek satır kod yok; sadece nereye tıklayacağınız ve neden. Makronun ne olduğunu, kaydediciyle nasıl üretildiğini ve kaydedilen kodun neden doğrudan güvenilmez olduğunu daha önce [SolidWorks makro nedir](https://mehmetseyrimez.com/blog/solidworks-makro-nedir) yazısında anlatmıştım. Burada odak tamamen çalıştırma tarafında. :::illustration full checklist | Menüden çalıştırma, butona atama, kısayol: üç ayrı ihtiyaç ::: ## En basit yol: menüden çalıştırmak Elinizde bir `.swp` dosyası var — belki kendiniz kaydettiniz, belki bir meslektaşınız gönderdi. Onu çalıştırmak için: **Araçlar > Makro > Çalıştır** yolunu izleyin, açılan pencereden dosyayı seçin, tamam deyin. Makro işini yapar ve sonlanır. Hepsi bu. Burada takılınan tek nokta genelde menünün yerinde olmuyor olması. SolidWorks sürümden sürüme menü yerleşimini biraz oynatıyor. Bulamazsanız en hızlı çözüm, sağ üstteki komut arama kutusuna "makro" yazmak — SolidWorks size doğrudan komutu gösterir. Bir de şu var: makro çalıştırdığınızda **önce doğru belgenin açık olduğundan emin olun.** Parça için yazılmış bir makro, teknik resim açıkken çalıştırıldığında ya hata verir ya da — daha kötüsü — sessizce hiçbir şey yapmaz ve siz makronun çalıştığını sanırsınız. Bu, makro dünyasının en can sıkıcı tuzağı; ayrıntısını birazdan konuşacağız. ### `.swp`, `.swb`, `.swb` — bu uzantılar da ne? Kafa karıştıran bir nokta, o yüzden hızlıca netleştirelim: | Uzantı | Nedir | Ne zaman görürsünüz | | --- | --- | --- | | `.swp` | VBA makrosu — okunabilir, düzenlenebilir | En yaygın; kaydedicinin ürettiği dosya | | `.swb` | Eski sürümlerden kalma makro biçimi | Eski arşivlerde | | `.dll` | Derlenmiş eklenti (add-in) | Makro değil; farklı bir dünya | Pratikte hep `.swp` ile çalışacaksınız. Bir `.dll` geldiğinde onu "makro çalıştır" ile açamazsınız; o bir eklentidir ve kurulması gerekir. İkisi arasındaki farkı merak ediyorsanız [makro, API ve add-in arasındaki fark](https://mehmetseyrimez.com/blog/solidworks-makro-api-farki) yazısında ayrıntısıyla ele aldım. ## Asıl istediğiniz şey: makroyu butona bağlamak Menüden çalıştırma, bir makroyu ayda birkaç kez kullanıyorsanız yeterli. Ama günlük işinizin parçası olacaksa, o menü yolculuğu kısa sürede sinir bozucu hale geliyor. Çözüm, makroyu bir araç çubuğu butonuna bağlamak. Yol şöyle: 1. **Araçlar > Özelleştir** penceresini açın. 2. **Komutlar** sekmesine geçin ve soldaki listeden **Makrolar** kategorisini seçin. 3. Sağda görünen boş makro butonunu, olmasını istediğiniz araç çubuğuna sürükleyin. 4. Butonu bıraktığınız anda SolidWorks size bir pencere açar: hangi makro dosyası, hangi yordam (procedure), butonun adı ne olacak, hangi ikonu kullanacak. 5. Makro dosyasını seçin, isim verin, tamam deyin. Artık makronuz orada, tek tıkla çalışıyor. Küçük ama önemli bir ayrıntı: butona **anlamlı bir ad** ve mümkünse **kendi ikonunu** verin. Üç makroyu aynı varsayılan ikonla araç çubuğuna koyduğunuzda hangisinin ne yaptığını iki hafta içinde unutuyorsunuz. İpucu metnine ("tooltip") makronun ne yaptığını bir cümleyle yazmak, altı ay sonraki kendinize yapacağınız en büyük iyilik. :::illustration right guidelines | Buton adı, ikon ve ipucu metni: altı ay sonraki kendinize not ::: ## Klavye kısayolu atamak Bazı makrolar o kadar sık kullanılır ki butona uzanmak bile fazla gelir. Antet doldurma, standart görünüş yerleştirme, seçili parçadan STEP çıkarma… Bunlar için klavye kısayolu doğru çözüm. Aynı **Araçlar > Özelleştir** penceresinde, bu sefer **Klavye** sekmesine geçin. Kategori listesinden makroları bulun, kısayol atamak istediğiniz makronun satırına gelin ve tuş kombinasyonunu yazın. Burada tek dikkat edilecek şey, SolidWorks'ün kendi kısayollarıyla çakışmamak. Genel olarak `Ctrl + Shift + ` kombinasyonları görece boştur ve makrolar için güvenli bir alandır. Zaten kullanılan bir kısayolu seçerseniz SolidWorks uyarır — o uyarıyı görmezden gelip devam etmeyin, çünkü kaybettiğiniz yerleşik komutu haftalar sonra arıyor olursunuz. ## Makro nerede durmalı: paylaşımın püf noktası Şimdi çoğu ekibin tökezlediği yere geldik. Makro sizin bilgisayarınızda güzelce çalışıyor, meslektaşınıza gönderiyorsunuz, onda çalışmıyor. Neredeyse her zaman sebep aynı: **butonun içinde makronun tam dosya yolu yazılı.** Butona makro bağladığınızda SolidWorks o dosyanın yolunu kaydeder. Sizde `C:\Kullanicilar\mehmet\Makrolar\antet.swp` yazıyorsa, o yol meslektaşınızın bilgisayarında yok. Buton var, makro yok. Bunun kalıcı çözümü şu: **makroları ortak bir ağ klasöründe tutun ve herkeste aynı sürücü harfiyle bağlayın.** Örneğin `M:\CAD\Makrolar` gibi. Ekipteki herkesin makinesinde aynı yol geçerli olduğu anda, buton tanımları da taşınabilir hale gelir. Bunu yaparken üç şeye dikkat edin: - **Yazma yetkisini kısıtlayın.** Makro klasörüne herkes yazabiliyorsa, bir gün birisi çalışan bir makroyu bozar ve kimse ne zaman bozulduğunu bilmez. - **Sürüm bilgisini dosya adına koymayın.** `antet_v3_son_SON.swp` gibi adlar ekibi felç eder. Tek bir `antet.swp` tutun, eski sürümleri ayrı bir arşiv klasöründe saklayın. - **Ağ kesildiğinde ne olacağını düşünün.** Ağ klasörüne erişilemediğinde makro çalışmaz. Kritik makroların yerel bir kopyasının bulunması, sahada işi durdurmamak için iyi bir sigorta. :::callout Küçük ekipler için pratik kural Üç kişiden az bir ekipseniz ağ klasörü kurmakla uğraşmayın; makroları herkesin bilgisayarında **aynı yerel yola** koyun (örneğin `C:\SW-Makro\`). Aynı işi görür, kurulum maliyeti sıfırdır. Ekip büyüdüğünde ağ klasörüne geçersiniz. ::: ## Makro çalışmıyorsa: sırayla bakılacak yerler "Makro çalışmıyor" cümlesi aslında beş farklı problemin ortak adı. Sırayla eleyerek gidersek hangisi olduğunu birkaç dakikada buluruz. **1. Hiç belge açık değil.** Makroların büyük çoğunluğu aktif bir belge üzerinde çalışır. Hiçbir şey açık değilse makro ilk satırda takılır. En basit ihtimal, o yüzden ilk bakılacak yer burası. **2. Yanlış türde belge açık.** Parça makrosunu montajda, montaj makrosunu teknik resimde çalıştırıyorsunuz. Bu durumda çoğu makro hata bile vermez, sessizce durur. Sessiz başarısızlık, makro dünyasının en pahalı hata türü — çünkü fark etmezsiniz. **3. Makro güvenlik ayarı engelliyor.** SolidWorks'ün VBA tarafı, makro güvenliğine bağlı olarak imzasız makroları çalıştırmayı reddedebilir. Bunu **Araçlar > Seçenekler > Sistem Seçenekleri** altındaki güvenlik/makro bölümünden kontrol edersiniz. Kurumsal ortamlarda bu ayarı BT ekibi kilitlemiş olabilir; o durumda konuşulacak kişi onlar. **4. Makronun aradığı şey o modelde yok.** Kaydedici ile üretilmiş makrolar, kayıt sırasındaki modelin özellik adlarını (`Boss-Extrude1` gibi) kodun içine gömer. Başka bir modelde o ad yoksa seçim başarısız olur ve makro yanlış nesne üzerinde çalışmaya devam eder. Bu, kaydedilmiş makroların bir numaralı zayıflığı; nasıl sağlamlaştırılacağını [SolidWorks makro nedir](https://mehmetseyrimez.com/blog/solidworks-makro-nedir) yazısında adım adım anlattım. **5. Referans eksik.** Makro, VBA düzenleyicisinde başka bir kütüphaneye bağlıysa ve o kütüphane karşı bilgisayarda yoksa, makro açılırken hata verir. Bu görece nadir ama başka bir firmadan gelen makrolarda karşınıza çıkabilir. :::illustration left problem-solving | "Makro çalışmıyor" beş farklı problemin ortak adı ::: ### Hata mesajını okumayı öğrenin Makro bir hata verdiğinde VBA düzenleyicisi genellikle sorunlu satırı sarıyla işaretler. O satırı okumak, hatanın ne olduğunu çoğu zaman doğrudan söyler. En sık gördüğünüz iki mesaj şunlar olacak: - **"Object variable or With block variable not set"** — kod, olmayan bir şeyi kullanmaya çalışıyor. Neredeyse her zaman "belge açık değil" ya da "seçim başarısız oldu" anlamına gelir. - **"Type mismatch"** — beklenen türde olmayan bir değer geldi. Genellikle sürüm farkından ya da yanlış belge türünden kaynaklanır. Hata mesajlarının daha uzun bir listesini ve her birinin pratik karşılığını ayrı bir yazıda toplayacağım; şimdilik bu ikisi, sahada karşılaşacağınızın büyük kısmını kapsıyor. ## Makroyu otomatik başlatmak: iyi fikir mi? Zaman zaman şu soru geliyor: "SolidWorks açılırken makro kendiliğinden çalışsın, mümkün mü?" Teknik olarak mümkün, ama benim tavsiyem genellikle hayır. Sebebi şu: kendiliğinden çalışan bir makro, kullanıcının haberi olmadan belgeyi değiştirebilir. Bir gün birisi "bu ölçü neden değişti" diye sorduğunda, sebebin arka planda çalışan bir makro olduğunu bulmak günler alır. Otomasyonun görünür olması, güvenilir olmasının ön şartı. Gerçekten otomatik bir davranış istiyorsanız — belge her açıldığında bir kontrol çalışsın, kaydetmeden önce antet doldurulsun gibi — doğru araç makro değil, **eklenti (add-in)**. Eklentiler SolidWorks'ün olay sistemine bağlanabilir, kullanıcıya ne yaptıklarını gösterebilir ve düzgün hata yönetimi yapabilir. Bu tarafa geçmek isterseniz [SolidWorks add-in geliştirme](https://mehmetseyrimez.com/blog/solidworks-add-in-gelistirme) yazısı başlangıç noktanız olsun. ## Hangi yol ne zaman: kısa bir karar rehberi | Kullanım sıklığı | Doğru yol | Neden | | --- | --- | --- | | Ayda birkaç kez | Menüden çalıştır | Kurulum maliyeti gereksiz | | Haftada birkaç kez | Araç çubuğu butonu | Bir tık, görünür, hatırlanır | | Günde birkaç kez | Klavye kısayolu | El klavyeden ayrılmaz | | Ekip genelinde | Ortak klasör + buton | Yol tutarlılığı taşınabilirliği sağlar | | Kendiliğinden çalışsın | Makro değil, eklenti | Olay sistemi ve hata yönetimi gerekir | Tablodaki son satır en önemlisi. Bir makronun "kendiliğinden çalışmasını" istemeye başladığınız an, aslında makronun sınırına gelmişsiniz demektir. ## Sık Sorulan Sorular **SolidWorks'te makro nasıl çalıştırılır?** Araçlar > Makro > Çalıştır menüsünden `.swp` uzantılı makro dosyasını seçmeniz yeterlidir. Sık kullandığınız makroları ise Araçlar > Özelleştir penceresinden bir araç çubuğu butonuna ya da klavye kısayoluna bağlamak çok daha pratiktir. **SolidWorks'te makro butonu nasıl eklenir?** Araçlar > Özelleştir penceresini açın, Komutlar sekmesinde Makrolar kategorisini seçin ve boş makro butonunu istediğiniz araç çubuğuna sürükleyin. Açılan pencerede makro dosyasını, çalıştırılacak yordamı, buton adını ve ikonu belirlersiniz. **SolidWorks makrosuna klavye kısayolu nasıl atanır?** Araçlar > Özelleştir penceresindeki Klavye sekmesinden makroyu bulup istediğiniz tuş kombinasyonunu yazarsınız. Yerleşik komutlarla çakışmamak için `Ctrl + Shift + ` kombinasyonları görece güvenlidir. **Makro benim bilgisayarımda çalışıyor, meslektaşımda çalışmıyor. Neden?** Neredeyse her zaman sebep, buton tanımının içinde makronun tam dosya yolunun kayıtlı olmasıdır. Çözüm, makroları ekipteki herkeste aynı yolla erişilebilen ortak bir klasörde tutmaktır — ağ paylaşımı ya da herkeste aynı yerel klasör. **SolidWorks makro güvenlik ayarı nerede?** Araçlar > Seçenekler > Sistem Seçenekleri altındaki güvenlik bölümündedir. Kurumsal ortamlarda bu ayar BT politikasıyla kilitlenmiş olabilir; imzasız makrolar engelleniyorsa çözüm bu ayarı zorlamak değil, BT ekibiyle konuşmaktır. **SolidWorks açılırken makro otomatik çalıştırılabilir mi?** Teknik olarak mümkündür ama tavsiye edilmez. Kullanıcının haberi olmadan belgeyi değiştiren bir makro, sonradan teşhis edilmesi çok zor sorunlar üretir. Otomatik davranış gerekiyorsa doğru araç makro değil, olay sistemine bağlanabilen bir eklentidir. **`.swp` dosyası nedir, nasıl açılır?** `.swp`, SolidWorks'ün VBA makro dosyasıdır. Çalıştırmak için Araçlar > Makro > Çalıştır, içeriğini görmek ve düzenlemek için Araçlar > Makro > Düzenle komutunu kullanırsınız. ## Özet Makroyu çalıştırmanın üç yolu var ve hangisini seçeceğiniz tek bir şeye bağlı: onu ne sıklıkla kullanacağınıza. Ayda birkaç kezse menü yeter, haftalıksa buton, günlükse kısayol. Ekip kullanacaksa makroların nerede durduğu, kodun kendisinden daha önemli hale gelir. Ve bir makronun "kendiliğinden çalışmasını" istemeye başladığınız gün, aslında bir sonraki adıma — eklenti geliştirmeye — hazırsınız demektir. --- # SolidWorks Makro Örnekleri: Günlük İşi Gerçekten Kısaltan 14 Fikir source: https://mehmetseyrimez.com/blog/solidworks-makro-ornekleri type: article published: 2026-08-26 category: Otomasyon Atölyesi tags: solidworks, makro, vba, otomasyon, cad-otomasyon author: Mehmet Seyrimez reading_minutes: 7 > Hangi işler makroya dökülmeye değer? Antet doldurmadan toplu çıktı almaya, özel özellik yönetiminden teknik resim standardizasyonuna kadar sahada karşılığı olan 14 makro fikri ve her birinin gerçek kazancı. Makro yazmayı öğrenmenin en zor kısmı sözdizimi değil, **neyi yazacağını bulmak.** İnsanlar bana genellikle "makroyu anladım ama ne yapacağımı bilmiyorum" diye geliyor. Bu yazı tam olarak o boşluk için: sahada gerçekten karşılığı olan, ilk makrolarınız olmaya uygun 14 fikir. Hepsinin ortak özelliği şu: **kurallı, tekrarlayan ve sonucu tartışmaya kapalı** işler. Bir makronun değeri, kazandırdığı süre çarpı tekrar sayısıdır — o yüzden her fikrin yanına gerçekçi bir kazanç notu da koydum. Kod yok; ne yapacağını ve neden değdiğini anlatıyorum. Makronun ne olduğunu ve nasıl yazıldığını henüz bilmiyorsanız önce [SolidWorks makro nedir](https://mehmetseyrimez.com/blog/solidworks-makro-nedir) yazısına, çalıştırma tarafını merak ediyorsanız [makro nasıl çalıştırılır](https://mehmetseyrimez.com/blog/solidworks-makro-nasil-calistirilir) yazısına bakın. :::illustration full scrum-board | İyi bir makro adayı: kurallı, tekrarlayan, sonucu tartışmasız ::: ## Teknik resim tarafı — en hızlı kazanç burada Neredeyse her ekipte en çok zaman kaybı teknik resimde oluyor. Modelleme yaratıcı bir iş, resim ise büyük ölçüde mekanik. Bu yüzden ilk makronuzu buradan seçmenizi öneririm. ### 1. Antet ve özel özellik doldurma Klasik ve hâlâ en değerli makro. Parçanın malzemesi, kalınlığı, ağırlığı ve çizen kişi bilgisi zaten modelde var; anteti elle doldurmak bu bilgiyi ikinci kez yazmak demek. Makro, modeldeki özellikleri okuyup antet alanlarına yazar. *Gerçek kazanç:* Resim başına 2–4 dakika. Haftada 20 resim çıkaran bir ekipte ayda 3–5 saat. *Neden iyi bir ilk makro:* Kuralı net, hata payı düşük, sonucu gözle anında görülür. ### 2. Standart görünüşleri yerleştirme Ön, üst, yan ve izometrik görünüşü sabit ölçekte, sabit konuma yerleştirmek. Ekibinizin resim standardı ne kadar netse makro o kadar kolay yazılır. *Gerçek kazanç:* Resim başına 3–5 dakika, ve daha önemlisi **tutarlılık** — resimler artık kim çizerse çizsin aynı görünür. ### 3. Kesit ve detay görünüşü adlandırma "A-A", "B-B", "Detay C" gibi etiketlerin sırayla ve boşluksuz gitmesi. Elle yapıldığında sıkça atlanan, düzeltmesi can sıkan bir iş. *Gerçek kazanç:* Küçük ama sürekli. Asıl faydası, revizyon sonrası kaymaların önlenmesi. ### 4. Katman ve çizgi tipi düzeltme Farklı kaynaklardan gelen resimlerde katman düzeni bozuluyorsa, makro hepsini firma standardına çeker. *Gerçek kazanç:* Dış kaynaklı resimlerin çok olduğu ekiplerde resim başına 5–10 dakika. ### 5. Revizyon tablosuna satır ekleme Revizyon numarası, tarih, açıklama ve revize eden kişi — dördü de kurala bağlanabilir. Makro doğru satırı doğru biçimde ekler, numarayı kendisi artırır. *Gerçek kazanç:* Süreden çok **hata önleme.** Atlanan revizyon numarası, üretimde yanlış parça anlamına gelir. ## Çıktı ve dosya tarafı — sessiz zaman kaybının olduğu yer Burası ölçmeden fark edilmeyen bir kayıp kalemi. İnsanlar "dosya çıkarmak zaten hızlı" der; iki hafta kayıt tutunca sayı şaşırtır. ### 6. Tek komutla PDF, DWG, DXF paketi Bir resimden üç formatta çıktı almak, elle yapıldığında üç ayrı diyalog, üç ayrı klasör seçimi ve üç ayrı ad yazma demek. Makro hepsini tek seferde, doğru adlarla, doğru klasörlere yazar. *Gerçek kazanç:* Çıktı başına 2–3 dakika. Seri üretim yapan bir ofiste ayda 8–12 saat. ### 7. Dosya adını kurala göre üretme Proje kodu, parça numarası, revizyon ve tarih içeren bir ad şeması varsa, o adı elle yazmak hem yavaş hem hataya açık. Makro aynı şemayı her seferinde birebir uygular. *Gerçek kazanç:* Süreden çok **aranabilirlik.** Adlandırması tutarlı bir arşivde dosya arama süresi çarpıcı biçimde düşer. ### 8. Montajdaki tüm parçalardan STEP çıkarma Tedarikçiye gönderilecek paket hazırlarken montajı açıp her parçayı tek tek kaydetmek, büyük montajlarda saatler alır. Makro ağacı gezer, her parçayı sırayla dışa aktarır. *Gerçek kazanç:* 100 parçalık bir montajda 1–2 saat, tek seferde. ### 9. Sac metal büküm resimlerini toplu üretme Sac metal ağırlıklı çalışan ekiplerde büküm açılımı ve büküm tablosu çıktısı her parça için ayrı ayrı yapılıyor. Makro klasördeki tüm sac parçaları gezip aynı işi tekrarlar. *Gerçek kazanç:* Parça başına 3–4 dakika, ve büküm tablosu formatında tam tutarlılık. :::illustration right factory | Çıktı paketleri: sessiz ama büyük bir zaman kalemi ::: ## Model ve veri tarafı — bakımı en kolay makrolar ### 10. Özel özellikleri (Custom Properties) toplu doldurma Malzeme, yüzey işlemi, tedarikçi kodu gibi alanların bir klasördeki tüm parçalarda aynı kurala göre doldurulması. ERP'ye veri gönderen ekipler için hayat kurtarıcı. *Gerçek kazanç:* Parça başına 1–2 dakika, ama asıl değer ERP tarafında: eksik özellik, eksik sipariş demek. ### 11. Malzeme ataması ve kütle doğrulaması Parçaya malzeme atanmamışsa kütle hesabı yanlış çıkar ve bu genellikle çok geç fark edilir. Makro klasörü gezip malzemesi atanmamış parçaları listeler. *Gerçek kazanç:* Doğrudan süre değil, **hata yakalama.** Bir yanlış kütle hesabının maliyeti, makronun yazım süresinden kat kat yüksek. ### 12. Kullanılmayan konfigürasyon ve görünüm temizliği Yıllar içinde dosyalar şişer: kullanılmayan konfigürasyonlar, unutulmuş görünüm durumları, ölü referanslar. Makro bunları tespit edip raporlar. *Gerçek kazanç:* Dosya boyutu ve açılma süresi. Büyük montajlarda hissedilir. ### 13. Global değişkenleri toplu güncelleme Bir ürün ailesinde standart bir ölçü değiştiğinde (örneğin sac kalınlığı), o değişikliği tüm parçalara elle yansıtmak hem yavaş hem risklidir. Makro denklem tablosundaki değişkeni bulup günceller ve modeli yeniden kurar. *Gerçek kazanç:* Standart değişikliği başına saatler; ve daha önemlisi, atlanan parça kalmaması. ### 14. Model kontrol listesi çalıştırma Teslim öncesi kontrol: malzeme atanmış mı, ad şemaya uygun mu, zorunlu özellikler dolu mu, rebuild hatası var mı? Makro hepsini kontrol edip tek bir rapor verir. *Gerçek kazanç:* Bu makronun kazancı süre değil **güven.** Teslim edilen paketin eksiksiz olduğunu bilmek, sonradan yapılan düzeltmelerin çoğunu ortadan kaldırır. :::illustration left knowledge | Kontrol listesi makrosu: kazancı süre değil, güven ::: ## Hangisiyle başlamalı? Listeye bakıp "hepsi lazım" demek kolay; ama ilk makronuzu seçerken üç şeye bakın: **Tekrar sayısı yüksek olsun.** Günde beş kez yapılan bir işi kabaca otomatikleştirmek, ayda bir yapılan bir işi mükemmel otomatikleştirmekten fazla kazandırır. Bu aritmetiği [otomasyon kazancını ölçmek](https://mehmetseyrimez.com/blog/otomasyon-kazancini-olcmek) yazısında ayrıntılandırdım. **Kuralı tartışmasız olsun.** "Antet şu alanlardan doldurulur" nettir. "Görünüş yerleşimi duruma göre değişir" değildir. Kuralı henüz oturmamış bir işi otomatikleştirmek, hareketli hedefi vurmaya çalışmaktır. **Sonucu gözle görülsün.** İlk makronuzun çıktısını anında doğrulayabilmeniz önemli — hem öğrenirken hem de ekibi ikna ederken. Bu üç ölçüte birlikte bakınca listenin başındaki **antet doldurma** neredeyse her ekipte birinci sırada çıkıyor. Ben de öyle başlamıştım. :::callout Küçük başlayın, ama uçtan uca İlk makronuz bir işin sadece ortasını halletmesin. Küçük olsun ama baştan sona bir işi bitirsin — yoksa kazancı hissetmezsiniz ve "makro işe yaramıyor" izlenimi oluşur. Bu prensibi [otomasyon projesine nasıl başlanır](https://mehmetseyrimez.com/blog/otomasyon-projesine-nasil-baslanir) yazısında pilot seçimi başlığında anlattım. ::: ## Makronun sınırına ne zaman gelirsiniz Bu listedeki fikirlerin hepsi makroyla yapılabilir. Ama şu üç işaretten biri belirdiğinde artık makro değil, eklenti (add-in) konuşuyoruz demektir: - **Kullanıcı arayüzü istiyorsunuz.** Birkaç değer sorup ona göre davranan bir panel gerekiyorsa, makronun basit giriş kutuları kısa sürede yetersiz kalır. - **Kendiliğinden çalışmasını istiyorsunuz.** Belge açıldığında, kaydedilmeden önce, bir özellik değiştiğinde… Bu tür olay tabanlı davranış makronun kapsamı dışında. - **Ekip kullanacak ve sürecek.** Makro dosyası büyüdükçe bakımı ağırlaşır; test edilemez, sürüm kontrolüne zor girer. Bu eşiği geçtiğinizde ne yapmanız gerektiğini [makro, API ve add-in arasındaki fark](https://mehmetseyrimez.com/blog/solidworks-makro-api-farki) ve [SolidWorks add-in geliştirme](https://mehmetseyrimez.com/blog/solidworks-add-in-gelistirme) yazılarında anlattım. ## Sık Sorulan Sorular **SolidWorks makro örnekleri nelerdir?** En yaygın ve karşılığı en yüksek olanlar: antet ve özel özellik doldurma, standart görünüş yerleştirme, tek komutla PDF/DWG/DXF çıktı paketi üretme, montajdaki tüm parçalardan STEP çıkarma, sac metal büküm resimlerinin toplu üretimi ve teslim öncesi model kontrol listesi. **İlk makromu hangi işle yazmalıyım?** Tekrar sayısı yüksek, kuralı tartışmasız ve sonucu gözle görülebilen bir işle. Bu üç ölçüt çoğu ekipte antet ve özel özellik doldurma makrosunu birinci sıraya koyar. **Makro yazmaya değer bir işi nasıl anlarım?** Kazandırdığı süreyi aylık tekrar sayısıyla çarpın ve makronun yazım ve bakım süresiyle karşılaştırın. Ayda birkaç kez yapılan kısa bir işi otomatikleştirmek genellikle elle yapmaktan pahalıdır. **Makro ile hangi işler yapılamaz?** Yargı gerektiren kararlar, olay tabanlı otomatik davranışlar ve zengin kullanıcı arayüzü isteyen akışlar. Bu üçüne ihtiyaç duyduğunuzda doğru araç makro değil, C# ile yazılmış bir SolidWorks eklentisidir. **SolidWorks makrosu toplu işlem yapabilir mi?** Evet. Bir klasördeki tüm dosyaları sırayla açıp işlem uygulamak makronun en verimli kullanım alanlarından biridir — toplu STEP çıkarma, özel özellik doldurma ve büküm resmi üretimi bunun tipik örnekleri. **Makro ile ERP'ye veri gönderilebilir mi?** Basit senaryolarda evet: makro özel özellikleri okuyup bir ara dosya (CSV, XML) üretebilir. Ancak canlı bir ERP bağlantısı, hata yönetimi ve kimlik doğrulama gerektirdiği için eklenti tarafına aittir. ## Özet Makro yazmayı öğrenmek, sözdizimini öğrenmek değil, **hangi işin makroya değdiğini görmek.** Yukarıdaki 14 fikrin ortak paydası basit: kurallı, tekrarlayan ve sonucu tartışmasız işler. Birinden başlayın, sahada çalıştığını görün, sonra ikinciye geçin. Otomasyon böyle büyür — listeyle değil, kanıtla. --- # SolidWorks Toplu İşlem Makroları: Yüzlerce Dosya Tek Seferde source: https://mehmetseyrimez.com/blog/solidworks-toplu-islem-makrolari type: article published: 2026-08-26 category: Otomasyon Atölyesi tags: solidworks, makro, vba, otomasyon, toplu-islem author: Mehmet Seyrimez reading_minutes: 8 > Bir klasördeki tüm parçalardan STEP çıkarmak, özel özellikleri toplu doldurmak, yüzlerce resmi PDF'e basmak. Toplu makro nerede patlar, nasıl güvenli olur? Toplu işlem, makronun en çok kazandırdığı yer. Sebebi basit aritmetik: bir işi bir kez otomatikleştirirsiniz, kazanç dosya sayısıyla çarpılır. 200 dosyada parça başına iki dakika kazandıran bir makro, tek çalıştırmada altı buçuk saat kazandırır. Ama toplu işlem aynı zamanda makronun en çok patladığı yer. Tek dosyada mükemmel çalışan bir makro, 200 dosyada üçüncüsünde takılıp kalır ve siz bilgisayarın başında bekler durursunuz. Bu yazıda toplu işlem makrolarının nasıl kurulacağını, nerede kırıldığını ve nasıl güvenli hale getirileceğini konuşacağız. Kod yok — mantığı ve tuzakları anlatıyorum, uyguladığınızda hangi kararı vereceğinizi bilesiniz diye. :::illustration full local-server | Toplu işlem: bir kere yaz, dosya sayısıyla çarp ::: ## Toplu işlem gerçekten neye benzer Çoğu insanın kafasında toplu işlem şöyle: "klasörü seç, düğmeye bas, bitsin." Gerçekte akış beş adımdan oluşuyor ve her adımın kendi tuzağı var. **Birinci adım: dosyaları bulmak.** Bir klasördeki dosyaları listelemek kolay. İşin zor kısmı, alt klasörlere inip inmeyeceğinize karar vermek ve doğru dosya türünü seçmek. Bir klasörde parça, montaj ve teknik resim bir aradaysa, hepsine aynı işlemi uygulamak sonucu bozar. **İkinci adım: dosyayı açmak.** Burada ilk gerçek tuzak var. SolidWorks bir dosyayı açarken uyarı penceresi çıkarabilir: "bu dosya eski bir sürümde kaydedilmiş", "referans bulunamadı", "salt okunur açılıyor". Bu pencerelerden biri açıldığı anda makronuz cevap bekler ve orada donar. **Üçüncü adım: işlemi yapmak.** Asıl iş burada. Ama dikkat: her dosya beklediğiniz yapıda olmayabilir. Aradığınız özellik yoksa, konfigürasyon farklıysa, malzeme atanmamışsa makronun ne yapacağına karar vermiş olmanız gerekir. **Dördüncü adım: kaydetmek veya kapatmak.** Değişiklik yaptıysanız kaydedeceksiniz; yapmadıysanız kaydetmeden kapatacaksınız. Bu kararı yanlış vermek, 200 dosyanın değiştirilme tarihini boş yere değiştirir ve versiyonlama sisteminizi karıştırır. **Beşinci adım: rapor etmek.** En çok atlanan adım ve en önemlisi. Birazdan ayrıntılı konuşacağız. ## Neden üçüncü dosyada takılır Toplu makroların bir numaralı problemi, **modal pencereler**. SolidWorks bir uyarı gösterdiğinde makro duraklar ve birinin "Tamam" demesini bekler. Bir gecede çalışsın diye başlattığınız makro, sabah geldiğinizde 3. dosyada bir uyarı penceresiyle sizi bekliyor olur. Çözüm iki parçalı: **Uyarıları sessize alın.** SolidWorks'ün bunun için ayarları var: dosya açma sırasında sessiz mod, kaydetme sırasında sessiz mod ve genel kullanıcı uyarısı bastırma. Makronun başında bunları açar, sonunda geri kapatırsınız. Sonunda kapatmayı unutursanız SolidWorks'ü kapatana kadar hiç uyarı görmezsiniz — bu da başlı başına bir tuzak. **Ama sessizliği kayda dönüştürün.** Bastırdığınız her uyarı, aslında size bir şey söylüyordu. Onu görmezden gelmek yerine kaydedin: hangi dosyada hangi uyarı çıktı? Makro bittiğinde bu liste elinizde olsun. > Sessiz mod, sessiz hataya dönüşmemeli. Bastırdığınız her uyarının yerine bir kayıt satırı koyun; yoksa toplu işlem kara kutuya döner. :::illustration right data-input | Sessize alınan her uyarının yerine bir kayıt satırı ::: ## Rapor: toplu makronun en değerli parçası Bir toplu makro çalıştıktan sonra tek bir soruya cevap verebilmelisiniz: **ne oldu?** Bunun için makronun sonunda bir metin dosyası üretmesi yeter. İçinde şunlar olsun: | Alan | Neden | | --- | --- | | Tarih ve saat | Hangi çalıştırma olduğunu bilmek için | | İşlenen dosya sayısı | Beklediğiniz sayı mı | | Atlanan dosyalar ve sebebi | Asıl değerli bilgi | | Uyarı çıkan dosyalar | Sonradan bakılacak liste | | Toplam süre | Bir dahaki sefere ne kadar süreceğini kestirmek | Bu rapor olmadan toplu makro, "umarım çalışmıştır" demekten ibaret. Raporla birlikte, ne olduğunu bilen bir araç haline geliyor. Pratik bir ipucu: raporu işlem yapılan klasöre değil, ayrı bir günlük klasörüne yazın ve dosya adına tarih koyun. Böylece eski çalıştırmaların kaydı da elinizde kalır — bir sorun çıktığında "geçen hafta çalıştırdığımızda da böyle miydi" sorusuna cevap verebilirsiniz. ## Döngü durmasın: tek bozuk dosya 199 dosyayı engellememeli İkinci büyük tasarım kararı bu. Makro 47. dosyada beklenmedik bir durumla karşılaştığında ne yapmalı? Yanlış cevap: durmak. 47. dosya bozuksa, kalan 153 dosyanın da işlenmemesi için bir sebep yok. Doğru cevap: o dosyayı atlamak, sebebi rapora yazmak ve devam etmek. Bunun için döngünün her adımının kendi hata yakalamasına sahip olması gerekiyor. Yani hata yönetimi döngünün dışında değil, **içinde** olmalı. Bu ayrım kulağa teknik geliyor ama sonucu çok somut: hata yönetimi döngünün dışındaysa makro ilk problemde durur; içindeyse tüm dosyaları dener ve size sorunlu olanların listesini verir. ## Değiştirmeden önce yedek: geri alınamayan işlemler Toplu işlemler iki gruba ayrılır ve bu ayrım çok önemli: **Okuyan işlemler.** Dosyadan bilgi çıkarır, dışa aktarır, rapor üretir. STEP çıkarma, PDF basma, özellik listeleme. Bunlar kaynak dosyaya dokunmaz — güvenlidir, yanlış giderse çıktıyı silip yeniden çalıştırırsınız. **Yazan işlemler.** Dosyayı değiştirir ve kaydeder. Özel özellik doldurma, malzeme atama, global değişken güncelleme. Bunlar geri alınamaz. İkinci gruba giren her makroyu çalıştırmadan önce üç kuralı uygulayın: 1. **Önce yedek alın.** Klasörün kopyası, sürüm kontrol sistemi, PDM — hangisi varsa. "Sadece bir özellik dolduracağım" diyerek atlanan yedek, en pahalı derstir. 2. **Önce beş dosyada deneyin.** Tam klasörü çalıştırmadan önce küçük bir örneklem üzerinde test edin ve sonucu gözle kontrol edin. 3. **Kuru çalıştırma (dry run) yapın.** Makronuza bir "sadece rapor et, değiştirme" modu ekleyin. Ne yapacağını önce görün, sonra gerçekten yaptırın. Üçüncü madde biraz fazladan iş gibi görünür ama toplu işlemlerde en çok işe yarayan alışkanlık odur. Bir kez yazarsınız, her toplu makroda kullanırsınız. :::callout Kuru çalıştırma neden bu kadar değerli "Şu klasördeki 213 parçadan 197'sinin malzemesi zaten atanmış, 14'ü boş, 2'si açılamadı" cümlesini görmek, aynı işi gerçekten yapmadan önce her şeyi değiştirir. Belki de 14 parça için toplu işlem çalıştırmaya hiç gerek yok. ::: ## Task Scheduler mı, makro mu? SolidWorks'ün kendi Görev Zamanlayıcı (Task Scheduler) aracı var ve toplu dönüştürme, toplu yazdırma gibi işleri yapabiliyor. Ne zaman onu, ne zaman makro yazmayı seçmeli? | Durum | Task Scheduler | Makro | | --- | --- | --- | | Standart dönüştürme (PDF, DXF) | ✔ Hazır, kod yok | Gereksiz emek | | Firma kuralına göre adlandırma | Sınırlı | ✔ Tam kontrol | | Koşullu işlem ("sadece şunlar") | ✘ | ✔ | | Rapor ve günlük | Sınırlı | ✔ İstediğiniz gibi | | Gece çalıştırma | ✔ Zamanlanabilir | Ek kurulum gerekir | | ERP'ye veri üretme | ✘ | ✔ | Kaba kural: **iş standartsa Task Scheduler, iş firmanıza özgüyse makro.** Ve zaten çoğu ekipte gerçek ihtiyaç ikinci gruba giriyor — çünkü kazandıran şey, tam olarak sizin sürecinize uyan otomasyon. ## Toplu işlemde performans: nereye dikkat etmeli 200 dosyalık bir işlem yarım saat de sürebilir, dört saat de. Farkı yaratan üç şey var: **Ekran güncellemesi.** Makro çalışırken her dosyayı ekrana çizdirmek ciddi zaman yiyor. Toplu işlemlerde ekran güncellemesini kapatmak tek başına belirgin hızlanma sağlar. **Gereksiz yeniden kurma.** Model üzerinde birden fazla değişiklik yapıyorsanız, her değişiklikten sonra değil hepsi bittikten sonra bir kez yeniden kurun. **Hafif açma.** Bazı işlemler için dosyayı tam olarak açmanız gerekmez — SolidWorks, belgeyi görsel arayüz olmadan ya da hafif modda açmanıza izin veriyor. Sadece özellik okuyacaksanız bu, süreyi ciddi biçimde kısaltır. Bu üçünü birlikte uyguladığınızda aynı işlemin birkaç kat hızlandığını görürsünüz. Ölçmeyi ihmal etmeyin: nasıl dürüst ölçüm yapılacağını [otomasyon kazancını ölçmek](https://mehmetseyrimez.com/blog/otomasyon-kazancini-olcmek) yazısında anlattım. ## Toplu işlemin sınırı: ne zaman eklentiye geçmeli Toplu makrolar hızla büyür. Başta "klasördeki parçalardan STEP al" diye başlarsınız, altı ay sonra elinizde şu olur: farklı ürün ailelerine farklı kurallar uygulayan, birden fazla çıktı formatı üreten, ERP'ye dosya yazan ve hata durumunda e-posta atan bir makro. Bu noktada makro artık makro değil, bakımı zor bir uygulamadır. Üç işaret size bunu söyler: - Makro dosyanız birkaç yüz satırı geçmiştir ve içinde ne olduğunu hatırlamıyorsunuzdur. - Bir değişiklik yaptığınızda başka bir yerin bozulmasından korkuyorsunuzdur. - Makroyu ekipte birden fazla kişi kullanıyordur ve herkeste farklı sürüm vardır. Üçünden ikisi varsa artık [eklenti (add-in) tarafına](https://mehmetseyrimez.com/blog/solidworks-add-in-gelistirme) geçme vakti gelmiştir. Aradaki farkı ve geçiş kararını [makro, API ve add-in arasındaki fark](https://mehmetseyrimez.com/blog/solidworks-makro-api-farki) yazısında ayrıntılı ele aldım. ## Sık Sorulan Sorular **SolidWorks'te bir klasördeki tüm dosyalara toplu işlem nasıl yapılır?** Makro klasördeki dosyaları listeler, her birini sırayla açar, işlemi uygular ve kapatır. Kritik nokta, işlem başında SolidWorks'ün kullanıcı uyarılarını sessiz moda almak ve döngünün her adımına kendi hata yakalamasını koymaktır — böylece tek bozuk dosya kalan dosyaların işlenmesini engellemez. **Toplu işlem makrom bir pencerede takılıp kalıyor, ne yapmalıyım?** Sebep, SolidWorks'ün dosya açarken veya kaydederken gösterdiği modal uyarı penceresidir. Makronun başında sessiz modu açın ve sonunda geri kapatın. Bastırdığınız uyarıları rapor dosyasına yazmayı ihmal etmeyin. **SolidWorks Task Scheduler mı yoksa makro mu kullanmalıyım?** İş standart bir dönüştürmeyse (toplu PDF, toplu DXF) Task Scheduler yeterlidir ve kod gerektirmez. Firmanıza özgü adlandırma, koşullu işlem, raporlama veya ERP'ye veri üretimi gerekiyorsa makro yazmak gerekir. **Toplu işlem öncesi yedek almak şart mı?** Dosyayı değiştiren her toplu işlem için evet. Okuma amaçlı işlemler (STEP, PDF, rapor üretimi) kaynak dosyaya dokunmadığı için güvenlidir; yazan işlemler geri alınamaz, bu yüzden önce yedek, sonra küçük örneklemde test, ardından tam çalıştırma sırası izlenmelidir. **Toplu makro neden çok yavaş çalışıyor?** En yaygın üç sebep: ekran güncellemesinin açık kalması, her değişiklikten sonra modelin yeniden kurulması ve dosyaların gereksiz yere tam modda açılması. Sadece özellik okuyacaksanız hafif modda açmak süreyi belirgin biçimde kısaltır. **Toplu işlem sonunda hangi dosyaların atlandığını nasıl bilirim?** Makronun sonunda bir rapor dosyası üretmesini sağlayın: işlenen dosya sayısı, atlanan dosyalar ve sebepleri, uyarı çıkan dosyalar ve toplam süre. Rapor olmadan toplu işlem kara kutudur. ## Özet Toplu işlem makrosu yazmak, tek dosyalık makro yazmaktan farklı bir iştir. Kod aynı olabilir ama sorumluluk değişir: artık gözünüzün önünde olmayan yüzlerce dosyaya dokunuyorsunuz. Üç kural her şeyi çözer: **uyarıları sessize al ama kaydet**, **döngü tek bir bozuk dosyada durmasın**, **sonunda rapor üret.** Bu üçü olmadan yazılmış bir toplu makro, çalıştığında bile ne yaptığını bilmediğiniz bir araçtır. --- # AutoCAD Otomasyonu: LISP mi, .NET mi, Yapay Zeka mı? source: https://mehmetseyrimez.com/blog/autocad-otomasyonu-lisp-net-yapay-zeka type: article published: 2026-08-20 updated: 2026-08-26 category: Otomasyon Atölyesi tags: autocad, otomasyon, yapay-zeka, cad-otomasyon author: Mehmet Seyrimez reading_minutes: 4 > AutoCAD otomasyonunda üç yol var: AutoLISP, .NET/ObjectARX ve yapay zeka. Ekip büyüklüğü ve bakım yüküne göre hangisi doğru? Karar tablosuyla anlatıyorum. AutoCAD otomasyonu sorusu neredeyse her zaman yanlış biçimde soruluyor: *"LISP mi yazsam, .NET mi?"* Doğru soru şu: **bu otomasyonu kim sürdürecek ve ne kadar süre yaşayacak?** Aracı bu iki cevap belirliyor. :::illustration full autocad-drafting | Parametre, kural ve çıktı zinciri ::: ## Üç yolun gerçek profili ### AutoLISP En hızlı başlangıç. Tek dosya, derleme yok, çizim ortamında anında çalışır. Küçük ve yerel işlerde — katman düzenleme, toplu yazdırma, öznitelik çıkarma — hâlâ en pratik yol. Sınırı, işin karmaşıklığı arttığında geliyor: hata yönetimi zayıf, birim testi pratikte yok, büyük bir LISP dosyasının bakımı zamanla ağırlaşıyor. Bir de sessiz bir maliyet var — LISP bilen kişi ayrıldığında kod çoğu firmada öksüz kalıyor. ### .NET / ObjectARX Derlenen, test edilebilen, sürüm kontrolüne giren kod. Karmaşık kural katmanları, dış veri kaynağına bağlanma, kurumsal dağıtım gerektiğinde doğru seçim. Bedeli kurulum maliyeti: proje yapısı, referanslar, imzalama, dağıtım. Küçük bir iş için bu yükü ödemek mantıklı değil. ### Yapay zeka destekli üretim Burada dikkatli olmak gerekiyor, çünkü iki farklı şey aynı isimle anılıyor: - **Kod üreten yardımcı.** LISP rutinini ya da .NET eklentisini sizin için yazar. Bu, yukarıdaki iki yolun *yerine* geçmez — onları **hızlandırır.** - **Komut anlayan asistan.** Düz metinle tarif ettiğiniz işi makroya çevirir. Keşif ve tek seferlik işler için kullanışlı, ama üretime giden bir akışta doğrulama katmanı olmadan çalıştırılmaz. Bu ayrımı yapmazsanız, "yapay zeka artık bunu yapıyor" diyerek sürdürülebilir bir çözümün yerine tek seferlik bir çıktı koymuş olursunuz. :::illustration right knowledge | Karar: kim sürdürecek, ne kadar yaşayacak ::: :::illustration left timeline | Seçimi belirleyen soru: kim sürdürecek, ne kadar yaşayacak ::: ## Karar tablosu Pratikte kullandığım eşikler: | Durum | Seçim | Gerekçe | | --- | --- | --- | | Tek kişilik iş, birkaç kez çalışacak | AutoLISP | Kurulum maliyeti kazancı yemesin | | Ekip kullanacak, kural içeriyor | .NET | Test ve sürüm kontrolü şart | | Dış veri / ERP bağlantısı var | .NET | LISP bu yükü taşımıyor | | Ne yapacağı henüz belirsiz | Yapay zeka + LISP | Önce keşif, sonra kalıcı çözüm | | Üretime giden çıktı üretiyor | .NET + doğrulama | Sessiz hata en pahalı hatadır | Son satır en önemlisi. Üretim çıktısı üreten bir otomasyonda araç seçimi ikinci sırada; **çıktının doğrulanması** birinci sırada gelir. ## Sık yapılan hata: aracı problemden önce seçmek Bir firma "AutoCAD'de LISP'lerimiz var, bunları yapay zekaya yazdıralım" diye geliyor. Sorulması gereken ilk soru bu değil. Önce şunu ölçmek gerekiyor: bu LISP'ler hangi işi yapıyor, o iş ayda kaç kez tekrarlanıyor, şu an nerede zaman kaybediliyor? Çoğu zaman cevap şu çıkıyor: mevcut LISP'lerin yarısı zaten kullanılmıyor, gerçek kayıp başka yerde. Bu yaklaşımı [otomasyon projesine nasıl başlanacağını anlattığım yazıda](https://mehmetseyrimez.com/blog/otomasyon-projesine-nasil-baslanir) adım adım anlattım — AutoCAD tarafında da aynı sıra geçerli. ## Sık Sorulan Sorular **AutoCAD otomasyonu için AutoLISP mi .NET mi seçmeliyim?** Karar teknik üstünlükte değil, sürdürülebilirlikte saklıdır: kodu kim sürdürecek ve ne kadar yaşayacak? Tek kişilik, kısa ömürlü ve çizim düzenleme ağırlıklı işlerde AutoLISP; ekip kullanacak, kural içeren veya dış veri kaynağına bağlanan işlerde .NET doğru seçimdir. **AutoLISP hâlâ kullanılıyor mu, ölü bir teknoloji mi?** Kesinlikle kullanılıyor. 1980'lerden beri neredeyse değişmeden duruyor ve AutoCAD'in her sürümünde destekleniyor. Küçük, hızlı ve çizim ortamına yakın otomasyonlarda hâlâ en pratik yol. **ObjectARX ile .NET arasındaki fark nedir?** ObjectARX C++ tabanlı, en düşük seviyeli ve en güçlü genişletme yoludur; .NET ise aynı API'ye yönetilen kodla erişir. Çoğu kurumsal ihtiyaç için .NET yeterlidir ve geliştirme maliyeti belirgin biçimde düşüktür. **Yapay zeka AutoCAD otomasyonunda LISP ve .NET'in yerini alır mı?** Almaz, ikisini de hızlandırır. Kod üreten yardımcılar rutin yazma süresini kısaltır ama üretilen kodun doğrulanması hâlâ size aittir; üretime giden bir akışta doğrulama katmanı olmadan çalıştırılmamalıdır. **Mevcut LISP rutinlerimi .NET'e taşımalı mıyım?** Hepsini değil. Yalnızca ekibin kullandığı, kural içeren ve bakımı ağırlaşmış olanları taşıyın. Çoğu firmada mevcut rutinlerin önemli bir bölümü zaten kullanılmıyor; taşımadan önce hangilerinin gerçekten çalıştığını ölçmek gerekir. **Üretime giden çıktı üreten bir otomasyonda neye dikkat etmeliyim?** Araç seçimi ikinci sırada; birinci sırada çıktının doğrulanması gelir. Sessizce yanlış çıktı üreten bir otomasyon, çöken bir otomasyondan çok daha pahalıdır çünkü hata üretim hattında fark edilir. ## Özet LISP ölmedi, .NET her zaman doğru değil, yapay zeka ikisinin yerine geçmiyor. Seçimi belirleyen teknik üstünlük değil, **sürdürülebilirlik:** kodu kim okuyacak, kim değiştirecek, ne kadar yaşayacak. Serinin bir sonraki yazısı, otomasyon kazancının nasıl dürüstçe ölçüleceği üzerine. --- # SolidWorks 2026 Yapay Zeka Özellikleri: Neyi Kısaltıyor? source: https://mehmetseyrimez.com/blog/solidworks-2026-yapay-zeka-ozellikleri type: article published: 2026-08-18 updated: 2026-08-26 category: Otomasyon Atölyesi tags: solidworks, yapay-zeka, otomasyon, cad-otomasyon author: Mehmet Seyrimez reading_minutes: 4 > SolidWorks 2026 teknik resim üretimini ve standart donanım tanımayı yapay zekaya devretti. Hangi iş gerçekten kısalıyor, hangisi hâlâ insanda kalıyor? Bir CAD sürümünün "yapay zeka" başlığıyla gelmesi artık haber değil. Asıl soru şu: bu özellikler günlük işin hangi dakikalarını geri veriyor, hangilerini vermiyor? SolidWorks 2026'da öne çıkan iki yetenek var — otomatik teknik resim üretimi ve standart donanımın tanınması. İkisi de gerçek bir kayıp kalemine dokunuyor. Ama ikisi de, otomasyon projelerinde defalarca gördüğüm aynı sınırla karşılaşıyor: **kural haline getirilebilen iş devredilebiliyor, yargı gerektiren iş devredilemiyor.** :::illustration full ai-agent | Girdi, karar katmanı ve üretim çıktısı ::: ## Otomatik teknik resim üretimi Tek komutla üretim resmi oluşturma, kâğıt üstünde en çarpıcı özellik. Pratikte doğru okuma şu: **resmin iskeletini** kuruyor. Görünüşlerin yerleşimi, kesitler, temel ölçülendirme — bunlar tekrarlayan ve kurallı işler, otomasyona en uygun kısım. Devredilemeyen kısım ise resmin *anlamı*: hangi ölçünün kritik olduğu, hangi toleransın üretim yöntemine göre değişeceği, hangi notun tedarikçi için zorunlu olduğu. Bunlar ürünü ve üretim hattını bilmeyi gerektirir. Bu yüzden özelliğin getirisini "resim çizme süresi sıfırlandı" diye ölçmek yanıltıcı olur. Doğru ölçüm şudur: **ilk taslağa ulaşma süresi ne kadar kısaldı, düzeltme süresi ne kadar arttı ya da azaldı?** İkisini birlikte ölçmezseniz kazancı olduğundan büyük görürsünüz. ## Standart donanım tanıma Cıvata, somun, pul gibi standart parçaların tanınıp montaja yerleştirilmesi, karmaşık ürünlerde hazırlık süresini gözle görülür biçimde kısaltıyor. Bu özelliğin değeri, tasarrufun **tekrar sayısıyla çarpılmasında.** Yüzlerce bağlantı elemanı içeren bir montajda kazanç ciddidir; on parçalık bir üründe fark edilmez bile. Otomasyonun getirisi her zaman kazanılan süre çarpı tekrar sayısıdır — bunu [otomasyon projesine nasıl başlanacağını anlattığım yazıda](https://mehmetseyrimez.com/blog/otomasyon-projesine-nasil-baslanir) daha ayrıntılı ele almıştım. :::illustration right predictive-analytics | Kazanç = kazanılan süre × tekrar sayısı ::: :::illustration left document-analysis | Hazır özellik genel olanı çözer; firmaya özgü olanı çözmez ::: ## Eklenti geliştirenler için ne değişiyor Buradaki asıl soru, hazır özellikler geldikçe eklenti yazmanın anlamsızlaşıp anlamsızlaşmadığı. Kendi deneyimimde tam tersi oldu. Hazır yapay zeka özellikleri **genel** olanı çözüyor: standart bir parça, standart bir resim düzeni. Firmaya özgü olanı çözmüyor — sizin çıktı adlandırma kuralınızı, revizyon numaralandırmanızı, tedarikçinizin istediği dosya paketini bilmiyor. Eklenti geliştirmenin değeri bu boşlukta duruyor ve daralmıyor: - **Kural katmanı.** Ürün ailesine özgü mühendislik kuralları hâlâ elle tanımlanır. - **Doğrulama katmanı.** Yapay zekanın ürettiği çıktının firmanın standardına uyup uymadığını kontrol eden katman. - **Paketleme.** PDF, DWG, DXF ve büküm resimlerinin doğru adlarla, doğru klasörlere gitmesi. Yeni özellikler bu üç katmanın *girdisini* iyileştiriyor, yerini almıyor. ## Ölçmeden önce sormanız gereken üç soru Yeni bir sürümün yapay zeka özelliğini değerlendirirken kullandığım kontrol listesi: | Soru | Neden önemli | | --- | --- | | Bu özellik hangi işi kısaltıyor? | "Genel olarak hızlandırır" ölçülemez bir iddiadır. | | O iş ayda kaç kez tekrarlanıyor? | Düşük tekrarda en iyi özellik bile fark etmez. | | Çıktı kaç dakikada doğrulanıyor? | Doğrulama süresi kazancı yiyorsa net kazanç sıfırdır. | Üçüncü soru en sık atlanan. Otomasyonun ürettiği çıktı her seferinde baştan kontrol ediliyorsa, kazanılan süre kontrol masasına geri veriliyor demektir. ## Özet SolidWorks 2026'nın yapay zeka özellikleri gerçek bir işe yarıyor — ama yaradığı iş, tekrarlayan ve kurallı olan kısım. Yargı gerektiren kısım yerinde duruyor, eklenti geliştirmenin alanı da orası. Bu seride sırada AutoCAD tarafı ve otomasyon kazancının nasıl dürüstçe ölçüleceği var. ## Sık Sorulan Sorular **SolidWorks 2026'nın yapay zeka özellikleri nelerdir?** Öne çıkan iki yetenek var: tek komutla otomatik teknik resim üretimi ve standart donanımın (cıvata, somun, pul) tanınıp montaja yerleştirilmesi. İkisi de tekrarlayan ve kurallı işlere dokunuyor. **Otomatik teknik resim üretimi resim çizme süresini sıfırlar mı?** Hayır. Resmin iskeletini kurar: görünüş yerleşimi, kesitler, temel ölçülendirme. Hangi ölçünün kritik olduğu, hangi toleransın üretim yöntemine göre değişeceği ve hangi notun tedarikçi için zorunlu olduğu hâlâ mühendiste kalır. **Bu özelliklerin gerçek kazancı nasıl ölçülür?** İlk taslağa ulaşma süresindeki kısalma ile düzeltme süresindeki değişimi **birlikte** ölçerek. Yalnızca üretim süresine bakmak, kazancı olduğundan büyük gösterir. **Hazır yapay zeka özellikleri eklenti geliştirmeyi gereksiz kılar mı?** Hayır. Hazır özellikler genel olanı çözüyor; firmanıza özgü çıktı adlandırma kuralınızı, revizyon numaralandırmanızı ve tedarikçinizin istediği dosya paketini bilmiyorlar. Kural katmanı, doğrulama katmanı ve paketleme hâlâ eklenti işidir. **Standart donanım tanıma her montajda kazandırır mı?** Kazanç tekrar sayısıyla çarpılır. Yüzlerce bağlantı elemanı içeren bir montajda ciddi; on parçalık bir üründe fark edilmez bile. **Yeni bir sürümün yapay zeka özelliğini değerlendirirken ne sormalıyım?** Üç soru: bu özellik hangi işi kısaltıyor, o iş ayda kaç kez tekrarlanıyor ve çıktı kaç dakikada doğrulanıyor? Üçüncüsü en sık atlanan ve kazancı belirleyen sorudur. --- # Üretken Yapay Zeka ile CAD Tasarım Süreçlerinin Otomasyonu source: https://mehmetseyrimez.com/blog/uretken-yapay-zeka-cad-otomasyonu type: article published: 2024-10-12 updated: 2026-08-26 category: Yapay Zeka tags: generative-ai, cad, llm, solidworks author: Mehmet Seyrimez reading_minutes: 6 > Parametrik modelleme ile LLM'ler mühendislik süreçlerinde nasıl bir arada çalışır? Entegrasyon katmanları, pilot senaryo tanımı, ölçüm ve durma noktası. Geleneksel bilgisayar destekli tasarım (CAD) süreçleri, üretken yapay zeka modellerinin kontrollü entegrasyonu ile yeni bir düzenlenebilirlik katmanı kazanabilir. Bu yazı, parametrik modelleme ile LLM destekli iş akışlarının nasıl düşünülebileceğine dair teknik bir çerçeve sunar. :::illustration full ai-code-assistant | Yapay zeka destekli mühendislik otomasyonu ::: ## Neden CAD + LLM birlikte düşünülmeli? CAD ortamında tekrarlayan operasyonlar — ölçü güncelleme, montaj revizyonu, çıktı paketleri — çoğu zaman kural tabanlıdır. LLM'ler bu kuralları doğal dil ve yapılandırılmış girdilerle köprüleyebilir; ancak geometri doğruluğu ve üretim gerçekliği hâlâ mühendislik disiplini ve doğrulama katmanlarında kalmalıdır. > Önemli: AI hız ve iterasyon için kaldıraçtır; mimari kararlar, test ve kalite sorumluluğu insanda kalır. --- ## Pratik entegrasyon katmanları - **Girdi normalizasyonu:** Kullanıcı ölçüleri, malzeme ve varyant seçimlerinin yapılandırılmış forma dönüştürülmesi - **Kural motoru:** Parametrik CAD güncellemelerini tetikleyen mühendislik kuralları - **Doğrulama:** Geometri, montaj çakışması ve üretim çıktısı kontrolleri - **Dokümantasyon:** PDF, DWG, DXF ve üretim verisi paketlerinin standart akışı :::illustration-left data-input | Parametre → kural → CAD → çıktı akışı ::: ### LLM'nin güçlü olduğu alanlar Doğal dil girdisini yapılandırılmış parametrelere çevirmek, hata mesajlarını sadeleştirmek ve tekrarlayan dokümantasyon metinlerini üretmek bu katmanda değerlidir. ### LLM'nin tek başına yeterli olmadığı alanlar Kritik geometri hesapları, tolerans zinciri, üretim hattı uyumu ve lisanslı CAD API sınırları insan denetimi gerektirir. :::illustration-right design-thinking | Parametrik kural paneli ve tasarım varyasyonları ::: --- ## SolidWorks ekosisteminde düşünme biçimi SolidWorks API, VBA, .NET ve C# ile otomasyon katmanı oluşturulduğunda LLM destekli arayüzler yalnızca “sohbet” değil, **iş akışı orkestrasyonu** haline gelebilir: kullanıcı niyetini alır, parametre setine çevirir, API çağrılarını sıralar, sonucu doğrular. :::illustration full robotics | SolidWorks API otomasyon katmanı ::: ## Pilot senaryoyu nasıl tanımlarım "AI ile CAD otomasyonu yapalım" cümlesi bir proje tanımı değil. Pilotu daraltmadan başlanan her denemenin sonu, çalışan ama kimsenin güvenmediği bir demo oluyor. Kullandığım daraltma şu dört soruyla yapılıyor: 1. **Hangi iş, ayda kaç kez tekrarlanıyor?** Ayda üç kez yapılan bir işi otomatikleştirmek, kazandırdığından fazlasını götürür. 2. **Girdi ne kadar yapılandırılmış?** Ölçüler bir formdan mı geliyor, e-posta metninden mi? İkincisi LLM'nin gerçekten değer kattığı yerdir. 3. **Yanlış çıktının bedeli ne?** Bir teklif resmi yanlışsa düzeltilir; kesime giden bir DXF yanlışsa sac çöpe gider. Bedel yükseldikçe doğrulama katmanı kalınlaşır. 4. **Doğru cevabı kim biliyor?** Çıktının doğruluğunu onaylayacak bir kişi yoksa pilot ölçülemez. İyi bir ilk pilot genelde şudur: **sık tekrarlanan, girdisi dağınık, yanlışının ucuz olduğu** bir iş. Teklif aşaması bu tarife çoğu firmada birebir uyar. ## Ölçüm: neyi, ne zaman ölçmeli Pilot başlamadan **önce** mevcut durumu ölçmezseniz, sonrasında elinizde kıyas olmaz. Kaydettiğim dört metrik: | Metrik | Nasıl ölçülür | Neden önemli | | --- | --- | --- | | Hazırlık süresi | Girdi alındığı andan çıktı hazır olana kadar geçen dakika | Doğrudan hissedilen kazanç | | Düzeltme oranı | Otomatik çıktının kaçta kaçı elle düzeltildi | Güvenin gerçek göstergesi | | İlk seferde doğru | Hiç düzeltme gerektirmeyen iş yüzdesi | Otomasyonun olgunluk seviyesi | | Kaçan hata | Üretime gidip orada yakalanan hata sayısı | Tek gerçek başarısızlık metriği | Bunlardan **düzeltme oranı** en öğreticisidir. Yüksekse otomasyon çalışmıyor demek değildir; kural setinin eksik olduğu yeri gösterir. Düzeltmelerin nerede yoğunlaştığına bakmak, bir sonraki geliştirme turunun gündemini kendiliğinden yazar. :::illustration-left data-input | Parametre → kural → CAD → çıktı akışı ::: ## Doğrulama listesi Üretime giden her otomatik çıktının geçmesi gereken kontroller — sırayla, ilk düşende dur: 1. **Girdi tamlığı** — zorunlu parametrelerin hepsi geldi mi, birimleri doğru mu 2. **Aralık kontrolü** — her ölçü, üretilebilir aralıkta mı (hat genişliği, minimum büküm yarıçapı, sac kalınlığı) 3. **Geometri sağlığı** — rebuild hatasız tamamlandı mı, açık kontur veya sıfır kalınlıkta yüzey var mı 4. **Montaj çakışması** — interference kontrolü temiz mi 5. **Çıktı bütünlüğü** — beklenen dosyaların hepsi üretildi mi, boyutları makul mü 6. **Ad ve revizyon** — dosya adı şemaya uyuyor mu, revizyon numarası artmış mı Bu listenin tamamı **deterministik**tir; hiçbir adımında LLM yoktur. Modelin işi girdiyi anlamak ve parametreye çevirmekti; doğruluğu kural kodu söyler. > Ayrım net olmalı: LLM'nin çıktısı hiçbir zaman doğrudan üretime gitmez, her zaman kural motorunun girdisi olur. Kural motoru reddederse iş durur. ## Nerede durmalı Üretken modellerin CAD tarafında **iyi olmadığı** yerleri baştan kabul etmek, projeyi kurtaran karardır: - **Tolerans zinciri.** Birikimli tolerans hesabı bir muhakeme işi değil, aritmetik ve standart işi. Modele yaptırmayın. - **Kritik geometri.** Mukavemet, ağırlık merkezi, kesit hesabı — bunlar kütüphane işidir, üretim işi değil. - **CAD API sınırları.** Hangi çağrının hangi sürümde ne döndürdüğü belgelenmiş bilgidir; halüsinasyona en açık alan tam da burasıdır. - **Üretim hattı gerçeği.** Roll-form hattının neyi bükebildiğini model bilmez; bu bilgi kural setine elle girer. Buna karşılık modelin gerçekten kazandırdığı üç yer var: **dağınık girdiyi yapılandırmak** (e-posta, telefon notu, elle çizilmiş kroki açıklaması), **hata mesajlarını kullanıcının anlayacağı dile çevirmek** ve **tekrar eden dokümantasyon metinlerini üretmek**. --- ## Özet çerçeve Sırayı şöyle kuruyorum: dar bir pilot seç → mevcut durumu ölç → girdi normalizasyonunu LLM'ye ver → kararı kural motoruna bırak → çıktıyı deterministik listeyle doğrula → düzeltme oranına bakarak kural setini büyüt. Bu döngü, teknoloji değişse de ayakta kalıyor. Model daha iyi olduğunda birinci adım hızlanır; ama doğrulama katmanına duyulan ihtiyaç azalmaz. :::callout İlgili Bu çerçevenin SolidWorks içine gömülü hâlini ParametriX'te uyguladım — doğal dil ve 2B girdiden parametrik 3B modele giden akışın kural ve doğrulama katmanlarıyla birlikte tasarımı. ::: ## Sık Sorulan Sorular **Üretken yapay zeka CAD tasarım süreçlerinde ne işe yarar?** En çok değer kattığı yer dağınık girdiyi yapılandırmaktır: e-posta, telefon notu ya da elle çizilmiş kroki açıklamasını parametre setine çevirmek. Ayrıca hata mesajlarını kullanıcının anlayacağı dile çevirmede ve tekrarlayan dokümantasyon metinlerini üretmede güçlüdür. **LLM çıktısı doğrudan üretime gidebilir mi?** Hayır. Modelin çıktısı hiçbir zaman doğrudan üretime gitmemeli, her zaman kural motorunun girdisi olmalıdır. Kural motoru reddederse iş durur; doğruluğu deterministik kural kodu söyler, model değil. **Yapay zeka destekli CAD otomasyonu pilotu nasıl seçilir?** Dört soruyla: iş ayda kaç kez tekrarlanıyor, girdi ne kadar yapılandırılmış, yanlış çıktının bedeli ne, doğru cevabı kim biliyor? İyi bir ilk pilot genelde sık tekrarlanan, girdisi dağınık ve yanlışının ucuz olduğu bir iştir — teklif aşaması çoğu firmada bu tarife uyar. **Hangi metrikler takip edilmeli?** Hazırlık süresi, düzeltme oranı, ilk seferde doğru çıktı yüzdesi ve üretime kaçan hata sayısı. Bunlardan düzeltme oranı en öğreticisidir: kural setinin eksik olduğu yeri doğrudan gösterir. **Üretken modellerin CAD tarafında iyi olmadığı yerler nereler?** Tolerans zinciri hesabı, kritik geometri hesapları, CAD API sınırları ve üretim hattı gerçeği. Bu dördü kütüphane, dokümantasyon ve kural seti işidir; modele bırakılırsa halüsinasyon riski en yüksek alanlardır. **Doğrulama katmanı neleri kapsamalı?** Girdi tamlığı, aralık kontrolü, geometri sağlığı, montaj çakışması, çıktı bütünlüğü ve ad/revizyon kontrolü. Bu listenin tamamı deterministik olmalı; hiçbir adımında model bulunmamalıdır. --- # AutoCAD'de AutoLISP Yükleme ve Otomatik Başlatma: 4 Yol source: https://mehmetseyrimez.com/blog/autolisp-yukleme-ve-otomatik-baslatma type: article published: 2026-08-26 category: Otomasyon Atölyesi tags: autocad, autolisp, otomasyon, cad-otomasyon, dagitim author: Mehmet Seyrimez reading_minutes: 8 > APPLOAD, Startup Suite, acaddoc.lsp ve destek dosya yolu. Dört yükleme yolundan hangisi ne zaman doğru, LISP rutinleri ekipte nasıl aynı kalır? Bir LISP rutini yazdınız, çalışıyor, mutlusunuz. Sonra AutoCAD'i kapatıp açıyorsunuz ve komut satırına yazdığınızda "bilinmeyen komut" diyor. Çünkü LISP kodu AutoCAD kapandığında bellekten siliniyor — her oturumda yeniden yüklenmesi gerekiyor. İşte bu yazı, o "yeniden yükleme" işini bir daha hiç düşünmemeniz için. Ve daha önemlisi: **ekipteki herkeste aynı düzenin kurulması için.** Çünkü tek başınıza çalışırken küçük bir zahmet olan bu iş, beş kişilik bir ekipte gerçek bir kaos kaynağına dönüşebiliyor. AutoLISP'e yeni başlıyorsanız önce [AutoLISP nedir](https://mehmetseyrimez.com/blog/autolisp-nedir) yazısına, kendi komutunuzu yazmayı merak ediyorsanız [AutoCAD'e yeni komut ekleme](https://mehmetseyrimez.com/blog/autocad-yeni-komut-ekleme-autolisp) yazısına bakabilirsiniz. :::illustration full checklist | Yükleme düzeni: tek kişide zahmet, beş kişide kaos ::: ## Dört yükleme yolu ve hangisi ne zaman AutoCAD size LISP yüklemenin birden fazla yolunu veriyor ve hepsinin farklı bir amacı var. Kafa karışıklığının çoğu, hangisinin ne işe yaradığının bilinmemesinden çıkıyor. ### 1. APPLOAD — elle yükleme `APPLOAD` komutu bir pencere açar, dosyayı seçersiniz, yüklenir. Sadece o oturum için geçerlidir; AutoCAD kapanınca gider. **Ne zaman:** Geliştirme sırasında. Kodu değiştirdiniz, yeniden yükleyip denemek istiyorsunuz. Bir de birisi size tek seferlik bir rutin gönderdiğinde. **Ne zaman değil:** Günlük kullanımda. Her sabah dosya yüklemek, otomasyonun kazandırdığı süreyi geri verir. ### 2. Startup Suite — kişisel otomatik yükleme APPLOAD penceresinin içinde "Startup Suite" (Başlangıç Paketi) adlı bir bölüm var. Buraya eklediğiniz dosyalar, AutoCAD her açıldığında kendiliğinden yüklenir. **Ne zaman:** Tek başınıza çalışıyorsanız ve birkaç dosyanız varsa. Kurulumu en kolay yol. **Ne zaman değil:** Ekip genelinde. Startup Suite kişisel profilde saklanır; her kullanıcının bilgisayarında elle kurulması gerekir. Beş kişilik bir ekipte beş kez, ve her yeni dosyada yine beş kez. ### 3. `acaddoc.lsp` — belge bazlı otomatik yükleme Bu, klasik ve en güçlü yol. `acaddoc.lsp` adlı bir dosya, AutoCAD'in arama yollarından birinde duruyorsa, **her çizim açıldığında** kendiliğinden çalıştırılır. Bu dosyanın içine kendi rutinlerinizi yükleyen satırlar koyarsınız. Böylece hem yeni açılan çizimlerde hem de AutoCAD açıkken açtığınız her çizimde kodunuz hazır olur. **Ne zaman:** Ekip genelinde kalıcı bir kurulum istediğinizde. Doğru yol budur. **Dikkat:** "Her çizim açılışında çalışır" cümlesini ciddiye alın. Buraya ağır bir işlem koyarsanız her çizim açılışı yavaşlar. `acaddoc.lsp` yalnızca yükleme yapmalı, iş yapmamalı. ### 4. Destek dosya arama yolu — dosyaların bulunduğu yer Bunlar birer yükleme yöntemi değil ama üçünü de mümkün kılan altyapı. AutoCAD, bir dosya adı gördüğünde onu **Destek Dosyası Arama Yolu** (Support File Search Path) listesindeki klasörlerde arar. Kendi LISP klasörünüzü bu listeye eklerseniz, dosyaları tam yol yazmadan adıyla çağırabilirsiniz. Ve daha önemlisi: dosyanın nerede durduğu değişse bile, arama yolu güncellendiğinde her şey çalışmaya devam eder. ## Ekip düzeni: nasıl kurulmalı Şimdi asıl meseleye gelelim. Tek kişilik kurulum kolay; ekip kurulumu ise bir tasarım işi. Sahada işe yarayan düzen şu: **Bir ortak klasör.** Tüm LISP dosyaları tek bir yerde dursun — ağ paylaşımı ya da senkronize edilen bir bulut klasörü. Önemli olan, ekipteki herkeste **aynı yolla** erişilebilmesi. **Herkeste aynı sürücü harfi.** Ağ klasörü kullanıyorsanız herkeste aynı harfe bağlayın (`M:\CAD\Lisp` gibi). Farklı harfler, taşınabilirliği bozan bir numaralı sebep. **Arama yoluna eklensin.** Bu klasör her kullanıcının Destek Dosyası Arama Yolu listesinde olsun. Böylece dosyalar adıyla çağrılabilir. **Tek bir `acaddoc.lsp`.** Ortak klasörde tek bir dosya dursun ve içinde hangi rutinlerin yükleneceği yazsın. Yeni bir rutin eklendiğinde tek bir dosyayı güncellersiniz, herkeste etkili olur. **Yazma yetkisi kısıtlı olsun.** Herkes yazabiliyorsa, bir gün birisi çalışan bir rutini bozar ve kimse ne zaman bozulduğunu bilmez. Yazma yetkisi bir ya da iki kişide olsun. Bu düzenin en büyük faydası şu: yeni bir bilgisayar kurulumunda yapılacak tek iş, arama yoluna bir klasör eklemek. Gerisi kendiliğinden gelir. :::illustration right scrum-board | Ortak klasör, tek acaddoc.lsp, kısıtlı yazma yetkisi ::: ## Yükleme sırası: sessiz bir tuzak Birden fazla dosyanız olduğunda sıra önemli hale geliyor. Bir rutin, başka bir dosyadaki yardımcı fonksiyonu kullanıyorsa, o dosyanın önce yüklenmiş olması gerekir. İki pratik çözüm var: **Yükleme dosyasında sırayı elle belirtin.** `acaddoc.lsp` içinde önce yardımcı fonksiyonları, sonra komutları yükleyin. Basit ve öngörülebilir. **Bağımlılıkları en aza indirin.** Her dosya mümkün olduğunca kendi kendine yetsin. Dosyalar arası bağımlılık arttıkça sıra problemi de büyür. İkincisini tercih ediyorum. Otuz dosyalık bir kütüphanede yükleme sırasını takip etmek, kısa sürede bakım yüküne dönüşüyor. ## Otomatik yükleme kurulduktan sonra: hata ayıklama Otomatik yükleme kurmanın bir bedeli var: bir şey ters gittiğinde nerede olduğunu bulmak zorlaşıyor. AutoCAD açılıyor, bir hata mesajı geçiyor ve siz onu okumaya fırsat bulamadan çizim ekranı geliyor. Üç alışkanlık bunu çözüyor: **Yükleme dosyanız konuşsun.** Her rutin yüklendiğinde komut satırına kısa bir satır yazsın: "MS-Katman rutinleri yüklendi." Ekibiniz bunu gördüğünde her şeyin yerinde olduğunu bilir; görmediğinde bir sorun olduğunu anlar. **Dosya bulunamazsa uyarsın.** Yüklenecek dosya yoksa AutoCAD sessizce geçer ve siz komutun neden çalışmadığını anlamaya çalışırsınız. Yükleme dosyanız, bulamadığı dosyayı açıkça söylesin. **Bir "yeniden yükle" komutu yazın.** Geliştirme sırasında değişiklik yaptığınızda tüm kütüphaneyi tek komutla yeniden yükleyebilmek, saatler kazandırır. `MS-RELOAD` gibi bir komut, yazması beş dakika sürer. :::callout Sık yapılan hata `acaddoc.lsp` içine yükleme dışında iş koymak. Buradaki her satır, açılan her çizimde çalışır. Ağır bir denetim rutinini buraya koyduğunuzda, ekibiniz AutoCAD'in neden yavaşladığını haftalarca anlayamaz. Yükleme dosyası yalnızca yükleme yapmalı. ::: ## Güvenlik ayarları: neden bazen hiç yüklenmiyor AutoCAD'in çalıştırılabilir dosyalar için bir güvenlik ayarı var (`SECURELOAD`). Bu ayar, LISP ve diğer eklenti dosyalarının yalnızca **güvenilir klasörlerden** yüklenmesini zorunlu kılabiliyor. Yeni bir ortak klasör kurup rutinlerin yüklenmediğini gördüğünüzde, bakılacak ilk yer burası. Klasörün güvenilir konumlar listesinde olması gerekiyor. Bu ayarı tamamen kapatmak yerine — ki güvenlik açısından doğru değil — LISP klasörünüzü güvenilir konumlara eklemek doğru çözüm. Kurumsal ortamlarda bu ayar BT politikasıyla yönetiliyor olabilir; o durumda konuşulacak kişi onlar. ## Sürüm yükseltmelerinde ne oluyor AutoCAD her yıl yeni bir sürüm çıkarıyor ve her yükseltmede aynı soru geliyor: rutinlerim çalışmaya devam edecek mi? İyi haber: **AutoLISP olağanüstü kararlı.** Yıllar önce yazılmış rutinlerin büyük çoğunluğu yeni sürümlerde de çalışıyor. Bu, LISP'in en büyük avantajlarından biri. Yine de yükseltme sonrasında üç şeyi kontrol edin: **Destek dosya arama yolu.** Yeni sürüm kendi profilini kurar ve sizin eklediğiniz klasörler orada olmayabilir. Bu, yükseltme sonrası "hiçbir komut çalışmıyor" şikâyetinin bir numaralı sebebi. **Güvenilir konumlar.** Aynı şekilde, yeni profilde güvenilir klasör listesi sıfırlanmış olabilir. **Kısmi CUI dosyaları.** Araç çubuğu ve şerit özelleştirmeleriniz de yeni profile taşınmalı. Pratik öneri: bu üç ayarı bir kontrol listesi olarak yazın ve her yükseltmede uygulayın. On dakikalık bu kontrol, ekibin yarım gün kaybetmesini önlüyor. :::illustration left maintenance | Yükseltme sonrası üç kontrol: arama yolu, güvenilir klasör, CUI ::: ## Kütüphaneyi sürdürülebilir tutmak Son olarak, birkaç yıl sonra da işe yaraması için birkaç not: **Sürüm kontrolüne alın.** LISP dosyaları düz metin — Git gibi bir sürüm kontrol sistemine mükemmel uyar. Kim ne zaman ne değiştirdi sorusunun cevabı elinizde olur. Bu, bir LISP kütüphanesinin kurumsal hafızaya dönüşmesinin en pratik yolu. **Her dosyanın başına üç satır yorum koyun.** Ne işe yarıyor, kim yazdı, ne zaman. Otuz saniyelik bir alışkanlık, dosyanın üç yıl sonra silinmesiyle kullanılmaya devam etmesi arasındaki farkı belirliyor. **Kullanılmayanları arşive alın, silmeyin.** Bir rutini kimse kullanmıyorsa yükleme listesinden çıkarın ama dosyayı saklayın. Bir gün lazım olur. **Yükleme listesini tek kaynak yapın.** Hangi rutinlerin yüklendiği tek bir yerde yazılı olsun. "Bende var ama sende yok" tartışmalarının tamamı bu tek dosyayla biter. Bu, yazılım tarafında **modüler mimari** dediğimiz yaklaşımın küçük ölçekteki hâli aslında; aynı prensipleri büyük mühendislik yazılımlarında nasıl uyguladığımı [modüler yazılım mimarisi](https://mehmetseyrimez.com/blog/moduler-yazilim-mimarisi) yazısında anlattım. ## Sık Sorulan Sorular **AutoLISP dosyası AutoCAD'e nasıl yüklenir?** Tek seferlik yükleme için APPLOAD komutu kullanılır; açılan pencereden `.lsp` dosyası seçilir. Bu yükleme yalnızca o oturum için geçerlidir, AutoCAD kapandığında silinir. **LISP rutinim her açılışta otomatik yüklensin, nasıl yaparım?** Tek kullanıcı için APPLOAD penceresindeki Startup Suite bölümüne eklemek yeterlidir. Ekip genelinde kalıcı bir kurulum içinse doğru yol, arama yollarından birinde duran bir `acaddoc.lsp` dosyasıdır; bu dosya her çizim açılışında kendiliğinden çalışır. **`acaddoc.lsp` nedir ve nereye konur?** AutoCAD'in her çizim açılışında otomatik çalıştırdığı bir LISP dosyasıdır. Destek Dosyası Arama Yolu listesindeki klasörlerden birine konur. İçinde yalnızca yükleme satırları olmalıdır; ağır işlemler her çizim açılışını yavaşlatır. **Rutinlerim ekipteki diğer bilgisayarlarda çalışmıyor, neden?** Genellikle dosyaların bulunduğu klasör diğer kullanıcıların Destek Dosyası Arama Yolu listesinde değildir ya da farklı bir sürücü harfine bağlanmıştır. Çözüm, ortak bir klasörü herkeste aynı yolla bağlamak ve arama yoluna eklemektir. **LISP dosyam yüklenmiyor, güvenlik ayarı mı engelliyor?** Muhtemelen evet. AutoCAD'in çalıştırılabilir dosya güvenliği, eklentilerin yalnızca güvenilir klasörlerden yüklenmesini zorunlu kılabilir. Doğru çözüm ayarı kapatmak değil, LISP klasörünüzü güvenilir konumlar listesine eklemektir. **AutoCAD sürüm yükseltmesinde LISP rutinlerim bozulur mu?** AutoLISP çok kararlı olduğu için rutinlerin kendisi genellikle çalışmaya devam eder. Bozulan şey ayarlardır: yeni sürüm kendi profilini kurar ve destek dosya arama yolu, güvenilir klasörler ve kısmi CUI dosyaları taşınmamış olabilir. **Birden fazla LISP dosyasının yükleme sırası önemli mi?** Bir rutin başka bir dosyadaki yardımcı fonksiyonu kullanıyorsa evet. En sağlam çözüm, dosyalar arası bağımlılığı en aza indirmek ve her dosyayı mümkün olduğunca kendi kendine yeter hale getirmektir. ## Özet Yazdığınız rutinin değeri, ne kadar iyi çalıştığıyla değil, **ne kadar kolay ulaşılabildiğiyle** ölçülüyor. Her sabah elle yüklenen bir rutin, kısa sürede kullanılmaz hale gelir. Ekip için doğru düzen basit: ortak bir klasör, herkeste aynı yol, arama yoluna eklenmiş, tek bir yükleme dosyasıyla yönetilen bir kütüphane. Bir kez kurarsınız, yıllarca sorun çıkarmaz — ve yeni bir bilgisayar kurulumunda yapılacak tek iş bir klasörü listeye eklemek olur. --- # AutoLISP Nedir? AutoCAD Otomasyonuna Sıfırdan Giriş source: https://mehmetseyrimez.com/blog/autolisp-nedir type: article published: 2026-08-26 category: Otomasyon Atölyesi tags: autocad, autolisp, otomasyon, cad-otomasyon, lisp author: Mehmet Seyrimez reading_minutes: 10 > AutoLISP nedir, ne işe yarar? .lsp/.fas/.vlx farkı, güçlü ve zayıf yönleri, AutoLISP mi .NET mi karar tablosu ve ilk haftanız için öğrenme sırası. En kısa hâliyle: **AutoLISP, AutoCAD'in içinde çalışan ve size kendi komutlarınızı yazma imkânı veren bir programlama dilidir.** Bir `.lsp` dosyasına yazarsınız, AutoCAD'e yüklersiniz, komut satırına yazdığınız anda çalışır. Derleme yok, kurulum yok, proje dosyası yok — yazdığınız şey doğrudan çizim ortamının bir parçası olur. Bu yüzden kırk yıldır ayakta. Ve bu yüzden hâlâ, "AutoCAD'de şu işi otomatikleştirebilir miyiz" sorusunun en hızlı cevabı çoğu zaman AutoLISP. Gelin baştan başlayalım. Hiç kod yazmamış olsanız bile takip edebileceğiniz bir anlatım hedefliyorum: LISP'in AutoCAD içinde tam olarak nerede durduğunu, neyi çözdüğünü, neyi çözemediğini ve ne zaman başka bir yola geçmeniz gerektiğini konuşacağız. :::illustration full knowledge | AutoLISP: AutoCAD'in içinde yaşayan küçük bir dil ::: ## AutoLISP tam olarak nedir AutoLISP, LISP adlı programlama dilinin AutoCAD için uyarlanmış bir sürümü. 1980'lerin ortasında AutoCAD'e eklendi ve o günden beri neredeyse hiç değişmeden duruyor — ki bu, bir yazılım için olağanüstü bir şey. Üç özelliği onu AutoCAD dünyasında bu kadar kalıcı yaptı: **Yorumlanır, derlenmez.** Yazdığınız metin dosyası doğrudan çalışır. Değişiklik yapıp yeniden yüklersiniz, saniyeler içinde sonucu görürsünüz. Bir .NET eklentisinde bu döngü dakikalar sürer. **Çizimin içinde yaşar.** LISP kodu, AutoCAD'in çizim veritabanına doğrudan erişir. Ekrandaki nesneleri seçebilir, özelliklerini okuyabilir, değiştirebilir, yenilerini yaratabilir. Ayrı bir uygulama değil, çizim ortamının uzantısıdır. **Komut gibi davranır.** Yazdığınız bir fonksiyonu, AutoCAD'in yerleşik komutlarından ayırt edilemeyecek şekilde komut satırına bağlayabilirsiniz. Kullanıcı açısından `LINE` ile sizin yazdığınız `HIZLI-ANTET` arasında hiçbir fark yoktur. Bu üçü bir araya geldiğinde ortaya şu çıkıyor: **kendi AutoCAD'inizi şekillendirebilirsiniz.** Sizin firmanızın çalışma biçimine göre komutlar, sizin standartlarınıza göre kontroller, sizin çizim düzeninize göre otomasyonlar. ### `.lsp` dosyası ne demek AutoLISP kodu düz metin dosyasında durur ve uzantısı `.lsp`'dir. Not Defteri'yle bile açıp okuyabilirsiniz — bu, LISP'in en sevdiğim yanlarından biri: kod şeffaftır, kimse size kapalı bir kutu veremez. Karşınıza çıkabilecek diğer uzantılar: | Uzantı | Nedir | | --- | --- | | `.lsp` | Düz AutoLISP kaynak dosyası — okunabilir, düzenlenebilir | | `.fas` | Derlenmiş LISP — hızlı çalışır ama kaynağı okunamaz | | `.vlx` | Birden fazla dosyanın paketlenmiş hâli | | `.dvb` | VBA makrosu — LISP değil, farklı bir dünya | | `.arx` / `.dll` | ObjectARX / .NET eklentisi — çok daha ağır bir katman | Pratikte `.lsp` ile çalışacaksınız. `.fas` ve `.vlx` ise genellikle bir yazılım firması size kodunu vermeden bir araç sattığında karşınıza çıkar. ## Peki gerçekte ne işe yarıyor Soyut kalmasın; sahada LISP'in en çok kullanıldığı işler şunlar: **Katman ve çizim düzeni işleri.** Katman oluşturma, renk ve çizgi tipi atama, dış kaynaktan gelen çizimleri firma standardına çekme. LISP'in en klasik kullanım alanı ve hâlâ en verimli olduğu yer. **Toplu düzenlemeler.** Seçili tüm metinlerin yazı tipini değiştirmek, belirli bir katmandaki her şeyi silmek, tüm blokların ölçeğini düzeltmek. Elle yapıldığında yarım gün süren işler saniyelere iner. **Öznitelik (attribute) işleri.** Bloklardaki öznitelikleri okumak, doldurmak, dışa aktarmak. Malzeme listesi çıkarmanın en pratik yolu genellikle budur. **Özel çizim komutları.** Sizin ürününüze özgü bir şeyi tek komutla çizmek: standart bir bağlantı detayı, bir kesit sembolü, firma antetiniz. **Yazdırma ve çıktı.** Sayfa düzeni ayarlarını uygulayıp toplu çıktı almak. Bir klasördeki tüm çizimleri aynı ayarlarla PDF'e basmak. **Veri çıkarma.** Çizimden bilgi toplayıp bir metin veya CSV dosyasına yazmak. ERP'ye veri besleyen ekiplerin ilk otomasyonu genellikle bu oluyor. Bu listeyi biraz açıp "AutoCAD'de tam olarak neler otomatikleştirilebilir" sorusuna ayrı bir yazıda daha ayrıntılı cevap verdim: [AutoCAD'de neler otomatikleştirilebilir](https://mehmetseyrimez.com/blog/autocadde-neler-otomatiklestirilebilir). :::illustration right code-sample | LISP'in klasik alanı: katman, öznitelik, toplu düzenleme, çıktı ::: ## AutoLISP nasıl çalışır — kod yazmadan mantığı LISP'i anlamanın en kolay yolu, onu "AutoCAD'e komut yazdırmak" olarak düşünmek. Siz normalde komut satırına `LINE` yazar, iki nokta tıklar, `Enter` dersiniz. LISP de aynı şeyi yapabilir — ama sizin yerinize, hatasız ve saniyede yüz kez. Bunun ötesinde iki şey daha yapabiliyor: **Çizim veritabanını doğrudan okuyabiliyor.** Ekrandaki her nesne — çizgi, daire, metin, blok — aslında bir veri kaydı. LISP bu kayıtlara erişip "bu çizginin uzunluğu kaç", "bu metnin içeriği ne", "bu blok hangi katmanda" gibi soruların cevabını alabiliyor. **Toplu seçim yapabiliyor.** "Şu katmandaki tüm daireleri seç", "yarıçapı 5'ten küçük olan her şeyi bul" gibi ölçütlerle seçim kümesi oluşturabiliyor. Elle yapıldığında imkânsıza yakın olan bu iş, LISP'te tek satırlık bir mesele. Bu ikisi birleştiğinde şu tür şeyler mümkün oluyor: "çizimdeki tüm blokları gez, öznitelik değerlerini oku, proje kodunu içerenleri bul, hepsinin katmanını değiştir ve bir rapor yaz." Tek komut, birkaç saniye. ### Visual LISP ne oluyor peki Karşınıza sık çıkacak bir isim. Visual LISP, AutoLISP'in üzerine eklenmiş iki şeyin ortak adı: 1. **Bir geliştirme ortamı (VLIDE).** Kod yazmak, satır satır çalıştırmak ve hata ayıklamak için AutoCAD'in içinde açılan bir editör. 2. **Genişletilmiş fonksiyonlar.** Nesnelere daha modern bir şekilde erişim, dosya işlemleri, dış uygulamalarla konuşma imkânı. Yani Visual LISP ayrı bir dil değil — AutoLISP'in daha yetenekli hâli. Bugün "LISP yazıyorum" diyen çoğu kişi aslında Visual LISP fonksiyonlarını da kullanıyor. Not: AutoCAD'in son sürümlerinde VLIDE editörü kaldırıldı ve yerine Visual Studio Code için resmî bir AutoLISP eklentisi geldi. Kod yazma tarafında modern bir editöre geçmiş oldunuz; dilin kendisi aynı. ## Güçlü ve zayıf yönleri: dürüst bir değerlendirme LISP'i severim ama her işe uygun değil. Nerede parladığını ve nerede tökezlediğini bilmek, doğru kararı vermenizi sağlar. **Parladığı yerler:** - **Hız.** Bir fikirden çalışan koda geçiş süresi dakikalarla ölçülür. Hiçbir alternatif bu kadar hızlı değil. - **Erişilebilirlik.** Kurulum yok, lisans yok, geliştirme ortamı satın alma yok. Not Defteri ve AutoCAD yeter. - **Şeffaflık.** Kod okunabilir. Altı ay sonra ne yaptığınıza bakabilirsiniz; sizden sonra gelen de bakabilir. - **Çizim ortamına yakınlık.** Seçim, komut çağırma, kullanıcıdan nokta isteme — bunlar LISP'te doğal, diğer yollarda daha zahmetli. **Tökezlediği yerler:** - **Hata yönetimi zayıf.** Bir şey ters gittiğinde LISP kibarca haber vermez; çoğu zaman ya durur ya da yanlış devam eder. - **Test yazmak pratik olarak imkânsız.** Otomatik test altyapısı yok. Bu, kod büyüdükçe ciddi bir risk. - **Büyük dosyalar bakımı zorlaştırır.** Bin satırlık bir LISP dosyası, aynı boyuttaki bir C# dosyasından çok daha zor yönetilir. - **Arayüz sınırlı.** Basit kutucuklar ötesinde bir kullanıcı arayüzü istiyorsanız zorlanırsınız. - **Sessiz bir kurumsal risk.** LISP'i yazan kişi ayrıldığında kod çoğu firmada öksüz kalıyor. Bunu sahada defalarca gördüm. Son madde, teknik olmayan ama en pahalıya mal olan sorun. Bir LISP kütüphanesi yıllar içinde büyür, kimse belgelemez, yazan kişi gider ve geriye kimsenin dokunmaya cesaret edemediği bir dosya yığını kalır. :::callout Küçük bir alışkanlık, büyük fark Yazdığınız her LISP dosyasının başına üç satır yorum koyun: ne işe yarıyor, kim yazdı, ne zaman. Bu otuz saniyelik alışkanlık, üç yıl sonra o dosyanın silinmesiyle kullanılmaya devam etmesi arasındaki farkı belirliyor. ::: ## AutoLISP mi, .NET mi? Karar tablosu En sık gelen soru bu ve cevabı teknik üstünlükte değil, **sürdürülebilirlikte** saklı. Ben şu soruyla başlıyorum: *bu kodu kim sürdürecek ve ne kadar süre yaşayacak?* | Durum | Doğru seçim | Neden | | --- | --- | --- | | Tek kişilik iş, birkaç kez çalışacak | AutoLISP | Kurulum maliyeti kazancı yemesin | | Katman/blok/öznitelik düzenleme | AutoLISP | Zaten en verimli olduğu alan | | Ekip kullanacak, kural içeriyor | .NET | Test ve sürüm kontrolü şart | | Dış veri kaynağı / ERP bağlantısı | .NET | LISP bu yükü taşımıyor | | Zengin kullanıcı arayüzü gerekiyor | .NET | LISP'in arayüz imkânları sınırlı | | Üretime giden çıktı üretiyor | .NET + doğrulama | Sessiz hata en pahalı hatadır | | Ne yapacağı henüz belirsiz | AutoLISP | Önce keşif, kalıcı çözüm sonra | Son satır önemli: LISP mükemmel bir **keşif dilidir.** Bir fikri yarım saatte deneyip işe yarayıp yaramadığını görürsünüz. İşe yarıyorsa ve kalıcı olacaksa, o zaman .NET'e taşımayı düşünürsünüz. Bu kararı ve yapay zekanın bu denkleme nasıl girdiğini [AutoCAD otomasyonu: LISP, .NET ve yapay zeka arasında nasıl seçim yaparım](https://mehmetseyrimez.com/blog/autocad-otomasyonu-lisp-net-yapay-zeka) yazısında daha ayrıntılı ele aldım. ## Nasıl başlanır: ilk haftanız LISP öğrenmenin en verimli yolu, kitap okumak değil, **küçük ve gerçek bir işi çözmek.** Şöyle bir sıra öneriyorum: **1. Bir sorun seçin.** Günde birkaç kez yaptığınız, sıkıcı ve kurallı bir iş. "Şu katmanı oluştur ve rengi şu olsun" gibi mütevazı bir şey ideal. **2. Editörünüzü kurun.** AutoCAD'in yeni sürümlerinde Visual Studio Code ve resmî AutoLISP eklentisi doğru başlangıç. Eski sürümlerde VLIDE zaten AutoCAD'in içinde. **3. Var olan kodu okuyun.** İnternette on binlerce ücretsiz LISP rutini var. Birini indirin, çalıştırın, sonra açıp okuyun. LISP'in sözdizimi ilk bakışta tuhaf gelir (parantezler!) ama iki gün içinde alışırsınız. **4. Küçük değişiklikler yapın.** Hazır bir rutini alıp katman adını değiştirmek, ilk sıfırdan yazma denemesinden çok daha öğreticidir. **5. Kendi komutunuzu tanımlayın.** İşin en tatmin edici anı, komut satırına kendi yazdığınız kısaltmayı yazıp bir şeyin olduğunu görmek. Bunun nasıl yapıldığını [AutoCAD'e AutoLISP ile yeni komut ekleme](https://mehmetseyrimez.com/blog/autocad-yeni-komut-ekleme-autolisp) yazısında adım adım anlattım. **6. Yüklemeyi otomatikleştirin.** Yazdığınız rutinlerin AutoCAD her açıldığında hazır olmasını istersiniz. Bunun yollarını [AutoLISP dosyası yükleme ve otomatik başlatma](https://mehmetseyrimez.com/blog/autolisp-yukleme-ve-otomatik-baslatma) yazısında topladım. :::illustration left guidelines | Öğrenmenin en hızlı yolu: küçük ve gerçek bir işi çözmek ::: ## Yapay zeka LISP yazmayı öğrenmeyi gereksiz kıldı mı? Bu soru artık her seminerde geliyor, o yüzden açıkça cevaplayayım: **hayır, ama denklemi değiştirdi.** Dil modelleri LISP kodu yazma konusunda gerçekten iyi. Basit bir rutini tarif ettiğinizde çalışan bir kod üretme ihtimalleri yüksek. Bu, LISP öğrenme eşiğini ciddi biçimde düşürdü — artık sözdizimini ezberlemek zorunda değilsiniz. Ama iki şey değişmedi: **Ne isteyeceğinizi bilmek gerekiyor.** "Çizimi düzelt" diye bir istek yok. "Şu katmandaki tüm metinleri şu yazı tipine çevir" diye bir istek var. Bu tarifi yapabilmek, işin kendisini anlamayı gerektiriyor. **Üretilen kodu doğrulamak gerekiyor.** LISP'in en zayıf yanı hata yönetimiydi, hatırlayın. Üretilen kod da bu zayıflığı miras alıyor: çalışır görünür, kenar durumda sessizce yanlış sonuç verir. Ve çizimde yaptığı değişiklikler geri alınamaz. Pratik tavsiyem: kodu üretin, ama **önce bir kopya çizimde deneyin.** Bu tek alışkanlık, yapay zeka destekli LISP yazmanın riskinin büyük kısmını ortadan kaldırıyor. ## Sık Sorulan Sorular **AutoLISP nedir?** AutoLISP, AutoCAD'in içinde çalışan ve kullanıcının kendi komutlarını yazmasına imkân veren bir programlama dilidir. Kod düz metin `.lsp` dosyasında durur, AutoCAD'e yüklendiğinde derleme gerektirmeden çalışır ve çizim veritabanına doğrudan erişebilir. **AutoLISP ne işe yarar?** Katman ve çizim standardı düzenleme, toplu değişiklikler, blok özniteliklerini okuma ve doldurma, firma ürünlerine özgü çizim komutları oluşturma, sayfa düzeniyle toplu çıktı alma ve çizimden veri çıkarma gibi işlerde kullanılır. Ortak paydası, kurallı ve tekrarlayan işler olmasıdır. **AutoLISP öğrenmek zor mu?** Sözdizimi ilk bakışta alışılmadıktır çünkü her şey parantezlerle yazılır, ama dil oldukça küçüktür. Var olan bir rutini indirip küçük değişiklikler yaparak başlamak, sıfırdan yazmayı denemekten çok daha hızlı ilerleme sağlar. **AutoLISP hâlâ kullanılıyor mu?** Evet. 1980'lerden beri neredeyse değişmeden duruyor ve AutoCAD'in her sürümünde destekleniyor. Küçük, hızlı ve çizim ortamına yakın otomasyonlarda hâlâ en pratik yol. **AutoLISP mi .NET mi kullanmalıyım?** Tek kişilik, kısa ömürlü ve çizim düzenleme ağırlıklı işlerde AutoLISP; ekip kullanacak, kural içeren, dış veri kaynağına bağlanan veya üretime çıktı üreten işlerde .NET. Karar teknik üstünlükte değil, kodu kimin sürdüreceği ve ne kadar yaşayacağı sorusunda saklıdır. **Visual LISP ile AutoLISP arasındaki fark nedir?** Visual LISP ayrı bir dil değil, AutoLISP'in genişletilmiş hâlidir: nesnelere daha modern erişim, dosya işlemleri ve dış uygulamalarla iletişim ekler. Ayrıca VLIDE adlı bir geliştirme ortamı sunuyordu; yeni AutoCAD sürümlerinde onun yerini Visual Studio Code için resmî AutoLISP eklentisi aldı. **`.lsp` dosyası nasıl açılır ve çalıştırılır?** `.lsp` düz metin dosyasıdır, herhangi bir metin editörüyle açılıp okunabilir. AutoCAD'de çalıştırmak için APPLOAD komutuyla yüklersiniz; her açılışta hazır olmasını istiyorsanız otomatik yükleme yollarından birini kullanmanız gerekir. **Yapay zeka ile AutoLISP yazdırmak güvenli mi?** Basit rutinlerde oldukça iyi sonuç veriyor, ama üretilen kod LISP'in zayıf hata yönetimini miras alır: kenar durumlarda sessizce yanlış sonuç verebilir ve çizimdeki değişiklikler geri alınamaz. Üretilen her rutini önce bir kopya çizim üzerinde denemek şarttır. ## Özet AutoLISP, AutoCAD'in size verdiği en doğrudan otomasyon kapısı. Küçük, hızlı, şeffaf ve çizim ortamının içinde yaşıyor. Küçük ve kurallı işlerde hiçbir alternatif ona yetişemiyor. Sınırı ise net: kod büyüdükçe, ekip kullanmaya başladıkça ve üretime giden çıktı ürettikçe LISP'in zayıf yanları (hata yönetimi, test edilemezlik, bakım yükü) öne çıkıyor. O eşiği geçtiğinizde .NET tarafına bakmanın vakti gelmiş demektir. Ama o eşiğe kadar — ki çoğu ofisin işi o eşiğin altındadır — LISP hâlâ en akıllı seçim. --- # SolidWorks Makro Nedir? Kaydetmekten Yazmaya Giriş source: https://mehmetseyrimez.com/blog/solidworks-makro-nedir type: article published: 2026-08-24 updated: 2026-08-26 category: Otomasyon Atölyesi tags: solidworks, makro, vba, otomasyon, cad-otomasyon author: Mehmet Seyrimez reading_minutes: 11 > Makro kaydediciyle üretilen kod neden doğrudan kullanılamaz? Kaydetmeden sağlam makro yazmaya, hata ayıklamadan butona atamaya uygulamalı bir giriş. SolidWorks makrosu, SolidWorks içinde çalışan ve elle yaptığınız bir dizi adımı tek komuta indiren küçük bir programdır. Genellikle VBA ile yazılır, `.swp` uzantısıyla saklanır ve çalıştırıldığında işini yapıp sonlanır. Makro yazarken SolidWorks API'sini kullanırsınız — ikisi rakip değil, biri diğerinin üzerinde durur. Bu yazının asıl konusu tanım değil, uygulama. Çünkü makroya başlayan hemen herkes aynı yerde takılıyor: makro kaydedici (Macro Recorder) ile bir işlemi kaydediyor, üretilen kodu çalıştırıyor ve kod ya hiçbir şey yapmıyor ya da yanlış şeyi yapıyor. Bunun nedeni kaydedicinin bozuk olması değil — **kaydedilen kodun tasarımı gereği o anki ekran durumuna bağımlı olması.** Aşağıda önce nasıl kaydedeceğinizi, sonra o bağımlılığı nasıl söküp atacağınızı anlatıyorum. :::illustration full macro-recorder | Kaydet, oku, sağlamlaştır: makro yazmanın üç adımı ::: ## SolidWorks Makrosu Ne İşe Yarar? Makronun işe yaradığı yer bellidir: **kurala bağlanabilen ve tekrarlanan** işler. Teknik resme standart görünüşleri yerleştirmek, antet alanlarını doldurmak, bir klasördeki tüm parçalardan STEP çıktısı almak, özel özellikleri (Custom Properties) toplu doldurmak, dosya adını revizyon kuralına göre üretmek. İşin tekrar sayısı burada belirleyicidir. Ayda bir yapılan bir işi makroya dökmek çoğu zaman elle yapmaktan pahalıdır; günde on kez yapılan bir işi kabaca otomatikleştirmek bile kazandırır. Hangi işin bu eşiği geçtiğini tahmin etmek yerine ölçmek gerekir — yöntemini [otomasyon projesine nasıl başlanır](https://mehmetseyrimez.com/blog/otomasyon-projesine-nasil-baslanir) yazısında adım adım anlattım. Makronun teknik olarak nerede durduğunu, API ve eklenti (add-in) mimarisiyle ilişkisini merak ediyorsanız [makro, API ve add-in arasındaki farkı](https://mehmetseyrimez.com/blog/solidworks-makro-api-farki) ayrı bir yazıda ele aldım. Burada odak tamamen pratikte: nasıl kaydedilir, nasıl düzeltilir, nasıl çalıştırılır. ## Makro Kaydedici (Macro Recorder) ile Kayıt Almak Kaydedici, API'yi öğrenmenin en hızlı yoludur. Bir işlemi elle yaparsınız, SolidWorks o işlemin karşılığı olan API çağrılarını koda döker. Hangi arayüzün hangi metodunu çağırmanız gerektiğini dokümantasyonda aramak yerine doğrudan görürsünüz. Akış şöyle işler: 1. **Kaydı başlatın.** Kaydet, duraklat ve durdur komutları `Araçlar > Makro` (Tools > Macro) menüsü altındadır; ayrıca ayrı bir Makro araç çubuğu olarak da açılabilir. Menü yerleşimi sürümden sürüme değişebildiği için, bulamazsanız komut arama kutusundan "makro" yazmak en hızlı yol. 2. **İşlemi normal hızınızda yapın.** Kaydedici fare hareketini değil, SolidWorks'ün gerçekleştirdiği komutları kaydeder. Yavaş yapmanın veya "temiz" yapmanın bir faydası yok. 3. **Kaydı durdurun.** Durdurduğunuzda SolidWorks makroyu kaydetmenizi ister. Anlamlı bir ad verin ve nerede tuttuğunuzu unutmayın. 4. **Kodu açın.** `Araçlar > Makro > Düzenle` (Edit) makroyu VBA düzenleyicisinde açar. Küçük bir alışkanlık: kaydı gerçek işinizin ortasında değil, **temiz bir belgede ve tek bir işlem için** alın. Beş işlemi birlikte kaydederseniz üretilen kodun hangi satırının hangi işleme ait olduğunu ayıklamakla uğraşırsınız. ### Neyin kaydedildiği, neyin kaydedilmediği Kaydedici her şeyi yakalamaz. Yakaladığı şey, SolidWorks'ün belge üzerinde gerçekleştirdiği komutlardır. Yakalayamadıkları arasında şunlar var: - Görünüm işlemleri (döndürme, yakınlaştırma) — çoğu zaman kayda girmez, girse de işlevsel bir karşılığı yoktur - Diyalog kutularında yaptığınız bazı ayarlar — sonuçları koda yansır, ara adımlar yansımaz - Sürümünüze özgü bazı komutlar — her komutun kaydedici karşılığı bulunmayabilir Bu yüzden kaydedilen kod, yaptığınız işin **eksiksiz bir kopyası değil, iskeletidir.** Onu bir tarif değil, bir ipucu listesi olarak okumak gerekir. ## Kaydedilen Kod Neden Doğrudan Kullanılamaz? Bu, Türkçe kaynaklarda en çok atlanan konu ve makroya başlayanların en çok vakit kaybettiği yer. Kaydedilen kod çoğu zaman **çalışır ama güvenilmez.** Üç ayrı bağımlılık yüzünden: ### 1. Seçime bağımlılık Kaydedici, "şu yüzeyi seç" işlemini genellikle şuna benzer bir satıra çevirir: Kaydedilen kodda bunu şöyle görürsünüz: "belgedeki şu adı taşıyan özelliği seç" diyen tek satırlık bir seçim komutu. O ad — `Boss-Extrude1` gibi — kayıt yaptığınız modele aittir. Bu satır, o modeldeki o ada sahip özelliği arar. Başka bir modelde o ad yoksa seçim başarısız olur — ve `SelectByID2` hata fırlatmaz, sadece `False` döner. Kod çalışmaya devam eder, bir sonraki satır "seçili olan şey" üzerinde işlem yapmaya kalkar ve ya patlar ya da yanlış nesneyi işler. Bazı durumlarda kaydedici, ada değil **koordinata** dayalı seçim üretir. O koordinat, kaydı aldığınız modeldeki noktadır. Model değişince o noktada artık başka bir şey vardır. ### 2. Aktif belgeye bağımlılık Kaydedilen kodun başında hemen her zaman şu vardır: Kaydedilen kodun ilk satırlarından biri hep aynıdır: "aktif belgeyi al". Yani o an ön planda hangi dosya varsa onunla çalışılacaktır. `ActiveDoc`, o an ön planda olan belgeyi verir. Hiç belge açık değilse `Nothing` döner. Makro bunu kontrol etmezse ilk kullanımda "Object variable not set" hatasıyla durur. Daha kötüsü: **yanlış türde** bir belge açıksa hata bile vermeyebilir. Parça için yazılmış bir makro teknik resim açıkken çalıştırıldığında sessizce hiçbir şey yapmaz — ve kullanıcı makronun çalıştığını sanır. ### 3. Ekran ve oturum durumuna bağımlılık Kaydedilen kod, kaydı aldığınız andaki bağlamı varsayar: hangi konfigürasyon aktifti, hangi sayfa açıktı, hangi nesneler zaten seçiliydi, hangi belge birim sistemi kullanılıyordu. Bunların hiçbiri kodda yazmaz — kod bunları "böyleydi" diye kabul eder. :::callout Asıl sorun sessiz başarısızlık Makronun hata vermesi kötü değil, iyidir. Asıl tehlike, makronun hiçbir şey söylemeden yanlış çıktı üretmesidir. Kaydedilen kodu sağlamlaştırmanın tek amacı, sessiz başarısızlıkları gürültülü hatalara çevirmektir. ::: :::illustration right code-sample | Kaydedilen kod bir tarif değil, ipucu listesidir ::: ## Kaydedilen Kodu Sağlamlaştırma Sağlamlaştırma dört hamleden ibaret: aktif belgeyi kontrollü almak, tür kontrolü yapmak, seçime bağımlılığı kaldırmak, sonucu kontrol etmek. ### Aktif belgeyi al ve türünü doğrula Her makro bu kontrolle başlamalı. Bu kısa blok, sahada karşılaşacağınız hataların büyük kısmını baştan keser: Her makronun ilk işi iki soruyu sormak olmalı: **belge var mı** ve **doğru türde mi?** Yani önce aktif belgeyi alırsınız, bu boş dönerse kullanıcıya "önce bir parça belgesi açın" diyip çıkarsınız. Sonra belgenin türünü kontrol edersiniz; parça bekliyorsanız ve montaj açıksa "bu makro yalnızca parça dosyalarında çalışır" deyip yine çıkarsınız. Bu kısacık blok, sahada karşılaşacağınız hataların büyük kısmını daha ortaya çıkmadan keser. Ve en önemlisi, sessiz başarısızlığı gürültülü hataya çevirir: kullanıcı artık makronun neden bir şey yapmadığını biliyor. ### Seçime bağımlılığı kaldır Kaydedilen `SelectByID2` satırını, nesneyi doğrudan modelden alan bir çağrıyla değiştirin. Seçim kullanıcı arayüzünün bir kavramıdır; kodun ona ihtiyacı yoktur: Sağlam hâli şöyle çalışır: seçim komutunu tamamen kaldırırsınız ve nesneyi doğrudan modelden istersiniz — "bana şu adı taşıyan özelliği ver". Dönen şey boşsa, yani o özellik bu modelde yoksa, makro durur ve kullanıcıya söyler: "beklenen özellik bu modelde yok". Fark ince ama önemli: birincisinde makro yanlış nesne üzerinde çalışmaya devam ediyordu, ikincisinde durup haber veriyor. Seçimi gerçekten kullanmanız gereken durumlar da vardır — örneğin makro, kullanıcının o an seçtiği nesne üzerinde çalışacaksa. O zaman kural şu olur: seçimi **varsayma, oku ve doğrula.** Kaç nesne seçili, doğru türde mi, değilse kullanıcıya söyle. ### Sonucu kontrol et API metotlarının büyük kısmı bir dönüş değeri verir ve bu değer çoğu zaman göz ardı edilir. Kaydedici bile `boolstatus` değişkenine atar ama hiç kontrol etmez: Somut bir örnek: bir özel özelliği (Custom Property) yazan çağrı bir sonuç kodu döndürür. Kaydedici bu kodu bir değişkene atar ama hiç bakmaz. Siz bakın — dönen değer beklediğiniz gibi değilse kullanıcıya "özellik yazılamadı" deyin. Dönen kodun tam anlamı sürüme göre değişebildiği için, kullandığınız sürümün dokümantasyonundan doğrulamakta fayda var. Bir uyarı: SolidWorks API'si uzunlukları **sistem birimiyle** işler — belgeniz milimetre gösterse de koda yazdığınız sayı metre olarak yorumlanır. Kaydedilen kodda göreceğiniz `0.05` gibi değerler bu yüzdendir. Elle sayı yazarken bu dönüşümü unutmak, makronun en sık ve en sinsi hatasıdır. ## Makroyu Çalıştırma, Düzenleme ve Butona Atama Çalıştırma ve düzenleme komutları da `Araçlar > Makro` menüsünde durur: **Çalıştır** (Run) makroyu doğrudan yürütür, **Düzenle** (Edit) VBA düzenleyicisinde açar. Düzenleyici içinden de çalıştırabilirsiniz — hata ayıklarken zaten oradan çalıştırırsınız. Bir makro günlük kullanıma girdiğinde menüden çağırmak yorucu olur. SolidWorks, makroları **klavye kısayoluna veya araç çubuğu butonuna** bağlamanıza izin verir; bu ayar özelleştirme (Customize) ekranındaki makro sekmesinden yapılır. Butona bir simge ve açıklama da verebilirsiniz. Buradaki pratik nokta şu: butona bağlanan makronun dosya yolu sabittir. Makroyu başka bir klasöre taşırsanız buton çalışmaz. Ekipçe kullanılacak makroları herkesin erişebildiği **ortak bir ağ klasöründe** tutmak, sonradan çıkacak "bende çalışmıyor" sorularının çoğunu önler. ## `.swp` Dosyası Ne Demek? VBA makroları `.swp` uzantısıyla saklanır. Bu dosyanın önemli bir özelliği var: **hem çalıştırılabilir program hem de kaynak kodun kendisidir.** Ayrı bir derleme adımı yoktur; dosyayı verdiğiniz kişi hem makroyu çalıştırabilir hem de içindeki kodu açıp okuyabilir, değiştirebilir. Bunun pratik sonuçları: - **Paylaşım kolaydır.** Tek dosya kopyalarsınız, karşı taraf çalıştırır. Kurulum yok. - **Kod açıktır.** Makroyu paylaşmak, kodunuzu paylaşmaktır. Kısıtlamak istediğiniz bir mantık varsa makro doğru kap değildir. - **Sürüm takibi zordur.** İkili bir dosya olduğu için Git gibi araçlarda satır bazlı fark göremezsiniz. Kim ne değiştirdi sorusunun cevabı yoktur. - **Kimin hangi kopyayı kullandığı bilinmez.** On kişiye dağıttığınız makronun üçüncü revizyonunda kimin hangi sürümde olduğunu takip edemezsiniz. Son iki madde, makronun sınırının nerede başladığını gösterir. O eşiğe geldiğinizde tartışma "makro mu başka bir şey mi" değil, mimari bir karara dönüşür — bunu [VBA makrodan eklenti mimarisine geçiş](https://mehmetseyrimez.com/blog/solidworks-makro-api-farki) yazısında ayrıntılandırdım. SolidWorks ayrıca .NET tabanlı makroları da destekler. Bu, makro ile eklenti arasında bir ara basamaktır ve ayrı bir konudur. :::illustration left fixing-bugs | Hata ayıklama: kesme noktası, adım adım yürütme, Immediate penceresi ::: ## Hata Ayıklama (Debug): Makro Çalışmadığında VBA düzenleyicisi tam bir hata ayıklama (debug) ortamı sunar ve bunu kullanmamak, makro yazarken yapılabilecek en büyük zaman kaybıdır. **Kesme noktası (breakpoint).** Bir satırın soluna tıklayarak makroyu o satırda durdurursunuz. Durduğunda değişkenlerin üzerine geldiğinizde değerlerini görürsünüz. **Adım adım çalıştırma (step).** Makroyu satır satır ilerletirsiniz. Hangi `If` bloğuna girdiğini, döngünün kaç kez döndüğünü doğrudan görürsünüz. Kaydedilen bir kodu anlamaya çalışırken en verimli yöntem budur. **Immediate penceresi.** Çalışma sırasında bir ifadenin değerini sorabilir veya koddan `Debug.Print` ile bu pencereye yazdırabilirsiniz. `MsgBox` ile akışı durdurmadan izlemenin yolu budur — özellikle döngü içinde. En sık karşılaşacağınız hatalar ve nedenleri: | Belirti | Muhtemel neden | |---|---| | "Object variable or With block variable not set" | `ActiveDoc` `Nothing` döndü ya da bir nesne çağrısı boş sonuç verdi | | Makro hiç hata vermiyor ama hiçbir şey de yapmıyor | Yanlış belge türü açık, ya da seçim başarısız olup kod sessizce devam etti | | İlk çalıştırmada doğru, ikincide yanlış sonuç | Önceki seçim temizlenmedi; makro artık başka bir nesne üzerinde işlem yapıyor | | Ölçüler bin kat sapıyor | Birim karışıklığı — API metre bekliyor, koda milimetre yazılmış | | Başka bilgisayarda çalışmıyor | Sabit dosya yolu veya o makinede bulunmayan bir referans | Bu tablodaki ikinci satır, en pahalı olanıdır. Çıktı üretildi sanılır, üretilmez; hata üretimde fark edilir. :::illustration full checklist | Beş alışkanlık: üçüncü makronuz birinciden çok daha hızlı yazılır ::: ## Makro Yazarken 5 Pratik Kural **1. Adlandırmayı baştan disipline edin.** `Makro1`, `Makro1_son`, `Makro1_son_v2` üç hafta sonra işe yaramaz. Dosya adı ne yaptığını söylesin: `TeknikResim_PDF_Disa_Aktar`. Kod içindeki değişkenler için de aynısı geçerli; kaydedicinin ürettiği `Part`, `boolstatus` gibi adları ilk iş olarak değiştirin. **2. Her adımda hata kontrolü yapın.** Belge var mı, tür doğru mu, nesne bulundu mu, metot başarılı döndü mü. Kural basit: **sessiz geçme.** Bir kontrolü atlamanın bedeli, o kontrolü yazmanın on katıdır. **3. Geri alma (undo) davranışını düşünün.** Makro modelde çok sayıda değişiklik yapıyorsa, kullanıcı bunları tek `Ctrl+Z` ile geri alamayabilir. SolidWorks API'si birden fazla işlemi tek geri alma adımında toplamaya izin verir; hangi metotların bu işi yaptığı sürümünüze göre değişebilir, dokümantasyondan doğrulayın. Yapamıyorsanız en azından kullanıcıya baştan söyleyin. **4. Kullanıcıya geri bildirim verin.** Makro bittiğinde ne yaptığını söylesin: kaç dosya işlendi, kaç tanesi atlandı, çıktılar nereye yazıldı. Geri bildirimsiz makro, her çalıştırıldığında elle kontrol edilir — yani kazandırdığı süreyi geri alır. Bu, otomasyon kazancının nerede eridiğini anlatan [dört adımlı ölçüm çerçevesinin](https://mehmetseyrimez.com/blog/otomasyon-kazancini-olcmek) doğrulama kalemine karşılık gelir. **5. Dosya yolu varsayımı yapmayın.** `C:\Users\...` ile başlayan sabit bir yol, sizin makinenizde çalışır. Yolu belgeden türetin (modelin bulunduğu klasör), kullanıcıya sorun ya da en azından klasörün var olup olmadığını yazmadan önce kontrol edin. ## Sık Sorulan Sorular **SolidWorks makro yazmak için programlama bilmek gerekir mi?** Başlamak için gerekmez; kaydedici çalışan bir kod üretir. Ama o kodu güvenilir hâle getirmek için temel VBA bilgisi — değişken, koşul, döngü, hata kontrolü — gerekir. Öğrenmenin en hızlı yolu, kaydedilen kodu satır satır adımlayarak okumaktır. **Kaydedilen makro neden başka bir modelde çalışmıyor?** Neredeyse her zaman seçime bağımlılık yüzünden. Kaydedici, nesneleri ada veya koordinata göre seçen kod üretir; o ad veya koordinat başka modelde farklıdır. Çözüm, seçim satırlarını nesneyi doğrudan modelden alan çağrılarla değiştirmektir. **Makro dosyası hangi uzantıya sahiptir?** VBA makroları `.swp` uzantısını kullanır. Bu dosya hem çalıştırılabilir hem de kaynak kodun kendisidir; ayrı bir derleme adımı yoktur. **Makroyu araç çubuğuna nasıl eklerim?** Özelleştirme (Customize) ekranındaki makro sekmesinden makro dosyasını seçip bir buton ve simge tanımlarsınız; aynı yerden klavye kısayolu da atanabilir. Ekranın tam yeri sürümünüze göre değişebilir. **Makro ile API farklı şeyler mi?** Hayır, rakip değiller. Makro yazdığınızda zaten API'yi çağırırsınız; API erişim katmanı, makro ise o katmanı kullanan biçimlerden biridir. Ayrımı [makro, API ve add-in rehberinde](https://mehmetseyrimez.com/blog/solidworks-makro-api-farki) ayrıntılı anlattım. **Makro çalışıyor ama sonuç yanlış. Nereden başlamalıyım?** VBA düzenleyicisinde ilk şüphelendiğiniz satıra kesme noktası koyup adım adım ilerleyin. Değişkenlerin gerçekten beklediğiniz değeri taşıyıp taşımadığını Immediate penceresinden doğrulayın. Yanlış sonuçların çoğu, başarısız olmuş ama hata vermemiş bir seçim veya birim dönüşümünden çıkar. ## Sonuç Makro öğrenmenin sırası şu: kaydet, oku, sağlamlaştır. Kaydedici size API'nin hangi metodunu çağıracağınızı gösterir — bu, dokümantasyonda aramaktan çok daha hızlıdır. Ama ürettiği kod, o anki seçime, açık belgeye ve ekran durumuna bağımlıdır. Kullanılabilir bir makro, o bağımlılıkları tek tek sökmekle ortaya çıkar: aktif belgeyi kontrollü al, türü doğrula, seçimi varsayma, her dönüş değerini kontrol et, kullanıcıya ne yaptığını söyle. Bu beş alışkanlığı baştan kurarsanız üçüncü makronuz birinciden çok daha hızlı yazılır — çünkü artık her seferinde aynı iskeletle başlıyor olursunuz. Makro seviyesinden başlayıp süreçle birlikte büyüyen bir otomasyonun somut karşılığını [SolidWorks CAD otomasyonu vaka çalışmasında](https://mehmetseyrimez.com/projeler/solidworks-cad-otomasyonu) görebilirsiniz. --- # SolidWorks Makro ve API Arasındaki Fark Nedir? source: https://mehmetseyrimez.com/blog/solidworks-makro-api-farki type: article published: 2026-08-24 updated: 2026-08-26 category: CAD Otomasyon tags: solidworks, api, makro, csharp, otomasyon, cad-otomasyon author: Mehmet Seyrimez reading_minutes: 11 > Makro ile API birbirinin alternatifi değil: API erişim katmanı, makro o katmanı kullanan yöntemlerden biri. Fark nerede ve ne zaman eklentiye geçilmeli? Bu sorunun kısa cevabı, arama sonuçlarında sık görülen cevaptan farklı: **SolidWorks makro ile SolidWorks API birbirinin alternatifi değildir.** API, SolidWorks'e programatik erişim sağlayan COM tabanlı arayüzdür — resmî dokümantasyonun ifadesiyle VB, VBA, VB.NET, C++, C# veya makro dosyalarından çağrılabilen yüzlerce fonksiyon. Makro ise bu API'yi kullanan otomasyon biçimlerinden **biridir**. Yani makro yazdığınızda zaten API kullanıyorsunuzdur. Dolayısıyla asıl karar "makro mu API mi" değildir. Asıl karar şudur: > API'ye hangi uygulama mimarisi üzerinden erişeceğim — makro mu, eklenti (add-in) mi, bağımsız uygulama mı? Bu yazı o kararı veriyor. Önce iki kavramı ayırıyor, sonra makronun nerede fazlasıyla yettiğini, hangi eşikte yetmemeye başladığını ve geçişin ne zaman gerçekten gerekli olduğunu anlatıyor. :::illustration full compare-options | API erişim katmanı, makro ve eklenti ise o katmanı kullanan uygulama biçimleri ::: ## SolidWorks Makro 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. ## SolidWorks API Nedir? 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. ## Makro ve API Arasındaki İlişki 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. :::callout Kısacası API bir yetenek havuzudur. Makro, eklenti ve bağımsız uygulama, o havuza farklı ömür ve farklı dağıtım modeliyle uzanan üç kaptır. ::: ## SolidWorks Makro Kullanmanın Avantajları Nelerdir? ### 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. ## SolidWorks Makro ile Hangi İşlemler Otomatikleştirilebilir? 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. ## SolidWorks Makro Ne Zaman Yeterlidir? 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. ## Makro Ne Zaman Yetersiz Kalmaya Başlar? 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ı?"** ## SolidWorks Makro ve Add-in Farkları | Kriter | VBA Makro | C#/.NET Add-in | |---|---|---| | Başlangıç hızı | Çok yüksek — dakikalar içinde çalışan kod | Düşük — proje kurulumu, kayıt, derleme | | Prototipleme | İdeal | Ağır kalır | | Öğrenme eğrisi | Düşük | Orta–yüksek (.NET + COM birlikte) | | Arayüz entegrasyonu | Sınırlı; temel formlar | CommandManager, TaskPane, PropertyManagerPage | | Olay yakalama | Kısıtlı; ömür boyu dinleme zor | Doğal; eklenti SolidWorks ile birlikte yaşar | | Dağıtım | Dosya kopyalama | Kurulum paketi, merkezî güncelleme | | Bakım | Tek dosya büyüdükçe zorlaşır | Modüler yapı, ayrıştırılmış sorumluluk | | Kayıt / log | Elle kurulur | Standart altyapı kullanılabilir | | Test edilebilirlik | Pratikte düşük | Birim testi mümkün | | Ekip kullanımı | Küçük ekipte iyi | Kurumsal ölçekte uygun | | ERP / PDM entegrasyonu | Zorlanır | Uygun | | Sürdürülebilirlik | Kısa–orta vade | Uzun vade | 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. ## VBA mı, C#/.NET mi? 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](https://mehmetseyrimez.com/blog/python-solidworks-otomasyonu) yazısında ayrıca ele aldım. ## Gerçek Kullanım Senaryoları **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](https://mehmetseyrimez.com/blog/2b-teknik-resimden-3b-modele-otomasyon) yazısında ayrıntılandırdım. ## Hangi Yaklaşımı Seçmelisiniz? 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](https://mehmetseyrimez.com/blog/otomasyon-projesine-nasil-baslanir) 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](https://mehmetseyrimez.com/blog/otomasyon-kazancini-olcmek) yazısındaki yaklaşımı kullanıyorum. ## Mehmet Seyrimez'in Yaklaşımı 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ı](https://mehmetseyrimez.com/projeler/solidworks-cad-otomasyonu) makro seviyesinden eklenti mimarisine geçişi, [ParametriX](https://mehmetseyrimez.com/projeler/parametrix-2d-3d) 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](https://mehmetseyrimez.com/blog/yapay-zeka-ile-solidworks-eklentisi-yazmak) yazısında ayrıntılandırdım. :::illustration left guidelines | Doğru soru "makro mu API mi" değil, "hangi kap" olmalı ::: ## Sık Sorulan Sorular **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. ## Sonuç "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](https://mehmetseyrimez.com/#iletisim) yazabilirsiniz. --- # SolidWorks API Nedir? COM Nesne Modeline Uygulamalı Giriş source: https://mehmetseyrimez.com/blog/solidworks-api-nedir type: article published: 2026-08-24 updated: 2026-08-29 category: CAD Otomasyon tags: solidworks, api, com, otomasyon, cad-otomasyon author: Mehmet Seyrimez reading_minutes: 11 > SolidWorks API nedir, nasıl çalışır? SldWorks.Application, ModelDoc2, PartDoc ve DrawingDoc hiyerarşisinde gezinme, öğrenme sırası ve otomasyon dili seçimi. SOLIDWORKS API, SOLIDWORKS için bir COM programlama arayüzüdür. Resmî dokümantasyonun tanımıyla: VB, VBA, VB.NET, C++, C# veya makro dosyalarından çağrılabilen yüzlerce fonksiyon içerir. Yani API, SolidWorks'ün içindeki her şeye — belgelere, feature'lara, ölçülere, konfigürasyonlara — dışarıdan kodla ulaşmanızı sağlayan katmandır. API'yi öğrenmek, fonksiyon listesi ezberlemek değildir. Öğrenilmesi gereken tek şey **nesne modelidir (object model)**: hangi nesne hangi nesnenin altındadır ve aradığınız yeteneğe hangi zincirden ulaşırsınız. Bu haritayı bir kez kurduğunuzda, bilmediğiniz bir metodu bulmak dakikalar sürer. Kurmadığınızda, dokümantasyonda saatlerce dolaşıp yine de nereden başlayacağınızı bilemezsiniz. Bu yazı o haritayı çiziyor. API'nin makro ve eklenti mimarileriyle ilişkisini burada tekrar anlatmayacağım; onu ayrıca [makro, API ve add-in ilişkisini ele aldığım yazıda](https://mehmetseyrimez.com/blog/solidworks-makro-api-farki) ayrıntılandırdım. Burada asıl soru şu: **API'yi anladım, nesne hiyerarşisinde nasıl gezinirim?** :::illustration full api-object-tree | Kökten belgeye, belgeden feature ve özelliklere uzanan API nesne zinciri ::: ## COM Ne Demek, Pratikte Ne Anlama Geliyor? COM (Component Object Model), Windows'un uygulamalar arası nesne paylaşım standardıdır. SolidWorks, yeteneklerini COM arayüzleri olarak dışarı açar. Pratikte bunun üç somut karşılığı var. **Birincisi: dil bağımsızlığı.** COM arayüzü bir sözleşmedir — hangi metodun hangi parametreleri aldığı, dilden bağımsız olarak tanımlıdır. Bu yüzden `ModelDoc2` nesnesine VBA'dan da, C#'tan da, C++'tan da, Python'un COM köprüsünden de aynı biçimde erişilir. Metot adları değişmez; yalnızca yazım biçimi (syntax) değişir. VBA'da öğrendiğiniz bir çağrı, C#'a neredeyse birebir taşınır. **İkincisi: nesne ömrü sizin sorumluluğunuzdadır.** COM nesneleri referans sayımıyla yaşar. Bir nesneye tutunup bırakmazsanız SolidWorks kapanmayabilir; erken bıraktığınızda ise beklenmedik hatalar alırsınız. .NET tarafında bu, otomasyon kodunun en sık gözden kaçan ayrıntısıdır. **Üçüncüsü: erken ve geç bağlama farkı.** Erken bağlama (early binding), SolidWorks'ün tip kütüphanesine (type library) derleme zamanında referans verilmesidir. C#'ta `SolidWorks.Interop.sldworks.dll` referansı eklediğinizde, VBA'da Tools → References ile SOLIDWORKS type library işaretlediğinizde erken bağlama kullanırsınız. Kazancı büyüktür: IntelliSense çalışır, yanlış yazılmış metot adı derlemede yakalanır, çağrılar daha hızlıdır. Geç bağlama (late binding) ise nesnenin tipini çalışma anında çözer — Python'daki `Dispatch("SldWorks.Application")` çağrısı budur. Esnektir, referans kurulumu gerektirmez, farklı SolidWorks sürümleriyle daha toleranslı çalışır. Bedeli, yazım hatalarının ancak çalışma anında ortaya çıkması ve IntelliSense'in olmamasıdır. Python tarafındaki pratik sonuçlarını [Python ile SolidWorks otomasyonu](https://mehmetseyrimez.com/blog/python-solidworks-otomasyonu) yazısında örneklerle gösterdim. :::callout Pratik kural Öğrenirken erken bağlamayı tercih edin. IntelliSense, nesne modelini keşfetmenin en hızlı yoludur: bir nesneye nokta koyup listeyi okumak, dokümantasyon aramaktan hızlıdır. ::: ## Nesne Hiyerarşisi: API'nin Haritası Nesne modeli bir ağaçtır ve her şey kökten başlar. Aşağıdaki şema, günlük otomasyon işlerinin yüzde doksanının geçtiği yolu gösteriyor: | Basamak | Nesne | Ne temsil eder | | --- | --- | --- | | 1 | `SldWorks` | Çalışan SolidWorks oturumunun kendisi — ağacın kökü | | 2 | `ModelDoc2` | Açık belge; parça, montaj ya da teknik resim olabilir | | 3 | `PartDoc` / `AssemblyDoc` / `DrawingDoc` | Belgenin türüne göre özelleşmiş hâli | | 3 | `Feature` | Tasarım ağacındaki her öğe: extrude, kesme, düzlem… | | 4 | `Dimension` | Bir feature'a bağlı ölçü | | 3 | `SelectionMgr` | Kullanıcının o an ekranda ne seçtiği | | 3 | `CustomPropertyManager` | Belgenin özel özellikleri (Custom Properties) | | 3 | `ModelDocExtension` | Sonradan eklenen gelişmiş işlemler | Zinciri şöyle okuyun: oturumdan belgeye, belgeden tasarım ağacına, ağaçtan tek tek özelliklere ve ölçülere. Her basamak bir alt basamağı **verir**; hiçbir basamağı atlayamazsınız. Otomasyon yazarken kaybolduğunuz anların çoğu, aslında bu zincirde bir basamağı atlamaya çalışmaktan çıkar. Her düğümün ne işe yaradığı tek cümleyle: - **`SldWorks`** — SolidWorks uygulamasının kendisi. Belge açma, kapatma, yeni belge oluşturma ve uygulama ayarları buradan yönetilir. Her kod bu nesneyi elde ederek başlar. - **`ModelDoc2`** — açık bir belge. Parça, montaj ve teknik resmin ortak davranışlarını taşır: kaydetme, yeniden oluşturma (rebuild), görünüm işlemleri, feature ağacına erişim. - **`PartDoc`** — belge parça olduğunda ulaşılan, parçaya özgü arayüz; katı gövde işlemleri ve malzeme ataması gibi konular burada. - **`AssemblyDoc`** — montaja özgü arayüz; bileşenler, mate'ler ve montaj düzeyi işlemler. - **`DrawingDoc`** — teknik resme özgü arayüz; sayfalar, görünüşler ve resim düzeyi işlemler. - **`Feature`** — tasarım ağacındaki tek bir öğe. Adı, tipi ve alt öğeleri buradan okunur; ağaçta gezinme bu nesne üzerinden yapılır. - **`Configuration`** — belgenin bir konfigürasyonu. Varyant üretiminin ve konfigürasyona özel özelliklerin merkezi. - **`Dimension`** — bir ölçü. Değerini okumak ve yazmak parametrik otomasyonun en doğrudan yoludur. - **`CustomPropertyManager`** — özel özelliklerin okunup yazıldığı yer. `ModelDoc2` üzerinden doğrudan değil, `ModelDocExtension` üzerinden alınır — hiyerarşide en çok kaybolunan nokta budur. - **`SelectionMgr`** — kullanıcının o an seçtiği nesnelerin listesi. Kaydedilen makrolarda sürekli karşınıza çıkar; bir sonraki bölümlerde neden dikkatli kullanılması gerektiğine geleceğim. Bu ağacın okunma biçimi önemli: aşağı inen her ok, "bu nesneyi elde etmek için önce üsttekine sahip olmalısın" demektir. `Dimension` nesnesine doğrudan ulaşamazsınız; önce uygulamaya, sonra belgeye, sonra feature'a ulaşırsınız. ## Kökten Aşağı: İlk Bağlantı Her otomasyon kodunun ilk iki satırı aynıdır — uygulamayı yakala, belgeyi al: Her otomasyon kodu aynı iki hamleyle başlar. Önce **kök nesneyi** yakalarsınız: çalışan SolidWorks oturumunu temsil eden `SldWorks`. Sonra bir basamak inip **aktif belgeyi** alırsınız — `ActiveDoc`. Buradaki kritik nokta, ikinci hamlenin boş dönebilmesi. Hiç belge açık değilse elinize hiçbir şey geçmez ve kodun bir sonraki satırı patlar. Bu yüzden her otomasyonun ilk kontrolü şu olmalı: **belge geldi mi?** Gelmediyse kullanıcıya "açık belge yok" deyip çık. Belge geldiyse ikinci kontrol türüdür. Belge türü işin geri kalanını belirler: parça mı, montaj mı, teknik resim mi? Parça için yazılmış bir mantığı montaja uygulamak, sahada en sık yapılan hatadır. `ActiveDoc` sonucunu kontrol etmeden devam etmek, sahada en sık gördüğüm hatadır. Belge kapalıysa kod sessizce çöker ve kullanıcı "çalışmadı" der. ## Belgeden Feature Ağacına İkinci basamak, belgeden tasarım ağacına inmektir. Feature ağacı bağlı liste gibi gezilir: ilk feature alınır, ardından sonraki istenir. İkinci basamak, belgeden tasarım ağacına inmektir. Feature ağacı bir bağlı liste gibi gezilir: belgeden **ilk feature'ı** istersiniz, sonra her feature'a "bir sonraki kardeşin kim?" diye sorarak zinciri sonuna kadar takip edersiniz. Zincir bittiğinde elinize boş bir sonuç gelir ve döngü orada durur. Pratik bir ayrıntı: her feature'ın adı, tasarım ağacında gördüğünüz adla birebir aynıdır. Bu, hata ayıklarken en çok işe yarayan bağlantı — koddaki adı ekrandaki ağaçta doğrudan arayabilirsiniz. Aynı gezinme mantığı montaj bileşenleri, teknik resim görünüşleri ve konfigürasyonlar için de geçerlidir: koleksiyonu iste, sırayla dolaş, aradığını bulunca dur. Bu on satır, nesne modelinin mantığını özetliyor: elinizde bir nesne varsa, bir alt seviyeye inmenin bir yolu da vardır. Ağaçta gezinmeyi öğrendiğinizde, "şu isimdeki feature'ı bul ve ölçüsünü değiştir" gibi işler mekanik hâle gelir. ## `I` Önekli Arayüzler: `IModelDoc2` ve `ModelDoc2` Dokümantasyonda aynı şeyin iki adını görürsünüz: `ModelDoc2` ve `IModelDoc2`. Bu bir sürüm farkı değildir. `I` öneki COM dünyasında **interface** demektir; nesnenin sözleşmesini tanımlar. `I` öneksiz ad ise o arayüzü uygulayan sınıfı (coclass) işaret eder. .NET tarafında SolidWorks interop kütüphanesi her ikisini de sunar ve pratikte `ModelDoc2` ile `IModelDoc2` birbirinin yerine kullanılabilir; C# kodunda çoğu geliştirici `I` önekli biçimi tercih eder çünkü sözleşmeye bağlanmak daha nettir. VBA'da genelde `I` öneksiz adı yazarsınız. Dokümantasyonda ise başlıklar çoğunlukla `I` önekli biçimdedir. Aynı sayfaya baktığınızı bilmek, aramada zaman kazandırır — `ModelDoc2` bulamadığınızda `IModelDoc2` aratın. ## Bir İşi API'de Nasıl Bulursunuz? Nesne modelini öğrenmenin en hızlı yolu dokümantasyonu baştan okumak değildir. Sıra şudur: **1. İşi elle yaparken kaydedin.** Macro Recorder'ı açın, otomatikleştirmek istediğiniz işlemi normal şekilde yapın, kaydı durdurun. **2. Üretilen kodda hangi arayüzün çağrıldığına bakın.** Kaydedilen kod üretime hazır değildir — seçime ve ekran durumuna bağımlı çıkar. Ama size aradığınız bilgiyi verir: bu iş **hangi nesnenin hangi metodu** üzerinden yapılıyor. **3. O arayüzü API Help'te aratın.** Artık aradığınız şeyin adını biliyorsunuz. Dokümantasyonda o metodun tam imzasını, parametrelerin anlamını ve varsa alternatiflerini okursunuz. **4. Kodu seçimden bağımsız hâle getirin.** Kaydedilen kod "ekranda seçili olanı" işler. Üretim kodu "adıyla bulduğunu" işlemelidir. Bu sıranın kazandırdığı şey şu: dokümantasyonda arama yapabilmek için önce **ne arayacağınızı** bilmeniz gerekir. Macro Recorder tam olarak bunu söyler. Yapay zeka araçları da bu keşif aşamasında hızlandırıcıdır, ancak COM yaşam döngüsü ve sürüme özgü davranışlarda kendinden emin biçimde yanılabilirler; sınırlarını [yapay zeka ile SolidWorks eklentisi yazarken](https://mehmetseyrimez.com/blog/yapay-zeka-ile-solidworks-eklentisi-yazmak) ayrıca ele aldım. ## Seçim Tabanlı Çalışmanın Tuzağı Kaydedilen her makro `SelectionMgr` üzerinden çalışır, çünkü Macro Recorder sizin tıklamalarınızı kaydeder. Kod şuna benzer: Kaydedilen her makro seçim yöneticisi (`SelectionMgr`) üzerinden çalışır, çünkü kaydedici sizin ekranda yaptığınız tıklamaları kaydeder. Bu yol iki şeyi varsayar: kullanıcının doğru şeyi seçmiş olduğunu ve seçimin hâlâ geçerli olduğunu. Seçimi gerçekten kullanmanız gerekiyorsa — örneğin makro, kullanıcının o an işaretlediği nesne üzerinde çalışacaksa — kural şudur: **seçimi varsayma, oku ve doğrula.** Önce kaç nesne seçili olduğunu sorun; sıfırsa iş orada biter ve kullanıcıya söylenir. Sonra seçilen nesnenin beklediğiniz türde olup olmadığını kontrol edin. Bir de klasik tuzak var: SolidWorks'ün seçim koleksiyonlarında dizin **1'den başlar**, sıfırdan değil. Sıfırıncı elemanı istemek, COM tarafında en sık düşülen hatalardan biri. Seçime hiç bağlı olmayan yol ise her zaman daha sağlamdır: nesneyi belgeden doğrudan isteyin. O zaman makro, kullanıcının ekranda ne yaptığından bağımsız çalışır. Bu kod çalışır, ama üç sebeple kırılgandır: - **Ekran durumuna bağımlıdır.** Kullanıcı yanlış şeyi seçtiyse, hiçbir şey seçmediyse veya seçim sırası değiştiyse davranış değişir. - **Toplu işlemde kullanılamaz.** Yüz dosyayı arka arkaya işleyen bir akışta "seçili nesne" diye bir şey yoktur. - **Sessizce yanlış çalışabilir.** Yanlış nesne seçiliyken kod hata vermez; yanlış nesneyi işler. Bu, hata vermekten daha kötüdür. Sağlam yaklaşım, nesneye **kimliğiyle** ulaşmaktır: feature'ı adıyla bulmak, konfigürasyonu adıyla almak, özel özelliği anahtarıyla okumak. Seçim yalnızca kullanıcının bilinçli olarak bir şey işaret ettiği etkileşimli senaryolarda kullanılmalı; toplu ve arka plan işlerinde hiç kullanılmamalıdır. ## Sürüm Bağımlılığı: Hangi Dokümantasyona Bakmalı? SolidWorks API sürümle birlikte gelişir. Yeni arayüzler eklenir, mevcut metotların yeni numaralı sürümleri çıkar — `Save3`, `GetSelectedObject6`, `Add3` gibi sondaki rakamlar tam olarak bunun izidir. Eski sürümler genelde çalışmaya devam eder, ancak yeni yetenekler yalnızca yeni arayüzlerde bulunur. Üç pratik kural: - **Hedef sürümün dokümantasyonuna bakın.** API Help sürüm sürüm yayınlanır. 2021 kurulumu için 2025 dokümantasyonuna bakmak, olmayan bir metodu aramanıza yol açar. - **En düşük ortak sürümü belirleyin.** Kodunuz beş kişinin makinesinde çalışacaksa, aralarındaki en eski SolidWorks sürümü hedefinizdir. - **Numaralı metotlarda en yüksek desteklenen sürümü seçin.** Aynı işi yapan `Save` ve `Save3` varsa, hedef sürümünüzün desteklediği en yenisi genelde daha fazla kontrol sunar. API'nin kendisi ayrı bir ürün olarak satılmaz; SolidWorks lisansının parçasıdır. Ancak erişebildiğiniz yetenekler kullandığınız sürüme ve lisans seviyesine göre değişir. ## SolidWorks API Öğrenme Yol Haritası Sıralamayı önemsiyorum, çünkü çoğu kişi üçüncü adımdan başlayıp tıkanıyor: **1. Macro Recorder ile keşif.** Beş farklı işi kaydedin ve üretilen kodu okuyun. Amaç kod yazmak değil, hangi işin hangi arayüze düştüğünü görmek. **2. Kökten belgeye zinciri ezberleyin.** `SldWorks` → `ModelDoc2` → belge türü dalı. Bu üç basamağı düşünmeden yazabilir hâle geldiğinizde, geri kalanı keşif işidir. **3. Kaydedilen bir makroyu seçimden kurtarın.** Elinizdeki kaydı alın, `SelectionMgr` bağımlılığını sökün, nesneleri adıyla bulun. Nesne modelini gerçekten burada öğrenirsiniz. **4. Özel özellikler ve konfigürasyonlarla çalışın.** `CustomPropertyManager` ve `Configuration`, geometri riski olmadan gerçek değer üreten alanlardır. Toplu özellik doldurma, ilk üretim otomasyonunuz için iyi bir adaydır. **5. Ölçü ve feature değiştirmeye geçin.** Geometriye dokunmak en son adımdır, çünkü hata maliyeti en yüksek burasıdır. Parametrik bir modeli koddan sürmek, bu beş adımın toplamıdır. Bu sıranın uygulanmış hâlini [ParametriX projesinde](https://mehmetseyrimez.com/projeler/parametrix-2d-3d) görebilirsiniz: parametrik model kurallarıyla API otomasyonunun birleştiği yer tam olarak beşinci adımdır. :::illustration left document-analysis | Dokümantasyonu okumak: arayüz adı, sürüm, dönüş değeri ::: ## Sık Sorulan Sorular **SolidWorks API nedir, kısaca?** SOLIDWORKS için bir COM programlama arayüzüdür. VB, VBA, VB.NET, C++, C# veya makro dosyalarından çağrılabilen yüzlerce fonksiyon içerir ve SolidWorks'ün nesne modeline dışarıdan erişim sağlar. **`ModelDoc2` nedir, neden her yerde geçiyor?** Açık bir belgeyi temsil eden arayüzdür. Parça, montaj ve teknik resmin ortak davranışları burada toplandığı için hemen her otomasyon kodu bu nesneden geçer. **`IModelDoc2` ile `ModelDoc2` arasındaki fark ne?** `I` öneki COM arayüzünü, öneksiz ad ise onu uygulayan sınıfı gösterir. Pratikte aynı yeteneklere erişirsiniz; dokümantasyonda arama yaparken her iki biçimi de deneyin. **API'yi öğrenmeye nereden başlamalıyım?** Macro Recorder'dan. Bir işi kaydedip üretilen kodda hangi arayüzün çağrıldığına bakmak, dokümantasyonu baştan okumaktan çok daha hızlı ilerletir. Hangi uygulama biçimiyle (makro, eklenti, bağımsız uygulama) çalışacağınıza ise [makro ve API rehberindeki](https://mehmetseyrimez.com/blog/solidworks-makro-api-farki) karar modeliyle bakabilirsiniz. **Hangi dili seçmeliyim?** Nesne modeli her dilde aynı olduğu için ilk aşamada dil ikincil bir karardır. VBA en hızlı başlangıcı verir, C#/.NET kalıcı çözümlerde tercih edilir, Python hızlı prototipleme için elverişlidir — COM üzerinden API'ye nasıl bağlanacağınızı [SolidWorks Python otomasyonu](https://mehmetseyrimez.com/blog/python-solidworks-otomasyonu) yazısında adım adım anlattım. **API ücretli mi, ayrıca satın alınıyor mu?** API, SolidWorks lisansının parçasıdır; ayrı bir ürün olarak satılmaz. Erişilebilen yetenekler kullandığınız sürüme göre değişir. **Kaydedilen makro neden üretimde bozuluyor?** Çünkü kaydedilen kod seçime ve ekran durumuna bağımlıdır. `SelectionMgr` bağımlılığı sökülüp nesneler adıyla bulunmadıkça, kod ilk farklı senaryoda ya durur ya da yanlış nesneyi işler. ## Sonuç SolidWorks API'yi öğrenmek, metot listesi ezberlemek değil, bir haritayı içselleştirmektir. `SldWorks` → `ModelDoc2` → belge türü → `Feature` / `Configuration` / `CustomPropertyManager` zincirini düşünmeden yazabildiğinizde, bilmediğiniz her iş yalnızca bir arama sorusuna dönüşür. Pratik özet: - Her şey kökten başlar; ara basamağı atlayamazsınız - COM sayesinde nesne modeli dilden bağımsızdır — öğrendiğiniz bilgi taşınır - Erken bağlama öğrenirken IntelliSense verir, geç bağlama esneklik verir - Bir işi bulmanın en hızlı yolu Macro Recorder → üretilen kod → API Help sırasıdır - Seçim tabanlı kod kırılgandır; nesneye kimliğiyle ulaşın - Hedeflediğiniz SolidWorks sürümünün dokümantasyonuna bakın Firmanızda tekrar eden SolidWorks adımlarını koda taşımayı düşünüyor ve nereden başlayacağınıza karar veremiyorsanız, süreci birlikte değerlendirebiliriz — [iletişim bölümünden](https://mehmetseyrimez.com/#iletisim) yazabilirsiniz. --- # SolidWorks Add-in Geliştirme: C# ile Eklenti Yazmaya Giriş source: https://mehmetseyrimez.com/blog/solidworks-add-in-gelistirme type: article published: 2026-08-24 updated: 2026-08-26 category: Otomasyon Atölyesi tags: solidworks, add-in, csharp, dotnet, api, otomasyon author: Mehmet Seyrimez reading_minutes: 12 > Eklenti kararı verildikten sonrası: ISwAddin yaşam döngüsü, COM kaydı, CommandManager ve TaskPane, olay yakalama tuzakları, modüler yapı ve dağıtım. Bir SolidWorks eklentisi (add-in) yazmanın zor tarafı API çağrıları değildir. Zor tarafı, kodunuzun artık **kendi ömrüne sahip olmamasıdır**: eklenti SolidWorks ile birlikte açılır, oturum boyunca bellekte kalır, olayları dinler ve SolidWorks kapanırken düzgün çekilmek zorundadır. Makroda hiç düşünmediğiniz üç şey — kayıt (registration), yaşam döngüsü ve nesne sahipliği — eklentide ilk gün karşınıza çıkar. Bu yazı "makro mu eklenti mi" sorusunu tartışmıyor; o karar verilmiş kabul ediliyor. Buradan sonrası **nasıl** sorusunun cevabı: eklenti SolidWorks'e nasıl tanıtılır, arayüzü nereye kurulur, olaylara nasıl bağlanılır ve hangi hatalar sahada üç hafta sonra ortaya çıkar. Kararın kendisini hâlâ veriyorsanız, [makro, API ve eklenti arasındaki ilişkiyi ayrıntılandırdığım yazıya](https://mehmetseyrimez.com/blog/solidworks-makro-api-farki) dönmenizi öneririm. Fikri hızlıca doğrulamak için önce [SolidWorks Python otomasyonu](https://mehmetseyrimez.com/blog/python-solidworks-otomasyonu) ile COM bağlantısını test etmek de işe yarar — eklenti kararından önce gelen adım. :::illustration full addin-plugin | Eklenti katmanları: COM kaydı, yaşam döngüsü, arayüz, olaylar ve iş mantığı ::: ## Eklenti nedir, mimari farkı nerede? Eklenti, SolidWorks süreci **içinde** çalışan bir .NET sınıf kütüphanesidir (`.dll`). Makro dış bir dosya olarak çağrılıp biter; bağımsız uygulama SolidWorks'ü dışarıdan sürer ve kendi penceresinde yaşar. Eklenti ise ikisinin arasında değil, tamamen başka bir yerde durur: SolidWorks onu başlangıçta yükler, arayüzüne yerleşmesine izin verir ve kapanana kadar bellekte tutar. Kabiliyet farkı değil, **ömür ve sahiplik farkı** budur — hangi belirtilerin bu geçişi gerektirdiğini [makro ile eklenti karşılaştırmasında](https://mehmetseyrimez.com/blog/solidworks-makro-api-farki) tablo halinde ele almıştım. ## ISwAddin: yaşam döngüsünün iki ucu Bir sınıfın SolidWorks tarafından eklenti olarak tanınması için `ISwAddin` arayüzünü uygulaması gerekir. Bu arayüzün iki üyesi vardır ve eklentinin tüm hikâyesi bu ikisinin arasında geçer: - **`ConnectToSW`** — SolidWorks eklentiyi yüklediğinde çağrılır. Uygulama nesnesi ve bir *cookie* (eklenti kimliği) verilir. Menüler, sekmeler ve olay abonelikleri burada kurulur. - **`DisconnectFromSW`** — SolidWorks kapanırken veya kullanıcı eklentiyi devre dışı bıraktığında çağrılır. `ConnectToSW` içinde kurulan **her şey burada geri alınır**: komut grupları kaldırılır, olay abonelikleri sökülür, tutulan referanslar bırakılır. Bağlanma anında sırayla üç şey yapılır. Önce SolidWorks'ün size verdiği uygulama nesnesi ve **çerez (cookie)** değeri saklanır — çerez, eklentinizin kimliğidir ve buton geri çağrılarının size ulaşması için şarttır. Ardından bu çerezle birlikte kendinizi geri çağrı hedefi olarak kaydettirirsiniz; bu adımı atlarsanız butonlarınız görünür ama tıklandığında hiçbir şey olmaz — sahada en çok vakit kaybettiren sessiz hatalardan biri. Sonra komut arayüzünü kurarsınız: CommandManager sekmesi ve butonlar. En sonda olay aboneliklerini bağlarsınız. Ve bu fonksiyonun dönüş değeri önemli: başarılı bir bağlanma olumlu bir sonuç döndürmelidir. Olumsuz dönerseniz SolidWorks eklentiyi hiç yüklemez — üstelik bunu kullanıcıya açıkça söylemez. İki ayrıntı sık atlanır. Birincisi, `ConnectToSW` içinden `false` dönmek eklentiyi sessizce yüklenmemiş hale getirir; hatayı yutarsanız kullanıcı yalnızca "sekme gelmedi" der. İkincisi, cookie'yi saklamazsanız buton geri çağrıları (callback) hiçbir zaman size ulaşmaz. :::callout Simetri kuralı `ConnectToSW` içinde yaptığınız her işlemin `DisconnectFromSW` içinde bir karşılığı olmalı. Bu simetriyi bozan eklentiler, SolidWorks kapanırken takılan ya da arka planda süreç bırakan eklentilerdir. ::: ## COM kaydı: eklenti SolidWorks'e nasıl tanıtılır? SolidWorks API'si COM tabanlıdır; eklentiniz .NET ile yazılmış olsa bile SolidWorks onu bir COM bileşeni olarak görür. Bu yüzden derlenmiş `.dll` dosyasını bir klasöre koymak yetmez — iki ayrı tanıtım gerekir: **1. COM kaydı.** Sınıf `ComVisible` olarak işaretlenir ve sabit bir `Guid` alır. Kayıt işlemi .NET Framework ile gelen `regasm` aracıyla yapılır; derlemeyi GAC'a koymuyorsanız `/codebase` anahtarı gerekir, çünkü SolidWorks DLL'i diskte nerede bulacağını bilmelidir. **2. SolidWorks kaydı.** SolidWorks, yükleyeceği eklentileri kendi registry dalında tutar. Uygulama düzeyindeki eklenti listesi `HKEY_LOCAL_MACHINE` altında, kullanıcının o eklentiyi açık mı kapalı mı bıraktığı bilgisi ise `HKEY_CURRENT_USER` altında saklanır. Bu ayrım pratikte şu anlama gelir: **eklentiyi kurmak, kullanıcıda otomatik açık gelmesini garanti etmez.** Anahtar adları ve tam yollar SolidWorks sürümüne göre değişebilir; kurulum betiğinizi yazmadan önce hedeflediğiniz sürümün resmî dokümantasyonundan doğrulayın. Bu ikinci adımı elle yapmak yerine `ComRegisterFunction` ve `ComUnregisterFunction` ile işaretlenmiş metotlara bırakmak yaygın yaklaşımdır: `regasm` çalıştığında bu metotlar tetiklenir ve registry girdilerini kod yazar. Böylece kurulum ve kaldırma tek yerden yönetilir. `HKEY_LOCAL_MACHINE`'e yazmak yönetici hakkı gerektirir. Bu, dağıtım bölümünde tekrar karşımıza çıkacak. ## Arayüz katmanı: hangisi ne zaman? Eklentinin görünen yüzü üç ana bileşene dayanır. Seçim estetik değil, **etkileşimin süresine** göre yapılır. | Bileşen | Ne zaman | Tipik kullanım | |---|---|---| | `CommandManager` sekmesi | Kullanıcı bir eylemi tetikleyecek | Toplu dışa aktarma, kontrol çalıştırma, araç butonları | | `TaskPane` | Bilgi oturum boyunca açık kalmalı | Proje ağacı, arama paneli, PDM/ERP bağlantı durumu | | `PropertyManagerPage` | Seçim ve parametre alınacak | Parametrik üretim formu, özellik düzenleme, adım adım sihirbaz | **CommandManager** eklentinin kimliğidir. Kendi sekmenizi ve buton grubunuzu ekler, her butona bir geri çağrı metodu ve isteğe bağlı olarak bir "etkin mi" metodu bağlarsınız. İkincisi önemlidir: aktif belge bir teknik resim değilken teknik resim butonu gri görünmelidir. Bu küçük ayrıntı, kullanıcının eklentiye güvenip güvenmemesini belirler. **TaskPane**, SolidWorks'ün sağ panelinde yaşayan bir görünümdür. İçine kendi WinForms/WPF kontrolünüzü yerleştirirsiniz. Bir işi başlatmak için değil, **durumu göstermek** için uygundur. **PropertyManagerPage**, SolidWorks'ün kendi komutlarının kullandığı sol paneldir. Kendi diyalog pencerenizi açmak yerine bunu kullanmanın iki avantajı vardır: kullanıcı zaten bu etkileşim biçimini biliyor ve model üzerinden seçim yapmaya (yüzey, kenar, bileşen) doğal olarak izin verir. Sayfa oluşturma ve olaylarını karşılayan işleyici (handler) arayüzünün sürüm numaralı birden fazla varyantı vardır; hangi sürümü uygulayacağınızı hedef SolidWorks sürümünün API dokümantasyonundan seçin. Pratik bir sıralama: önce `CommandManager` ile tek buton, sonra iş büyüdükçe `PropertyManagerPage`, gerçekten sürekli görünür bir şey gerekiyorsa `TaskPane`. Ters sırada başlamak, kullanılmayan arayüz üretir. ## Olay yakalama ve en pahalı hata Eklentiyi makrodan ayıran asıl yetenek olay yakalamadır (event handling): belge açıldığında kontrol etmek, kaydetmeden önce doğrulamak, aktif belge değiştiğinde arayüzü güncellemek. Olaylar iki seviyede gelir. **Uygulama seviyesindeki** olaylar `SldWorks` nesnesinden gelir — belge açılması, aktif belgenin değişmesi gibi. **Belge seviyesindeki** olaylar ise belge türüne özel arayüzlerden gelir: parça, montaj ve teknik resim için ayrı olay kümeleri vardır. Yani "kaydetmeden önce doğrula" davranışını üç belge türü için de istiyorsanız, üç ayrı aboneliği yönetmeniz gerekir. Olaylar iki seviyede yaşar. **Uygulama seviyesindeki** olaylar SolidWorks'ün kendisiyle ilgilidir: yeni bir belge açılması, aktif belgenin değişmesi. **Belge seviyesindeki** olaylar ise tek bir belgeye aittir: kaydedilmeden önce, yeniden kurulduktan sonra, bir özellik değiştiğinde. Buradaki en sinsi tuzak şu: bir belge açıldığında o belgeye özel bir olay dinleyicisi oluşturursunuz — ve o nesneye başka hiçbir yerde referans tutmazsanız, .NET çöp toplayıcısı onu bir süre sonra temizler. Olaylar sessizce gelmemeye başlar. Hata yoktur, mesaj yoktur; sadece eklentiniz bir gün "bazen çalışmıyor" olur. Çözüm basit ama unutulması kolay: belge işleyicilerini bir sözlükte (dosya adına göre) **tutun**, belge kapanınca da o kayıttan çıkarın. Bu tek alışkanlık, eklenti geliştirmenin en zor teşhis edilen problemini baştan çözer. Buradaki `_handlers` sözlüğü süs değil. **COM olaylarında en sık yapılan hata budur:** olay aboneliğini kuran nesneye başka hiçbir yerden güçlü referans tutulmazsa, çöp toplayıcı (garbage collector) o nesneyi bir süre sonra toplar ve olaylar sessizce gelmemeye başlar. Hata mesajı yoktur, istisna (exception) fırlamaz, derleme uyarı vermez. Eklenti dakikalarca doğru çalışır, sonra "bazen çalışmıyor" olur. Bu yüzden kural nettir: **her olay işleyici nesnesi, ömrü boyunca eklenti sınıfının tuttuğu bir koleksiyonda yaşar.** Belge kapandığında o girdi koleksiyondan çıkarılır ve abonelik sökülür. `DisconnectFromSW` içinde koleksiyon boşaltılır. İkinci sık hata, olay işleyicisinin içinde uzun iş yapmaktır. Olay geri çağrıları SolidWorks'ün kendi akışının ortasında çalışır; orada dakikalarca süren bir işlem başlatmak arayüzü kilitler ve kullanıcının SolidWorks'ün çöktüğünü sanmasına yol açar. ## Proje yapısı: API erişimini iş mantığından ayırın Eklenti projelerinin bozulma biçimi hep aynıdır: buton geri çağrısının içine hem SolidWorks API çağrıları, hem iş kuralları, hem de dosya yazma işlemleri girer. İlk sürümde çalışır, üçüncü kuralda okunamaz hale gelir. Ayrım basit bir soruyla yapılır: *bu kod SolidWorks'ü bilmek zorunda mı?* - **Eklenti katmanı** — `ISwAddin`, komut kaydı, arayüz. SolidWorks'ü bilir, kural bilmez. - **API erişim katmanı** — belgeden özellik okuma, dışa aktarma, geometri sorgulama. SolidWorks'ü bilir, kural bilmez. - **İş mantığı katmanı** — adlandırma kuralları, doğrulama, hangi çıktının ne zaman üretileceği. Kuralı bilir, SolidWorks'ü **hiç bilmez**. Üçüncü katmanın SolidWorks'ü bilmemesi teorik bir zarafet değil, doğrudan test edilebilirlik demektir: "revizyon numarası bu formata uyuyor mu" sorusunu SolidWorks açmadan, saniyeler içinde test edebilirsiniz. Kuralların çoğu hatası da orada yaşar. Bu ayrımın genel gerekçesini ve nasıl kurulacağını [modüler yazılım mimarisi](https://mehmetseyrimez.com/blog/moduler-yazilim-mimarisi) yazısında ayrıca anlattım; eklenti tarafında en çok işe yarayan yanı, arayüzü değiştirmeden kuralı değiştirebilmektir. ## Hata yönetimi ve loglama neden zorunlu? Makroda hata yönetimi opsiyoneldir çünkü hatayı yapan kişi ile onu gören kişi aynıdır: makro patlar, siz görürsünüz, düzeltirsiniz. Eklentide bu zincir kopar. Kodunuz başka bir bilgisayarda, başka bir SolidWorks sürümünde, sizin hiç görmediğiniz bir montaj üzerinde çalışır ve size ulaşan geri bildirim tek cümledir: "çalışmadı". Log yoksa geriye kalan tahmin oyunudur. Üç kural yeterli bir başlangıç sağlar: 1. **Olay geri çağrılarından ve buton geri çağrılarından dışarı istisna sızdırmayın.** COM sınırının ötesine geçen bir istisna, kullanıcıya anlamsız bir hata olarak görünür ya da daha kötüsü SolidWorks'ü kararsız bırakır. Her giriş noktası `try/catch` ile sarılır, yakalanan hata loglanır. 2. **Dönüş değerlerini kontrol edin.** SolidWorks API'sinin birçok metodu hata fırlatmaz; `null` veya `false` döner. Kontrol edilmeyen bir dönüş, sessizce eksik çıktı üretir — otomasyonun en pahalı hata türü budur ve [yapay zeka ile üretilen eklenti kodunda](https://mehmetseyrimez.com/blog/yapay-zeka-ile-solidworks-eklentisi-yazmak) en sık atlanan kontrol de tam olarak budur. 3. **Kullanıcı başına dosyaya yazın.** Log dosyası, kullanıcının yazma hakkı olan bir dizinde tutulmalı ve sürüm numarası, SolidWorks sürümü, belge adı ve zaman damgası içermelidir. Buton geri çağrılarının iskeleti her zaman aynı olmalı ve üç kuralı taşımalı. **Bir:** aktif belgeyi al ve yokluğunu kontrol et. Belge yoksa kullanıcıya anlaşılır bir şey söyle ve çık. **İki:** asıl işi geri çağrının içine yazma. Geri çağrı yalnızca bir tetikleyicidir; iş mantığı ayrı bir serviste dursun. Bu ayrım, eklentinizin test edilebilir kalmasının tek yolu. **Üç:** her şeyi bir hata yakalayıcıyla sar. Bu, eklenti geliştirmenin en kritik kuralı: **hiçbir istisna COM sınırını geçmemeli.** Geri çağrıdan dışarı sızan bir hata, SolidWorks'ün kendisini kararsız hale getirebilir ya da doğrudan çökertir. Hatayı yakalayın, günlüğe yazın, kullanıcıya sade bir mesaj gösterin — ve akışı orada bitirin. ## Dağıtım, sürüm ve uyumluluk Eklentiyi yazmak işin yarısı; on kişinin bilgisayarında **aynı sürümün** çalıştığından emin olmak diğer yarısı. **Kurulum paketi.** Dosya kopyalama yetmez, çünkü COM kaydı ve registry girdileri gerekiyor ve bunlar yönetici hakkı isteyebiliyor. Bir MSI ya da eşdeğeri kurulum paketi, kurulum ve kaldırmayı tek adıma indirir. Kaldırma senaryosunu baştan test edin: geride kalan registry girdisi, SolidWorks açılışında var olmayan bir DLL'i yüklemeye çalışmasına yol açar. **Sürüm yönetimi.** Eklentinin sürüm numarasını hem derlemeye gömün hem de arayüzde görünür bir yerde gösterin (About butonu ya da TaskPane alt bilgisi). Log satırlarına da yazın. "Hangi sürümü kullanıyorsunuz" sorusunun cevabını kullanıcıya sormak zorunda kalmamak, destek süresini belirgin biçimde kısaltır. `Guid` değerini sürümler arasında **sabit tutun** — değiştirmek, kullanıcının eklentiyi tekrar elle etkinleştirmesini gerektirir. **Mimari ve çalışma zamanı uyumu.** Eklenti SolidWorks süreci içinde yüklendiği için işlemci mimarisi uyuşmak zorundadır; güncel SolidWorks sürümleri 64 bit çalışır ve 32 bit derlenmiş bir eklenti yüklenmez. Aynı şekilde eklentinizin hedeflediği .NET çalışma zamanı da SolidWorks'ün desteklediği aralıkta olmalıdır. Desteklenen .NET sürümü SolidWorks sürümüne göre değişir; hedef sürümü seçmeden önce resmî sistem gereksinimlerinden doğrulayın. **Geriye dönük uyum.** API metotlarının sürüm numaralı varyantları vardır ve eski adlar zamanla kullanımdan kaldırılabilir. Birden fazla SolidWorks sürümünü desteklemeniz gerekiyorsa, desteklediğiniz en eski sürümün interop derlemesine karşı derlemek yaygın bir yaklaşımdır — ama her sürümde test edilmeden bu bir varsayımdır. ## Sık yapılan hatalar 1. **Olay işleyicilerine güçlü referans tutmamak.** En sinsi hata. Olaylar bir süre çalışır, sonra sessizce kesilir. Belirti: "bazen çalışıyor bazen çalışmıyor". 2. **`DisconnectFromSW` içini boş bırakmak.** Komut grupları kaldırılmaz, abonelikler sökülmez, referanslar bırakılmaz. Sonuç: SolidWorks kapanırken takılır veya arka planda süreç kalır. 3. **COM sınırını geçen istisnalar.** Geri çağrılardan dışarı sızan bir istisna, kullanıcıya anlamsız görünür ve oturumu kararsız bırakabilir. 4. **Dönüş değerlerini kontrol etmemek.** Fırlatmayan ama `null`/`false` dönen çağrılar, sessizce eksik çıktı üretir. 5. **Her şeyi buton geri çağrısına yazmak.** İş mantığı arayüz koduna karışınca test imkânsızlaşır, kural değişikliği her seferinde arayüze dokunmayı gerektirir. 6. **Uzun işi olay içinde çalıştırmak.** Arayüz kilitlenir, kullanıcı SolidWorks'ün çöktüğünü sanır. 7. **Sürüm bilgisini kaydetmemek.** Sahadan gelen hata raporu, hangi sürüme ait olduğu bilinmediğinde işe yaramaz. 8. **`Guid`'i sürümler arasında değiştirmek.** Kullanıcı tarafında eklenti "kaybolur", yeniden etkinleştirilmesi gerekir. :::illustration left version-control | Eklenti canlı bir üründür: sürüm, dağıtım ve bakım düzeni ister ::: ## Sık Sorulan Sorular **SolidWorks eklentisi hangi dillerle yazılır?** En yaygın olarak C# ve VB.NET; C++ ile de yazılabilir. Ortak koşul, bileşenin COM üzerinden SolidWorks tarafından yüklenebilmesidir. **Eklenti geliştirmek için hangi lisans gerekir?** API, SolidWorks lisansının parçasıdır; eklenti geliştirmek için ayrı bir ürün satın alınmaz. Erişebildiğiniz yetenekler kullandığınız sürüme göre değişir. **Eklentim neden eklenti listesinde görünmüyor?** Genellikle üç nedenden biri: COM kaydı yapılmamıştır (`regasm`, gerekiyorsa `/codebase` ile), SolidWorks registry girdisi eksiktir, ya da mimari uyuşmuyordur (32/64 bit veya desteklenmeyen .NET sürümü). **Olaylarım bir süre sonra neden gelmiyor?** Neredeyse her zaman olay işleyici nesnesine güçlü referans tutulmamasındandır; çöp toplayıcı nesneyi topladığında abonelik sessizce düşer. İşleyicileri eklenti sınıfında bir koleksiyonda saklayın. **Kendi diyalog penceremi mi açmalıyım, PropertyManagerPage mi kullanmalıyım?** Model üzerinden seçim alınacaksa veya akış SolidWorks komutları gibi hissettirilecekse `PropertyManagerPage`. Bağımsız, karmaşık ve nadiren açılan bir yapılandırma ekranı için ayrı pencere de makuldür. **Mevcut VBA makromu doğrudan C# eklentiye çevirebilir miyim?** Çağrıların çoğu bire bir karşılık bulur, ama doğrudan çeviri genellikle yeterli olmaz: makro tek seferlik bir akış varsayar, eklenti ise durum, yaşam döngüsü ve hata yönetimi ister. Çeviriyi başlangıç noktası olarak kullanın, mimariyi baştan kurun. **Birden fazla SolidWorks sürümünü tek eklentiyle destekleyebilir miyim?** Genellikle evet — yaygın yaklaşım desteklenen en eski sürümün interop derlemesine karşı derlemektir. Ancak sürüme bağlı davranış farkları olabileceği için her hedef sürümde test edilmesi gerekir. ## Sonuç Eklenti geliştirmede zorlanılan yer API'nin genişliği değil, **eklentinin SolidWorks ile aynı ömrü paylaşıyor olmasıdır.** Bu yüzden ilk günden itibaren üç şeyi doğru kurmak, sonradan gelen her şeyi kolaylaştırır: - `ConnectToSW` ile `DisconnectFromSW` arasında **tam simetri** - Olay işleyicilerine **güçlü referans**, uzun işe olay içinde **yer yok** - İş mantığı, SolidWorks'ü **hiç bilmeyen** ayrı bir katmanda Arayüz bileşenini etkileşimin süresine göre seçin, hatayı loglayın, sürümü görünür kılın ve kurulumu paketleyin. Gerisi büyük ölçüde tekrar eden iskelet koddur. Bu mimarinin makro seviyesinden nasıl büyüdüğünü görmek isterseniz [SolidWorks CAD otomasyonu vaka çalışmasına](https://mehmetseyrimez.com/projeler/solidworks-cad-otomasyonu) bakabilirsiniz. Kendi sürecinizde eklenti eşiğine gelip gelmediğinizi birlikte değerlendirmek isterseniz [iletişim bölümünden](https://mehmetseyrimez.com/#iletisim) yazabilirsiniz. --- # Otomasyon Projesine Nasıl Başlanır? Dört Adımlık Yöntem source: https://mehmetseyrimez.com/blog/otomasyon-projesine-nasil-baslanir type: article published: 2026-08-22 updated: 2026-08-26 category: CAD Otomasyon tags: otomasyon, cad-otomasyon, surec, solidworks, proje-yonetimi author: Mehmet Seyrimez reading_minutes: 9 > CAD otomasyon projesinin ilk haftası, hangi aracı seçtiğinizle değil neyi ölçtüğünüzle belirlenir. Problemi ölçmekten sahada büyütmeye dört adım. Bir CAD otomasyon projesine başlamanın doğru sırası şudur: **önce hangi işin ne sıklıkla tekrarlandığını ölçün, sonra otomasyonun nerede biteceğini yazılı olarak sınırlayın, ardından sonucu tartışmaya kapalı küçük bir pilot çalıştırın ve kapsamı yalnızca ölçülmüş kayıplara karşılık gelecek şekilde büyütün.** Araç seçimi — LISP mi, C# mı, Python mı — bu dört adımın sonunda gelir ve genellikle o noktada kendiliğinden bellidir. Otomasyon projelerinin çoğu, yanlış soruyla başladığı için başarısız olur. Soru genellikle şudur: *"Bunu hangi araçla otomatikleştirebiliriz?"* Oysa bu soru, cevaplanması gereken üçün sonuncusudur. Aşağıdaki dört adım, kendi projelerimde izlediğim sırayı anlatıyor. Sıra tesadüfi değil: her adım bir sonrakinin yanlış yöne gitmesini engellemek için var. :::illustration full process-steps | Otomasyon projesinin dört adımı: ölç, sınırla, pilotla, büyüt ::: ## 01 — Problemi ölç Araçtan değil problemden başlarım. İlk yapılan iş kod yazmak değil, iki şeyi ölçmektir: - **Hangi iş, ne sıklıkla tekrarlanıyor?** - **Mevcut süreçte zaman tam olarak nerede kayboluyor?** Bu iki soru kulağa basit gelir ama cevapları çoğu zaman sürprizlidir. Bir ekip "modelleme çok uzun sürüyor" der; ölçtüğünüzde asıl kaybın modellemede değil, teknik resim çıktılarının elle düzenlenmesinde olduğu görülür. Yanlış yeri otomatikleştiren bir proje, teknik olarak kusursuz çalışsa bile hissedilir bir kazanç üretmez. ### İki haftalık ölçüm nasıl tutulur Ölçüm karmaşık olmak zorunda değil. Bir tablo, üç sütun ve iki hafta yeter: | Alan | Örnek | Neden gerekli | | --- | --- | --- | | İşin adı | "Teklif resmi antet doldurma" | Kalemi tekilleştirir | | Tekrar sayısı | 14 kez / hafta | Getirinin çarpanı budur | | Ortalama süre | 9 dk | Getirinin tabanı budur | | Kim yapıyor | Tasarım — 2 kişi | Kazancın kime döneceği | | Hata payı | 2 kez düzeltme | Doğrulama yükünün habercisi | Önemli olan hassasiyet değil, **doğru kalemi bulmak.** Dakikayı yuvarlamanız sonucu değiştirmez; yanlış işi seçmeniz her şeyi değiştirir. > Otomasyonun getirisi, kazanılan süre çarpı tekrar sayısıdır. Tekrar sayısı düşük bir işi mükemmel otomatikleştirmek, yüksek tekrarlı bir işi kabaca otomatikleştirmekten daha az değer üretir. ### Ölçümü bozan üç alışkanlık **Hafızadan tahmin etmek.** "Herhalde günde bir saat gidiyor" cümlesi ölçüm değildir. Kayıt tutulduğunda çoğu tahminin iki katı ya da yarısı çıkar. **En kötü günü örneklemek.** İnsanlar en can sıkıcı işi hatırlar, en çok zaman alanı değil. İki hafta boyunca sıradan günleri kaydetmek bu sapmayı düzeltir. **Sadece "yapma" süresini saymak.** İşin başlamasını bekleyen süre — dosyayı bulmak, doğru revizyonu teyit etmek, birinden bilgi beklemek — çoğu zaman asıl işten uzundur. Otomasyon bu bekleme süresine dokunmuyorsa, kazanç kâğıt üstünde kalır. :::illustration right speed-test | Ölçüm: hangi iş, kaç kez, ne kadar süre ::: ## 02 — Otomasyonun sınırını çiz İkinci adım, birinci adımdan çıkan listeye bakıp şu ayrımı **açıkça** yapmaktır: neyin yazılıma, neyin insana kalacağı. Bu adım atlanırsa proje şu iki şekilden biriyle bozulur: 1. **Kapsam sürekli büyür.** Her istisna yazılıma eklenir, sistem kural yığınına döner ve bakımı imkânsızlaşır. 2. **Kimse güvenmez.** Nerede devreye girip nerede çıkacağı belirsiz olan bir otomasyonun çıktısı, kullanıcı tarafından her seferinde baştan kontrol edilir — yani kazanılan süre geri verilir. Sınırı çizerken işe yarayan pratik bir ayrım şudur: **kural haline getirilebilen iş yazılıma, yargı gerektiren iş insana.** Bir profilin uzunluğunu parametreden hesaplamak kuraldır. Müşteri özel bir talep gönderdiğinde bunun standart üretim akışına uyup uymadığına karar vermek yargıdır. ### Sınırı yazıya dökmek Sınırın nerede olduğu kadar, **nerede olduğunun yazılı olması** da önemlidir. Tek sayfalık bir belge yeter; içinde şu dört başlık bulunsun: - **Otomasyon şunu yapar:** girdi listesi ve üretilen çıktı listesi, tek tek sayılmış. - **Otomasyon şunu yapmaz:** özellikle sık istenecek ama kapsam dışı bırakılan işler. - **Şu durumda durur ve insana devreder:** eksik parametre, aralık dışı ölçü, tanınmayan ürün ailesi. - **Bu belgeyi kim değiştirebilir:** kapsamı büyütme kararının sahibi. Sonradan gelen her istisna talebi bu belgeye karşı değerlendirilir. Belge yoksa, her talep haklı görünür ve kapsam sessizce büyür. :::illustration left guidelines | Sınır: neyin yazılıma, neyin insana kalacağı ::: ### İstisnayı kural yapmayın Sahada en sık gördüğüm bozulma şu: bir müşteri için yapılan tek seferlik istisna, kural motoruna `if` olarak giriyor. Altı ay sonra kural motorunda yirmi tane böyle `if` oluyor ve hiçbiri neden orada olduğunu söylemiyor. Pratik önlem: istisnaları koda değil **veriye** koyun. Ürün ailesine bağlı bir yapılandırma tablosu, aynı işi yapar ama okunabilir kalır ve kaldırılması kolaydır. ## 03 — Doğrulanabilir bir pilotla başla Üçüncü adımda kod yazmaya başlanır — ama tamamı değil. Küçük ve **sonucu ölçülebilir** bir parça seçilir. Pilotun iyi seçilmiş olduğunun ölçütü şudur: bittiğinde, işe yarayıp yaramadığı tartışmaya açık olmamalı. "Daha iyi hissettiriyor" bir sonuç değildir. "Aynı çerçevenin hazırlanması 40 dakikadan 6 dakikaya indi" bir sonuçtur. Pilot ayrıca bir şeyi daha yapar: **varsayımları erken kırar.** Otomasyon projelerinde en pahalı hatalar, altı ay kod yazdıktan sonra üretim verisinin sandığınız formatta olmadığını fark etmektir. Küçük bir pilot bunu ikinci haftada gösterir. ### İyi pilotun beş özelliği 1. **Uçtan uca, ama dar.** Tek ürün varyantı için parametre girişinden üretim çıktısına kadar tüm zincir. Zincirin yalnızca ortasını otomatikleştiren pilot, gerçek darboğazları göstermez. 2. **Gerçek veriyle.** Temizlenmiş örnek dosyayla değil, sahadan gelen dosyayla. Kirli veri, pilotun asıl sınavıdır. 3. **Tek bir kullanıcıyla.** Beş kişiye aynı anda vermek geri bildirimi bulanıklaştırır. 4. **Süresi belli.** Dört-altı hafta. Bitiş tarihi olmayan pilot, pilot değil, süresiz bir projedir. 5. **Başarı ölçütü önceden yazılı.** "Hazırlık süresi %40 azalırsa devam" gibi. Sonradan konan ölçüt, her sonucu başarı gösterir. :::illustration full checklist | Pilotun ölçütü: sonucu tartışmaya açık olmamalı ::: ### Pilot bittiğinde sorulacak tek soru "Çalıştı mı?" değil, şu: **aynı işi otomasyon olmadan yapan kişi, otomasyona geri dönmek ister mi?** Cevap "hayır"sa, kazanç sayısı ne gösterirse göstersin bir yerde yanlış vardır — genellikle doğrulama yükü hafife alınmıştır. ## 04 — Sahada büyüt Son adım, kapsamı genişletmektir — ama **kanıtla, tahminle değil.** Pilot sahada çalıştığını gösterdikçe bir sonraki varyant, bir sonraki ürün ailesi, bir sonraki çıktı tipi eklenir. Her genişleme öncesinde aynı soru sorulur: bu ekleme, birinci adımda ölçtüğümüz kayıp kalemlerinden hangisine karşılık geliyor? Bu disiplin olmadan otomasyon projeleri, kimsenin kullanmadığı özelliklerle şişer. Kullanılmayan her özellik yalnızca boşa harcanmış zaman değildir; bakım yükü olarak kalıcı bir maliyet üretir. ### Büyüme sırasını belirleyen basit puanlama Genişleme adaylarını sıralamak için kullandığım üç çarpanlı puan: | Çarpan | Nasıl puanlanır | | --- | --- | | Tekrar sayısı | Aylık tekrar / 10 | | Kayıp süre | Ortalama dakika / 10 | | Kural netliği | Kural yazılı ve sabitse 3, tartışmalıysa 1 | Üç sayının çarpımı, hangi işin sırada olduğunu şaşırtıcı derecede iyi gösteriyor. Özellikle üçüncü çarpan önemli: kuralı henüz oturmamış bir işi otomatikleştirmek, hareketli bir hedefi sabitlemeye çalışmaktır. ## Otomatikleştirmediklerim Bir yöntemi anlatırken neyi kapsamadığını söylemek, kapsadığını söylemek kadar önemli. - **Yargı gerektiren kararlar.** Yapay zeka araçlarını hız ve iterasyon için kullanırım; mimari kararlar, doğrulama ve test yükü bende kalır. Bu ayrımın kod tarafındaki karşılığını [yapay zeka ile SolidWorks eklentisi yazmak](https://mehmetseyrimez.com/blog/yapay-zeka-ile-solidworks-eklentisi-yazmak) yazısında ayrıntılandırdım. - **Az tekrarlanan işler.** Ayda bir yapılan bir işi otomatikleştirmek, çoğu zaman elle yapmaktan pahalıdır. - **Henüz oturmamış süreçler.** Sürekli değişen bir iş akışını otomatikleştirmek, hareketli bir hedefi sabitlemeye çalışmaktır. Önce süreç oturur, sonra otomatikleştirilir. - **Doğrulaması olmayan çıktılar.** Üretime giden bir çıktının doğruluğunu kontrol edecek deterministik bir kural yoksa, o adım otomatikleştirilmez. :::callout Sık yapılan hata Proje "hangi dili kullanalım" tartışmasıyla başlarsa, ekip haftalarca araç karşılaştırması yapar ve hiç ölçüm tutulmaz. Araç kararı, ölçüm bittikten sonra genellikle on dakika sürer — çünkü kısıtlar (kim sürdürecek, nereye dağıtılacak, hangi CAD sürümü) o noktada zaten bellidir. ::: ## Araç seçimi: dört adımdan sonra Ölçüm ve sınır belliyse araç kararı mekanik hale gelir. Kaba eşikler: | Durum | Uygun araç | Gerekçe | | --- | --- | --- | | Tek kişilik, birkaç kez çalışacak | Makro (VBA) | Kurulum maliyeti kazancı yemesin | | Keşif, fikri doğrulama | Python + COM | En hızlı deneme döngüsü | | Ekip kullanacak, kural içeriyor | C# / .NET eklenti | Test, sürüm kontrolü, dağıtım | | Üretime giden çıktı üretiyor | C# / .NET + doğrulama katmanı | Sessiz hata en pahalı hatadır | Bu üç yolun teknik farkını [makro, API ve add-in arasındaki fark](https://mehmetseyrimez.com/blog/solidworks-makro-api-farki) yazısında; Python tarafının nerede bitip C# tarafının nerede başladığını [Python ile SolidWorks otomasyonu](https://mehmetseyrimez.com/blog/python-solidworks-otomasyonu) yazısında ayrıntılı anlattım. ## Sık Sorulan Sorular **Otomasyon projesine başlamak için kaç kişilik ekip gerekir?** Pilot aşaması için tek bir geliştirici ve tek bir kullanıcı yeterlidir. Ekip büyüklüğü, kapsam sahada kanıtlandıktan sonra artırılmalıdır; başta kalabalık bir ekip, ölçülmemiş varsayımların üzerine paralel iş yığar. **Bir işin otomatikleştirilmeye değip değmediğine nasıl karar verilir?** Kazanılan süreyi tekrar sayısıyla çarpın ve bakım yükünü düşün. Aylık toplam kazanç, otomasyonun geliştirme ve bakım süresini makul bir sürede (tipik olarak altı ay) karşılamıyorsa o iş elle kalır. Ölçüm yönteminin ayrıntısını [otomasyon kazancını ölçmek](https://mehmetseyrimez.com/blog/otomasyon-kazancini-olcmek) yazısında anlattım. **Pilot projenin süresi ne kadar olmalı?** Dört ile altı hafta. Daha kısası varsayımları kırmaya yetmez, daha uzunu pilot olmaktan çıkıp süresiz projeye döner. Bitiş tarihi ve başarı ölçütü baştan yazılı olmalıdır. **Otomasyon projesinde en sık yapılan hata nedir?** Ölçüm yapmadan araç seçmek. İkinci sırada, otomasyonun sınırını yazıya dökmemek geliyor: sınır yazılı değilse her istisna talebi haklı görünür ve kapsam sessizce büyür. **CAD otomasyonu için hangi dili seçmeliyim?** Keşif ve fikir doğrulama için Python, üretime giden kalıcı akışlar için C# / .NET. Tek seferlik küçük işlerde VBA makrosu hâlâ en hızlı yoldur. Karar, işin kim tarafından sürdürüleceğine ve ne kadar yaşayacağına göre verilir. **Otomasyonun başarısını hangi metriklerle takip etmeliyim?** Dört kalem yeterlidir: hazırlık süresi, düzeltme oranı, ilk seferde doğru çıktı yüzdesi ve üretime kaçan hata sayısı. Yalnızca üretim süresini ölçmek, kazancı olduğundan büyük gösterir. ## Özet Otomasyon projesinin başarısı, ilk gün seçilen kütüphaneyle değil, ilk hafta sorulan sorularla belirlenir: | Adım | Soru | | --- | --- | | 01 | Hangi iş ne sıklıkla tekrarlanıyor, zaman nerede kayboluyor? | | 02 | Ne yazılıma, ne insana kalacak? | | 03 | Sonucu ölçülebilir en küçük parça hangisi? | | 04 | Bu genişleme hangi ölçülmüş kayba karşılık geliyor? | Araç seçimi bu dört sorunun cevabından sonra gelir — ve genellikle o noktada zaten belli olmuştur. :::callout Pratikte Bu yöntemin uygulanmış hâlini prefabrik ve hafif çelik üretimi için geliştirdiğim CAD/CAM platformunda ve SolidWorks otomasyon çalışmalarında görebilirsiniz; ikisinde de sıra aynıydı: ölç, sınırla, pilotla, büyüt. ::: --- # 2B Teknik Resimden 3B Modele Otomasyon: Nereye Kadar? source: https://mehmetseyrimez.com/blog/2b-teknik-resimden-3b-modele-otomasyon type: article published: 2026-08-22 updated: 2026-08-26 category: Otomasyon Atölyesi tags: solidworks, otomasyon, parametrik-tasarim, yapay-zeka, dwg author: Mehmet Seyrimez reading_minutes: 7 > Eski DWG arşivini 3B modele çevirmek, CAD otomasyonunun en çok hafife alınan işi. Geometri neden yetmez, tasarım niyeti nasıl geri kazanılır, süre ne kadar? 2B teknik resimden 3B modele otomatik dönüşümde **geometrinin kendisi otomatikleştirilebilir, tasarım niyeti otomatikleştirilemez.** Temizlik, profil tanıma, ürün ailesi sınıflandırması ve taslak katı üretimi bugün büyük ölçüde makineye devredilebilir. Devredilemeyen şey, hangi ölçünün hangi ölçüyü sürdüğü — yani parametrelerin birbirine nasıl bağlanacağı. O bilgi teknik resimde hiç yoktur; resim, geometrinin *sonucunu* taşır, *nedenini* değil. Arşivde binlerce DWG var, hepsi üretilmiş ve sahada çalışmış parçalara ait. Soru basit görünüyor: bunları 3B modele çevirelim, bir daha çizmeyelim. Bu iş, CAD otomasyonunun en çok istenen ve en çok hafife alınan kalemi. Sebebi tek cümleyle şu: **teknik resim geometriyi taşır, tasarım niyetini taşımaz.** :::illustration full drafting-board | Geometri, kural katmanı ve model arasındaki boşluk ::: ## Geometri neden yetmiyor Bir teknik resimden çıkarabileceğiniz şey, parçanın **o anki** hâlidir: şu uzunluk, şu delik çapı, şu büküm açısı. Çıkaramayacağınız şey, o değerlerin *neden* öyle olduğu. Somut örnek: resimde 120 mm'lik bir mesafe var. Bu mesafe; - sabit bir montaj ölçüsü mü, - yoksa toplam genişliğin yarısı mı, - yoksa yandaki delikten 40 mm uzakta olması gerektiği için mi 120? Üçü de aynı çizgiyi üretir. Ama parçayı parametrik yapmak istediğinizde üçü tamamen farklı davranır. Genişliği değiştirdiğinizde birincisi yerinde kalır, ikincisi ortalanır, üçüncüsü deliği takip eder. Otomatik dönüşümün ürettiği model, çoğu zaman birinci varsayımı seçer — yani **ölü bir katı.** Görüntü doğrudur, ama parametre değiştirdiğinizde model dağılır. ### "Ölü katı" ne zaman yeterlidir Her dönüşümün parametrik olması gerekmiyor. Ölü katı üç durumda tamamen yeterli: - **Görselleştirme ve montaj yerleşimi.** Parçanın yer kaplamasını görmek için niyet gerekmez. - **Çakışma ve gabari kontrolü.** Geometri doğruysa kontrol doğrudur. - **Arşiv taşıma.** Eski parçaların 3B ortamda saklanması, yeniden çizim gerektirmeden. Parametrik model gereken tek durum, **o parçanın varyantlarının üretilecek olmasıdır.** Bu ayrımı baştan yapmak, projenin en pahalı kararı: arşivin tamamını parametrikleştirmeye çalışmak, çoğu firmada gereksiz bir maliyet. ## Otomasyonun gerçekten çözdüğü kısım Bu, dönüşümün otomatikleştirilemeyeceği anlamına gelmiyor. Zincirin bir kısmı fazlasıyla otomatikleştirilebilir: - **Temizlik.** Kopuk çizgiler, üst üste binmiş elemanlar, kullanılmayan katmanlar, ölçek tutarsızlıkları. Sıkıcı ve kurallı — otomasyona en uygun kısım. - **Tanıma.** Kapalı profillerin, delik gruplarının ve büküm çizgilerinin ayırt edilmesi. - **Sınıflandırma.** Resmin hangi ürün ailesine ait olduğunun belirlenmesi. Kural katmanı buna göre seçilir. - **Taslak katı.** Doğru profil ve kalınlıkla ilk katının üretilmesi. Dördü birlikte, işin mekanik yükünün büyük kısmını alıyor. Kalan kısım — parametrelerin neye bağlanacağı — tasarım kararıdır. ### Temizlik adımının gizli değeri Sahada gördüğüm en sık sürpriz: temizlik adımı tek başına, projenin beklenen kazancının önemli bir bölümünü üretiyor. Sebebi, eski arşivlerin sanıldığından çok daha kirli olması. Tipik bir DWG arşivinde karşılaşılanlar: | Sorun | Sıklık | Otomatik düzeltilebilir mi | | --- | --- | --- | | Kopuk/çakışan çizgiler | Çok yüksek | Evet — tolerans eşiğiyle | | Kullanılmayan katman ve blok | Yüksek | Evet | | Ölçek/birim tutarsızlığı | Orta | Kısmen — referans ölçü gerekir | | Patlatılmış (explode) kotalar | Orta | Hayır — bilgi kaybolmuş | | Elle yazılmış "yaklaşık" notlar | Düşük | Hayır — yargı gerektirir | Son iki satır, dönüşümün sınırını gösteriyor: bilginin kaybolduğu yerde otomasyon onu geri getiremez. :::illustration right design-thinking | Aynı çizgi, üç farklı parametrik niyet ::: ## Tasarım niyetini nasıl geri kazanırsınız Niyet resimde yoksa, başka bir yerden gelmek zorunda. Pratikte üç kaynak var: **1. Ürün ailesi kuralı.** Aynı ailenin tüm parçaları aynı mantıkla boyutlanır. Bir kez tanımlarsınız, tüm aileye uygularsınız. En verimli yol budur — ve arşivin sınıflandırılmış olmasını gerektirir. **2. Varyant karşılaştırması.** Aynı parçanın iki farklı boyuttaki resmi elinizdeyse, hangi ölçünün değiştiği hangisinin sabit kaldığı doğrudan görülür. Bu, niyeti veriden çıkarmanın en güvenilir yolu. **3. Üreten kişinin bilgisi.** En pahalı ama en kesin kaynak. Bir ürün ailesi için yarım günlük bir görüşme, yüzlerce parçanın niyetini belirleyebilir. Üçünü birlikte kullanmak, tek tek kullanmaktan belirgin biçimde hızlı. Kural taslağını aile bazında yazarsınız, varyant karşılaştırmasıyla doğrularsınız, kalan belirsizliği görüşmeyle kapatırsınız. ## Yapay zeka bu zincirde nereye oturuyor Yapay zekanın burada iki gerçek katkısı var, bir de abartılan tarafı. **Gerçek katkı 1 — tanıma.** Görüntü işleme tarafı, elle kural yazmaktan çok daha iyi. "Bu bir sac metal büküm çizgisi mi" sorusunda örüntü tanıma güçlü. **Gerçek katkı 2 — sınıflandırma.** Binlerce resmi ürün ailesine göre gruplamak, elle yapıldığında haftalar süren bir iş. Model bunu saatlerde yapar ve hatalarını insan gözüyle ayıklamak kolaydır. **Abartılan taraf — niyet çıkarımı.** "Yapay zeka tasarım niyetini anlar" iddiası bugün için fazla iyimser. Model, hangi ölçünün sürücü olduğunu tahmin edebilir; tahminin doğruluğunu **doğrulamadan** kabul ederseniz, hatayı parametrik modele gömmüş olursunuz. Ve bu hata, [sessizce yanlış çıktı üreten](https://mehmetseyrimez.com/blog/yapay-zeka-ile-solidworks-eklentisi-yazmak) türden — aylar sonra, başka bir varyant üretilirken ortaya çıkar. :::callout Doğrulama olmadan tahmin kabul edilmez Modelin niyet tahminini kabul etmeden önce tek bir test yeter: parametreyi üç farklı değerle çalıştırın. Model dağılıyorsa niyet yanlıştır. Bu test otomatikleştirilebilir ve tüm zincirin en değerli adımıdır. ::: ## Pratikte izlediğim sıra 1. **Dar başla.** Tek bir ürün ailesi, tek bir varyant. Uçtan uca çalıştır. 2. **Arşivi sınıflandır.** Hangi resim hangi aileye ait — bu adım olmadan kural katmanı seçilemez. 3. **Niyeti elle tanımla.** O aile için hangi ölçünün sürücü olduğu bir kez belirlenir; sonra tüm aileye uygulanır. 4. **Doğrulamayı otomatikleştir.** Üretilen modeli birkaç parametre değeriyle yeniden oluştur; dağılıyorsa niyet yanlıştır. 5. **Sonra genişlet.** Bir aile sağlam çalıştıktan sonra sıradakine geç. Bu sıra, serinin ilk yazısındaki [dört adımlı yöntemin](https://mehmetseyrimez.com/blog/otomasyon-projesine-nasil-baslanir) bu probleme uygulanmış hâli. :::illustration left problem-solving | Doğrulama: modeli üç farklı parametreyle yeniden kur ::: ## Ne kadar sürer, ne kadar kazandırır Beklenti kurmak için kullandığım kaba oranlar — bin resimlik bir arşiv, tek ürün ailesi varsayımıyla: | Aşama | Otomasyon payı | İnsan payı | | --- | --- | --- | | Temizlik ve tanıma | ~%90 | Örnekleme kontrolü | | Sınıflandırma | ~%80 | Sınır durumların ayıklanması | | Taslak katı | ~%70 | Başarısız dönüşümlerin elle çizimi | | Parametrik bağlama | ~%20 | Niyet tanımı ve doğrulama | | **Toplam** | **belirgin kazanç** | **Kural yazımı ve kontrol** | Buradaki asıl mesaj sondaki satır değil, dördüncü satır: parametrik bağlama otomasyonun en az yardım ettiği aşama, ama projenin değerinin çoğu orada. Bu yüzden dönüşüm projelerini "arşivi çevirelim" diye değil, **"şu ürün ailesini parametrik hâle getirelim"** diye tanımlamak daha sağlıklı sonuç veriyor. Ölçümü nasıl kurduğumu [otomasyon kazancını ölçmek](https://mehmetseyrimez.com/blog/otomasyon-kazancini-olcmek) yazısında anlattım. ## Sık Sorulan Sorular **2B teknik resimden 3B modele otomatik dönüşüm mümkün mü?** Geometrinin dönüşümü büyük ölçüde mümkündür: temizlik, profil tanıma, sınıflandırma ve taslak katı üretimi otomatikleştirilebilir. Parametrik, yani ölçüleri birbirine bağlı bir model üretmek ise tasarım niyeti gerektirir ve bu bilgi teknik resimde bulunmaz. **Tasarım niyeti ne demek ve neden teknik resimde yok?** Tasarım niyeti, bir ölçünün neden o değerde olduğudur — sabit mi, başka bir ölçüye bağlı mı, bir kısıtın sonucu mu. Teknik resim geometrinin sonucunu gösterir, bu bağımlılıkları göstermez. Aynı çizgi üç farklı niyetten doğmuş olabilir. **DWG arşivinin tamamını 3B'ye çevirmeye değer mi?** Genellikle hayır. Parametrik model yalnızca varyantları üretilecek parçalar için gereklidir. Görselleştirme, çakışma kontrolü ve arşivleme için parametrik olmayan "ölü katı" yeterlidir ve çok daha ucuza üretilir. **Yapay zeka teknik resimden tasarım niyetini çıkarabilir mi?** Tahmin edebilir, ama tahmini doğrulanmadan kullanılmamalıdır. Güvenilir doğrulama yöntemi, üretilen modeli birkaç farklı parametre değeriyle yeniden oluşturmaktır; model dağılıyorsa niyet tahmini yanlıştır. **Dönüşüm projesine nereden başlanmalı?** Tek bir ürün ailesinden ve tek bir varyanttan. Önce arşiv sınıflandırılır, sonra o aile için sürücü ölçüler tanımlanır, ardından doğrulama otomatikleştirilir. Kapsam ancak bu zincir uçtan uca çalıştıktan sonra genişletilir. **Otomatik dönüşümde en sık karşılaşılan sorun nedir?** Kaynak resimlerin kirli olması: kopuk çizgiler, patlatılmış kotalar, tutarsız ölçek ve kullanılmayan katmanlar. Patlatılmış kotalarda ölçü bilgisi tamamen kaybolduğu için otomatik kurtarma mümkün değildir. ## Özet 2B'den 3B'ye geçişte otomatikleştirilebilen şey temizlik, tanıma, sınıflandırma ve taslak üretimidir. Otomatikleştirilemeyen şey, ölçülerin birbirine nasıl bağlanacağıdır — çünkü o bilgi resimde hiç yoktur. Doğru proje tanımı "arşivi çevirelim" değil, "şu ürün ailesini parametrik hâle getirelim" olmalı. Bu yaklaşımın ürün hâline gelmiş sürümünü [ParametriX vaka çalışmasında](https://mehmetseyrimez.com/projeler/parametrix-2d-3d) anlatıyorum. --- # Otomasyon Kazancını Ölçmek: "%90 Daha Hızlı" Ne Demek? source: https://mehmetseyrimez.com/blog/otomasyon-kazancini-olcmek type: article published: 2026-08-21 updated: 2026-08-26 category: Otomasyon Atölyesi tags: otomasyon, olcum, cad-otomasyon, surec, roi author: Mehmet Seyrimez reading_minutes: 7 > CAD otomasyonu araçları %70, %85, %90 hızlanma vaat ediyor. Bu sayılar neyi ölçer, neyi ölçmez ve dürüst bir kazanç hesabı dört adımda nasıl kurulur? Bir otomasyonun gerçek kazancı tek bir yüzdeyle ifade edilemez. Dürüst ölçüm dört kalemi birden karşılaştırmayı gerektirir: **hazırlık, üretim, doğrulama ve düzeltme.** Satıcıların duyurduğu "%90 daha hızlı" sayısı neredeyse her zaman yalnızca ikinci kalemi — üretim adımını — ölçer. Dört kalem birlikte ölçüldüğünde tipik gerçek kazanç %30–50 bandına oturur; bu hâlâ çok iyi bir sonuçtur, ama beklentiyi buna göre kurmak gerekir. Otomasyon araçlarının tanıtım sayfalarında hep bir yüzde var: %70, %85, bazen %90. Bu sayılar tamamen uydurma değil — ama neyi ölçtükleri neredeyse hiç yazmıyor. Bu yazı, o yüzdeyi nasıl okuyacağınız ve kendi ölçümünüzü nasıl kuracağınız üzerine. :::illustration full charts-analysis | Kazanç zinciri: hazırlık, üretim, doğrulama, düzeltme ::: ## Yüzde neyin yüzdesi? Bir satıcı "çizim süresi %90 azaldı" dediğinde, genellikle şu ölçülmüştür: **tek bir işlemin, ideal koşullarda, ilk çıktıya ulaşma süresi.** Ölçülmeyenler ise şunlar: - Girdinin hazırlanma süresi (parametrelerin toplanması, modelin temizlenmesi) - Çıktının doğrulanma süresi - Doğrulamada çıkan hataların düzeltilme süresi - Otomasyonun kendi bakım süresi Dördü toplandığında %90'lık kazanç çoğu zaman %30–50 bandına iniyor. > Bir otomasyonun getirisi, en yavaş halkasıyla sınırlıdır. Üretim adımını on kat hızlandırıp doğrulama adımını olduğu gibi bırakırsanız, toplam kazanç doğrulamanın izin verdiği kadardır. ### Amdahl'ın mühendislik ofisindeki karşılığı Bilgisayar mimarisinde bilinen bir kural var: bir sistemin ancak hızlandırdığınız kısım kadar hızlanabileceğini söyler. Aynı aritmetik mühendislik ofisinde de geçerli. Diyelim toplam iş 100 dakika ve şöyle dağılıyor: hazırlık 30, üretim 40, doğrulama 20, düzeltme 10. Üretim adımını on kat hızlandırdınız — 40 dakika 4 dakikaya indi. | Adım | Önce | Sonra | | --- | --- | --- | | Hazırlık | 30 dk | 30 dk | | Üretim | 40 dk | 4 dk | | Doğrulama | 20 dk | 20 dk | | Düzeltme | 10 dk | 10 dk | | **Toplam** | **100 dk** | **64 dk** | Üretimde %90 kazanç var, toplamda %36. İkisi de doğru sayı; hangisini duyurduğunuz bir tercih meselesi. Sorun, satın alma kararının birinciye göre verilmesi. ## Dört adımın hepsini ölçün Kendi projelerimde kullandığım ölçüm çerçevesi dört kalemli: | Adım | Öncesi | Sonrası | Neden ölçülür | | --- | --- | --- | --- | | Hazırlık | ? dk | ? dk | Otomasyon girdi ister; o girdi bedava değildir | | Üretim | ? dk | ? dk | Satıcının ölçtüğü tek kalem genelde budur | | Doğrulama | ? dk | ? dk | Güvenilmeyen çıktı her seferinde kontrol edilir | | Düzeltme | ? dk | ? dk | Hata oranı düşmediyse kazanç yanıltıcıdır | Dört satırı da doldurmadan önce ve sonra karşılaştırmak, çoğu abartılı iddiayı kendiliğinden çözüyor. ### Ölçümü kim, nasıl tutar Ölçümü otomasyonu yazan kişi tutmamalı. Yazan kişi, aracın en iyi çalıştığı yolu bilir ve farkında olmadan onu seçer. Ölçümü işi gerçekten yapan kişi tutar; geliştirici yalnızca tablonun biçimini verir. Pratikte işe yarayan en basit yöntem: iki hafta önce, iki hafta sonra, aynı kişi, aynı iş tipi, telefonda bir kronometre. Daha gelişmiş bir araç gerekmiyor — gereken şey, **aynı işin** ölçülmesi. ## Kazancın gerçek geri dönüş hesabı Süre kazancı tek başına bir karar vermez. Kararı veren, geri dönüş süresidir. Hesap üç cümlelik: Önce **aylık kazancı** bulun: iş başına kazanılan dakikayı aylık tekrar sayısıyla çarpın ve saate çevirin. Sonra otomasyonun **toplam maliyetini** yazın: geliştirme saati artı ilk yıl için ayıracağınız bakım saati. **Geri dönüş süresi**, bu maliyetin aylık kazanca bölümüdür. Yukarıdaki örnekle gidelim: iş başına 36 dakika kazanç var ve iş ayda 40 kez tekrarlanıyor. 36 × 40 = 1440 dakika, yani ayda 24 saat. Geliştirme 80 saat, ilk yıl bakım 20 saat sürecekse toplam maliyet 100 saat. 100 ÷ 24 ≈ **4,2 ay.** Altı ayın altındaki geri dönüşlerde karar genellikle nettir. On iki ayı aşan hesaplarda iki şeyden birini yapmak gerekir: kapsamı daraltıp geliştirme süresini düşürmek, ya da işten vazgeçmek. :::illustration right cost-savings | Geri dönüş = geliştirme + bakım ÷ aylık kazanç ::: ## Dikkat edilmesi gereken beş tuzak **1. En iyi durumu ölçmek.** Otomasyonu en uygun parça üzerinde denerseniz güzel bir sayı elde edersiniz. Ortalama iş üzerinde deneyin — asıl yaşayacağınız sayı odur. **2. Öğrenme süresini yok saymak.** Yeni araç ilk iki hafta işi *yavaşlatır*. Ölçümü ilk hafta yaparsanız kazancı göremezsiniz; hiç yapmazsanız gerçek maliyeti gizlemiş olursunuz. Doğru yol: ölçümü üçüncü haftadan itibaren başlatmak ve öğrenme süresini tek seferlik maliyet olarak ayrı yazmak. **3. Bakım yükünü unutmak.** Otomasyon canlı bir yazılımdır. Ürün ailesi değişince kural katmanı da değişir, CAD sürümü yükselince API çağrıları kontrol edilir. Yılda birkaç gün bakım, kazancın içinden çıkar. **4. Kazancı boş zamana çevirmemek.** Ayda 24 saat kazandınız diyelim; o saatler başka bir işe aktarılmadıysa muhasebe defterinde hiçbir şey değişmez. Kazancın nereye gideceğine baştan karar vermek, ölçümün bir parçasıdır. **5. Tek bir kişiden ölçmek.** Aracı en iyi kullanan kişinin sayısı, ekibin ortalamasını temsil etmez. En az iki farklı kullanıcıdan ölçün. :::illustration left maintenance | Bakım yükü ölçüme girmezse kazanç olduğundan büyük görünür ::: ## Ne zaman ölçmeye değmez Dürüst olmak gerekirse, her otomasyonu ölçmek gerekmiyor. Ayda iki kez yapılan on dakikalık bir iş için ölçüm kurmanın maliyeti, otomasyonun kendisinden yüksek. Böyle durumlarda karar zaten nettir: ya açıkça küçük bir kolaylıktır ya da hiç yapılmamalıdır. Ölçüm, **kararın sonucu belirsizse** anlamlıdır: kapsamı büyütüp büyütmemeye karar verirken, bütçe isterken, ya da bir aracın gerçekten işe yarayıp yaramadığını tartışırken. ## Ölçüm sonuçlarını nasıl okumalı Ölçüm bittiğinde çıkan tabloya bakarken üç sorunun cevabını ararım: **Hangi adım büyüdü?** Otomasyon bir adımı kısaltırken başka bir adımı uzatabilir. En sık görüleni: üretim kısalır, hazırlık uzar — çünkü otomasyon artık daha derli toplu bir girdi ister. Bu kötü bir sonuç değil, ama görülmesi gerekir. **Düzeltme oranı düştü mü?** Süre aynı kalsa bile düzeltme sayısı düştüyse otomasyon değer üretiyor demektir. Tutarlılık, tek başına ölçmeye değer bir kazançtır. **Değişkenlik azaldı mı?** Elle yapılan işte süre 20 ile 70 dakika arasında dolaşırken otomasyonla 8 ile 12 arasına oturuyorsa, planlama kabiliyeti kazanılmıştır. Bu kalem tabloda görünmez ama üretim planlaması yapan ekipler için ortalama kazançtan bile değerli olabilir. ## Bizim ölçtüğümüz örnek Hafif çelik CAD/CAM platformunda, eski CAD sistemine kıyasla şirket içi ölçümlerde hazırlık aşamasında belirgin bir hızlanma raporlandı. Bu sayının anlamlı olmasının nedeni, tek bir işlemin değil **hazırlık aşamasının tamamının** ölçülmüş olması — girdi toplama ve çıktı kontrolü dahil. Aynı ölçüm disiplinini SolidWorks tarafındaki eklenti çalışmalarında da uyguladım; oradaki asıl kazanç süreden çok **çıktı tutarlılığında** çıktı: aynı ürün ailesinin resimleri artık kim üretirse üretsin aynı düzende geliyor. Projelerin ayrıntılarını [hafif çelik CAD/CAM vaka çalışmasında](https://mehmetseyrimez.com/projeler/prefabrik-hafif-celik-cadcam) bulabilirsiniz. :::callout Ölçmeden önce Otomasyonun sınırını çizmeden ölçüm kurmak zaman kaybıdır: kapsam belirsizse "önce" ve "sonra" aynı işi tarif etmez. Sınır çizme adımını [otomasyon projesine nasıl başlanır](https://mehmetseyrimez.com/blog/otomasyon-projesine-nasil-baslanir) yazısında anlattım. ::: ## Sık Sorulan Sorular **Otomasyonun kazancı nasıl hesaplanır?** Hazırlık, üretim, doğrulama ve düzeltme adımlarının süresini otomasyon öncesi ve sonrası ayrı ayrı ölçün. Toplam farkı aylık tekrar sayısıyla çarpın, ardından geliştirme ve bakım saatlerini bu aylık kazanca bölerek geri dönüş süresini bulun. **Satıcıların verdiği "%90 daha hızlı" iddiası güvenilir mi?** Sayı genelde doğru ama dar kapsamlıdır: yalnızca üretim adımını, ideal girdiyle ölçer. Hazırlık, doğrulama ve düzeltme dahil edildiğinde aynı araç tipik olarak %30–50 bandında toplam kazanç verir. **Otomasyon ölçümüne ne zaman başlanmalı?** Otomasyon devreye alındıktan sonra üçüncü haftadan itibaren. İlk iki hafta öğrenme dönemidir ve kazancı olduğundan küçük gösterir; bu dönemi tek seferlik maliyet olarak ayrı kaydedin. **Otomasyonun geri dönüş süresi ne kadar olmalı?** Altı ayın altındaki geri dönüşlerde karar genellikle nettir. On iki ayı aşan hesaplarda ya kapsamı daraltıp geliştirme süresini düşürmek ya da işten vazgeçmek gerekir. **Bakım maliyeti hesaba nasıl katılır?** İlk yıl için yıllık geliştirme süresinin yaklaşık dörtte biri kadar bakım saati ayırmak gerçekçi bir başlangıçtır. CAD sürüm yükseltmeleri, ürün ailesi değişiklikleri ve kural güncellemeleri bu kalemden çıkar. **Süre kazancı dışında hangi kazançlar ölçülmeli?** Düzeltme oranı, ilk seferde doğru çıktı yüzdesi ve süre değişkenliği. Özellikle değişkenliğin azalması, üretim planlaması yapan ekipler için ortalama süre kazancından daha değerli olabilir. ## Özet Yüzdelere değil, dört adıma bakın. Bir otomasyon aracını değerlendirirken sorulacak tek soru şu: **hangi adımı kısaltıyor, hangi adımı uzatıyor?** Serinin devamında 2B teknik resimden 3B modele geçişin otomasyonunu ele alıyorum — orada da asıl mesele hangi adımın gerçekten devredilebildiği. --- # Yapay Zeka ile SolidWorks Eklentisi Yazmak: Nerede Yanılır? source: https://mehmetseyrimez.com/blog/yapay-zeka-ile-solidworks-eklentisi-yazmak type: article published: 2026-08-19 updated: 2026-08-26 category: Otomasyon Atölyesi tags: solidworks, yapay-zeka, csharp, otomasyon author: Mehmet Seyrimez reading_minutes: 4 > Yapay zeka, SolidWorks eklentisi geliştirirken iskeleti ve API keşfini gerçekten hızlandırıyor; COM yaşam döngüsünde ise emin biçimde yanlış kod üretiyor. Yapay zeka araçlarını eklenti geliştirirken kontrollü bir kaldıraç olarak kullanıyorum. "Kontrollü" kelimesi burada süs değil: SolidWorks API'si, dil modellerinin en çok yanıldığı alanlardan biri. Bu yazı, işe yaradığı yerlerle yaramadığı yerleri ayırıyor. :::illustration full code-inspection | Üretilen kodun doğrulanması, üretilmesinden daha uzun sürebilir ::: ## Gerçekten hızlandırdığı yerler **İskelet kod.** Add-in kaydı, `ISwAddin` uygulaması, CommandManager sekmesi ve buton bağlama — bunlar her eklentide neredeyse aynı. Elle yazmak yarım gün, üretmek birkaç dakika. Burada kazanç gerçek ve risk düşük, çünkü hata anında derleme zamanında ortaya çıkar. **API keşfi.** SolidWorks API'si geniş ve dokümantasyonu dağınık. "Bir sac metal parçanın büküm tablosuna nasıl erişilir" sorusunun cevabını aramak yerine sormak, çoğu zaman doğru arayüz adına daha hızlı götürüyor. Ama cevabı **doğrulamadan** kullanmıyorum — bunun nedeni aşağıda. **Tekrarlayan dönüşümler.** Elimde VBA makro varsa ve C#'a taşınacaksa, bu mekanik bir çeviri işi. Yapay zeka bu işte iyi. **Test verisi ve kenar durum listesi.** "Bu fonksiyon hangi girdilerde patlar" sorusuna verdiği liste, kendi düşündüğümden genellikle daha uzun oluyor. ## Kendinden emin biçimde yanıldığı yerler Buradaki tehlike, hata yapması değil — **hata yaptığını belli etmemesi.** **COM nesne yaşam döngüsü.** SolidWorks API'si COM üzerinden çalışır. Üretilen kod çoğu zaman nesneleri serbest bırakmayı atlar veya yanlış sırada bırakır. Sonuç anında görünmez: uygulama çalışır, ama uzun oturumlarda bellek şişer ya da SolidWorks kapanırken takılır. Bu tür hatalar testte değil, sahada üç hafta sonra ortaya çıkar. **Sürüm farkları.** API'nin bir metodu sürümler arasında değişmişse, model genellikle eski imzayı üretir. Derlenir, çalışır, yanlış sonuç verir. **Sessiz başarısızlık.** SolidWorks API'sinde birçok çağrı hata fırlatmaz; `null` veya `false` döner. Üretilen kod bu dönüşleri kontrol etmeyi sık sık atlar. Otomasyon "çalışır" görünür, çıktı eksik üretilir. > Otomasyonun en pahalı hatası çöken koddur değil, **sessizce yanlış çıktı üreten** koddur. Çöken kodu fark edersiniz; yanlış çıktı üretim hattına gider. :::illustration left fixing-bugs | Üretim katmanı ile doğrulama katmanını ayırmak ::: ## Kurduğum çalışma düzeni Bu ayrımı bir kurala bağladım: 1. **İskelet ve mekanik dönüşüm** — üretilir, hızlıca gözden geçirilir. 2. **API çağrısı içeren her kod** — üretilebilir, ama dönüş değeri kontrolü ve nesne serbest bırakma elle eklenir. 3. **Kural ve doğrulama katmanı** — elle yazılır. Ürünün doğru olup olmadığına karar veren kod, üretilmiş koda emanet edilmez. 4. **Test** — yapay zeka kenar durumları önerir, testleri ben yazarım. Bu düzen, [otomasyonun sınırını çizme](https://mehmetseyrimez.com/blog/otomasyon-projesine-nasil-baslanir) prensibinin kod tarafındaki karşılığı: kural haline getirilebilen iş devredilir, yargı gerektiren iş devredilmez. ## Ölçtüğüm şey "Yapay zeka geliştirmeyi hızlandırdı mı" sorusunu tek bir sayıyla cevaplamak yanlış olur. Ölçmeye değer iki ayrı şey var: | Ölçüm | Gözlemim | | --- | --- | | İlk çalışan sürüme ulaşma | Belirgin biçimde kısalıyor | | Sahada güvenilir sürüme ulaşma | Belirgin bir fark görmedim | İkisi arasındaki fark, doğrulama yükünün nereye taşındığını gösteriyor: yazma süresinden okuma süresine. Toplam kazanç, doğrulama disiplininiz kadar oluyor. ## Özet Yapay zeka, SolidWorks eklentisi geliştirmede iskeleti ve keşfi hızlandırıyor; API'nin tuzaklarını bilmiyor. Kazancı korumanın yolu, üretilen kodu nereye koyacağınızı baştan ayırmaktan geçiyor. Serinin devamında AutoCAD tarafındaki seçenekleri ve kazancın nasıl ölçüleceğini ele alıyorum. ## Sık Sorulan Sorular **Yapay zeka SolidWorks eklentisi geliştirmeyi gerçekten hızlandırıyor mu?** İskelet kod ve API keşfinde belirgin biçimde hızlandırıyor. Add-in kaydı, yaşam döngüsü uygulaması ve komut arayüzü kurulumu neredeyse her eklentide aynıdır; bunları üretmek dakikalar sürer ve hata derleme zamanında ortaya çıktığı için risk düşüktür. **Yapay zekanın SolidWorks API'sinde en çok yanıldığı konular nelerdir?** Üç başlık: COM nesne yaşam döngüsü (serbest bırakma sırası), sürümler arasında değişmiş metot imzaları ve sessiz başarısızlık (hata fırlatmayan, `null` veya `false` dönen çağrıların kontrol edilmemesi). **Üretilen kodu nasıl doğrulamalıyım?** Kodu üç gruba ayırın: iskelet ve mekanik dönüşüm üretilir ve hızlıca gözden geçirilir; API çağrısı içeren kodda dönüş değeri kontrolü ve nesne serbest bırakma elle eklenir; kural ve doğrulama katmanı elle yazılır. **Sessiz hata neden en pahalı hata türü?** Çöken kodu fark edersiniz; sessizce yanlış çıktı üreten kod üretim hattına gider. Hata haftalar sonra, yanlış parça üretildiğinde ortaya çıkar ve maliyeti kodu baştan yazmaktan kat kat yüksektir. **Yapay zeka toplam geliştirme süresini kısaltıyor mu?** İlk çalışan sürüme ulaşma süresi belirgin biçimde kısalıyor; sahada güvenilir sürüme ulaşma süresinde belirgin bir fark görmedim. Yük yazma süresinden okuma süresine kayıyor — toplam kazanç, doğrulama disiplininiz kadar oluyor. **Hangi kod yapay zekaya bırakılmamalı?** Ürünün doğru olup olmadığına karar veren kod. Kural ve doğrulama katmanı elle yazılır; testleri de siz yazarsınız, model yalnızca kenar durum önerir. --- # Otonom Sualtı Kaynağı ve Muayene ROV'u — DYUK'22 Bildirisi source: https://mehmetseyrimez.com/blog/otonom-sualti-kaynak-ve-muayene-rov type: article published: 2022-05-16 category: Serüven Notları tags: rov, sualti-kaynak, goruntu-isleme, makine-ogrenmesi, cad, yayin author: Mehmet Seyrimez reading_minutes: 4 > DYUK'22'de sunduğumuz ROV tasarımı: sualtı kaynağı ve kaynak muayenesini tek araçta, görüntü işleme ve makine öğrenmesi desteğiyle otonom yapma denemesi. 16–18 Mayıs 2022'de İstanbul Gedik Üniversitesi Gedik Meslek Yüksekokulu'nun düzenlediği **I. Disiplinlerarası Yaklaşımlar Ulusal Kongresi (DYUK'22)** — teması "Sürdürülebilir Gelecek ve Dijital Dönüşüm" — kapsamında, *Otonom Sualtı Kaynağı ve Sualtı Kaynak Muayene Aracı* başlıklı bildirimizi sunduk. Bildiri, kongrenin resmî özet kitabında **ID 4449** numarasıyla yer alıyor. Çalışma; Kadir Gökhan Çalkap, benim, Hüseyin Kaygısız ve Erkin Duman'ın ortak imzasını taşıyor ve İstanbul Gedik Üniversitesi Makine Programı bünyesinde yürütüldü. :::photo full rov-otonom-sualti ::: ## Problem: darboğaz insanda, maliyet zamanda Sualtı kaynağı ve kaynak muayenesi, denizcilik lojistiği ve savunma sanayii için kritik ama dar bir alan. Bu işi yapabilen teknik eleman sayısı az; azlık doğrudan iki maliyete dönüşüyor: - **Ücret maliyeti** — nitelikli dalgıç-kaynakçı arzı kısıtlı olduğu için birim iş pahalı. - **Zaman maliyeti** — sürecin kendisi uzun; her operasyon dalış hazırlığı, iniş, işlem ve kontrol döngüsü gerektiriyor. Bir gemi ya da petrol boru hattı beklerken geçen her saat, doğrudan operasyonel kayıp demek. Sorunun teknik değil ekonomik tarafı, projenin çıkış noktasıydı. --- ## Yaklaşım: kaynak ve muayeneyi aynı araçta birleştirmek Çözüm olarak, sualtı kaynağını **ve** kaynak muayenesini otonom biçimde yapabilen bir ROV (uzaktan kumandalı sualtı aracı) tasarladık. Kritik karar, iki işlemi ayrı araçlara bölmek yerine tek platformda toplamaktı: kaynağı yapan araç, kaynağın kalitesini de yerinde ölçebiliyorsa ikinci bir dalış turu gerekmiyor. Bunun için ROV'a iki uç birim eklendi: 1. **Sualtı kaynak torcu** — kaynak işlemini gerçekleştiren kol. 2. **Daldırma probu** — kaynak muayenesini yapan ikinci kol. Bu iki ünitenin koordineli ve otonom kontrolü için araç üzerinde bir mikrobilgisayar çalışıyor. ### Donanım mimarisi Bildiride tanımladığımız bileşen listesi, aracın neden "sadece bir drone gövdesi" olmadığını iyi özetliyor: - **Servo motorlar** — pervanelerin (iticilerin) kontrolü - **Jiroskoplar** — kaynak sırasında denge ve konum hesabı - **Ultrasonik mesafe sensörü** — işlem yapılacak bölgeye olan uzaklığın ölçümü - **Kamera modülü** — işlem yapılacak bölgenin belirlenmesi - **Step motorlar** — robot kolların hassas hareketi - **Motor sürücüleri** — motor kontrolü - **Kablosuz haberleşme modülleri** — dışarıdaki kullanıcı paneli ile etkileşim - **Mikrodenetleyici** — sensörlerin bağlanması ve kontrolü Kaynak sırasında jiroskopla denge tutmak, listedeki en kritik maddelerden biri. Sualtında akıntı altında sabit kalamayan bir araç, ne kadar iyi bir torç taşırsa taşısın kabul edilebilir bir dikiş bırakamaz. ### Yazılım tarafı Kontrol paneliyle etkileşim ve aracın verilen görevi yerine getirebilmesi için sisteme **görüntü işleme ve makine öğrenmesi** yazılımları yüklendi. Kamera modülünün gördüğü bölgeyi anlamlandırmak, kaynak yapılacak hattı belirlemek ve muayene sonucunu değerlendirmek bu katmanın işi. :::callout Bugünden bakınca 2022'de "kamera görsün, model karar versin" dediğimiz katman, bugün üzerinde çalıştığım CAD otomasyonu problemlerinin aynısı: geometriyi tanı, kuralı uygula, sonucu doğrula. Alan değişti, döngü değişmedi. ::: --- ## Karşılaştırma: ticari bir ROV'a karşı nerede duruyoruz Tasarımı havada bırakmamak için, ticari bir referansla — **Aegir 250 (Ocean Robotics)** — yan yana koyduk. Kongredeki karşılaştırma slaytı şu tabloyu veriyordu: :::photo full dyuk22-karsilastirma ::: | Ölçü | Aegir 250 (referans) | Geliştirilen ROV | | --- | --- | --- | | Uzunluk | 1350 mm | 1630 mm | | Genişlik | 1000 mm | 905 mm | | Yükseklik | 850 mm | 580 mm | | Ağırlık | 350 kg | 307 kg | Sonuç okunabilir: aracımız referanstan **daha uzun** ama **daha dar, belirgin biçimde daha alçak ve 43 kg daha hafif**. Alçak profil, gemi gövdesi ve boru hattı gibi dar açıklıklarda manevra için doğrudan avantaj; ağırlık farkı ise taşıma ve konuşlandırma maliyetine yansıyor. --- ## Çıktı ve sınırlar Çalışma kapsamında ROV tasarımı tamamlandı, çalışma sistemi incelendi ve **maket model üretimi** gerçekleştirildi. Yani elimizde çalışan bir saha aracı değil, doğrulanmış bir tasarım ve fiziksel bir maket vardı — bunu olduğundan büyük göstermenin anlamı yok. Modelin geliştirilip ürüne dönüştürülmesi hâlinde hedeflenen kullanım alanları şunlardı: - Petrol iletimi için kullanılan sualtı boru hatları - Deniz yolu lojistiğinde kullanılan gemilerin bakım ve onarımı - Savunma sanayiinde gerekli durumlarda kaynak ve muayene işlemleri Amaç, bu işlemleri **seri, düşük maliyetli ve hatasız** yapılabilir hâle getirmekti. --- ## Kaynak Bildirinin tam özeti, kongrenin resmî özet kitabında yayımlanmıştır: > Çalkap, K. G., Seyrimez, M., Kaygısız, H., Duman, E. (2022). *Otonom Sualtı Kaynağı ve Sualtı Kaynak Muayene Aracı* (Bildiri ID 4449). I. Disiplinlerarası Yaklaşımlar Ulusal Kongresi Özet Kitabı, s. 35. İstanbul Gedik Üniversitesi, 16–18 Mayıs 2022. Özet kitabına üniversitenin resmî sitesinden ulaşabilirsiniz: [dyuk.gedik.edu.tr — DYUK'22 Özet Kitabı (PDF)](https://dyuk.gedik.edu.tr/wp-content/uploads/Ozet-Kitabi.pdf) **Anahtar kelimeler:** ROV (Remotely Operated Underwater Vehicle), sualtı kaynağı, sualtı kaynak muayenesi, görüntü işleme, makine öğrenmesi. --- # İHA ile Kargo Teslimatı: Paper Plane Takımından Notlar source: https://mehmetseyrimez.com/blog/iha-ile-kargo-teslimati type: article published: 2022-04-06 category: Serüven Notları tags: iha, drone, lojistik, cad, takim-calismasi author: Mehmet Seyrimez reading_minutes: 3 > Gedik Üniversitesi'ndeki İHA ve Teknoloji seminerim: kargo lojistiğinin maliyet kalemleri ve mobil yer kontrol istasyonlarına dayalı teslimat ağı önerisi. Bir mühendislik fikrinin sunum slaytına dönüşmesi, o fikrin ilk ciddi sınavıdır. 2022'nin Nisan ayında İstanbul Gedik Üniversitesi Teknoloji Kulübü ile birlikte düzenlediğimiz **İnsansız Hava Araçları ve Teknoloji Semineri**'nde, kurucusu olduğum Paper Plane İHA Takımı'nı anlatırken bunu net biçimde gördüm: bir drone tasarlamak kolay kısımdı, zor olan onu neden yaptığınızı bir salonu ikna edecek kadar iyi anlatabilmekti. :::photo full paper-plane-sunum-biz-kimiz ::: ## Önce problem, sonra araç Takımı kurarken en sık düştüğümüz tuzak, işe araçtan başlamaktı. "Şu tip bir drone yapalım" cümlesi heyecan vericiydi ama hangi problemi çözdüğünü söylemiyordu. Sunumun omurgasını bu yüzden araca değil, kargo dağıtımının maliyet tablosuna kurdum. :::photo right paper-plane-sunum-problem ::: Kargo ve son kilometre teslimatında maliyeti şişiren kalemler şaşırtıcı derecede sıradan: - Araç ve yakıt masrafları - Şube ve çalışan giderleri - Olumsuz hava koşulları - Yoğun trafik ve kaza kaynaklı gecikmeler - Kargoya verilen fiziksel zararlar - Müşteri iletişimi ve yanlış teslimat sorunları - Dağıtım filosunun yarattığı çevre kirliliği Bu listenin önemi şurada: hiçbiri "havacılık problemi" değil. Hepsi **lojistik** problemi. İnsansız hava aracı burada amaç değil, bu kalemlerin bir kısmını ortadan kaldırmayı deneyen bir araç. > Aracı problemden önce seçerseniz, geri kalan her mühendislik kararınız o seçimi haklı çıkarmaya çalışmakla geçer. --- ## Önerdiğimiz model: tek drone değil, bir ağ Seminerin ikinci yarısında çözüm tarafını anlattım. Tek bir uzun menzilli aracın her şeyi taşıdığı senaryo, hem batarya hem mevzuat açısından gerçekçi değildi. Bunun yerine **mobil yer kontrol istasyonlarından oluşan bir ağ** önerdik. :::photo full paper-plane-sunum-cozum ::: Modelin işleyişi kabaca şöyleydi: 1. Sabit şubeler yerine, 7/24 aktif konumlanabilen mobil yer kontrol istasyonları kurulur. 2. İHA'lar bu istasyonlar arasında kısa ve orta menzilli sıçramalar yapar; her sıçrama batarya kapasitesine sığacak şekilde planlanır. 3. İstasyonlar ve araçlar sürekli veri alışverişi yapar; rota, hava durumu ve teslimat durumu ağ üzerinde ortak bilinir. 4. Böylece uzun menzil, tek bir aracın kapasitesinden değil, ağın topolojisinden gelir. Bu yaklaşım, ilk etapta lisans ve orta menzildeki konumlar için daha ucuz ve daha hızlı bir lojistik seçeneği hedefliyordu. :::callout Geriye dönüp baktığımda Bugün CAD otomasyonu ve mühendislik yazılımı üzerine çalışırken kullandığım refleksin temeli burada atıldı: bir sistemi tek bir güçlü bileşene değil, birbirini tamamlayan küçük ve doğrulanabilir parçalara yaslamak. ::: --- ## ::center Gövde tarafı: Paper Plane kargo İHA'sı :::center Ağ tasarımı kadar aracın kendisi de üzerinde çalıştığımız bir konuydu. Altı rotorlu bir kargo insansız hava aracı üzerinde durduk; alt gövdede taşıma modülü, üst tarafta uçuş kontrol ve itki sistemi yer alıyordu. ::: :::gallery paper-plane-kargo-render-front paper-plane-kargo-render-iso | Paper Plane kargo İHA'sının iki CAD render varyantı ::: :::center Altı kanatlı bu düzen, kalkış ve iniş için geniş bir alan ihtiyacını azaltırken kargo hacmini gövde merkezinde toplamayı hedefliyordu. Bu çalışma benim için aynı zamanda CAD tarafında ciddi bir egzersizdi: her kol veya kargo modülü değişikliği, gövde kesitini ve ağırlık merkezini yeniden hesaplamayı gerektiriyordu. Parametrik tasarımın neden lüks değil zorunluluk olduğunu ilk kez burada hissettim. ::: --- # Modüler Yazılım Mimarisi: Sınırları Nereden Kesmeli? source: https://mehmetseyrimez.com/blog/moduler-yazilim-mimarisi type: article published: 2024-10-05 updated: 2026-08-26 category: Serüven Notları tags: mimari, cad-cam, urun-gelistirme author: Mehmet Seyrimez reading_minutes: 6 > Endüstriyel projelerde sürdürülebilir kod tabanı: modül sınırını nereden kesmeli, API sözleşmeleri nasıl versiyonlanır, karar kayıtları ne işe yarar? Mühendislik yazılımı projelerinde modüler mimari, domain sınırlarını netleştirerek hem geliştirme hızını hem de sahada güvenilirliği artırır. Özellikle CAD/CAM ve otomasyon ürünlerinde “tek dev monolith” yaklaşımı kısa vadede hızlı görünse de orta vadede bakım maliyetini yükseltir. :::illustration full modular-blocks | Modüler bileşenler ve bağımlılık sınırları ::: ## Domain → yazılım sınırı Prefabrik üretim, roll-form hatları veya SolidWorks otomasyonu gibi alanlarda yazılım modülleri, **üretim gerçekliğine** göre ayrılmalıdır: geometri işleme, kural doğrulama, çıktı üretimi, lisans ve kullanıcı arayüzü birbirinden bağımsız evrimleşebilmelidir. > Domain bilgisi yazılım sınırını belirler; AI araçları bu sınırlar içinde hızlandırıcı olarak kullanılır. --- ## Önerilen modül grupları - **Core:** Geometri, parametre modeli, kural motoru - **Integration:** CAD API, dosya I/O, ERP/MES köprüleri - **Output:** Teknik resim, DXF/DWG, üretim verisi - **Platform:** Lisans, loglama, yapılandırma, UI :::illustration-left scrum-board | Ekip iş akışı ve modül sahipliği ::: ### Test ve doğrulama disiplini Modüler yapı, birim testlerinin anlamlı olmasını sağlar. Kritik modüllerde regresyon setleri — özellikle parametre değişim senaryoları — ürün güvenilirliğinin temelidir. :::illustration-right code-review-desk | Kod inceleme ve kalite kapıları ::: --- ## Üretim ortamına taşıma Pilot → sınırlı kullanıcı → tam roll-out akışı, mühendislik yazılımında özellikle önemlidir. Her aşamada ölçülebilir metrikler (hazırlık süresi, hata oranı, çıktı tutarlılığı) kaydedilmelidir; sayısal iddialar yalnızca bu verilerle desteklenmelidir. :::illustration full version-control | CAD/CAM mühendislik platformu ::: ## Sınır bağlam: nerede kesmeli Modülü teknolojiye göre değil, **değişim hızına** göre kesin. Aynı sebeple aynı anda değişen şeyler bir modülde durur; farklı sebeplerle değişenler ayrılır. CAD/CAM tarafında bu şöyle bir tabloya oturuyor: | Modül | Ne zaman değişir | Neye bağımlı olmalı | | --- | --- | --- | | Geometri çekirdeği | Nadiren — matematik değişmez | Hiçbir şeye | | Kural motoru | Sık — üretim standardı değiştikçe | Yalnızca geometri çekirdeğine | | CAD entegrasyonu | CAD sürümü yükseldikçe | Kural motorunun çıktısına | | Çıktı üreteci | Müşteri/hat talebiyle | Kural motoruna | | Platform (lisans, log) | Bağımsız | Hiçbir iş modülüne | Buradaki tek yön kuralı önemli: **hiçbir iş modülü platform modülünü çağırmamalı, platform da iş modülünü tanımamalı.** Lisans kontrolü geometri kodunun içine sızdığı an, o kodu test etmek için lisans sunucusu gerekir — ve testler yazılmaz. ## API sözleşmeleri ve versiyonlama Modüller arası sınır bir **veri sözleşmesidir**, fonksiyon imzası değil. Sözleşmeyi açık bir tipte tutun ve o tipi versiyonlayın: Sözleşmeyi somutlaştıralım. Diyelim kural motoru bir panel üretiyor. CAD katmanının bilmesi gereken tek şey şu birkaç alan: **şema sürümü**, genişlik, yükseklik, profil tipi ve boşluk listesi. Başka hiçbir şey. Kural motorunun içinde bu değerlerin nasıl hesaplandığı CAD katmanını hiç ilgilendirmez. Buradaki `şema sürümü` alanını **ilk günden** koyun, değeri `1` olarak dursa bile. Sebebi şu: alan eklemek kırıcı bir değişiklik değildir, ama alan **kaldırmak** ya da anlamını değiştirmek kırıcıdır. Kırıcı bir değişiklik geldiğinde sürümü artırır ve eski sürüm için küçük bir dönüştürücü yazarsınız. Bu, tüm tüketicileri aynı gün güncellemek zorunda kalmaktan çok daha ucuza gelir. `SchemaVersion` alanını baştan koyun, ilk sürümde `1` olarak dursun bile. Alan eklemek kırıcı değildir; alan **kaldırmak** veya anlamını değiştirmek kırıcıdır. Kırıcı değişiklikte sürümü artırıp eski sürüm için bir dönüştürücü yazmak, tüm tüketicileri aynı gün güncellemek zorunda kalmaktan ucuzdur. > Sözleşmeyi dosyaya (JSON/XML) yazılabilir tutun. Diskte okunabilen bir ara format, hata ayıklamada elinizdeki en güçlü araçtır: müşteriden gelen "şu iş çalışmıyor" mesajı, tek bir dosyaya indirgenebilir. :::illustration-left scrum-board | Ekip iş akışı ve modül sahipliği ::: ## Karar kayıtları: neden'i koda gömmeyin Mühendislik yazılımında en pahalı bilgi kaybı, bir kararın **gerekçesinin** unutulmasıdır. Altı ay sonra "bu profil hesabı neden böyle?" sorusuna cevap veremeyen ekip, ya kodu olduğu gibi bırakır ya da yanlış düzeltir. Ağır bir süreç gerekmez. Depo içinde `docs/kararlar/` altında, her kararı tek sayfada tutan kısa notlar yeter: 1. **Bağlam** — hangi kısıt bu kararı zorunlu kıldı (hat toleransı, CAD API sınırı, müşteri standardı) 2. **Karar** — ne yapmaya karar verildi 3. **Sonuç** — bunun neyi kolaylaştırdığı, neyi zorlaştırdığı 4. **Reddedilen alternatifler** — ve neden reddedildikleri Dördüncü madde en değerlisidir; aynı alternatifin bir yıl sonra tekrar önerilmesini engeller. ### Test disiplini: hangi modülde ne test edilir - **Geometri çekirdeği** — saf birim testleri. Bağımlılığı olmadığı için en ucuz ve en hızlı testler burada; kapsama oranı en yüksek burada olmalı. - **Kural motoru** — senaryo testleri. Gerçek üretim vakalarını girdi/beklenen-çıktı çiftleri olarak dondurun; standart değiştiğinde hangi vakaların kaydığını anında görürsünüz. - **CAD entegrasyonu** — az sayıda, gerçek CAD oturumuna karşı çalışan duman testi. Pahalıdır, bu yüzden azdır; ama sıfır olmamalı. - **Çıktı üreteci** — anlık görüntü (snapshot) testleri. Üretilen DXF'in bayt bayt aynı olması gerekmez, ama katman adları ve ölçüler sabit kalmalı. :::illustration-right code-review-desk | Kod inceleme ve kalite kapıları ::: ## AI destekli geliştirmede modül sahipliği AI araçları modüler mimaride belirgin biçimde daha verimli çalışıyor — sebebi basit: sınırı net olan bir modül, modelin bağlam penceresine sığar. Karşılığında iki kural koyuyorum: - **Sınırlar insanda kalır.** Modülün ne yapıp ne yapmayacağına, sözleşmenin şekline ve bağımlılık yönüne ben karar veririm. Bu kararlar yanlışsa, hızlı üretilen kod yanlışı hızlı çoğaltır. - **Sözleşme testi olmayan modülde AI kullanılmaz.** Üretilen kodu doğrulayacak bir mekanizma yoksa, kazanılan hız doğrudan risk olarak geri döner. Pratikte en iyi sonucu, geometri çekirdeği gibi **girdisi ve çıktısı saf** modüllerde alıyorum; en kötü sonucu, CAD API'siyle konuşan ve durum taşıyan katmanlarda. --- ## Üretime taşırken ölçün Pilot → sınırlı kullanıcı → tam roll-out akışında her aşamada aynı üç sayıyı kaydedin: **hazırlık süresi**, **hata oranı**, **çıktı tutarlılığı**. Sayısal iddialar yalnızca bu kayıtla desteklenmeli — "çok hızlandı" cümlesi bir mühendislik iddiası değildir. :::callout Pratikte Bu yaklaşımın uygulanmış hâlini prefabrik ve hafif çelik için geliştirdiğim CAD/CAM platformunda görebilirsiniz: geometri çekirdeği, kural motoru ve çıktı üreteci ayrı ayrı evrimleşiyor, lisans katmanı hiçbirini tanımıyor. ::: ## Sık Sorulan Sorular **Modüler yazılım mimarisi nedir?** Bir sistemi, birbirine yalnızca açık sözleşmelerle bağlanan bağımsız parçalara ayırmaktır. Mühendislik yazılımında bu ayrım teknolojiye göre değil, **değişim hızına** göre yapılır: aynı sebeple aynı anda değişen şeyler bir modülde durur. **Modül sınırını nereden geçirmeliyim?** Değişim sebebinden. Geometri çekirdeği nadiren değişir, kural motoru üretim standardı değiştikçe sık değişir, CAD entegrasyonu sürüm yükseldikçe. Farklı sebeplerle değişen kodu aynı modülde tutmak, en yaygın mimari hatadır. **Modüller arası sözleşme nasıl tanımlanır?** Fonksiyon imzasıyla değil, açık bir veri tipiyle. O tipe bir şema sürümü alanı ekleyin ve dosyaya yazılabilir (JSON/XML) tutun; diskte okunabilen bir ara format, hata ayıklamada elinizdeki en güçlü araçtır. **Karar kayıtları (ADR) neden gerekli?** Mühendislik yazılımında en pahalı bilgi kaybı, bir kararın gerekçesinin unutulmasıdır. Bağlam, karar, sonuç ve reddedilen alternatifleri tek sayfada tutmak yeterlidir; dördüncü madde aynı alternatifin bir yıl sonra tekrar önerilmesini engeller. **Hangi modülde ne test edilmeli?** Geometri çekirdeğinde saf birim testleri, kural motorunda gerçek üretim vakalarından dondurulmuş senaryo testleri, CAD entegrasyonunda az sayıda gerçek oturum duman testi, çıktı üretecinde anlık görüntü testleri. **Yapay zeka destekli geliştirme modüler mimaride neden daha verimli?** Sınırı net olan bir modül modelin bağlam penceresine sığar. Ancak iki kural şart: sınır kararları insanda kalmalı ve sözleşme testi olmayan bir modülde üretilen kod kullanılmamalıdır. --- # Python ile SolidWorks Otomasyonu: Nereden Başlanır source: https://mehmetseyrimez.com/blog/python-solidworks-otomasyonu type: article published: 2024-09-28 updated: 2026-08-26 category: CAD Otomasyon tags: solidworks, python, api, otomasyon, com author: Mehmet Seyrimez reading_minutes: 8 > Python ile SolidWorks'e COM üzerinden bağlanmak, parametre güncellemek ve çıktı paketi üretmek nasıl çalışır? Tuzaklar ve C#'a geçiş eşiği. Kısa cevap şu: **Python ile SolidWorks otomasyonu tamamen mümkün ve keşif için en hızlı yol** — ama üretime giden kalıcı bir eklenti yazacaksanız yolun bir yerinde C# / .NET'e geçmeniz gerekir. Python'un SolidWorks'e bağlanma biçimi COM üzerinden; yani aynı API'yi kullanıyorsunuz, sadece farklı bir kapıdan giriyorsunuz. Bu yazıda o kapıyı nasıl açacağınızı, içeride nelere dikkat edeceğinizi ve hangi noktada başka bir yola geçmeniz gerektiğini konuşacağız. Kod yazmayacağım — mantığı ve kararları anlatacağım, çünkü asıl zorluk sözdiziminde değil, tuzakları önceden bilmekte. SolidWorks API'sinin ne olduğunu hiç bilmiyorsanız önce [SolidWorks API nedir](https://mehmetseyrimez.com/blog/solidworks-api-nedir) yazısına göz atmanızı öneririm; buradaki her şey o zemine oturuyor. :::illustration full code-sample | Python: SolidWorks otomasyonunun keşif dili ::: ## Python SolidWorks'e nasıl 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](https://mehmetseyrimez.com/blog/solidworks-api-nedir) 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. ## Parametreleri güncellemenin doğru yolu 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. :::callout Bu, mimari bir karardır Global değişkenle sürmek sadece bir kolaylık değil; otomasyonun **sözleşmesini** tanımlar. Betik ile model arasındaki anlaşma "şu isimleri bilirim" olur. Model tarafında kim ne değiştirirse değiştirsin, bu isimler durduğu sürece otomasyon ayakta kalır. ::: 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. :::illustration right local-server | COM köprüsü: aynı API, farklı kapı ::: ## Oturum yönetimi: betiğin asılı kalmasını önlemek 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. ## Çıktı paketi üretimi: sahada en çok hissedilen fayda 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. :::illustration left factory | Çıktı paketi: sonucu anında görülen otomasyon ::: ## Python nerede biter, C# nerede başlar 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](https://mehmetseyrimez.com/blog/solidworks-add-in-gelistirme) yazısında ayrıntılı anlattım. ## Nereden başlamalı: ilk betiğiniz 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. ## Sık Sorulan Sorular **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. ## Özet 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. --- =============================================================================== # Topic guides (EN) =============================================================================== # SolidWorks Automation: Macro vs API vs Add-in Guide source: https://mehmetseyrimez.com/en/guides/solidworks-otomasyonu type: topic guide published: 2026-09-01 updated: 2026-09-01 keywords: solidworks automation, what is a solidworks macro, what is the solidworks api, solidworks add-in, solidworks add-in development, how to write a solidworks macro, solidworks macro vs api, solidworks vba, python solidworks, cad automation author: Mehmet Seyrimez > SolidWorks automation means handing repetitive CAD work to software through the SolidWorks API. It has three layers: VBA macros that can be recorded and live in a single file, the API itself where you address the object model directly, and C#/.NET add-ins that load into SolidWorks and run inside it. All three use the same API; what differs is where the code lives and how it is distributed. ## What is SolidWorks automation? Changing a dimension and updating the drawing, exporting hundreds of files to PDF, filling in custom property fields one at a time — all of it can be done by hand. Automation means having SolidWorks do the same work on command from code. The thing that carries that command is the SolidWorks API. The API is the layer that lets you reach every object inside SolidWorks — application, document, feature, dimension, configuration — from code. Macros and add-ins both use this same layer; the difference is not API access but how the code is stored and shipped. Short answer: a macro is the fastest way to use the API. An add-in is the way to ship that same API work at team scale. The API is the common ground under both. ## Macro, API or add-in? A decision table | | VBA Macro | C# / .NET Add-in | Python (COM) | | Where it runs | Inside SolidWorks, a .swp file | A DLL loaded into SolidWorks | Outside, as its own process | | Installation | Hand over the file and run it | Needs registration and an installer | Python plus pywin32 | | User interface | Simple form | CommandManager, PropertyManager tab | None, or your own | | Use it when | One desk, quick job | Team-wide, versioned product | Batch work, data processing, integrations | | Maintenance | Gets harder as files multiply | Version control and tests are possible | Easy at script level | A practical rule: if the job stays on one person's desk and runs a few times a week, a macro is enough. Once the same job spreads across a team, needs a user interface, and has to be versioned, it is time to move to an add-in. If you will process data outside SolidWorks — generating hundreds of variants from an Excel list, say — Python is usually the shortest path. ## How do you write a SolidWorks macro? A learning order - Record with the Macro Recorder: Do the job by hand and record it. The generated code is messy, but it shows you which interfaces get called — it is the fastest way to search the API. - Read the object model: SldWorks → ModelDoc2 → document type → Feature / Configuration / Dimension. You cannot skip a step in that chain; internalising the hierarchy matters more than memorising methods. - Throw away selection-based code: A recorded macro reaches objects through whatever the user had selected, and that is brittle. Move to code that reaches objects by name or by identity. - Add error handling: Closed file, missing configuration, renamed feature — a macro meets all of these in production. Do not swallow errors silently; report them. - Bind it to a button and a shortcut: A macro that is hard to launch does not get used. Add a toolbar button or assign a keyboard shortcut. - Move to an add-in when you ship it: Once the same macro exists in three versions on three machines, it is a product. A C# add-in solves versioning and installation. ## What can you automate in SolidWorks? - Building a complete assembly and its configurations from entered dimensions - Generating drawing sheets, views and dimensioning automatically - Packaging PDF, DWG, DXF and flat-pattern output in one command with standard naming - Filling custom property fields consistently with the bill of materials - Batch saving, converting and reporting across hundreds of files in a folder - Checking design rules: missing properties, wrong material, non-standard dimensions The most direct gain is eliminating the repeated modelling of the same work. The second — often more valuable — gain is standardisation: when output naming, folder structure and revision numbering are part of the automation, the files that reach production no longer vary by whoever made them. ## How is AI changing SolidWorks automation? Language models can produce SolidWorks API code, but between the size of the API surface and the subtleties of the COM object lifecycle, that code often does not run unverified. The gain is in scaffolding and in searching documentation; the loss is in shipping unverified code to production. ## From macro to product: how to set the project up The first week of an automation project is decided by what you measure, not by which tool you pick. Measure the repeated work first, choose a pilot, then grow it in the field. Tool choice comes at the end of that order. ## FAQ ### What is a SolidWorks macro? A SolidWorks macro is a VBA program that runs inside SolidWorks and automates CAD work through the API. It can be recorded with the Macro Recorder or written by hand, lives in a single .swp file, and runs without any installation. ### What is the SolidWorks API? The SolidWorks API is the COM-based interface layer that lets you reach the SolidWorks object model from code. You start at the SldWorks.Application root and travel through ModelDoc2, PartDoc, AssemblyDoc and DrawingDoc to features, dimensions and configurations. Macros and add-ins both use this same API. ### What is the difference between a SolidWorks macro and an add-in? Both use the same API; the difference is distribution. A macro is a single file, needs no installation, and is fast for one user. An add-in is a DLL loaded into SolidWorks: it can create its own toolbar and PropertyManager tab, can be versioned, and is deployed team-wide through an installer. ### Which language should I learn for SolidWorks automation? VBA to begin with, because the Macro Recorder emits VBA directly and the object model you learn carries over to every other language. C# / .NET if you are building a product for a team. Python with pywin32 is usually the shortest path when you are processing data outside SolidWorks or doing batch work. ### How do you run a SolidWorks macro? Through Tools → Macro → Run, selecting the .swp file. For macros you use often, Tools → Customize lets you add a toolbar button or assign a keyboard shortcut, so the macro runs in one click instead of being hunted for in a menu. ### Why is my SolidWorks macro not working? Three common causes: the recorded macro produced selection-based code and the object is no longer selected; ModelDoc2 was accessed with no open document; or the referenced feature has been renamed. The fix for all three is the same — reach objects by name or identity rather than by selection. --- # AutoCAD Automation: AutoLISP, Plugin and Bundle Guide source: https://mehmetseyrimez.com/en/guides/autocad-otomasyonu type: topic guide published: 2026-09-01 updated: 2026-09-01 keywords: autocad automation, what is autolisp, autocad lisp, autocad plugin, autocad bundle, autocad add command, autolisp load, objectarx, autocad batch processing, cad automation author: Mehmet Seyrimez > AutoCAD automation means having AutoCAD do repetitive drawing work on command from code. It has three layers: AutoLISP for quick commands and routines, .NET (ObjectARX) for versioned plugins with a real interface, and Autodesk's .bundle package format for shipping those plugins without an installer. ## What is AutoCAD automation? Setting up the layer standard by hand in every drawing, filling attributes one at a time, opening hundreds of DWGs to print them to PDF — most of the time spent in AutoCAD goes to work like this. Automation means having AutoCAD's own command line and object model do it from code. AutoCAD exposes more than one surface for automation. The lowest-threshold one is AutoLISP: a language that ships inside AutoCAD, needs no separate compiler, and lives in a plain text file. For larger work, the .NET API and ObjectARX take over. Short answer: AutoLISP is for writing commands and routines, .NET is for building plugins and products. The two run side by side in the same installation. ## AutoLISP or .NET? A decision table | | AutoLISP / Visual LISP | .NET (C# / VB.NET) | Script (.scr) | | File | .lsp plain text | Compiled .dll | .scr command list | | Compilation | Not needed | Visual Studio required | Not needed | | Interface | Simple DCL dialog | Palette, ribbon tab, WPF | None | | Object access | Drawing entities, command line | Full object model and database | Commands only | | Use it when | Shortcut commands, daily routines | Products, team plugins, complex logic | Fixed-order batch work | | Deployment | Startup Suite, acaddoc.lsp | .bundle package | Run manually | AutoLISP's biggest advantage is its low threshold: a text editor and AutoCAD are enough, and you can try the line you just wrote immediately. Moving to .NET costs you an install and a build chain; in return you get a real interface, version control, and much faster code. ## How do you package an AutoCAD plugin? (.bundle) The cleanest way to ship a plugin to a team is Autodesk's bundle format. A bundle is an ordinary folder whose name ends in .bundle; inside it sits a PackageContents.xml describing what the plugin is and how to load it, plus a Contents folder holding the files. Copy that folder into AutoCAD's ApplicationPlugins directory and the plugin is picked up on its own: no registry writes, no installer to build, no asking users to run APPLOAD. Removing it is just as simple — delete the folder. - PackageContents.xml declares the plugin's name, version, author, and which AutoCAD releases it supports - One bundle can carry several components at once: .lsp routines, .NET assemblies, menu and ribbon definitions - Declaring a version range lets a single package serve multiple AutoCAD releases - It can be deployed by copying from a shared network folder or through group policy The rule: a one-person routine can stay a .lsp file; anything shipped to a team should be a bundle. Otherwise the question "who has which version?" turns up sooner or later. ## What can you automate in AutoCAD? - Setting up the layer, linetype and text style standard in one command - Filling and exporting attribute fields in bulk - Batch PDF, DXF or version conversion across every DWG in a folder - Writing title block and sheet data automatically from project data - Drawing cleanup: purging unused blocks, layers and styles - Extracting dimension, area and count reports from the drawing into a table ## From routine to product: how to set the project up The order is the same on the AutoCAD side: measure how often a job actually repeats, pick a pilot, then roll it out to the team. Which layer you use — LISP or .NET — becomes clear at the end of that measurement, not at the start. ## FAQ ### What is AutoLISP? AutoLISP is a programming language built into AutoCAD, used to automate drawing work. It needs no separate compiler; the code lives in a plain text file with a .lsp extension and runs as soon as it is loaded into AutoCAD. ### How do you add a new command to AutoCAD? In AutoLISP, any function defined with a C: prefix on its name becomes a command callable from the AutoCAD command line. Once the file is loaded with APPLOAD the command is available; to have it ready on every launch, use the Startup Suite or acaddoc.lsp. ### What is an AutoCAD bundle? A bundle is Autodesk's plugin packaging format: an ordinary folder whose name ends in .bundle, containing a PackageContents.xml manifest and a Contents folder. Copied into AutoCAD's ApplicationPlugins directory, the plugin is recognised without registry entries or an installer. ### Should I use AutoLISP or .NET? AutoLISP for shortcut commands and daily routines — the threshold is low and nothing needs compiling. .NET if you are building a versioned plugin with an interface that ships to a team. The two can coexist in the same installation, and most teams use both. ### How do you load an AutoLISP file automatically at startup? Two common routes: add the file to the Startup Suite, or load it from acaddoc.lsp. If a team shares a common folder, adding that folder to AutoCAD's support file search path gives everyone the same setup. ### What can be automated in AutoCAD? Setting up layer and style standards, bulk-filling attribute fields, batch PDF/DXF conversion of every DWG in a folder, writing title block data from project data, drawing cleanup, and extracting reports from a drawing into a table are the jobs most often automated. --- =============================================================================== # English articles =============================================================================== # AutoCAD Automation: LISP, .NET, or AI? A Decision Table source: https://mehmetseyrimez.com/en/blog/autocad-otomasyonu-lisp-net-yapay-zeka type: article published: 2026-08-20 updated: 2026-08-26 category: Automation Workshop tags: autocad, otomasyon, yapay-zeka, cad-otomasyon author: Mehmet Seyrimez reading_minutes: 5 > AutoCAD automation has three routes: AutoLISP, .NET/ObjectARX and AI-assisted code. Which one fits your team size and maintenance load, in one decision table. The AutoCAD automation question is almost always asked the wrong way round: *"should I write LISP or .NET?"* The right question is: **who will maintain this, and how long will it live?** Those two answers pick the tool. :::illustration full autocad-drafting | The parameter, rule, and output chain ::: ## The honest profile of each route ### AutoLISP Fastest start. One file, no build step, runs immediately inside the drawing environment. For small, local jobs — layer cleanup, batch plotting, attribute extraction — it is still the most practical route. Its limit arrives with complexity: weak error handling, no practical unit testing, and a large LISP file that grows harder to maintain over time. There is also a quiet cost — when the person who knew LISP leaves, the code is orphaned in most companies. ### .NET / ObjectARX Compiled, testable code that lives in version control. The right call when you need complex rule layers, external data sources, or enterprise deployment. The price is setup cost: project structure, references, signing, deployment. For a small job that overhead is not worth paying. ### AI-assisted generation This needs care, because two different things travel under one name: - **A code-writing assistant.** It writes the LISP routine or .NET add-in for you. This does not *replace* the two routes above — it **accelerates** them. - **A command-understanding assistant.** It turns a plain-language description into a macro. Useful for exploration and one-off work, but it does not belong in a production flow without a validation layer. Miss that distinction and you replace a sustainable solution with a one-off output while telling yourself "AI does this now". :::illustration right knowledge | The decision: who maintains it, how long it lives ::: ## Decision table The thresholds I use in practice: | Situation | Choice | Reason | | --- | --- | --- | | One person, runs a few times | AutoLISP | Don't let setup cost eat the gain | | A team will use it, contains rules | .NET | Testing and version control are essential | | External data / ERP connection | .NET | LISP does not carry that load | | Scope still unclear | AI + LISP | Explore first, build the durable version after | | Produces output that goes to production | .NET + validation | Silent faults are the expensive ones | The last row matters most. In automation that produces manufacturing output, tool choice comes second; **verifying the output** comes first. ## The common mistake: picking the tool before the problem A company arrives saying "we have these LISP routines in AutoCAD, let's have AI rewrite them." That is not the first question to ask. First you measure: what job do these routines do, how often does that job repeat, and where is time actually being lost right now? The answer is often that half the existing routines are no longer used, and the real loss is somewhere else entirely. I walked through that sequence in [how I start an automation project](https://mehmetseyrimez.com/en/blog/otomasyon-projesine-nasil-baslanir) — the same order applies on the AutoCAD side. ## Frequently Asked Questions **Should I choose AutoLISP or .NET for AutoCAD automation?** The decision is not about technical superiority but sustainability: who will maintain the code, and how long will it live? AutoLISP for single-person, short-lived, drawing-editing work; .NET when a team will use it, when it carries rules, or when it connects to external data. **Is AutoLISP still used, or is it a dead technology?** Very much alive. It has stayed almost unchanged since the 1980s and is supported in every AutoCAD release. For small, fast automations close to the drawing environment it is still the most practical route. **What is the difference between ObjectARX and .NET?** ObjectARX is the C++-based, lowest-level and most powerful extension route; .NET reaches the same API through managed code. For most enterprise needs .NET is sufficient and markedly cheaper to develop. **Will AI replace LISP and .NET in AutoCAD automation?** No — it accelerates both. Code assistants shorten the time to write a routine, but verifying the generated code is still on you; nothing should run in a production flow without a verification layer. **Should I migrate my existing LISP routines to .NET?** Not all of them. Migrate only the ones a team uses, that carry rules, and whose maintenance has become heavy. In most companies a large share of existing routines is no longer used at all; measure what actually runs before migrating. **What matters most in automation that produces production output?** Tool choice comes second; verifying the output comes first. Automation that silently produces wrong output is far more expensive than automation that crashes, because the error is caught on the shop floor. ## Summary LISP is not dead, .NET is not always right, and AI does not replace either. What decides the choice is not technical superiority but **sustainability:** who will read the code, who will change it, and how long it will live. Next in the series: how to measure automation gains honestly. --- # SolidWorks 2026 AI Features: What They Don't Automate source: https://mehmetseyrimez.com/en/blog/solidworks-2026-yapay-zeka-ozellikleri type: article published: 2026-08-18 updated: 2026-08-26 category: Automation Workshop tags: solidworks, yapay-zeka, otomasyon, cad-otomasyon author: Mehmet Seyrimez reading_minutes: 5 > SolidWorks 2026 automates drawing generation and standard hardware recognition. Which minutes of the working day they give back — and which they never will. A CAD release shipping with an "AI" headline is no longer news. The real question is narrower: which minutes of the working day do these features give back, and which ones do they not? Two capabilities stand out in SolidWorks 2026 — automatic drawing generation and standard hardware recognition. Both touch a genuine loss line. And both run into the same boundary I keep meeting in automation projects: **work that can be turned into a rule can be handed over; work that requires judgement cannot.** :::illustration full ai-agent | Input, decision layer, production output ::: ## Automatic drawing generation Producing a manufacturing drawing with a single command is the most striking feature on paper. In practice the honest reading is: it builds **the skeleton** of the drawing. View placement, sections, base dimensioning — repetitive, rule-shaped work, the part best suited to automation. What cannot be handed over is the drawing's *meaning*: which dimension is critical, which tolerance shifts with the manufacturing method, which note is mandatory for a given supplier. Those require knowing the product and the line it will be built on. So measuring this feature as "drawing time went to zero" is misleading. The correct measurement is: **how much shorter is the path to a first draft, and did correction time go up or down?** Measure only the first and you will overstate the gain. ## Standard hardware recognition Recognising bolts, nuts, and washers and placing them into an assembly visibly shortens preparation on complex products. The value of this feature lies in multiplying the saving by **repetition count**. On an assembly with hundreds of fasteners the gain is serious; on a ten-part product it is not noticeable at all. The return on automation is always time saved multiplied by repetition — something I covered in more detail in [how I start an automation project](https://mehmetseyrimez.com/en/blog/otomasyon-projesine-nasil-baslanir). :::illustration right predictive-analytics | Gain = time saved × repetition count ::: :::illustration left document-analysis | Built-in features solve the generic case, not the company-specific one ::: ## What changes for add-in developers The real question here is whether writing add-ins becomes pointless as built-in features arrive. In my own experience the opposite happened. Built-in AI features solve the **generic** case: a standard part, a standard drawing layout. They do not solve the company-specific case — they do not know your output naming convention, your revision numbering, or the file package your supplier expects. The value of add-in development sits in that gap, and the gap is not shrinking: - **The rule layer.** Engineering rules specific to a product family are still defined by hand. - **The validation layer.** The layer that checks whether AI-produced output conforms to the company standard. - **Packaging.** Getting PDF, DWG, DXF, and bend drawings into the right names and the right folders. Script-level export patterns are covered in [SolidWorks Python scripting](https://mehmetseyrimez.com/en/blog/python-solidworks-otomasyonu); production packaging usually moves to add-ins once rules stabilise. New features improve the *input* to those three layers; they do not replace them. ## Three questions to ask before measuring The checklist I use when evaluating a release's AI feature: | Question | Why it matters | | --- | --- | | Which task does this shorten? | "Generally faster" is an unmeasurable claim. | | How many times a month does that task repeat? | At low repetition even the best feature is invisible. | | How long does verifying the output take? | If verification eats the saving, the net gain is zero. | The third is the most frequently skipped. If automated output gets re-checked from scratch every time, the saved time has been handed back to the checking desk. ## Summary The AI features in SolidWorks 2026 do real work — but the work they do is the repetitive, rule-shaped part. The judgement-shaped part stays where it was, and that is exactly where add-in development lives. Next in this series: the AutoCAD side, and how to measure automation gains honestly. ## Frequently Asked Questions **What are the AI features in SOLIDWORKS 2026?** Two stand out: one-command automatic drawing generation, and recognition and placement of standard hardware (bolts, nuts, washers). Both touch repetitive, rule-bound work. **Does automatic drawing generation eliminate drawing time?** No. It builds the skeleton: view placement, sections, basic dimensioning. Which dimension is critical, which tolerance shifts with the production method, and which note is mandatory for a supplier all still sit with the engineer. **How do you measure the real gain from these features?** By measuring the reduction in time-to-first-draft **together with** the change in correction time. Looking only at generation time makes the gain look larger than it is. **Do built-in AI features make add-in development unnecessary?** No. Built-in features solve the generic case; they do not know your output naming convention, your revision numbering or the file package your supplier expects. The rule layer, the verification layer and packaging remain add-in work. **Does standard hardware recognition pay off in every assembly?** The gain is multiplied by repetition. In an assembly with hundreds of fasteners it is substantial; in a ten-part product it is not even noticeable. **What should I ask when evaluating a new release's AI feature?** Three questions: which task does it shorten, how often is that task repeated per month, and how many minutes does verifying the output take? The third is the most skipped and the one that decides the gain. --- # Generative AI in CAD Automation: A Practical Framework source: https://mehmetseyrimez.com/en/blog/uretken-yapay-zeka-cad-otomasyonu type: article published: 2024-10-12 updated: 2026-08-26 category: Artificial Intelligence tags: generative-ai, cad, llm, solidworks author: Mehmet Seyrimez reading_minutes: 7 > Where generative AI fits in CAD automation: input normalisation, rule engine, validation and documentation layers — how to scope a pilot and where to stop. Traditional computer-aided design (CAD) workflows can gain a new layer of adjustability through the controlled integration of generative AI models. This article offers a technical framework for thinking about how parametric modelling and LLM-assisted workflows fit together. :::illustration full ai-code-assistant | AI-assisted engineering automation ::: ## Why think about CAD and LLMs together? Repetitive operations in a CAD environment — dimension updates, assembly revisions, output packages — are mostly rule-based. LLMs can bridge those rules with natural language and structured input; but geometric correctness and manufacturing reality must stay with engineering discipline and validation layers. > Important: AI is leverage for speed and iteration; architectural decisions, testing, and quality remain the responsibility of a person. --- ## Practical integration layers - **Input normalisation:** turning user dimensions, material, and variant choices into a structured form - **Rule engine:** the engineering rules that trigger parametric CAD updates - **Validation:** geometry, assembly interference, and production output checks - **Documentation:** the standard flow of PDF, DWG, DXF, and production-data packages :::illustration-left data-input | Parameter → rule → CAD → output flow ::: ### Where LLMs are strong Converting natural-language input into structured parameters, simplifying error messages, and producing repetitive documentation text are valuable at this layer. ### Where LLMs are not enough on their own Critical geometry calculations, tolerance chains, production-line compatibility, and licensed CAD API limits require human oversight. :::illustration-right design-thinking | Parametric rule panel and design variations ::: --- ## How I scope a pilot "Let's do CAD automation with AI" is not a project definition. Every attempt started without narrowing the pilot ends the same way: a demo that works but nobody trusts. I narrow it with four questions: 1. **Which task repeats, and how many times a month?** Automating something done three times a month costs more than it returns. 2. **How structured is the input?** Do the dimensions arrive from a form or from the body of an email? The second is where an LLM genuinely adds value. 3. **What does a wrong output cost?** A wrong quotation drawing gets corrected; a wrong DXF sent to cutting turns sheet metal into scrap. As the cost rises, the validation layer thickens. 4. **Who knows the right answer?** If nobody can confirm the output is correct, the pilot cannot be measured. A good first pilot is usually this: a task that **repeats often, has messy input, and where being wrong is cheap.** In most firms, the quotation stage fits that description exactly. ## Measurement: what to measure, and when If you do not measure the current state **before** the pilot starts, you have no baseline afterwards. The four metrics I record: | Metric | How it is measured | Why it matters | | --- | --- | --- | | Preparation time | Minutes from receiving input to output ready | The gain people feel directly | | Correction rate | What share of automatic output was edited by hand | The real indicator of trust | | Right first time | Percentage of jobs needing no correction at all | The automation's maturity level | | Escaped errors | Errors caught only once they reached production | The only true failure metric | Of these, the **correction rate** teaches the most. A high rate does not mean the automation is not working; it shows where the rule set is incomplete. Looking at where corrections cluster writes the agenda for the next development round on its own. ## The validation checklist The checks every automatic output must pass before reaching production — in order, stopping at the first failure: 1. **Input completeness** — did every required parameter arrive, are the units right 2. **Range check** — is each dimension within a manufacturable range (line width, minimum bend radius, sheet thickness) 3. **Geometry health** — did the rebuild complete without errors, are there open contours or zero-thickness faces 4. **Assembly interference** — is the interference check clean 5. **Output integrity** — were all expected files produced, are their sizes plausible 6. **Naming and revision** — does the filename follow the scheme, has the revision number advanced This entire list is **deterministic**; there is no LLM at any step of it. The model's job was to understand the input and turn it into parameters; correctness is decided by rule code. > The separation must be clean: an LLM's output never goes straight to production, it always becomes the rule engine's input. If the rule engine rejects it, the job stops. ## Where to stop Accepting up front where generative models are **not good** on the CAD side is the decision that saves the project: - **Tolerance chains.** Cumulative tolerance calculation is arithmetic and standards work, not judgement. Do not hand it to the model. - **Critical geometry.** Strength, centre of gravity, section calculations — these are library work, not generation work. - **CAD API limits.** Which call returns what in which version is documented knowledge; this is exactly where hallucination is most likely. - **Production-line reality.** The model does not know what the roll-form line can bend; that knowledge is entered into the rule set by hand. Against that, there are three places the model genuinely pays: **structuring messy input** (an email, a phone note, the description of a hand sketch), **translating error messages into language the user understands**, and **producing repetitive documentation text**. --- ## The framework in short I order it like this: pick a narrow pilot → measure the current state → give input normalisation to the LLM → leave the decision to the rule engine → validate the output with a deterministic checklist → grow the rule set by watching the correction rate. This loop survives changes in the technology. When the model gets better, the first step gets faster; but the need for the validation layer does not shrink. :::callout Related I applied this framework in its embedded form inside SolidWorks with ParametriX — designing the flow from natural language and 2D input to a parametric 3D model, together with its rule and validation layers. ::: ## Frequently Asked Questions **What is generative AI actually good for in CAD design processes?** Its highest-value job is structuring messy input: turning an email, a phone note or a description of a hand sketch into a parameter set. It is also strong at translating error messages into language a user understands and at producing repetitive documentation text. **Can LLM output go straight to production?** No. The model's output should never go directly to production; it is always the input to the rule engine. If the rule engine rejects it, the job stops. Correctness is decided by deterministic rule code, not by the model. **How do you scope a pilot for AI-assisted CAD automation?** With four questions: how often does the task repeat per month, how structured is the input, what does a wrong output cost, and who knows the right answer? A good first pilot is usually frequently repeated, with messy input, where being wrong is cheap — quoting fits that description in most companies. **Which metrics should be tracked?** Preparation time, rework rate, first-time-right percentage and errors that escape to production. Rework rate is the most instructive: it points straight at where the rule set is incomplete. **Where are generative models weak on the CAD side?** Tolerance stack-up, critical geometry calculations, CAD API limits and shop-floor reality. Those four are library, documentation and rule-set work; left to a model, they are the areas most exposed to hallucination. **What should the validation layer cover?** Input completeness, range checks, geometry health, interference, output completeness, and naming/revision checks. The whole list must be deterministic — no step should involve the model. --- # What Is AutoLISP and What Is It Used For in AutoCAD? source: https://mehmetseyrimez.com/en/blog/autolisp-nedir type: article published: 2026-08-26 category: Automation Workshop tags: autocad, autolisp, otomasyon, cad-otomasyon, lisp author: Mehmet Seyrimez reading_minutes: 13 > AutoLISP is a language that runs inside AutoCAD and lets you write your own commands. What .lsp files do, its real limits, and when to move up to .NET. At its shortest: **AutoLISP is a programming language that runs inside AutoCAD and lets you write your own commands.** You write it in a `.lsp` file, load it into AutoCAD, and it runs the moment you type it at the command line. No compilation, no installation, no project file — what you write becomes part of the drawing environment directly. That is why it has survived forty years. And it is why the fastest answer to "can we automate this job in AutoCAD" is still, often, AutoLISP. Let's start from the beginning. I am aiming at an explanation you can follow even if you have never written code: where exactly LISP sits inside AutoCAD, what it solves, what it cannot solve, and when you need to move to another route. :::illustration full knowledge | AutoLISP: a small language living inside AutoCAD ::: ## What AutoLISP actually is AutoLISP is a version of the LISP programming language adapted for AutoCAD. It was added to AutoCAD in the mid-1980s and has stayed almost unchanged since — which is remarkable for a piece of software. Three properties made it this durable in the AutoCAD world: **It is interpreted, not compiled.** The text file you write runs directly. You make a change, reload, and see the result in seconds. In a .NET add-in that loop takes minutes. **It lives inside the drawing.** LISP code reaches the AutoCAD drawing database directly. It can select objects on screen, read their properties, change them, create new ones. It is not a separate application but an extension of the drawing environment. **It behaves like a command.** You can bind a function you wrote to the command line so that it is indistinguishable from AutoCAD's built-in commands. From the user's point of view there is no difference between `LINE` and the `QUICK-TITLE` you wrote. Put those three together and you get this: **you can shape your own AutoCAD.** Commands that match how your company works, checks that match your standards, automation that matches your drawing scheme. ### What a `.lsp` file means AutoLISP code sits in a plain text file with a `.lsp` extension. You can open and read it even in Notepad — one of my favourite things about LISP: the code is transparent, nobody can hand you a closed box. Other extensions you may run into: | Extension | What it is | | --- | --- | | `.lsp` | Plain AutoLISP source — readable, editable | | `.fas` | Compiled LISP — runs fast but the source cannot be read | | `.vlx` | Several files packaged together | | `.dvb` | A VBA macro — not LISP, a different world | | `.arx` / `.dll` | An ObjectARX / .NET plugin — a far heavier layer | In practice you will work with `.lsp`. `.fas` and `.vlx` usually turn up when a software company sells you a tool without giving you its code. ## So what is it actually good for? Let's not keep it abstract; these are the jobs LISP is used for most in the field: **Layer and drawing scheme work.** Creating layers, assigning colours and linetypes, pulling drawings that arrive from outside into your company standard. LISP's most classic use, and still where it is most productive. **Bulk edits.** Changing the font of every selected text, deleting everything on a given layer, fixing the scale of all blocks. Jobs that take half a day by hand drop to seconds. **Attribute work.** Reading, filling and exporting block attributes. Producing a bill of materials is usually most practical this way. **Custom drawing commands.** Drawing something specific to your product with a single command: a standard connection detail, a section symbol, your company title block. **Plotting and output.** Applying page setup settings and plotting in bulk. Printing every drawing in a folder to PDF with the same settings. **Data extraction.** Collecting information from a drawing and writing it to a text or CSV file. The first automation of teams feeding data into an ERP is usually this one. I answered the question "what exactly can be automated in AutoCAD" in more detail in a separate article: [what can be automated in AutoCAD](https://mehmetseyrimez.com/blog/autocadde-neler-otomatiklestirilebilir). :::illustration right code-sample | LISP's classic ground: layers, attributes, bulk edits, output ::: ## How AutoLISP works — the logic without writing code The easiest way to understand LISP is to think of it as "making AutoCAD type commands for you." Normally you type `LINE` at the command line, click two points, press `Enter`. LISP can do the same — but in your place, without mistakes, a hundred times a second. Beyond that it can do two more things: **It can read the drawing database directly.** Every object on screen — line, circle, text, block — is actually a data record. LISP can reach those records and answer questions like "how long is this line", "what does this text say", "which layer is this block on". **It can select in bulk.** It can build selection sets on criteria like "select every circle on this layer", "find everything with a radius smaller than 5". Work that is near impossible by hand is a one-line matter in LISP. Combine those two and things like this become possible: "walk every block in the drawing, read the attribute values, find the ones containing the project code, change all their layers and write a report." One command, a few seconds. ### So what is Visual LISP? A name you will meet often. Visual LISP is the shared name for two things added on top of AutoLISP: 1. **A development environment (VLIDE).** An editor that opens inside AutoCAD for writing code, running it line by line and debugging. 2. **Extended functions.** More modern access to objects, file operations, the ability to talk to external applications. So Visual LISP is not a separate language — it is AutoLISP made more capable. Most people who say "I write LISP" today are actually using Visual LISP functions as well. A note: in recent AutoCAD releases the VLIDE editor was removed and replaced by an official AutoLISP extension for Visual Studio Code. On the writing side you have moved to a modern editor; the language itself is the same. ## Strengths and weaknesses: an honest assessment I like LISP but it is not suited to every job. Knowing where it shines and where it stumbles is what lets you decide correctly. **Where it shines:** - **Speed.** The time from an idea to working code is measured in minutes. No alternative is this fast. - **Accessibility.** No installation, no licence, no development environment to buy. Notepad and AutoCAD are enough. - **Transparency.** The code is readable. You can look at what you did six months later; so can whoever comes after you. - **Closeness to the drawing environment.** Selection, calling commands, asking the user for a point — these are natural in LISP and more laborious by other routes. **Where it stumbles:** - **Error handling is weak.** When something goes wrong LISP does not report it politely; it usually either stops or carries on incorrectly. - **Writing tests is practically impossible.** There is no automated test infrastructure. That is a serious risk as the code grows. - **Large files become hard to maintain.** A thousand-line LISP file is far harder to manage than a C# file of the same size. - **The interface is limited.** If you want a user interface beyond simple boxes you will struggle. - **A quiet organisational risk.** When the person who wrote the LISP leaves, the code is orphaned at most companies. I have seen this many times in the field. That last item is the non-technical one that costs the most. A LISP library grows over the years, nobody documents it, the person who wrote it leaves, and what remains is a pile of files nobody dares touch. :::callout A small habit, a big difference Put three lines of comment at the top of every LISP file you write: what it does, who wrote it, when. That thirty-second habit decides whether the file is deleted three years later or still being used. ::: ## AutoLISP or .NET? A decision table This is the most frequent question, and the answer lies not in technical superiority but in **sustainability.** I start with this question: *who will maintain this code and how long will it live?* | Situation | The right choice | Why | | --- | --- | --- | | One-person job, will run a few times | AutoLISP | Don't let setup cost eat the gain | | Layer/block/attribute editing | AutoLISP | Already the ground where it is most productive | | A team will use it, it contains rules | .NET | Tests and version control are essential | | External data source / ERP connection | .NET | LISP does not carry this load | | A rich user interface is needed | .NET | LISP's interface options are limited | | It produces output that goes to production | .NET plus validation | A silent error is the most expensive kind | | What it will do is still undefined | AutoLISP | Explore first, build the lasting solution later | That last row matters: LISP is an excellent **exploration language.** You try an idea in half an hour and see whether it works. If it does and it is going to be permanent, then you think about moving it to .NET. I covered this decision, and how AI enters the equation, in more detail in [AutoCAD automation: how I choose between LISP, .NET and AI](https://mehmetseyrimez.com/en/blog/autocad-otomasyonu-lisp-net-yapay-zeka). ## How to start: your first week The most productive way to learn LISP is not reading a book but **solving a small, real job.** I suggest this order: **1. Pick a problem.** Something you do a few times a day, boring and rule-bound. Something modest like "create this layer and make its colour this" is ideal. **2. Set up your editor.** On newer AutoCAD releases, Visual Studio Code plus the official AutoLISP extension is the right start. On older versions VLIDE is already inside AutoCAD. **3. Read existing code.** There are tens of thousands of free LISP routines online. Download one, run it, then open it and read it. LISP's syntax looks odd at first (the parentheses!) but you get used to it within two days. **4. Make small changes.** Taking a ready-made routine and changing a layer name teaches you far more than a first attempt at writing from scratch. **5. Define your own command.** The most satisfying moment of the job is typing your own abbreviation at the command line and seeing something happen. I described how that is done, step by step, in [adding a new command to AutoCAD with AutoLISP](https://mehmetseyrimez.com/blog/autocad-yeni-komut-ekleme-autolisp). **6. Automate the loading.** You will want the routines you write to be ready every time AutoCAD opens. I gathered the ways of doing that in [loading AutoLISP files and starting them automatically](https://mehmetseyrimez.com/blog/autolisp-yukleme-ve-otomatik-baslatma). :::illustration left guidelines | The fastest way to learn: solve a small, real job ::: ## Has AI made learning to write LISP unnecessary? This question now comes up at every seminar, so let me answer it plainly: **no, but it changed the equation.** Language models are genuinely good at writing LISP code. Describe a simple routine and the odds of getting working code back are high. That lowered the threshold for learning LISP considerably — you no longer have to memorise the syntax. But two things did not change: **You need to know what to ask for.** There is no such request as "fix the drawing." There is "convert every text on this layer to this font." Being able to write that description requires understanding the job itself. **You need to verify the generated code.** LISP's weakest side was error handling, remember. Generated code inherits that weakness: it looks like it works and silently gives a wrong result in an edge case. And the changes it makes in the drawing cannot be undone. My practical advice: generate the code, but **try it on a copy of the drawing first.** That one habit removes most of the risk of AI-assisted LISP writing. ## Frequently Asked Questions **What is AutoLISP?** AutoLISP is a programming language that runs inside AutoCAD and lets users write their own commands. The code sits in a plain text `.lsp` file, runs without compilation once loaded into AutoCAD, and can reach the drawing database directly. **What is AutoLISP used for?** Editing layers and drawing standards, bulk changes, reading and filling block attributes, creating drawing commands specific to a company's products, plotting in bulk with page setups, and extracting data from drawings. What they have in common is that they are rule-bound, repetitive jobs. **Is AutoLISP hard to learn?** The syntax is unfamiliar at first because everything is written with parentheses, but the language is quite small. Downloading an existing routine and making small changes gets you moving far faster than trying to write from scratch. **Is AutoLISP still used?** Yes. It has stayed almost unchanged since the 1980s and is supported in every AutoCAD release. For small, fast automation close to the drawing environment it is still the most practical route. **Should I use AutoLISP or .NET?** AutoLISP for one-person, short-lived, drawing-editing work; .NET for work a team will use, that contains rules, connects to an external data source, or produces output that goes to production. The decision lies not in technical superiority but in who will maintain the code and how long it will live. **What is the difference between Visual LISP and AutoLISP?** Visual LISP is not a separate language but an extended AutoLISP: it adds more modern object access, file operations and communication with external applications. It also offered a development environment called VLIDE; in newer AutoCAD releases that has been replaced by the official AutoLISP extension for Visual Studio Code. **How do I open and run a `.lsp` file?** `.lsp` is a plain text file and can be opened and read in any text editor. To run it in AutoCAD you load it with the APPLOAD command; if you want it ready on every launch you need one of the automatic loading routes. **Is it safe to have AI write AutoLISP?** It gives quite good results on simple routines, but the generated code inherits LISP's weak error handling: it can silently give a wrong result in edge cases, and changes in the drawing cannot be undone. Trying every generated routine on a copy of the drawing first is essential. ## Summary AutoLISP is the most direct automation door AutoCAD gives you. Small, fast, transparent, and living inside the drawing environment. On small, rule-bound jobs no alternative catches up with it. Its limit is clear: as the code grows, as a team starts using it, and as it produces output that goes to production, LISP's weak sides — error handling, untestability, maintenance burden — come to the front. Once you cross that threshold, it is time to look at the .NET side. But up to that threshold — and most offices' work sits below it — LISP is still the smartest choice. --- # What Is a SolidWorks Macro? Record One, Then Harden It source: https://mehmetseyrimez.com/en/blog/solidworks-makro-nedir type: article published: 2026-08-24 updated: 2026-08-26 category: Automation Workshop tags: solidworks, makro, vba, otomasyon, cad-otomasyon author: Mehmet Seyrimez reading_minutes: 15 > What a SolidWorks macro is and how to write one: why recorded code breaks in production, how to harden it, what .swp really means, and 5 rules that hold up. A SolidWorks macro is a small program that runs inside SolidWorks and collapses a series of manual steps into a single command. It is usually written in VBA, stored with a `.swp` extension, and once run it does its job and ends. Writing a macro means using the SolidWorks API — the two are not rivals; one stands on top of the other. The real subject of this article is not the definition but the practice. Because almost everyone who starts with macros gets stuck in the same place: they record an operation with the Macro Recorder, run the generated code, and the code either does nothing or does the wrong thing. The reason is not that the recorder is broken — it is that **recorded code is, by design, dependent on the screen state at the moment of recording.** Below I cover first how to record, then how to strip that dependency out. :::illustration full macro-recorder | Record, read, harden: the three steps of writing a macro ::: ## What Is a SolidWorks Macro Good For? Where a macro pays off is clear: work that is **rule-bound and repeated**. Placing standard views on a drawing, filling in title block fields, exporting STEP files from every part in a folder, bulk-filling custom properties, generating a file name according to a revision rule. The repetition count is what decides it here. Turning a job you do once a month into a macro usually costs more than doing it by hand; even a rough automation of a job you do ten times a day pays for itself. Rather than guessing which job crosses that threshold, you should measure it — I described the method step by step in [how to start an automation project](https://mehmetseyrimez.com/en/blog/otomasyon-projesine-nasil-baslanir). If you are curious about where a macro sits technically, and how it relates to the API and add-in architecture, I covered [the difference between macros, the API and add-ins](https://mehmetseyrimez.com/en/blog/solidworks-makro-api-farki) in a separate article. The focus here is entirely practical: how to record, how to fix, how to run. ## Recording with the Macro Recorder The recorder is the fastest way to learn the API. You perform an operation by hand and SolidWorks writes out the API calls that correspond to it. Instead of searching the documentation for which method on which interface to call, you see it directly. The flow works like this: 1. **Start recording.** The record, pause and stop commands live under the `Tools > Macro` menu; they can also be opened as a separate Macro toolbar. Menu placement changes between versions, so if you cannot find it, typing "macro" into the command search box is the quickest route. 2. **Perform the operation at your normal speed.** The recorder captures the commands SolidWorks executes, not your mouse movement. Going slowly or being "tidy" gains you nothing. 3. **Stop the recording.** When you stop, SolidWorks asks you to save the macro. Give it a meaningful name and remember where you put it. 4. **Open the code.** `Tools > Macro > Edit` opens the macro in the VBA editor. A small habit: take the recording **on a clean document and for a single operation**, not in the middle of your real work. Record five operations together and you will spend your time working out which line of the generated code belongs to which operation. ### What gets recorded, and what does not The recorder does not capture everything. What it captures are the commands SolidWorks performs on the document. Among the things it cannot capture: - View operations (rotating, zooming) — these mostly do not enter the recording, and where they do they have no functional equivalent - Some settings you make in dialog boxes — the results appear in the code, the intermediate steps do not - Certain version-specific commands — not every command has a recorder equivalent So recorded code is **not a complete copy of the job you did, but its skeleton.** You should read it as a list of hints, not as a recipe. ## Why Can't Recorded Code Be Used Directly? This is the topic most often skipped, and where people starting with macros lose the most time. Recorded code usually **runs but cannot be trusted.** For three separate dependencies: ### 1. Dependence on selection The recorder generally turns "select this face" into a line resembling: a single selection command saying "select the feature with this name in the document." That name — something like `Boss-Extrude1` — belongs to the model you recorded on. That line looks for the feature carrying that name in that model. If another model has no such name the selection fails — and `SelectByID2` does not throw an error, it just returns `False`. The code carries on, the next line tries to operate on "whatever is selected," and it either blows up or processes the wrong object. In some cases the recorder generates selection based on **coordinates** rather than names. Those coordinates are a point in the model you recorded on. When the model changes, something else is at that point. ### 2. Dependence on the active document One of the first lines of recorded code is always the same: "get the active document." Whatever file happens to be in the foreground is what gets worked on. `ActiveDoc` gives you the document currently in the foreground. If no document is open it returns `Nothing`. If the macro does not check for this, it stops at first use with an "Object variable not set" error. Worse: if a document of the **wrong type** is open, it may not error at all. A macro written for a part, run while a drawing is open, silently does nothing — and the user believes the macro worked. ### 3. Dependence on screen and session state Recorded code assumes the context at the moment you recorded it: which configuration was active, which sheet was open, which objects were already selected, which unit system the document used. None of this is written in the code — the code simply takes it as given. :::callout The real problem is silent failure A macro that errors is not bad; it is good. The real danger is a macro that produces the wrong output without saying anything. The only purpose of hardening recorded code is turning silent failures into loud errors. ::: :::illustration right code-sample | Recorded code is a list of hints, not a recipe ::: ## Hardening Recorded Code Hardening comes down to four moves: getting the active document under control, checking its type, removing the dependence on selection, and checking the result. ### Get the active document and verify its type Every macro should start with this check. This short block cuts off most of the errors you will meet in the field before they happen. The first job of every macro should be asking two questions: **is there a document** and **is it the right type?** So first you get the active document, and if that comes back empty you tell the user "open a part document first" and exit. Then you check the document's type; if you expect a part and an assembly is open, you say "this macro only works on part files" and exit again. This tiny block cuts off most of the errors you will meet in the field before they surface. And most importantly, it turns silent failure into a loud error: the user now knows why the macro did nothing. ### Remove the dependence on selection Replace the recorded `SelectByID2` line with a call that takes the object straight from the model. Selection is a user interface concept; the code has no need of it. The robust version works like this: you remove the selection command entirely and ask the model for the object directly — "give me the feature with this name." If what comes back is empty, meaning the feature does not exist in this model, the macro stops and tells the user: "the expected feature is not in this model." The difference is subtle but important: in the first version the macro carried on working on the wrong object; in the second it stops and reports. There are cases where you genuinely need the selection — for instance when the macro is meant to work on whatever the user has just selected. Then the rule becomes: **do not assume the selection, read it and validate it.** How many objects are selected, are they the right type, and if not, tell the user. ### Check the result Most API methods return a value, and that value is usually ignored. Even the recorder assigns it to a `boolstatus` variable and then never checks it. A concrete example: the call that writes a custom property returns a result code. The recorder assigns that code to a variable but never looks at it. You should look — if the returned value is not what you expected, tell the user "the property could not be written." Since the exact meaning of the returned code can vary by version, it is worth confirming against the documentation for the version you are using. A warning: the SolidWorks API handles lengths in **system units** — even if your document displays millimetres, the number you write in code is interpreted as metres. That is why you see values like `0.05` in recorded code. Forgetting this conversion when typing numbers by hand is the most common and most insidious macro bug. ## Running, Editing and Binding a Macro to a Button The run and edit commands also live in the `Tools > Macro` menu: **Run** executes the macro directly, **Edit** opens it in the VBA editor. You can also run it from inside the editor — while debugging, that is where you will run it from anyway. Once a macro enters daily use, calling it from a menu becomes tiring. SolidWorks lets you bind macros to **a keyboard shortcut or a toolbar button**; this is configured from the macro tab in the Customize screen. You can give the button an icon and a description too. The practical point here: the file path of a macro bound to a button is fixed. Move the macro to another folder and the button stops working. Keeping macros meant for a team in **a shared network folder** everyone can reach prevents most of the "it doesn't work on my machine" questions that come later. ## What Does the `.swp` File Mean? VBA macros are stored with a `.swp` extension. This file has an important property: **it is both the executable program and the source code itself.** There is no separate build step; whoever you hand the file to can both run the macro and open, read and change the code inside it. The practical consequences: - **Sharing is easy.** You copy a single file, the other side runs it. No installation. - **The code is open.** Sharing the macro means sharing your code. If there is logic you want to restrict, a macro is the wrong container. - **Version tracking is hard.** Because it is a binary file, you cannot see line-level differences in tools like Git. There is no answer to "who changed what." - **You do not know who is using which copy.** By the third revision of a macro distributed to ten people, you cannot track who is on which version. The last two items show where a macro's limit begins. When you reach that threshold, the discussion stops being "macro or something else" and becomes an architectural decision — I went into it in [moving from a VBA macro to an add-in architecture](https://mehmetseyrimez.com/en/blog/solidworks-makro-api-farki). SolidWorks also supports .NET-based macros. That is an intermediate step between a macro and an add-in, and a separate subject. :::illustration left fixing-bugs | Debugging: breakpoints, stepping, the Immediate window ::: ## Debugging: When the Macro Does Not Work The VBA editor offers a full debugging environment, and not using it is the biggest waste of time available to you while writing macros. **Breakpoints.** Clicking to the left of a line stops the macro on that line. Once stopped, hovering over variables shows you their values. **Stepping.** You advance the macro line by line. You see directly which `If` block it enters and how many times the loop runs. This is the most productive method for understanding recorded code. **The Immediate window.** During execution you can ask for the value of an expression, or write to this window from code with `Debug.Print`. This is how you observe the flow without stopping it with `MsgBox` — especially inside a loop. The errors you will meet most often and their causes: | Symptom | Likely cause | |---|---| | "Object variable or With block variable not set" | `ActiveDoc` returned `Nothing`, or an object call returned an empty result | | The macro never errors but never does anything either | The wrong document type is open, or the selection failed and the code silently carried on | | Right on the first run, wrong on the second | The previous selection was not cleared; the macro is now operating on a different object | | Dimensions are off by a factor of a thousand | Unit confusion — the API expects metres, millimetres were written in the code | | It does not work on another computer | A hard-coded file path, or a reference that machine does not have | The second row of that table is the most expensive one. Output is believed to have been produced and is not; the error is discovered in production. :::illustration full checklist | Five habits: your third macro gets written far faster than your first ::: ## 5 Practical Rules for Writing Macros **1. Discipline your naming from the start.** `Macro1`, `Macro1_final`, `Macro1_final_v2` are useless three weeks later. Let the file name say what it does: `Drawing_Export_PDF`. The same goes for variables inside the code; changing the recorder's `Part` and `boolstatus` should be your first job. **2. Check for errors at every step.** Is there a document, is the type right, was the object found, did the method return success. The rule is simple: **do not pass silently.** The cost of skipping a check is ten times the cost of writing it. **3. Think about undo behaviour.** If the macro makes many changes to the model, the user may not be able to undo them with a single `Ctrl+Z`. The SolidWorks API allows several operations to be gathered into one undo step; which methods do this can vary by version, so confirm from the documentation. If you cannot do it, at least tell the user up front. **4. Give the user feedback.** When the macro finishes, let it say what it did: how many files were processed, how many were skipped, where the output was written. A macro with no feedback gets checked by hand every time it runs — which takes back the time it saved. This corresponds to the verification item in [the four-step measurement framework](https://mehmetseyrimez.com/en/blog/otomasyon-kazancini-olcmek) that explains where automation gains evaporate. **5. Do not assume file paths.** A hard-coded path starting with `C:\Users\...` works on your machine. Derive the path from the document (the folder the model sits in), ask the user, or at the very least check whether the folder exists before writing to it. ## Frequently Asked Questions **Do I need to know programming to write a SolidWorks macro?** Not to start; the recorder produces working code. But making that code reliable requires basic VBA — variables, conditions, loops, error checking. The fastest way to learn is to read recorded code by stepping through it line by line. **Why doesn't my recorded macro work on another model?** Almost always because of the dependence on selection. The recorder generates code that selects objects by name or by coordinate; that name or coordinate is different in another model. The fix is replacing the selection lines with calls that take the object straight from the model. **What extension does a macro file have?** VBA macros use the `.swp` extension. This file is both executable and the source code itself; there is no separate build step. **How do I add a macro to a toolbar?** From the macro tab in the Customize screen you select the macro file and define a button and an icon; a keyboard shortcut can be assigned from the same place. The exact location of the screen can vary with your version. **Are macros and the API different things?** No, they are not rivals. When you write a macro you are already calling the API; the API is the access layer and a macro is one of the forms that uses it. I explained the distinction in detail in [the macro, API and add-in guide](https://mehmetseyrimez.com/en/blog/solidworks-makro-api-farki). **The macro runs but the result is wrong. Where should I start?** Put a breakpoint on the first line you suspect in the VBA editor and step forward. Confirm from the Immediate window whether the variables really carry the values you expect. Most wrong results come out of a selection that failed without erroring, or a unit conversion. ## Conclusion The order for learning macros is this: record, read, harden. The recorder shows you which API method to call — far faster than searching the documentation. But the code it produces depends on the selection at that moment, on the open document, and on screen state. A usable macro emerges by stripping those dependencies out one at a time: get the active document under control, verify the type, do not assume the selection, check every return value, tell the user what you did. Set these five habits up from the start and your third macro gets written far faster than your first — because by then you are starting from the same skeleton every time. You can see the concrete result of an automation that starts at macro level and grows with the process in [the SolidWorks CAD automation case study](https://mehmetseyrimez.com/en/projects/solidworks-cad-otomasyonu). --- # SolidWorks Macro vs API vs Add-in: Which One Do You Need? source: https://mehmetseyrimez.com/en/blog/solidworks-makro-api-farki type: article published: 2026-08-24 updated: 2026-08-26 category: CAD Automation tags: solidworks, api, makro, csharp, otomasyon, cad-otomasyon author: Mehmet Seyrimez reading_minutes: 15 > A SolidWorks macro is not an alternative to the API — it runs on it. Where the real line sits, what a macro handles well, and 8 signs you need an add-in. The short answer to this question differs from the one you usually see in search results: **a SolidWorks macro and the SolidWorks API are not alternatives to each other.** The API is the COM-based interface that gives programmatic access to SolidWorks — in the words of the official documentation, hundreds of functions callable from VB, VBA, VB.NET, C++, C# or macro files. A macro is **one of** the automation forms that uses this API. In other words, when you write a macro you are already using the API. So the real decision is not "macro or API." The real decision is this: > Through which application architecture will I reach the API — a macro, an add-in, or a standalone application? This article makes that decision. First it separates the two concepts, then it covers where a macro is more than enough, at which threshold it starts not to be, and when the move is genuinely necessary. :::illustration full compare-options | The API is the access layer; macros and add-ins are application forms that use it ::: ## What Is a SolidWorks Macro? A macro is a small program that runs inside SolidWorks and collapses a specific task into a single command. It is produced in two ways: **By recording.** The operations you perform while the Macro Recorder is running are written out as code. This is the fastest way to learn the API: doing an operation by hand and looking at the generated code shows you directly which method on which interface is called. **By writing.** Recorded code is rarely production ready — it usually comes out dependent on selection, on the active document, and on the state of the screen. A real macro emerges by rewriting that code by hand. Macros are written in VBA and stored as a `.swp` file. That file is both executable and the source code itself; being a single piece makes sharing easy. SolidWorks also supports .NET-based macros (`.swb`). A macro's defining property is not that it is a single file but its **lifecycle**: it starts when the user calls it, does its job, and ends. ## What Is the SolidWorks API? The API (Application Programming Interface) is the layer that gives external access to the SolidWorks object model. The names you meet while writing code are parts of that model: - `SldWorks` — the application itself - `ModelDoc2` — an open document (part, assembly or drawing) - `PartDoc`, `AssemblyDoc`, `DrawingDoc` — interfaces specific to the document type - `CustomPropertyManager` — custom properties - `ISwAddin` — the interface through which add-ins register with SolidWorks The API is COM-based. In practice that means the same object model can be reached from VBA, from C#, from C++, and from Python's COM bridge. What you reach does not change; **the program doing the reaching does.** That is why the question "should I use the API or a macro" does not quite land technically. The right question is about architecture. ## The Relationship Between Macros and the API The mental model is built like this — five layers from the top down: 1. **SOLIDWORKS** — the application itself. 2. **The SOLIDWORKS API** — the layer that lets you reach the application from code (it works over COM). 3. **Language** — which language you call that layer with: VBA, C#, VB.NET, C++ or Python. 4. **Form** — which container what you write sits in: a macro, an add-in, or a standalone application. 5. **CAD automation** — all of the above applied to an engineering process. The source of the confusion is that the third and fourth layers are constantly mixed up. "Should I write a macro or use the API" is a badly formed question for that reason: when you write a macro you are already using the API. The right question concerns the fourth layer — **which container?** The third row from the bottom is where the decision is made. The two rows above it are fixed; the row below it is what the work actually amounts to. :::callout In short The API is a pool of capability. Macros, add-ins and standalone applications are three containers that reach into that pool with different lifetimes and different distribution models. ::: ## What Are the Advantages of Using SolidWorks Macros? ### Collapsing repeated operations into one command If an engineer performs the same 12–15 steps on every drawing — placing views, setting the scale, filling title block fields, saving, exporting PDF — that flow can be reduced to a single button. The gain is small once; multiplied by the repetition count, it grows. ### Standardisation This is the side of macros that gets discussed least but makes the biggest difference in the field. A macro does not only speed the work up, it makes **everyone do the same job by the same rule.** File naming, revision fields, output folders, layer mapping — done by hand these vary from person to person. In code there is a single definition. The measurable gain of an automation project usually comes not from time but from that consistency. A single misnamed DXF takes back every minute it saved, in production. ### Reducing the risk of human error The places where risk concentrates are known: file names, revision numbers, custom properties, output folders, layer and colour mapping, unit selection. All of them are repetitive and attention-demanding — which is to say, exactly where people slip most easily. ### Batch processing Processing a folder from start to finish instead of opening and saving 100 drawings one by one is a macro's most visible gain. There is a distinction here that often gets skipped. For bulk PDF/DXF, the Task Scheduler or PDM tasks are usually recommended. Both work — but both depend on licence level and **their rules are fixed**. A macro or API-based solution runs on SolidWorks Standard and writes the rule according to your process: which configuration, which layer mapping, which naming template, under which condition to skip. A ready-made tool "converts the file"; code "converts it by your rule." ### Automating production output PDF, DXF, DWG, STEP, STL, BOM and Excel output — this is the point where design passes into manufacturing, and it is also where mistakes are most expensive. ### Combined with a parametric model An important distinction: **parametric design is not a macro.** A parametric model is geometry bound to rules; a macro is code that can drive those rules from outside. Each is useful on its own; combined, the automation changes class: the user enters a few dimensions, the model builds itself, and the drawing and production output follow. ## What Can Be Automated with a SolidWorks Macro? The items I meet most often in the field: - Bulk reading, writing and validating of custom properties - Bulk PDF / DXF / DWG generation from drawings - STEP / STL export from parts - Binding file naming and revision fields to a rule - Exporting the BOM and matching it against Excel - View placement, scale and title block filling - Configuration generation and table-driven variant creation - Standards compliance checking on models and drawings What these have in common: they are all jobs that **can be bound to a rule.** Jobs that require judgement — which design is correct, which tolerance is appropriate — are not on this list, and should not be. ## When Is a SolidWorks Macro Enough? A macro is usually the right and sufficient choice in these situations: - The number of people using the tool is small; often just the person who wrote it - The job is a flow that starts and ends with a single command - The task has limited scope, such as bulk export or property editing - You need to validate quickly whether the idea works at all (proof of concept) - The process has not settled; the rule changes from week to week That last point matters. Building an add-in architecture on top of a process whose rules are undefined is one of the most expensive mistakes there is. In such cases a macro is not just the fast solution but **the right one** — because it is cheap to throw away. ## When Does a Macro Start Falling Short? I am deliberately careful with the language here: this is not a list of jobs macros "cannot do." A surprising amount can be done with VBA. The problem is not capability but **sustainability.** The line has been crossed when these symptoms start appearing: - **Continuous operation is needed.** A macro starts when called and ends. Behaviour that listens in the background as long as SolidWorks is open (check when a document opens, validate before saving) runs against a macro's lifecycle. - **Event handling is needed.** Hooking into save, open and rebuild events is the job of an add-in architecture. - **The interface is growing.** Beyond a simple input box — a CommandManager tab, a TaskPane, a PropertyManagerPage — VBA forms quickly fall short. - **There is team-wide distribution.** Ten people updating a macro file by hand works right up until the first revision. - **Central updates are needed.** If you cannot tell who is using which version, you cannot trust the output the automation produces. - **Error handling and logging have to be taken seriously.** Finding a problem from "it didn't work" feedback is a guessing game without logs. - **Version control and tests are needed.** A single-file binary format is not suited to code review or diffing. - **Integration enters the picture.** A PDM, ERP, database or external service connection requires dependency and authentication management. It is more productive to ask the question this way: not *"Is it technically possible?"* but **"Will this architecture still be standing a year from now for this job?"** ## Differences Between SolidWorks Macros and Add-ins | Criterion | VBA Macro | C#/.NET Add-in | |---|---|---| | Speed to start | Very high — working code in minutes | Low — project setup, registration, build | | Prototyping | Ideal | Too heavy | | Learning curve | Low | Medium–high (.NET plus COM together) | | Interface integration | Limited; basic forms | CommandManager, TaskPane, PropertyManagerPage | | Event handling | Restricted; lifetime listening is hard | Natural; the add-in lives alongside SolidWorks | | Deployment | Copying a file | Installer, central updates | | Maintenance | Harder as the single file grows | Modular structure, separated responsibility | | Logging | Set up by hand | Standard infrastructure available | | Testability | Low in practice | Unit testing possible | | Team use | Good in a small team | Suitable at enterprise scale | | ERP / PDM integration | Struggles | Suitable | | Sustainability | Short to medium term | Long term | How you read the table matters: the right-hand column does not mean "better." The left-hand column is **more correct** for small, undefined jobs — because it carries no architectural cost. ## VBA or C#/.NET? The decision comes down to three questions: **How many people will use it?** One person, VBA. A team, and you have a distribution and update problem; that is what the .NET side is for. **How long will it live?** For a need lasting a few weeks, VBA. If it will live for years alongside the process, maintenance cost overtakes setup cost quickly. **How intertwined with SolidWorks will it be?** A single command the user calls, VBA is enough. If it changes SolidWorks' behaviour — adds a tab to the interface, controls saving, runs checks at startup — you need an add-in architecture. Python sits in a separate place outside this table: it suits rapid prototyping, data processing and certain automation scenarios over COM, but it does not offer an interface embedded inside SolidWorks. I covered its limits separately in [where Python fits in SolidWorks automation](https://mehmetseyrimez.com/en/blog/python-solidworks-otomasyonu). ## Real Usage Scenarios **1. The same custom properties are filled on every drawing.** Approach: a VBA macro. One command, one file, a quick win. **2. PDF and DXF output is needed from hundreds of parts.** Approach: macro or API-based batch processing. If the rule is complex (different layer mapping per configuration, conditional skipping), code beats a ready-made tool. **3. The user enters a few dimensions and a complete assembly is built.** Approach: parametric model plus API. The real work here is not in the code but in building the model's rules soundly. A badly built parametric model will not carry even the best code. **4. A custom SolidWorks interface is needed across the company.** Approach: a C#/.NET add-in. CommandManager tab, central updates, user settings. **5. There is data exchange between SolidWorks and ERP/PDM.** Approach: API plus an integration layer, and an add-in where needed. The critical point is whether the data flow is one-way or two-way; if two-way, conflict resolution must be designed from the start. **6. 3D models are generated from 2D drawings according to rules.** Approach: parametric rules plus the API, with an AI-assisted interpretation layer where needed. I went into this scenario in [automating 2D drawings into 3D models](https://mehmetseyrimez.com/en/blog/2b-teknik-resimden-3b-modele-otomasyon). ## Which Approach Should You Choose? The order is simple and should not be reversed: 1. **Measure first.** Which job, how often, taking how long? Without that measurement it does not matter which tool you pick. I described the method step by step in [how to start an automation project](https://mehmetseyrimez.com/en/blog/otomasyon-projesine-nasil-baslanir). 2. **Validate with the smallest working solution.** Usually that is a macro. 3. **Watch how it gets used.** Who uses it, where do they get stuck, which rule changes? 4. **Grow the architecture as the need grows.** The add-in decision is made when a macro's limit has actually been hit — not when it is predicted that it will be. When calculating whether the gain is real, development and maintenance cost belong in the equation too; for that I use the approach in [measuring automation gains](https://mehmetseyrimez.com/en/blog/otomasyon-kazancini-olcmek). ## My Approach In my own projects I have almost never started with an add-in. The order I have followed in SolidWorks automation work has always been the same: measure the repeated job first, confirm the rule is right with a small macro, and grow the architecture once the rule has settled in the field. That is how I made the moves from VBA to a C#/.NET add-in architecture too — the decision to move was not a preference but the result of accumulated symptoms: the team grew, distribution became a problem, event-based behaviour was needed. You can see the concrete result of this approach in two places: [the SolidWorks CAD automation case study](https://mehmetseyrimez.com/en/projects/solidworks-cad-otomasyonu) covers the move from macro level to an add-in architecture, and [ParametriX](https://mehmetseyrimez.com/en/projects/parametrix-2d-3d) covers where parametric design meets API automation. I use AI in this process but knowing its limits: it genuinely accelerates scaffolding and API discovery, and it is confidently wrong about the COM lifecycle and silent failures. I went into the distinction in [writing a SolidWorks add-in with AI](https://mehmetseyrimez.com/en/blog/yapay-zeka-ile-solidworks-eklentisi-yazmak). :::illustration left guidelines | The right question is not "macro or API" but "which container" ::: ## Frequently Asked Questions **Are a SolidWorks macro and the API the same thing?** No. The API is the access layer; a macro is one of the application forms that uses it. When you write a macro you are already using the API. **Which language are SolidWorks macros written in?** Primarily VBA. SolidWorks also supports .NET-based macros. Add-ins are written in C#, VB.NET or C++. **Does the SolidWorks API cost extra?** The API is part of the SolidWorks licence; it is not sold as a separate product. The capabilities you can reach vary with the SolidWorks version you use. **Should I choose a macro or an add-in?** Look at how many people will use it, how long it will live, and how intertwined with SolidWorks it will be. Single user and a single command, a macro; a team, an interface and event handling, an add-in. **Is the SolidWorks API hard to learn?** The object model is broad but the entry threshold is low. Recording an operation with the Macro Recorder and looking at the generated code moves you forward faster than starting from the documentation. **When does a macro fall short?** When continuous operation, event handling, team-wide distribution, central updates, advanced error handling or enterprise integration are needed. This is a sustainability limit, not a capability limit. **What is the difference between parametric design and a macro?** Parametric design is geometry bound to rules; a macro is code that drives those rules from outside. Combined, they produce far more powerful automation. ## Conclusion "Macro or API" is a question that needs correcting rather than answering. The API is underneath every route already; the choice is which architecture you reach it with. A practical summary: - Small, single-user, short-lived job → **a macro** - Team-wide, continuously running work needing an interface and integration → **a C#/.NET add-in** - The decision between the two → a question of architectural sustainability, not capability - In every case → measure first, validate with the smallest solution, then grow If you repeat the same SolidWorks steps on every order or every project at your company, we can assess together whether the process suits automation at macro, API or add-in level — write to me from [the contact section](https://mehmetseyrimez.com/en#contact). --- # What Is the SolidWorks API? The COM Object Model Explained source: https://mehmetseyrimez.com/en/blog/solidworks-api-nedir type: article published: 2026-08-24 updated: 2026-08-29 category: CAD Automation tags: solidworks, api, com, otomasyon, cad-otomasyon author: Mehmet Seyrimez reading_minutes: 15 > What the SolidWorks API is and how it works: the SldWorks, ModelDoc2 and PartDoc hierarchy, the selection-based code trap, and a 5-step learning path. The SOLIDWORKS API is a COM programming interface for SOLIDWORKS. In the words of the official documentation: it contains hundreds of functions that can be called from VB, VBA, VB.NET, C++, C# or macro files. In other words, the API is the layer that lets you reach everything inside SolidWorks — documents, features, dimensions, configurations — from code on the outside. Learning the API is not about memorising a list of functions. There is only one thing you actually need to learn: **the object model**. Which object sits under which, and through which chain you reach the capability you are after. Once you have built that map, finding a method you have never used takes minutes. Without it, you can wander through the documentation for hours and still not know where to start. This article draws that map. I will not repeat how the API relates to macro and add-in architectures here; I covered that separately in [the article on the relationship between macros, the API and add-ins](https://mehmetseyrimez.com/en/blog/solidworks-makro-api-farki). The question here is a different one: **I understand the API — how do I navigate the object hierarchy?** :::illustration full api-object-tree | The API object chain, from the root to the document and from the document down to features and properties ::: ## What Does COM Mean in Practice? COM (Component Object Model) is Windows' standard for sharing objects between applications. SolidWorks exposes its capabilities as COM interfaces. In practice this has three concrete consequences. **First: language independence.** A COM interface is a contract — which method takes which parameters is defined independently of any language. That is why the `ModelDoc2` object is reached the same way from VBA, from C#, from C++, and from Python's COM bridge. Method names do not change; only the syntax does. A call you learn in VBA carries over to C# almost verbatim. **Second: object lifetime is your responsibility.** COM objects live by reference counting. Hold on to an object and never release it and SolidWorks may refuse to close; release it too early and you get unexpected errors. On the .NET side this is the single most overlooked detail in automation code. **Third: the difference between early and late binding.** Early binding means referencing the SolidWorks type library at compile time. You are using early binding when you add a reference to `SolidWorks.Interop.sldworks.dll` in C#, or tick the SOLIDWORKS type library under Tools → References in VBA. The payoff is large: IntelliSense works, a mistyped method name is caught at build time, and calls are faster. Late binding resolves the object's type at run time instead — that is what the `Dispatch("SldWorks.Application")` call in Python does. It is flexible, needs no reference setup, and tolerates different SolidWorks versions more gracefully. The price is that typos only surface at run time, and there is no IntelliSense. I showed the practical consequences on the Python side, with examples, in [SolidWorks automation with Python](https://mehmetseyrimez.com/en/blog/python-solidworks-otomasyonu). :::callout A practical rule Prefer early binding while you are learning. IntelliSense is the fastest way to explore the object model: putting a dot after an object and reading the list beats searching the documentation. ::: ## The Object Hierarchy: The API's Map The object model is a tree, and everything starts at the root. The table below shows the path that ninety percent of everyday automation work travels along: | Level | Object | What it represents | | --- | --- | --- | | 1 | `SldWorks` | The running SolidWorks session itself — the root of the tree | | 2 | `ModelDoc2` | An open document: part, assembly or drawing | | 3 | `PartDoc` / `AssemblyDoc` / `DrawingDoc` | The document specialised by its type | | 3 | `Feature` | Every item in the design tree: extrude, cut, plane… | | 4 | `Dimension` | A dimension attached to a feature | | 3 | `SelectionMgr` | What the user currently has selected on screen | | 3 | `CustomPropertyManager` | The document's custom properties | | 3 | `ModelDocExtension` | Advanced operations added later | Read the chain like this: from the session to the document, from the document to the design tree, from the tree to individual features and dimensions. Each level **hands you** the next one; you cannot skip a level. Most of the moments where you get lost writing automation actually come from trying to skip a step in this chain. What each node is for, in one sentence: - **`SldWorks`** — the SolidWorks application itself. Opening, closing and creating documents, plus application settings, are managed from here. Every piece of code starts by getting hold of this object. - **`ModelDoc2`** — an open document. It carries the behaviour that parts, assemblies and drawings share: saving, rebuilding, view operations, access to the feature tree. - **`PartDoc`** — the part-specific interface you reach when the document is a part; solid body operations and material assignment live here. - **`AssemblyDoc`** — the assembly-specific interface: components, mates, and assembly-level operations. - **`DrawingDoc`** — the drawing-specific interface: sheets, views, and drawing-level operations. - **`Feature`** — a single item in the design tree. Its name, type and children are read from here; navigating the tree happens through this object. - **`Configuration`** — a configuration of the document. The centre of variant generation and configuration-specific properties. - **`Dimension`** — a dimension. Reading and writing its value is the most direct route into parametric automation. - **`CustomPropertyManager`** — where custom properties are read and written. You do not get it from `ModelDoc2` directly but through `ModelDocExtension` — this is the point in the hierarchy where people get lost most often. - **`SelectionMgr`** — the list of objects the user currently has selected. It turns up constantly in recorded macros; I will come to why it needs handling with care in a later section. How you read this tree matters: every arrow pointing down means "to get this object you must first hold the one above it." You cannot reach a `Dimension` object directly; you reach the application, then the document, then the feature. ## Down from the Root: The First Connection The first two lines of every piece of automation code are the same — grab the application, get the document. Every piece of automation starts with the same two moves. First you take hold of the **root object**: `SldWorks`, representing the running SolidWorks session. Then you go down one level and take the **active document** — `ActiveDoc`. The critical point here is that the second move can come back empty. If no document is open you get nothing, and the next line of your code blows up. That is why the first check in every automation should be: **did a document come back?** If not, tell the user "no open document" and exit. If a document did come back, the second check is its type. The document type determines everything that follows: part, assembly, or drawing? Applying logic written for a part to an assembly is the most common mistake I see in the field. Carrying on without checking the result of `ActiveDoc` is the most frequent error I run into. If the document is closed, the code fails silently and the user says "it didn't work." ## From the Document to the Feature Tree The second level is descending from the document into the design tree. The feature tree is walked like a linked list: you take the first feature, then ask for the next. You ask the document for its **first feature**, then ask each feature "who is your next sibling?" and follow the chain to the end. When the chain runs out you get an empty result back and the loop stops there. A practical detail: every feature's name is exactly the name you see in the design tree. That is the most useful link you have while debugging — you can search for the name from your code directly in the tree on screen. The same navigation logic applies to assembly components, drawing views and configurations: ask for the collection, walk it in order, stop when you find what you were after. Those ten lines summarise the logic of the object model: if you hold an object, there is a way down to the level below it. Once you have learned to navigate the tree, jobs like "find the feature with this name and change its dimension" become mechanical. ## Interfaces with the `I` Prefix: `IModelDoc2` and `ModelDoc2` In the documentation you will see two names for the same thing: `ModelDoc2` and `IModelDoc2`. This is not a version difference. The `I` prefix means **interface** in COM; it defines the object's contract. The name without the prefix points at the class (coclass) that implements the interface. On the .NET side the SolidWorks interop library offers both, and in practice `ModelDoc2` and `IModelDoc2` can be used interchangeably; most developers prefer the `I`-prefixed form in C# because binding to the contract is clearer. In VBA you usually write the name without the prefix. In the documentation, headings are mostly in the `I`-prefixed form. Knowing you are looking at the same page saves time while searching — when you cannot find `ModelDoc2`, search for `IModelDoc2`. ## How Do You Find a Job in the API? The fastest way to learn the object model is not to read the documentation front to back. The order is this: **1. Record yourself doing the job by hand.** Open the Macro Recorder, perform the operation you want to automate the normal way, stop recording. **2. Look at which interface the generated code calls.** Recorded code is not production ready — it comes out dependent on selection and screen state. But it gives you the thing you were looking for: **which method on which object** does this job. **3. Search for that interface in the API Help.** Now you know the name of the thing you are after. In the documentation you read the method's full signature, what the parameters mean, and what alternatives exist. **4. Make the code independent of selection.** Recorded code operates on "whatever is selected on screen." Production code should operate on "what it found by name." What this order buys you is simple: to search the documentation, you first need to know **what to search for**. The Macro Recorder tells you exactly that. AI tools are also an accelerator at this discovery stage, though they can be confidently wrong about the COM lifecycle and version-specific behaviour; I covered their limits separately in [writing a SolidWorks add-in with AI](https://mehmetseyrimez.com/en/blog/yapay-zeka-ile-solidworks-eklentisi-yazmak). ## The Trap of Selection-Based Code Every recorded macro works through `SelectionMgr`, because the Macro Recorder records your clicks. This route assumes two things: that the user selected the right thing, and that the selection is still valid. If you genuinely need the selection — say the macro is meant to work on whatever the user has just highlighted — the rule is: **do not assume the selection, read it and validate it.** First ask how many objects are selected; if the answer is zero, the job stops there and you tell the user. Then check whether the selected object is the type you expected. There is also a classic trap: indexes in SolidWorks selection collections start **at 1**, not at zero. Asking for element zero is one of the most common mistakes on the COM side. The route that does not depend on selection at all is always more robust: ask the document for the object directly. Then the macro works regardless of what the user is doing on screen. Selection-based code works, but it is brittle for three reasons: - **It depends on screen state.** If the user selected the wrong thing, selected nothing, or the selection order changed, behaviour changes. - **It cannot be used in batch work.** In a flow processing a hundred files back to back, there is no such thing as "the selected object." - **It can be silently wrong.** With the wrong object selected the code does not error; it processes the wrong object. That is worse than erroring. The robust approach is reaching the object **by its identity**: finding the feature by name, getting the configuration by name, reading the custom property by its key. Selection should only be used in interactive scenarios where the user has deliberately pointed at something; in batch and background work it should not be used at all. ## Version Dependency: Which Documentation Should You Read? The SolidWorks API evolves with each release. New interfaces are added and existing methods get new numbered versions — the trailing digits in `Save3`, `GetSelectedObject6` and `Add3` are exactly that trail. Older versions generally keep working, but new capabilities only exist on the new interfaces. Three practical rules: - **Read the documentation for your target version.** API Help is published per release. Looking at the 2025 documentation for a 2021 installation will send you hunting for a method that does not exist. - **Identify the lowest common version.** If your code will run on five people's machines, the oldest SolidWorks among them is your target. - **On numbered methods, pick the highest supported version.** If both `Save` and `Save3` do the job, the newest one your target version supports usually gives you more control. The API is not sold as a separate product; it is part of the SolidWorks licence. The capabilities you can reach, however, vary with the version and licence level you have. ## A Learning Roadmap for the SolidWorks API I care about the order here, because most people start at step three and get stuck: **1. Explore with the Macro Recorder.** Record five different jobs and read the generated code. The aim is not to write code but to see which job falls to which interface. **2. Memorise the chain from root to document.** `SldWorks` → `ModelDoc2` → the document type branch. Once you can write those three steps without thinking, the rest is exploration. **3. Free a recorded macro from selection.** Take a recording you have, strip out the `SelectionMgr` dependency, find objects by name. This is where you actually learn the object model. **4. Work with custom properties and configurations.** `CustomPropertyManager` and `Configuration` are the areas that produce real value with no geometric risk. Bulk property filling is a good candidate for your first production automation. **5. Move on to changing dimensions and features.** Touching geometry is the last step, because that is where the cost of a mistake is highest. Driving a parametric model from code is the sum of these five steps. You can see this order applied in [the ParametriX project](https://mehmetseyrimez.com/en/projects/parametrix-2d-3d): where parametric model rules meet API automation is exactly step five. :::illustration left document-analysis | Reading the documentation: interface name, version, return value ::: ## Frequently Asked Questions **What is the SolidWorks API, briefly?** It is a COM programming interface for SOLIDWORKS. It contains hundreds of functions callable from VB, VBA, VB.NET, C++, C# or macro files, and gives external access to the SolidWorks object model. **What is `ModelDoc2` and why does it turn up everywhere?** It is the interface representing an open document. Because the shared behaviour of parts, assemblies and drawings is gathered here, almost every piece of automation code passes through this object. **What is the difference between `IModelDoc2` and `ModelDoc2`?** The `I` prefix denotes the COM interface; the name without it denotes the class that implements it. In practice you reach the same capabilities; when searching the documentation, try both forms. **Where should I start learning the API?** With the Macro Recorder. Recording a job and looking at which interface the generated code calls moves you forward far faster than reading the documentation from the beginning. For deciding which form to build in — macro, add-in or standalone application — use the decision model in [the macro and API guide](https://mehmetseyrimez.com/en/blog/solidworks-makro-api-farki). **Which language should I choose?** Because the object model is the same in every language, the language is a secondary decision at first. VBA gives the fastest start, C#/.NET is preferred for lasting solutions, and Python suits rapid prototyping — I walked through connecting to the API over COM step by step in [SolidWorks automation with Python](https://mehmetseyrimez.com/en/blog/python-solidworks-otomasyonu). **Does the API cost extra? Is it bought separately?** The API is part of the SolidWorks licence; it is not sold as a separate product. The capabilities you can reach vary with the version you use. **Why does my recorded macro break in production?** Because recorded code depends on selection and screen state. Until the `SelectionMgr` dependency is removed and objects are found by name, the code will either stop or process the wrong object at the first scenario that differs. ## Conclusion Learning the SolidWorks API is not about memorising a list of methods; it is about internalising a map. Once you can write the `SldWorks` → `ModelDoc2` → document type → `Feature` / `Configuration` / `CustomPropertyManager` chain without thinking, every job you have never done turns into nothing more than a search question. A practical summary: - Everything starts at the root; you cannot skip a level - Thanks to COM the object model is language independent — what you learn carries over - Early binding gives you IntelliSense while learning, late binding gives you flexibility - The fastest way to find a job is Macro Recorder → generated code → API Help - Selection-based code is brittle; reach objects by their identity - Read the documentation for the SolidWorks version you are targeting If you are thinking about moving repetitive SolidWorks steps into code at your company and cannot decide where to start, we can work through it together — write to me from [the contact section](https://mehmetseyrimez.com/en#contact). --- # SolidWorks Add-in Development: Writing a Plugin in C#/.NET source: https://mehmetseyrimez.com/en/blog/solidworks-add-in-gelistirme type: article published: 2026-08-24 updated: 2026-08-26 category: Automation Workshop tags: solidworks, add-in, csharp, dotnet, api, otomasyon author: Mehmet Seyrimez reading_minutes: 15 > SolidWorks add-in development in C#: the ISwAddin lifecycle, COM registration, CommandManager and TaskPane, event traps, and 8 mistakes that surface later. The hard part of writing a SolidWorks add-in is not the API calls. The hard part is that your code **no longer owns its own lifetime**: the add-in opens with SolidWorks, stays in memory for the whole session, listens for events, and has to withdraw cleanly when SolidWorks closes. Three things you never think about in a macro — registration, lifecycle and object ownership — meet you on day one with an add-in. This article does not argue "macro or add-in"; that decision is taken as made. What follows is the answer to **how**: how the add-in is introduced to SolidWorks, where its interface is built, how it hooks into events, and which mistakes surface in the field three weeks later. If you are still making the decision itself, I would suggest going back to [the article where I go into the relationship between macros, the API and add-ins](https://mehmetseyrimez.com/en/blog/solidworks-makro-api-farki). Testing the COM connection first with [SolidWorks automation in Python](https://mehmetseyrimez.com/en/blog/python-solidworks-otomasyonu) to validate the idea quickly is also useful — a step that comes before the add-in decision. :::illustration full addin-plugin | Add-in layers: COM registration, lifecycle, interface, events and business logic ::: ## What is an add-in, and where is the architectural difference? An add-in is a .NET class library (`.dll`) that runs **inside** the SolidWorks process. A macro is called as an external file and ends; a standalone application drives SolidWorks from outside and lives in its own window. An add-in is not between the two but somewhere else entirely: SolidWorks loads it at startup, lets it settle into its interface, and keeps it in memory until it closes. This is not a difference in capability but **in lifetime and ownership** — I covered which symptoms make this move necessary, in table form, in [the macro versus add-in comparison](https://mehmetseyrimez.com/en/blog/solidworks-makro-api-farki). ## ISwAddin: the two ends of the lifecycle For a class to be recognised by SolidWorks as an add-in it must implement the `ISwAddin` interface. That interface has two members, and the add-in's whole story happens between them: - **`ConnectToSW`** — called when SolidWorks loads the add-in. You are handed the application object and a *cookie* (the add-in's identity). Menus, tabs and event subscriptions are set up here. - **`DisconnectFromSW`** — called when SolidWorks closes or the user disables the add-in. **Everything** set up in `ConnectToSW` is undone here: command groups removed, event subscriptions detached, held references released. At connection time you do three things in order. First you store the application object SolidWorks handed you and the **cookie** value — the cookie is your add-in's identity and is required for button callbacks to reach you. Then you register yourself as the callback target using that cookie; skip this step and your buttons appear but nothing happens when clicked — one of the silent failures that costs the most time in the field. Then you build the command interface: the CommandManager tab and its buttons. Last, you attach event subscriptions. And the return value of this function matters: a successful connection must return a positive result. Return a negative one and SolidWorks does not load the add-in at all — and does not tell the user so clearly. Two details get skipped often. First, returning `false` from `ConnectToSW` silently leaves the add-in unloaded; swallow the error and the user just says "the tab didn't appear." Second, if you do not store the cookie, button callbacks never reach you. :::callout The symmetry rule Every operation you perform in `ConnectToSW` must have a counterpart in `DisconnectFromSW`. Add-ins that break this symmetry are the ones that hang while SolidWorks closes or leave a process running in the background. ::: ## COM registration: how is the add-in introduced to SolidWorks? The SolidWorks API is COM-based; even though your add-in is written in .NET, SolidWorks sees it as a COM component. So putting the compiled `.dll` in a folder is not enough — two separate registrations are required: **1. COM registration.** The class is marked `ComVisible` and given a fixed `Guid`. Registration is done with the `regasm` tool that ships with the .NET Framework; if you are not putting the assembly in the GAC you need the `/codebase` switch, because SolidWorks has to know where to find the DLL on disk. **2. SolidWorks registration.** SolidWorks keeps the add-ins it will load in its own registry branch. The application-level add-in list lives under `HKEY_LOCAL_MACHINE`, while whether the user left that add-in on or off is stored under `HKEY_CURRENT_USER`. In practice that distinction means: **installing the add-in does not guarantee it comes up enabled for the user.** Key names and exact paths can change between SolidWorks versions; confirm from the official documentation for your target version before writing your installer script. Rather than doing this second step by hand, the common approach is to leave it to methods marked with `ComRegisterFunction` and `ComUnregisterFunction`: when `regasm` runs, these methods are triggered and code writes the registry entries. Installation and removal are then managed from one place. Writing to `HKEY_LOCAL_MACHINE` requires administrator rights. That comes back in the deployment section. ## The interface layer: which one, when? An add-in's visible face rests on three main components. The choice is not aesthetic but based on **how long the interaction lasts.** | Component | When | Typical use | |---|---|---| | `CommandManager` tab | The user will trigger an action | Bulk export, running checks, tool buttons | | `TaskPane` | Information must stay open for the session | Project tree, search panel, PDM/ERP connection status | | `PropertyManagerPage` | Selection and parameters will be taken | Parametric generation form, property editing, step-by-step wizard | **CommandManager** is the add-in's identity. You add your own tab and button group, binding each button to a callback method and optionally an "is enabled" method. The second one matters: a drawing button should look greyed out when the active document is not a drawing. This small detail decides whether the user trusts the add-in. **TaskPane** is a view that lives in the SolidWorks right-hand panel. You place your own WinForms/WPF control inside it. It suits **showing state**, not starting a job. **PropertyManagerPage** is the left panel SolidWorks' own commands use. Using it instead of opening your own dialog has two advantages: the user already knows this interaction style, and it naturally allows selection from the model (face, edge, component). The handler interface that creates the page and receives its events has several version-numbered variants; pick which one to implement from the API documentation for your target SolidWorks version. A practical order: first a single button with `CommandManager`, then `PropertyManagerPage` as the job grows, and `TaskPane` only if something genuinely needs to stay visible. Starting in the reverse order produces interface nobody uses. ## Event handling and the most expensive mistake The real capability that separates an add-in from a macro is event handling: checking when a document opens, validating before saving, updating the interface when the active document changes. Events arrive at two levels. **Application-level** events come from the `SldWorks` object — a document opening, the active document changing. **Document-level** events come from interfaces specific to the document type: parts, assemblies and drawings each have their own event sets. So if you want "validate before saving" behaviour for all three document types, you have three separate subscriptions to manage. The most insidious trap here: when a document opens you create an event listener specific to that document — and if you hold no reference to that object anywhere else, the .NET garbage collector cleans it up after a while. Events silently stop arriving. There is no error, no message; your add-in simply becomes "sometimes it doesn't work" one day. The fix is simple but easy to forget: **hold** the document handlers in a dictionary (keyed by file name) and remove the entry when the document closes. That one habit solves add-in development's hardest-to-diagnose problem from the start. That `_handlers` dictionary is not decoration. **This is the most common mistake with COM events:** if no strong reference is held anywhere to the object that set up the subscription, the garbage collector collects it after a while and events silently stop arriving. There is no error message, no exception is thrown, the build gives no warning. The add-in works correctly for minutes, then becomes "sometimes it doesn't work." So the rule is clear: **every event handler object lives, for its whole lifetime, in a collection held by the add-in class.** When a document closes, that entry is removed from the collection and the subscription detached. In `DisconnectFromSW`, the collection is emptied. The second common mistake is doing long work inside an event handler. Event callbacks run in the middle of SolidWorks' own flow; starting an operation there that takes minutes locks the interface and makes the user think SolidWorks has crashed. ## Project structure: separate API access from business logic Add-in projects always degrade the same way: SolidWorks API calls, business rules and file writing all end up inside the button callback. It works in the first version and becomes unreadable by the third rule. The separation is made with a simple question: *does this code have to know about SolidWorks?* - **The add-in layer** — `ISwAddin`, command registration, interface. Knows SolidWorks, knows no rules. - **The API access layer** — reading properties from a document, exporting, querying geometry. Knows SolidWorks, knows no rules. - **The business logic layer** — naming rules, validation, which output is produced when. Knows the rules, knows **nothing at all** about SolidWorks. The third layer not knowing about SolidWorks is not theoretical elegance but direct testability: you can test "does this revision number match this format" in seconds, without opening SolidWorks. And most rule bugs live there. I covered the general rationale for this separation and how to build it in [modular software architecture](https://mehmetseyrimez.com/en/blog/moduler-yazilim-mimarisi); on the add-in side its most useful property is being able to change a rule without touching the interface. ## Why are error handling and logging mandatory? In a macro, error handling is optional because the person making the error and the person seeing it are the same: the macro blows up, you see it, you fix it. With an add-in that chain breaks. Your code runs on another computer, on another SolidWorks version, on an assembly you have never seen, and the feedback that reaches you is one sentence: "it didn't work." Without logs, what remains is a guessing game. Three rules make an adequate start: 1. **Do not let exceptions leak out of event callbacks and button callbacks.** An exception crossing the COM boundary appears to the user as a meaningless error or, worse, leaves SolidWorks unstable. Every entry point is wrapped in `try/catch` and the caught error logged. 2. **Check return values.** Many SolidWorks API methods do not throw; they return `null` or `false`. An unchecked return silently produces incomplete output — the most expensive class of automation bug, and exactly the check most often skipped in [add-in code produced with AI](https://mehmetseyrimez.com/en/blog/yapay-zeka-ile-solidworks-eklentisi-yazmak). 3. **Write to a per-user file.** The log file should live in a directory the user has write access to, and should contain the version number, SolidWorks version, document name and a timestamp. The skeleton of a button callback should always be the same and carry three rules. **One:** get the active document and check for its absence. If there is no document, say something intelligible to the user and exit. **Two:** do not write the actual work inside the callback. The callback is only a trigger; business logic should sit in a separate service. That separation is the only way your add-in stays testable. **Three:** wrap everything in an error handler. This is the most critical rule of add-in development: **no exception should cross the COM boundary.** An error leaking out of a callback can leave SolidWorks itself unstable or crash it outright. Catch the error, write it to the log, show the user a plain message — and end the flow there. ## Deployment, versioning and compatibility Writing the add-in is half the job; making sure **the same version** runs on ten people's computers is the other half. **The installer.** Copying files is not enough, because COM registration and registry entries are needed and these can require administrator rights. An MSI or equivalent installer reduces installation and removal to one step. Test the uninstall scenario from the start: a leftover registry entry makes SolidWorks try to load a DLL that no longer exists at startup. **Version management.** Embed the add-in's version number in the assembly and show it somewhere visible in the interface (an About button or TaskPane footer). Write it into log lines too. Not having to ask the user "which version are you on" shortens support time noticeably. Keep the `Guid` **fixed** across versions — changing it forces the user to enable the add-in by hand again. **Architecture and runtime compatibility.** Because the add-in loads inside the SolidWorks process, the processor architecture must match; current SolidWorks versions are 64-bit and a 32-bit build will not load. Likewise the .NET runtime your add-in targets must be within the range SolidWorks supports. The supported .NET version varies with the SolidWorks version; confirm from the official system requirements before choosing your target. **Backward compatibility.** API methods have version-numbered variants, and older names may be deprecated over time. If you need to support several SolidWorks versions, compiling against the interop assembly of the oldest version you support is a common approach — but without testing on every version, that is an assumption. ## Common mistakes 1. **Not holding strong references to event handlers.** The most insidious bug. Events work for a while, then silently stop. Symptom: "sometimes it works, sometimes it doesn't." 2. **Leaving `DisconnectFromSW` empty.** Command groups are not removed, subscriptions not detached, references not released. Result: SolidWorks hangs while closing, or a process stays in the background. 3. **Exceptions crossing the COM boundary.** An exception leaking out of a callback looks meaningless to the user and can leave the session unstable. 4. **Not checking return values.** Calls that do not throw but return `null`/`false` silently produce incomplete output. 5. **Writing everything into the button callback.** Once business logic mixes into interface code, testing becomes impossible and every rule change means touching the interface. 6. **Running long work inside an event.** The interface locks up and the user thinks SolidWorks has crashed. 7. **Not recording version information.** A bug report from the field is useless when you do not know which version it belongs to. 8. **Changing the `Guid` between versions.** The add-in "disappears" on the user's side and has to be re-enabled. :::illustration left version-control | An add-in is a live product: it wants versioning, deployment and a maintenance scheme ::: ## Frequently Asked Questions **Which languages are SolidWorks add-ins written in?** Most commonly C# and VB.NET; C++ works too. The common condition is that the component can be loaded by SolidWorks over COM. **What licence do I need to develop an add-in?** The API is part of the SolidWorks licence; no separate product is purchased for add-in development. The capabilities you can reach vary with the version you use. **Why doesn't my add-in show up in the add-in list?** Usually one of three reasons: COM registration was not done (`regasm`, with `/codebase` if needed), the SolidWorks registry entry is missing, or the architecture does not match (32/64-bit, or an unsupported .NET version). **Why do my events stop arriving after a while?** Almost always because no strong reference is held to the event handler object; when the garbage collector takes it, the subscription silently drops. Store handlers in a collection on the add-in class. **Should I open my own dialog window or use a PropertyManagerPage?** If selection will be taken from the model, or the flow should feel like a SolidWorks command, use `PropertyManagerPage`. For a standalone, complex, rarely-opened configuration screen, a separate window is reasonable. **Can I convert my existing VBA macro directly into a C# add-in?** Most calls map one to one, but a direct conversion is usually not enough: a macro assumes a one-off flow, while an add-in wants state, a lifecycle and error handling. Use the conversion as a starting point and build the architecture from scratch. **Can one add-in support several SolidWorks versions?** Usually yes — the common approach is compiling against the interop assembly of the oldest version you support. But because version-dependent behaviour differences exist, it needs testing on every target version. ## Conclusion What makes add-in development hard is not the breadth of the API but the fact that **the add-in shares a lifetime with SolidWorks.** So getting three things right from day one makes everything that follows easier: - **Full symmetry** between `ConnectToSW` and `DisconnectFromSW` - **Strong references** to event handlers, and **no room** for long work inside an event - Business logic in a separate layer that knows **nothing** about SolidWorks Choose the interface component by how long the interaction lasts, log your errors, make the version visible, and package the installation. The rest is largely repeating skeleton code. If you would like to see how this architecture grows from macro level, have a look at [the SolidWorks CAD automation case study](https://mehmetseyrimez.com/en/projects/solidworks-cad-otomasyonu). If you would like to assess together whether your own process has reached the add-in threshold, write to me from [the contact section](https://mehmetseyrimez.com/en#contact). --- # How to Start a CAD Automation Project: 4 Steps That Work source: https://mehmetseyrimez.com/en/blog/otomasyon-projesine-nasil-baslanir type: article published: 2026-08-22 updated: 2026-08-26 category: CAD Automation tags: otomasyon, cad-otomasyon, surec, solidworks, proje-yonetimi author: Mehmet Seyrimez reading_minutes: 11 > Start from the problem, not the tool. A four-step method for CAD automation: measure the loss, draw the boundary, run a verifiable pilot, widen in the field. The correct order for starting a CAD automation project is this: **measure which task repeats and how often, write down where the automation stops, run a small pilot whose result cannot be argued about, and widen scope only against losses you actually measured.** Tool selection — LISP, C#, Python — comes after those four steps, and by then it is usually obvious. Most automation projects fail because they begin with the wrong question. The question is usually *"which tool can we automate this with?"* — but that is the last of three, not the first. The four steps below describe the order I follow in my own projects. The order is not arbitrary: each step exists to stop the next one from going the wrong way. :::illustration full process-steps | The four steps of an automation project: measure, bound, pilot, widen ::: ## 01 — Measure the problem I start from the problem, not the tool. The first thing to do is not to write code but to measure two things: - **Which task repeats, and how often?** - **Where exactly is time lost in the current process?** These sound simple, but the answers are often surprising. A team says "modelling takes too long"; when you measure, the real loss turns out to be in manually fixing drawing output, not in modelling. A project that automates the wrong place produces no felt gain, however flawless the code. ### How to keep a two-week log Measurement does not have to be complex. One table, a few columns, two weeks: | Field | Example | Why it is needed | | --- | --- | --- | | Task name | "Filling drawing title blocks" | Makes the item specific | | Repetitions | 14 / week | This is the multiplier of the return | | Average duration | 9 min | This is the base of the return | | Who does it | Design — 2 people | Who the gain returns to | | Rework | 2 corrections | Early signal of verification load | What matters is not precision but **finding the right item.** Rounding minutes will not change the outcome; picking the wrong task changes everything. > The return of automation is time saved times repetition count. Perfectly automating a rarely repeated task produces less value than roughly automating a frequently repeated one. ### Three habits that ruin measurement **Estimating from memory.** "It probably takes about an hour a day" is not a measurement. Once logged, most estimates turn out to be double or half. **Sampling the worst day.** People remember the most annoying task, not the most time-consuming one. Logging ordinary days for two weeks corrects that bias. **Counting only the "doing" time.** The waiting around the task — finding the file, confirming the right revision, waiting for information — is often longer than the task itself. If automation does not touch that waiting, the gain stays on paper. :::illustration right speed-test | Measurement: which task, how many times, how long ::: ## 02 — Draw the boundary of the automation The second step is to look at the list from step one and make one distinction **explicitly**: what goes to software, and what stays with a person. Skip this and the project breaks in one of two ways: 1. **Scope keeps growing.** Every exception is added to the software, the system turns into a pile of rules, and maintenance becomes impossible. 2. **Nobody trusts it.** If it is unclear where the automation begins and ends, users re-check its output every single time — which hands the saved time straight back. A practical distinction that works: **work that can be turned into a rule goes to software; work that requires judgement stays with a person.** Computing a profile length from a parameter is a rule. Deciding whether a customer's special request fits the standard production flow is judgement. ### Put the boundary in writing Where the boundary sits matters, and so does **the fact that it is written down.** A single page is enough, with four headings: - **The automation does this:** the input list and the produced output list, itemised. - **The automation does not do this:** the things that will be asked for often but are deliberately out of scope. - **It stops and hands over when:** a parameter is missing, a dimension is out of range, a product family is unrecognised. - **Who may change this document:** the owner of scope decisions. Every later exception request is judged against this page. Without it, every request looks reasonable and the scope grows silently. :::illustration left guidelines | The boundary: what goes to software, what stays with a person ::: ### Do not turn exceptions into rules The most common decay I see in the field: a one-off exception made for one customer enters the rule engine as an `if`. Six months later there are twenty such branches and none of them explains why it is there. Practical guard: put exceptions in **data**, not code. A configuration table keyed by product family does the same job but stays readable and is easy to remove. ## 03 — Start with a verifiable pilot The third step is where code begins — but not all of it. You pick a small piece with a **measurable result.** The test of a well-chosen pilot: when it is done, whether it worked should not be open to debate. "It feels better" is not a result. "Preparing the same frame went from 40 minutes to 6" is a result. The pilot does one more thing: it **breaks assumptions early.** The most expensive mistakes in automation projects come from discovering, six months in, that production data is not in the shape you assumed. A small pilot shows that in week two. ### Five properties of a good pilot 1. **End to end, but narrow.** One product variant, from parameter entry to production output. A pilot that automates only the middle of the chain hides the real bottlenecks. 2. **On real data.** Not a cleaned sample file — a file from the field. Dirty data is the pilot's real exam. 3. **With one user.** Handing it to five people at once blurs the feedback. 4. **Time-boxed.** Four to six weeks. A pilot with no end date is not a pilot; it is an open-ended project. 5. **Success criterion written first.** Something like "continue if preparation time drops by 40%." A criterion set afterwards makes every outcome look like success. :::illustration full checklist | The test of a pilot: its result should not be debatable ::: ### The one question to ask when a pilot ends Not "did it work?" but: **would the person who used to do this by hand refuse to go back?** If the answer is no, something is wrong regardless of the numbers — usually the verification load was underestimated. ## 04 — Widen it in the field The final step is expanding scope — but **with evidence, not guesses.** As the pilot proves itself in the field, you add the next variant, the next product family, the next output type. Before each expansion, the same question: which of the loss items measured in step one does this address? Without that discipline, automation projects bloat with features nobody uses. Every unused feature is not just wasted time; it is a permanent maintenance cost. ### A simple score for expansion order Three factors, multiplied: | Factor | How to score | | --- | --- | | Repetition | Monthly repetitions / 10 | | Lost time | Average minutes / 10 | | Rule clarity | 3 if the rule is written and stable, 1 if contested | The product of the three predicts what should come next surprisingly well. The third factor matters most: automating a task whose rules have not settled is trying to pin down a moving target. ## What I do not automate Describing a method means naming what it excludes, not only what it covers. - **Decisions that require judgement.** I use AI tools for speed and iteration; architecture decisions, verification and test load stay with me. The code-side version of this line is in [writing a SolidWorks add-in with AI](https://mehmetseyrimez.com/en/blog/yapay-zeka-ile-solidworks-eklentisi-yazmak). - **Rarely repeated tasks.** Automating something done once a month usually costs more than doing it by hand. - **Processes that have not settled.** First the process stabilises, then it gets automated. - **Outputs with no verification.** If no deterministic rule can check an output that goes to production, that step is not automated. :::callout A common mistake If the project starts with a "which language should we use" debate, the team spends weeks comparing tools and never logs a single measurement. The tool decision usually takes ten minutes once measurement is done — because by then the constraints (who maintains it, where it deploys, which CAD version) are already known. ::: ## Tool selection: after the four steps Once measurement and boundary are settled, the tool decision becomes mechanical. Rough thresholds: | Situation | Suitable tool | Rationale | | --- | --- | --- | | One person, runs a few times | Macro (VBA) | Don't let setup cost eat the gain | | Exploration, validating an idea | Python + COM | Fastest iteration loop | | A team will use it, contains rules | C# / .NET add-in | Tests, version control, deployment | | Produces output that goes to production | C# / .NET + verification layer | Silent failure is the expensive failure | I cover the technical difference between these three routes in [macro, API and add-in](https://mehmetseyrimez.com/en/blog/solidworks-makro-api-farki), and where Python ends and C# begins in [SolidWorks automation with Python](https://mehmetseyrimez.com/en/blog/python-solidworks-otomasyonu). ## Frequently Asked Questions **How large a team do you need to start an automation project?** One developer and one user are enough for the pilot phase. Team size should grow only after scope is proven in the field; a crowded team at the start stacks parallel work on unverified assumptions. **How do you decide whether a task is worth automating?** Multiply time saved by repetition count, then subtract maintenance load. If the monthly gain does not cover development and maintenance within a reasonable window (typically six months), the task stays manual. The measurement method is in [measuring automation gains](https://mehmetseyrimez.com/en/blog/otomasyon-kazancini-olcmek). **How long should a pilot project run?** Four to six weeks. Shorter does not break assumptions; longer stops being a pilot. The end date and the success criterion must be written down before it starts. **What is the most common mistake in automation projects?** Choosing a tool before measuring. A close second: not writing the automation's boundary down — without it, every exception request looks justified and scope grows silently. **Which language should I choose for CAD automation?** Python for exploration and validation, C# / .NET for permanent flows that go to production. For one-off small jobs a VBA macro is still the fastest route. The decision follows from who will maintain it and how long it will live. **Which metrics should track an automation's success?** Four are enough: preparation time, rework rate, first-time-right percentage, and the number of errors that escape to production. Measuring only production time makes the gain look bigger than it is. ## Summary An automation project's success is decided by the questions asked in the first week, not by the library chosen on day one: | Step | Question | | --- | --- | | 01 | Which task repeats how often, and where is time lost? | | 02 | What goes to software, what stays with a person? | | 03 | What is the smallest piece with a measurable result? | | 04 | Which measured loss does this expansion address? | Tool selection comes after these four answers — and by then it is usually obvious anyway. :::callout In practice You can see this method applied in the CAD/CAM platform I built for prefabricated light steel production and in my SolidWorks automation work; in both, the order was the same: measure, bound, pilot, widen. ::: --- # 2D to 3D Conversion Automation: What Actually Works source: https://mehmetseyrimez.com/en/blog/2b-teknik-resimden-3b-modele-otomasyon type: article published: 2026-08-22 updated: 2026-08-29 category: Automation Workshop tags: solidworks, otomasyon, parametrik-tasarim, yapay-zeka, dwg author: Mehmet Seyrimez reading_minutes: 9 > 2D to 3D conversion automation: cleanup and classification reach ~90% and ~80%, parametric wiring only ~20%. Why design intent is not in the drawing. In automated 2D-to-3D conversion, **the geometry can be automated; the design intent cannot.** Cleanup, profile recognition, product-family classification and draft solid generation can largely be handed to a machine today. What cannot be handed over is which dimension drives which — how the parameters are wired to each other. That information is nowhere in the drawing; a drawing carries the *result* of the geometry, not its *reason*. There are thousands of DWGs in the archive, all of parts that were manufactured and worked in the field. The question looks simple: let's turn them into 3D models and never draw them again. This is the most requested and most underestimated item in CAD automation. The reason fits in one sentence: **a drawing carries geometry, not design intent.** :::illustration full drafting-board | The gap between geometry, the rule layer, and the model ::: ## Why geometry is not enough What you can extract from a drawing is the part's **current** state: this length, this hole diameter, this bend angle. What you cannot extract is *why* those values are what they are. A concrete example: the drawing shows a 120 mm distance. Is it - a fixed assembly dimension, - half the overall width, - or 120 because it must sit 40 mm from the hole beside it? All three produce the same line. But the moment you want the part parametric, all three behave completely differently. Change the width and the first stays put, the second re-centres, the third follows the hole. The model an automatic conversion produces usually picks the first assumption — which makes it a **dead solid.** The picture is correct, but change a parameter and the model falls apart. ### When a dead solid is good enough Not every conversion needs to be parametric. A dead solid is entirely sufficient in three cases: - **Visualisation and assembly layout.** You do not need intent to see how much space a part takes. - **Interference and envelope checks.** If the geometry is right, the check is right. - **Archive migration.** Storing old parts in a 3D environment without redrawing them. The only case that genuinely requires a parametric model is **when variants of that part will be produced.** Making this distinction upfront is the project's most expensive decision: trying to parametrise the entire archive is unnecessary cost in most companies. ## What automation genuinely solves None of this means conversion cannot be automated. A large part of the chain automates very well: - **Cleanup.** Broken lines, overlapping entities, unused layers, scale inconsistencies. Tedious and rule-bound — the part best suited to automation. - **Recognition.** Telling closed profiles, hole groups and bend lines apart. - **Classification.** Determining which product family a drawing belongs to. The rule layer is chosen accordingly. - **Draft solid.** Producing the first solid with the right profile and thickness. Together, those four take most of the mechanical load. What remains — what the parameters get wired to — is a design decision. ### The hidden value of the cleanup step The most common surprise in the field: the cleanup step alone produces a large share of the project's expected gain. The reason is that old archives are far dirtier than anyone assumes. What a typical DWG archive contains: | Problem | Frequency | Auto-fixable | | --- | --- | --- | | Broken / overlapping lines | Very high | Yes — with a tolerance threshold | | Unused layers and blocks | High | Yes | | Scale / unit inconsistency | Medium | Partly — needs a reference dimension | | Exploded dimensions | Medium | No — the information is gone | | Hand-written "approximately" notes | Low | No — requires judgement | The last two rows show the boundary of conversion: where information has been lost, automation cannot bring it back. :::illustration right design-thinking | The same line, three different parametric intents ::: ## How you recover design intent If the intent is not in the drawing, it has to come from somewhere else. In practice there are three sources: **1. The product-family rule.** Every part in a family is dimensioned by the same logic. Define it once, apply it to the whole family. This is the most efficient route — and it requires the archive to be classified. **2. Variant comparison.** If you have drawings of the same part at two different sizes, which dimension changed and which stayed fixed is directly visible. This is the most reliable way to derive intent from data. **3. The knowledge of whoever designed it.** The most expensive but most certain source. Half a day of conversation about one product family can settle the intent of hundreds of parts. Using all three together is markedly faster than using any one alone: draft the rule per family, confirm it with variant comparison, close the remaining uncertainty with a conversation. ## Where AI fits in this chain AI makes two genuine contributions here, and one overstated one. **Genuine contribution 1 — recognition.** The image-processing side is far better than hand-written rules. For "is this a sheet metal bend line?", pattern recognition is strong. **Genuine contribution 2 — classification.** Grouping thousands of drawings by product family takes weeks by hand. A model does it in hours, and its mistakes are easy for a human to spot. **The overstated part — intent inference.** The claim that "AI understands design intent" is too optimistic today. A model can guess which dimension is the driver; accept that guess **without verification** and you have buried the error inside a parametric model. And it is the [silently-wrong kind](https://mehmetseyrimez.com/en/blog/yapay-zeka-ile-solidworks-eklentisi-yazmak) — it surfaces months later, while producing another variant. :::callout No guess is accepted without verification Before accepting a model's intent guess, one test is enough: rebuild with three different parameter values. If the model falls apart, the intent is wrong. This test can be automated and it is the most valuable step in the whole chain. ::: ## The order I follow in practice 1. **Start narrow.** One product family, one variant. Run it end to end. 2. **Classify the archive.** Which drawing belongs to which family — without this step the rule layer cannot be chosen. 3. **Define intent by hand.** Determine once which dimension drives that family; then apply it to the whole family. 4. **Automate verification.** Rebuild the generated model with a few parameter values; if it falls apart, the intent is wrong. 5. **Then widen.** Move to the next family only once one works solidly. This order is the [four-step method](https://mehmetseyrimez.com/en/blog/otomasyon-projesine-nasil-baslanir) from the first post in this series, applied to this specific problem. :::illustration left problem-solving | Verification: rebuild the model at three different parameter values ::: ## How long it takes, what it returns Rough ratios I use to set expectations — assuming a thousand-drawing archive and a single product family: | Stage | Automation share | Human share | | --- | --- | --- | | Cleanup and recognition | ~90% | Spot checks | | Classification | ~80% | Sorting out edge cases | | Draft solid | ~70% | Drawing failed conversions by hand | | Parametric wiring | ~20% | Intent definition and verification | | **Total** | **clear gain** | **Rule writing and checking** | The message here is not the last row but the fourth: parametric wiring is the stage automation helps least with, yet most of the project's value lives there. Which is why defining conversion projects as **"let's make this product family parametric"** rather than "let's convert the archive" produces much healthier outcomes. How I set up measurement is in [measuring automation gains](https://mehmetseyrimez.com/en/blog/otomasyon-kazancini-olcmek). Once a product family is parametric, batch export and release packages often move to [SolidWorks Python scripting](https://mehmetseyrimez.com/en/blog/python-solidworks-otomasyonu) or C# add-ins — the object model is the same; only the binding changes. ## Frequently Asked Questions **Can 2D drawings be converted to 3D models automatically?** The geometry can largely be converted: cleanup, profile recognition, classification and draft solid generation all automate well. Producing a parametric model — one whose dimensions are wired to each other — requires design intent, and that information does not exist in the drawing. **What is design intent, and why is it missing from a drawing?** Design intent is why a dimension has the value it has: is it fixed, tied to another dimension, or the result of a constraint? A drawing shows the result of the geometry, not those dependencies. The same line may have come from three different intents. **Is it worth converting an entire DWG archive to 3D?** Usually not. A parametric model is only needed for parts whose variants will be produced. For visualisation, interference checking and archiving, a non-parametric "dead solid" is enough and far cheaper to produce. **Can AI infer design intent from a drawing?** It can guess, but the guess must not be used unverified. The reliable verification method is to rebuild the generated model at several different parameter values; if it falls apart, the intent guess was wrong. **Where should a conversion project start?** With a single product family and a single variant. Classify the archive first, then define the driving dimensions for that family, then automate verification. Scope is widened only once that chain works end to end. **What is the most common problem in automated conversion?** Dirty source drawings: broken lines, exploded dimensions, inconsistent scale and unused layers. Exploded dimensions are unrecoverable — the dimension information is simply gone. ## Summary What can be automated in the 2D-to-3D move is cleanup, recognition, classification and draft generation. What cannot is how the dimensions get wired to each other — because that information was never in the drawing. The right project definition is not "let's convert the archive" but "let's make this product family parametric." The productised version of this approach is described in the [ParametriX case study](https://mehmetseyrimez.com/en/projects/parametrix-2d-3d). --- # Measuring Automation Gains: What 90% Faster Leaves Out source: https://mehmetseyrimez.com/en/blog/otomasyon-kazancini-olcmek type: article published: 2026-08-21 updated: 2026-08-26 category: Automation Workshop tags: otomasyon, olcum, cad-otomasyon, surec, roi author: Mehmet Seyrimez reading_minutes: 8 > Vendors measure the generation step alone. Add preparation, verification and rework and the honest gain lands at 30-50% — with a payback you can calculate. The real gain of an automation cannot be expressed as a single percentage. Honest measurement compares four items at once: **preparation, generation, verification and rework.** The "90% faster" figure vendors publish almost always measures only the second — the generation step. Measured across all four, a typical real gain lands between 30% and 50%; still an excellent result, but expectations should be set there. Automation tool pages always carry a percentage: 70%, 85%, sometimes 90%. Those numbers are not invented — but what they measure is almost never stated. This post is about how to read them and how to set up your own measurement. :::illustration full charts-analysis | The gain chain: preparation, generation, verification, rework ::: ## A percentage of what? When a vendor says "drawing time dropped 90%," what was usually measured is: **the time for a single operation, under ideal conditions, to reach a first output.** What was not measured: - Time to prepare the input (collecting parameters, cleaning the model) - Time to verify the output - Time to fix what verification caught - The automation's own maintenance time Add those four and the 90% often falls into the 30–50% band. > An automation's return is bounded by its slowest link. Speed the generation step up tenfold and leave verification untouched, and the total gain is whatever verification allows. ### Amdahl's law in the engineering office Computer architecture has a familiar rule: a system can only speed up as much as the part you sped up allows. The same arithmetic applies in an engineering office. Say the whole task takes 100 minutes: preparation 30, generation 40, verification 20, rework 10. You make generation ten times faster — 40 minutes becomes 4. | Step | Before | After | | --- | --- | --- | | Preparation | 30 min | 30 min | | Generation | 40 min | 4 min | | Verification | 20 min | 20 min | | Rework | 10 min | 10 min | | **Total** | **100 min** | **64 min** | That is a 90% gain in generation and 36% overall. Both numbers are true; which one you publish is a choice. The problem is when the purchase decision is made on the first one. ## Measure all four steps The framework I use in my own projects has four rows: | Step | Before | After | Why it is measured | | --- | --- | --- | --- | | Preparation | ? min | ? min | Automation demands input; that input is not free | | Generation | ? min | ? min | This is usually the only thing a vendor measured | | Verification | ? min | ? min | Output you do not trust is checked every time | | Rework | ? min | ? min | If the error rate did not drop, the gain is misleading | Filling all four rows before and after resolves most inflated claims on its own. ### Who keeps the log, and how The person who wrote the automation should not keep the log. They know the path where the tool works best and will pick it without noticing. The log is kept by the person who actually does the work; the developer only supplies the table format. The simplest method that works in practice: two weeks before, two weeks after, same person, same task type, a stopwatch on a phone. No better tool is needed — what is needed is that **the same task** is measured. ## The real payback calculation Time saved alone does not make a decision. Payback period does — and the calculation is three sentences long. First find the **monthly gain**: multiply the minutes saved per job by the monthly repetition count, then convert to hours. Next write down the **total cost**: development hours plus the maintenance hours you will set aside for the first year. **Payback period** is that cost divided by the monthly gain. Take the example above: 36 minutes saved per job, 40 jobs a month. That is 1440 minutes, or 24 hours a month. If development takes 80 hours and first-year maintenance 20, total cost is 100 hours. 100 ÷ 24 ≈ **4.2 months.** Under six months the decision is usually clear. Past twelve months, one of two things has to happen: narrow the scope to cut development time, or drop the idea. :::illustration right cost-savings | Payback = development + maintenance ÷ monthly gain ::: ## Five traps to watch for **1. Measuring the best case.** Try the automation on the most convenient part and you will get a lovely number. Try it on an average job — that is the number you will actually live with. **2. Ignoring the learning curve.** A new tool *slows work down* for the first two weeks. Measure in week one and you will miss the gain; never measure it and you hide the real cost. The right approach: start measuring from week three and record the learning period separately as a one-off cost. **3. Forgetting maintenance.** Automation is live software. When a product family changes, the rule layer changes; when the CAD version moves up, API calls get re-checked. A few days a year comes out of the gain. **4. Not converting the gain into anything.** Say you saved 24 hours a month; if those hours were not redirected to other work, nothing changes in the ledger. Deciding where the gain goes is part of the measurement. **5. Measuring one person.** The number from your best user does not represent the team average. Measure at least two different users. :::illustration left maintenance | Leave maintenance out and the gain looks larger than it is ::: ## When measuring is not worth it Honestly, not every automation needs measuring. Setting up measurement for a ten-minute task done twice a month costs more than the automation itself. In such cases the decision is already clear: either it is an obvious small convenience, or it should not be built at all. Measurement matters **when the decision is genuinely uncertain**: deciding whether to widen scope, asking for budget, or arguing about whether a tool actually works. ## How to read the results When the table is filled, I look for three answers: **Which step grew?** Automation can shorten one step while lengthening another. The most common: generation shrinks, preparation grows — because the automation now demands tidier input. That is not a bad outcome, but it must be visible. **Did the rework rate drop?** Even if total time is unchanged, fewer corrections means the automation is producing value. Consistency is a gain worth measuring on its own. **Did variance drop?** If a manual task ranged from 20 to 70 minutes and now sits between 8 and 12, you have gained planning capability. That line never appears in the table, but for teams doing production planning it can be worth more than the average gain. ## What we measured On the light steel CAD/CAM platform, internal measurements against the previous CAD system reported a clear speedup in the preparation phase. That number is meaningful because what was measured was not a single operation but **the whole preparation phase** — input collection and output checking included. I applied the same discipline to the SolidWorks add-in work, where the main gain turned out to be **output consistency** rather than raw time: drawings for a product family now come out in the same layout no matter who produces them. The same release-package problem is often prototyped first with [SolidWorks Python scripting](https://mehmetseyrimez.com/en/blog/python-solidworks-otomasyonu) before it becomes an add-in. Project details are in the [light steel CAD/CAM case study](https://mehmetseyrimez.com/en/projects/prefabrik-hafif-celik-cadcam). :::callout Before you measure Setting up measurement before drawing the automation's boundary wastes time: if scope is unclear, "before" and "after" do not describe the same task. The boundary step is in [how to start an automation project](https://mehmetseyrimez.com/en/blog/otomasyon-projesine-nasil-baslanir). ::: ## Frequently Asked Questions **How do you calculate the gain from automation?** Measure preparation, generation, verification and rework separately, before and after. Multiply the total difference by monthly repetitions, then divide development plus maintenance hours by that monthly gain to get the payback period. **Are vendor claims like "90% faster" reliable?** The number is usually accurate but narrow: it measures only the generation step with ideal input. Including preparation, verification and rework, the same tool typically delivers a 30–50% total gain. **When should measurement start?** From the third week after rollout. The first two weeks are the learning period and understate the gain; record that period separately as a one-off cost. **What payback period is acceptable?** Under six months the decision is usually clear. Past twelve months you should either narrow the scope to cut development time or drop the idea. **How is maintenance cost included?** Budgeting maintenance hours at roughly a quarter of the annual development time is a realistic starting point for year one. CAD version upgrades, product family changes and rule updates come out of that line. **Besides time, what else should be measured?** Rework rate, first-time-right percentage and variance in duration. Reduced variance in particular can matter more to production planning teams than the average time saved. ## Summary Look at the four steps, not the percentage. The only question worth asking about an automation tool: **which step does it shorten, and which step does it lengthen?** Next in this series: automating the move from 2D drawings to 3D models — where the real question is again which step can genuinely be handed over. --- # Writing SolidWorks Add-ins with AI: What It Gets Wrong source: https://mehmetseyrimez.com/en/blog/yapay-zeka-ile-solidworks-eklentisi-yazmak type: article published: 2026-08-19 updated: 2026-08-26 category: Automation Workshop tags: solidworks, yapay-zeka, csharp, otomasyon author: Mehmet Seyrimez reading_minutes: 5 > AI speeds up add-in scaffolding and API discovery, then gets COM lifetimes, version signatures and silent failures confidently wrong. Where I draw the line. I use AI tools as controlled leverage when building add-ins. "Controlled" is not decoration there: the SolidWorks API is one of the areas where language models go wrong most often. For flows still in the exploration phase — connecting over COM, testing parameters, validating export paths — [SolidWorks Python scripting](https://mehmetseyrimez.com/en/blog/python-solidworks-otomasyonu) is usually faster before you commit to add-in architecture. This post separates where it helps from where it does not. :::illustration full code-inspection | Verifying generated code can take longer than generating it ::: ## Where it genuinely speeds things up **Scaffolding.** Add-in registration, the `ISwAddin` implementation, the CommandManager tab, button wiring — near-identical in every add-in. Half a day by hand, a few minutes to generate. The gain is real and the risk is low, because mistakes surface at compile time. **API discovery.** The SolidWorks API is broad and its documentation is scattered. Asking "how do I reach the bend table of a sheet metal part" usually gets to the right interface name faster than searching for it. But I do not use the answer **without verifying it** — for the reason below. **Repetitive conversions.** If a VBA macro exists and needs porting to C#, that is mechanical translation. AI is good at it. **Test data and edge-case lists.** Asked "what inputs break this function", the list that comes back is usually longer than the one I had in my head. ## Where it is confidently wrong The danger here is not that it makes mistakes — it is that **the mistakes do not announce themselves.** **COM object lifetimes.** The SolidWorks API runs over COM. Generated code often skips releasing objects, or releases them in the wrong order. Nothing visible happens immediately: the application runs, but memory grows over long sessions or SolidWorks hangs on shutdown. These faults show up in the field three weeks later, not in testing. **Version differences.** If an API method changed between releases, the model usually emits the older signature. It compiles, it runs, it returns the wrong result. **Silent failure.** Many SolidWorks API calls do not throw; they return `null` or `false`. Generated code frequently skips checking those returns. The automation looks like it worked and quietly produces incomplete output. > The most expensive automation fault is not code that crashes — it is code that **silently produces wrong output.** You notice a crash; wrong output goes to the shop floor. :::illustration left fixing-bugs | Keeping the generation layer separate from the validation layer ::: ## The working rule I settled on I turned that separation into a rule: 1. **Scaffolding and mechanical conversion** — generate it, review quickly. 2. **Any code containing an API call** — generate it, but add return-value checks and object release by hand. 3. **The rule and validation layer** — written by hand. Code that decides whether the product is correct is not entrusted to generated code. 4. **Tests** — AI suggests edge cases, I write the tests. This is the code-side counterpart of [drawing the automation boundary](https://mehmetseyrimez.com/en/blog/otomasyon-projesine-nasil-baslanir): rule-shaped work is delegated, judgement-shaped work is not. ## What I actually measure Answering "did AI speed up development" with a single number would be wrong. There are two separate things worth measuring: | Measurement | What I observe | | --- | --- | | Time to first working version | Noticeably shorter | | Time to field-reliable version | No clear difference | The gap between them shows where the verification load moved: from writing time to reading time. Your total gain is only as good as your verification discipline. ## Summary AI accelerates scaffolding and discovery in SolidWorks add-in work; it does not know the API's traps. Protecting the gain comes down to deciding upfront where generated code is allowed to live. Next in the series: the AutoCAD options, and how to measure the gain honestly. ## Frequently Asked Questions **Does AI genuinely speed up SolidWorks add-in development?** It speeds up scaffolding and API discovery markedly. Add-in registration, lifecycle implementation and command UI setup are nearly identical in every add-in; generating them takes minutes and the risk is low because mistakes surface at compile time. **Where is AI most often wrong about the SolidWorks API?** Three areas: COM object lifetime (release order), method signatures that changed between versions, and silent failure — calls that do not throw but return `null` or `false` and go unchecked. **How should generated code be verified?** Split the code into three groups: scaffolding and mechanical conversion can be generated and reviewed quickly; any code containing API calls gets return-value checks and object release added by hand; the rule and verification layer is written by hand. **Why is silent failure the most expensive kind of bug?** You notice code that crashes; code that quietly produces wrong output goes to the shop floor. The error surfaces weeks later, when the wrong part has been made, and costs many times more than rewriting the code would have. **Does AI shorten total development time?** Time to a first working version drops clearly; time to a version that is reliable in the field showed no clear difference in my experience. The load moves from writing to reading — total gain equals your verification discipline. **Which code should never be delegated to AI?** The code that decides whether the product is correct. The rule and verification layer is written by hand; you write the tests too, and the model only suggests edge cases. --- # Autonomous Underwater Welding and Inspection ROV — DYUK'22 source: https://mehmetseyrimez.com/en/blog/otonom-sualti-kaynak-ve-muayene-rov type: article published: 2022-05-16 category: Journey Notes tags: rov, sualti-kaynak, goruntu-isleme, makine-ogrenmesi, cad, yayin author: Mehmet Seyrimez reading_minutes: 5 > The ROV from our DYUK'22 paper: underwater welding and weld inspection in one autonomous vehicle, using image processing and machine learning. Paper ID 4449. On 16–18 May 2022, at the **1st National Congress on Interdisciplinary Approaches (DYUK'22)** — themed "Sustainable Future and Digital Transformation" and hosted by Istanbul Gedik University's Gedik Vocational School — we presented our paper *Autonomous Underwater Welding and Underwater Weld Inspection Vehicle*. It appears in the congress's official abstract book under **ID 4449**. The work was co-authored by Kadir Gökhan Çalkap, myself, Hüseyin Kaygısız, and Erkin Duman, and carried out within the Machinery Program at Istanbul Gedik University. :::photo full rov-otonom-sualti ::: ## The problem: the bottleneck is people, the cost is time Underwater welding and weld inspection are critical but narrow fields for maritime logistics and the defence industry. Few technicians can do this work, and that scarcity turns directly into two costs: - **Wage cost** — the supply of qualified diver-welders is limited, so each unit of work is expensive. - **Time cost** — the process itself is long; every operation requires a dive preparation, descent, operation, and inspection cycle. Every hour a ship or an oil pipeline spends waiting is a direct operational loss. The economic side of the problem, not the technical one, was the project's starting point. --- ## The approach: welding and inspection in the same vehicle Our answer was an ROV (remotely operated underwater vehicle) able to perform underwater welding **and** weld inspection autonomously. The critical decision was to combine both operations on one platform rather than splitting them across two vehicles: if the vehicle that lays the weld can also measure its quality in place, no second dive is needed. Two end units were added to the ROV for this: 1. **An underwater welding torch** — the arm that performs the weld. 2. **An immersion probe** — a second arm that carries out the weld inspection. An onboard microcomputer coordinates and controls both units autonomously. ### Hardware architecture The component list from the paper is a good summary of why the vehicle is not "just a drone frame": - **Servo motors** — control of the propellers (thrusters) - **Gyroscopes** — balance and position calculation during welding - **Ultrasonic distance sensor** — measuring the distance to the work area - **Camera module** — identifying the region to be worked on - **Stepper motors** — precise motion of the robotic arms - **Motor drivers** — motor control - **Wireless communication modules** — interaction with the operator panel above water - **Microcontroller** — attaching and controlling the sensors Holding balance with gyroscopes during welding is one of the most critical items on that list. A vehicle that cannot stay still under current will not lay an acceptable bead, however good the torch it carries. ### The software side Image processing and machine learning software were loaded onto the system so it could interact with the control panel and carry out its assigned task. Making sense of what the camera module sees, identifying the line to be welded, and evaluating the inspection result all belong to this layer. :::callout Looking back from today The layer we described in 2022 as "let the camera see and the model decide" is the same loop I work on today in CAD automation: recognise the geometry, apply the rule, verify the result. The domain changed; the loop did not. ::: --- ## Comparison: where we stand against a commercial ROV To keep the design grounded, we placed it side by side with a commercial reference — the **Aegir 250 (Ocean Robotics)**. The comparison slide from the congress gave this table: :::photo full dyuk22-karsilastirma ::: | Dimension | Aegir 250 (reference) | Our ROV | | --- | --- | --- | | Length | 1350 mm | 1630 mm | | Width | 1000 mm | 905 mm | | Height | 850 mm | 580 mm | | Weight | 350 kg | 307 kg | The result reads clearly: our vehicle is **longer** than the reference but **narrower, markedly lower, and 43 kg lighter**. The low profile is a direct advantage for manoeuvring in tight openings such as ship hulls and pipelines; the weight difference shows up in transport and deployment cost. --- ## Output and limits The work completed the ROV design, examined the operating system, and produced a **scale model**. In other words, what we had was not a working field vehicle but a validated design and a physical model — there is no point in presenting it as more than that. If the model were developed and turned into a product, the intended application areas were: - Underwater pipelines used for oil transport - Maintenance and repair of ships in maritime logistics - Welding and inspection work in the defence industry where required The goal was to make these operations **fast, low-cost, and error-free**. --- ## Citation The full abstract is published in the congress's official abstract book: > Çalkap, K. G., Seyrimez, M., Kaygısız, H., Duman, E. (2022). *Autonomous Underwater Welding and Underwater Weld Inspection Vehicle* (Paper ID 4449). Abstract Book of the 1st National Congress on Interdisciplinary Approaches, p. 35. Istanbul Gedik University, 16–18 May 2022. The abstract book is available from the university's official site: [dyuk.gedik.edu.tr — DYUK'22 Abstract Book (PDF)](https://dyuk.gedik.edu.tr/wp-content/uploads/Ozet-Kitabi.pdf) **Keywords:** ROV (Remotely Operated Underwater Vehicle), underwater welding, underwater weld inspection, image processing, machine learning. --- # Cargo Delivery by UAV: Founding the Paper Plane Team source: https://mehmetseyrimez.com/en/blog/iha-ile-kargo-teslimati type: article published: 2022-04-06 category: Journey Notes tags: iha, drone, lojistik, cad, takim-calismasi author: Mehmet Seyrimez reading_minutes: 3 > The UAV seminar I gave at Gedik University: the real cost lines of parcel delivery, a network of mobile ground control stations, and the Paper Plane airframe. Turning an engineering idea into a presentation slide is that idea's first serious test. In April 2022, at the **Unmanned Aerial Vehicles and Technology Seminar** we organised together with Istanbul Gedik University's Technology Club, I saw this plainly while presenting the Paper Plane UAV Team I had founded: designing a drone was the easy part; the hard part was explaining *why* you built it well enough to convince a room. :::photo full paper-plane-sunum-biz-kimiz ::: ## Problem first, vehicle second The trap we fell into most often while founding the team was starting from the vehicle. "Let's build a drone like this" was exciting, but it did not say which problem it solved. So I built the spine of the presentation not on the aircraft but on the cost table of parcel distribution. :::photo right paper-plane-sunum-problem ::: The line items that inflate cost in parcel and last-mile delivery are surprisingly ordinary: - Vehicle and fuel costs - Branch and staff expenses - Adverse weather conditions - Delays from heavy traffic and accidents - Physical damage to parcels - Customer communication and misdelivery problems - Pollution generated by the delivery fleet Here is why that list matters: none of these is an *aviation* problem. Every one of them is a **logistics** problem. The unmanned aircraft is not the goal here; it is a tool that attempts to remove some of these line items. > If you pick the vehicle before the problem, every engineering decision that follows is spent justifying that choice. --- ## The model we proposed: a network, not a single drone In the second half of the seminar I covered the solution. A scenario where one long-range aircraft carries everything was unrealistic on both battery and regulatory grounds. Instead, we proposed **a network of mobile ground control stations**. :::photo full paper-plane-sunum-cozum ::: Roughly, the model worked like this: 1. Instead of fixed branches, mobile ground control stations are deployed and can operate around the clock. 2. UAVs make short and medium-range hops between these stations; each hop is planned to fit within battery capacity. 3. Stations and vehicles exchange data continuously; route, weather, and delivery status are common knowledge across the network. 4. Range therefore comes not from a single vehicle's capacity but from the topology of the network. In its first stage, this approach targeted a cheaper and faster logistics option for short and medium-range locations. :::callout Looking back The reflex I use today, working on CAD automation and engineering software, was formed here: rest a system not on one powerful component but on small, verifiable parts that complete each other. ::: --- ## ::center The airframe: Paper Plane cargo UAV :::center The aircraft itself mattered as much as the network design. We focused on a six-rotor cargo UAV with a dedicated payload bay beneath the main body and flight control above. ::: :::gallery paper-plane-kargo-render-front paper-plane-kargo-render-iso | Two CAD render variants of the Paper Plane cargo UAV ::: :::center This hexacopter layout aimed to keep the cargo volume centred in the airframe while reducing the footprint needed for take-off and landing. For me the study was also a serious CAD exercise: every change to an arm or the cargo module meant recalculating the body section and the centre of gravity. This was the first time I felt why parametric design is a necessity rather than a luxury. ::: --- # Modular Software Architecture for CAD/CAM and Automation source: https://mehmetseyrimez.com/en/blog/moduler-yazilim-mimarisi type: article published: 2024-10-05 updated: 2026-08-26 category: Journey Notes tags: mimari, cad-cam, urun-gelistirme author: Mehmet Seyrimez reading_minutes: 7 > Modular architecture for engineering software: cut modules by rate of change, not by technology. Module groups, data contracts, decision records and tests. In engineering software projects, a modular architecture raises both development speed and field reliability by making domain boundaries explicit. In CAD/CAM and automation products especially, the "one big monolith" approach looks fast in the short term but drives up maintenance cost over the medium term. :::illustration full modular-blocks | Modular components and dependency boundaries ::: ## Domain to software boundary In fields such as prefab manufacturing, roll-form lines, or SolidWorks automation, software modules should be split along **manufacturing reality**: geometry processing, rule validation, output generation, licensing, and the user interface must be able to evolve independently of each other. > Domain knowledge sets the software boundary; AI tools are used as accelerators inside those boundaries. --- ## Suggested module groups - **Core:** Geometry, parameter model, rule engine - **Integration:** CAD API, file I/O, ERP/MES bridges - **Output:** Drawings, DXF/DWG, production data - **Platform:** Licensing, logging, configuration, UI ## Boundaries: where to cut Cut modules by **rate of change**, not by technology. Things that change for the same reason at the same time belong together; things that change for different reasons come apart. On the CAD/CAM side, that produces a table like this: | Module | When it changes | What it may depend on | | --- | --- | --- | | Geometry core | Rarely — the maths does not move | Nothing | | Rule engine | Often — as production standards shift | Only the geometry core | | CAD integration | As the CAD version moves | The rule engine's output | | Output generator | On customer or line demand | The rule engine | | Platform (licensing, logging) | Independently | No business module | The one-way rule here matters: **no business module may call the platform module, and the platform must not know the business modules.** The moment a licence check leaks into geometry code, testing that code requires a licence server — and the tests never get written. ## Data contracts and versioning The boundary between modules is a **data contract**, not a function signature. Keep the contract in an explicit type and version that type: Let's make the contract concrete. Say the rule engine produces a panel. All the CAD layer needs to know is a handful of fields: a **schema version**, width, height, profile type and a list of openings. Nothing else. How those values were computed inside the rule engine is none of the CAD layer's business. Put that `schema version` field in from **day one**, even if it stays at `1`. The reason: adding a field is not a breaking change, but **removing** one — or changing its meaning — is. When a breaking change arrives you bump the version and write a small converter for the old one. That is far cheaper than having to update every consumer on the same day. Put the `SchemaVersion` field in from the start, even if it sits at `1` for the first release. Adding a field is not breaking; **removing** a field or changing its meaning is. On a breaking change, bumping the version and writing a converter for the old one is cheaper than having to update every consumer on the same day. > Keep the contract writable to disk (JSON/XML). A readable intermediate format is the most powerful debugging tool you have: a customer's "this job doesn't work" message reduces to a single file. :::illustration-left scrum-board | Team workflow and module ownership ::: ## Decision records: don't bury the why The most expensive knowledge loss in engineering software is forgetting the **reasoning** behind a decision. A team that cannot answer "why is this profile calculation like this?" six months later will either leave the code untouched or fix it wrongly. No heavy process is needed. Short notes under `docs/decisions/` in the repository, one page per decision, are enough: 1. **Context** — which constraint forced this decision (line tolerance, CAD API limit, customer standard) 2. **Decision** — what was decided 3. **Consequence** — what it makes easier, what it makes harder 4. **Rejected alternatives** — and why they were rejected The fourth item is the most valuable; it stops the same alternative being proposed again a year later. ### Test discipline: what gets tested where - **Geometry core** — pure unit tests. With no dependencies, these are the cheapest and fastest tests; coverage should be highest here. - **Rule engine** — scenario tests. Freeze real production cases as input/expected-output pairs; when a standard changes you see immediately which cases moved. - **CAD integration** — a small number of smoke tests against a real CAD session. Expensive, hence few — but never zero. - **Output generator** — snapshot tests. The produced DXF need not be byte-identical, but layer names and dimensions must stay fixed. :::illustration-right code-review-desk | Code review and quality gates ::: ## Module ownership in AI-assisted development AI tools work markedly better in a modular architecture, for a simple reason: a module with a clear boundary fits in the model's context window. In return I set two rules: - **Boundaries stay human.** I decide what a module will and will not do, the shape of the contract, and the direction of dependency. If those decisions are wrong, fast-generated code multiplies the mistake quickly. - **No AI in a module without a contract test.** If there is no mechanism to verify the generated code, the speed you gain comes straight back as risk. In practice I get the best results in modules whose **inputs and outputs are pure**, such as the geometry core; the worst in layers that talk to the CAD API and carry state. --- ## Measure when moving to production In a pilot → limited users → full roll-out flow, record the same three numbers at every stage: **preparation time**, **error rate**, and **output consistency**. Numerical claims should be supported only by that record — "it got much faster" is not an engineering claim. :::callout In practice You can see this approach applied in the CAD/CAM platform I built for prefab and light steel: the geometry core, the rule engine, and the output generator evolve separately, and the licensing layer knows none of them. ::: ## Frequently Asked Questions **What is modular software architecture?** Splitting a system into independent parts connected only by explicit contracts. In engineering software the split follows **rate of change**, not technology: things that change together for the same reason live in the same module. **Where should a module boundary go?** At the reason for change. A geometry core rarely changes, a rule engine changes as production standards move, CAD integration changes as versions rise. Keeping code that changes for different reasons in one module is the most common architectural mistake. **How should a contract between modules be defined?** Not with a function signature but with an explicit data type. Give that type a schema-version field and keep it serialisable (JSON/XML); an intermediate format readable on disk is the strongest debugging tool you have. **Why are architecture decision records needed?** The most expensive knowledge loss in engineering software is forgetting why a decision was made. Context, decision, consequence and rejected alternatives on a single page is enough; the fourth item stops the same alternative from being proposed again a year later. **What should be tested in which module?** Pure unit tests in the geometry core, scenario tests frozen from real production cases in the rule engine, a small number of smoke tests against a real session in CAD integration, and snapshot tests in the output generator. **Why is AI-assisted development more effective in a modular architecture?** A module with a clear boundary fits in the model's context window. Two rules apply though: boundary decisions stay with a human, and generated code is not used in a module that has no contract tests. --- # SolidWorks Python Scripting: pywin32 Code and COM Traps source: https://mehmetseyrimez.com/en/blog/python-solidworks-otomasyonu type: article published: 2024-09-28 updated: 2026-08-29 category: CAD Automation tags: solidworks, python, api, otomasyon, com author: Mehmet Seyrimez reading_minutes: 13 > SolidWorks Python scripting with pywin32: connect to the API over COM, drive dimensions, rebuild once, export PDF or DXF — and dodge the COM traps. **SolidWorks Python scripting** is a practical way to automate parts, assemblies, and drawings through the same COM-based **SolidWorks API** that VBA and C# use. With `pywin32`, you connect to `SldWorks.Application`, open or attach to a document (`IModelDoc2`), change parameters, rebuild, save, and export PDF or DXF — without writing a full add-in first. This guide covers how **Python automation** connects to SolidWorks, the COM traps that waste the most time in production, minimal code patterns you can run today, and when a script should become a C# add-in. If you are scoping a first project, [how to start a CAD automation project](https://mehmetseyrimez.com/en/blog/otomasyon-projesine-nasil-baslanir) pairs well with the workflow here. :::illustration full code-sample | Python: the exploration language of SolidWorks automation ::: ## How Python connects to SolidWorks SolidWorks exposes its automation surface through COM. On the Python side, `pywin32` (`win32com.client`) creates the bridge to `SldWorks.Application` — the root of the API object tree documented in the [official SolidWorks API Help](https://help.solidworks.com/2025/english/api/sldworksapiprogguide/Welcome.htm). Three connection patterns matter in daily scripting: - **`Dispatch`** — starts SolidWorks if it is not running, or attaches to a new invisible session. - **`GetActiveObject`** — attaches to an already open SolidWorks instance (useful when engineers work interactively). - **`ActiveDoc`** — returns the active `IModelDoc2`; empty if no file is open. After you have the application object, document type drives everything: `PartDoc`, `AssemblyDoc`, and `DrawingDoc` behave differently. Applying part logic to an assembly is still the most common early mistake. ### Where you are probably stuck in setup On the Python side, the biggest time sink is not the code — it is **architecture mismatch.** A 32-bit Python cannot talk to 64-bit SolidWorks; the COM error rarely says that plainly. Match bitness: 64-bit SolidWorks requires 64-bit Python. The second common issue is the COM type library not being generated on first run. `pywin32` constants such as `swDocPART` are cached on first access; until then, use numeric document-type values or generate the type library once. ## Practical Python examples The snippets below are minimal patterns for **SolidWorks Python scripting** — connect, read the active document, change a driving dimension through a global variable, rebuild once, save, and export. Adjust names to match your model's equation table and file paths. ### Connect to SolidWorks ```python import win32com.client # Start or attach to SolidWorks sw = win32com.client.Dispatch("SldWorks.Application") sw.Visible = True ``` To attach to an already running session: ```python import win32com.client sw = win32com.client.GetActiveObject("SldWorks.Application") ``` ### Get the active document ```python model = sw.ActiveDoc if model is None: raise RuntimeError("No document open") doc_type = model.GetType() # 1=part, 2=assembly, 3=drawing ``` ### Change a dimension through a global variable Driving through **global variables** (equation-table names) is more stable than hard-coding feature dimension IDs. The API stores lengths in **metres** — 2400 mm is `2.4`: ```python eqn_mgr = model.GetEquationMgr() # Index -1 appends; equation text uses metres in API units eqn_mgr.Add2(-1, '"Width"=2.4', True) ``` For a named model dimension tied to a sketch: ```python param = model.Parameter("D1@Sketch1") # name depends on your model param.SystemValue = 2.4 # metres ``` ### Rebuild once after all parameter writes ```python model.ForceRebuild3(False) ``` Write every parameter first, then rebuild **once**. Rebuilding after each change is the usual reason batch scripts slow down by an order of magnitude. ### Save the document Many API methods return status through `ByRef` out-parameters in COM. In Python, wrap them with `win32com.client.VARIANT`: ```python import pythoncom import win32com.client errors = win32com.client.VARIANT(pythoncom.VT_BYREF | pythoncom.VT_I32, 0) warnings = win32com.client.VARIANT(pythoncom.VT_BYREF | pythoncom.VT_I32, 0) ok = model.Save3(1, errors, warnings) if not ok: raise RuntimeError(f"Save failed — errors={errors.value}, warnings={warnings.value}") ``` Always inspect result codes; unchecked saves are how silent data loss enters production automation. ### Export PDF or DXF Export paths and options vary by document type; a typical drawing export uses `Extension.SaveAs`: ```python pdf_path = r"C:\Output\part-rev-A.pdf" result = model.Extension.SaveAs( pdf_path, 0, # save version — use constants from the type library when available 0, None, errors, warnings, ) ``` Check each format separately — a successful PDF does not guarantee DXF or DWG export succeeded. For drawing-heavy output packages (naming rules, folder structure, multi-format batches), the same patterns appear in [2D drawing to 3D model automation](https://mehmetseyrimez.com/en/blog/2b-teknik-resimden-3b-modele-otomasyon) workflows where geometry and release packages must stay aligned. ## The right way to drive parameters Most automation boils down to one job: **change the dimensions, rebuild the model, take the output.** The trick is in the first step. Pulling dimensions one by one through features works, but it is fragile: the moment a feature is renamed the script goes quiet without any error. A far more durable route is to drive the design through **global variables**. A global variable is a named number you define in SolidWorks' equation table — "Width", "Height" and so on. The model's dimensions bind to those variables. Your script now touches a name, not geometry. Feature names can change on the model side and the automation keeps working. :::callout This is an architectural decision Driving through global variables is not just a convenience; it defines the automation's **contract.** The agreement between script and model becomes "I know these names." Whatever anyone changes on the model side, the automation stays standing as long as those names do. ::: Then there is the units question, and this is the trap Python users fall into most often: **the SolidWorks API works in metres.** Even if your document displays millimetres, the number you write in code is read as metres. To set 2400 mm you write 2.4. Forget it and the model grows a thousandfold — and in batch runs that is not always visible to the eye. ### Call rebuild in the right place After changing parameters the model has to be rebuilt. But rebuilding is expensive. The common mistake is rebuilding after every parameter. Twenty parameters means twenty full rebuilds — and the runtime goes from seconds to minutes. The correct approach is to write all parameters and then rebuild **once**. In batch operations, that single decision is the difference between a runtime that multiplies and one that stays reasonable. :::illustration right local-server | The COM bridge: same API, different door ::: ## Session management: keeping the script from hanging The number one reason Python scripts die in production is SolidWorks' **modal dialogs.** A warning window opens, the script waits for an answer, and the operation hangs forever. The script you started to run overnight is waiting for you at file three in the morning. The fix is to disable user interaction at the start of the run: silent mode for opening and saving, plus general warning suppression. Remember to switch it back at the end — otherwise you will see no warnings at all until SolidWorks is restarted. But turn that silence into a record: every warning you suppressed was telling you something. Have the script print a list at the end — "these files produced these warnings." ### COM's `ByRef` trap This is the technical detail that costs the most time on the Python side. Many SolidWorks API methods return their result not as a return value but by **writing into variables you hand them.** In C# and VBA that is natural; in Python it needs a special wrapper. The practical consequence: to read the error code of a save or an export, you have to set those wrappers up correctly. Skip it and the operation still runs — but you never see the error code, which is an open door to silent failure. The rule is always the same: **do not move to the next step without checking the result code.** A silent save, unchecked, means silent data loss. ## Producing output packages: the most visible benefit Producing PDF, DWG, DXF and bend drawings with one command is the part users respond to most. The reason is simple: the result is immediately visible and nobody asks whether it really saved anything. Three things to watch: **The naming rule must be part of the automation.** Project code, part number, revision — bind them all to a rule. Otherwise files get produced but nobody knows which revision sits in which folder, and the time you saved goes back into searching. **Let the script create the folder structure.** If the target folder does not exist, create it. "Folder not found" is the stupidest possible reason for an overnight run to stop. **Check each format's result separately.** A PDF being produced does not mean the DXF was. All three return their own result code. :::illustration left factory | The output package: automation whose result is visible immediately ::: ## Where Python ends and C# begins This is the most frequent question, and my answer is clear: **Python is the exploration language here, C# the production one.** Where Python genuinely shines is testing an idea in half an hour and seeing whether it works. No restart, no compile, no project setup. If you have a hypothesis — "can I drive this product family from parameters?" — Python answers it fastest. But for an add-in that goes to production I prefer C# / .NET for three reasons: **Deployment.** Installing a Python interpreter and its dependencies on a user's machine is far more fragile than installing a single signed add-in. And the cost of that fragility is paid not by you but by the user asking for support. **Performance.** When the COM call count rises — in an assembly with hundreds of components — managed code's direct API binding is markedly faster. Every COM call has a cost, and on the Python side that cost is higher. **Interface.** A panel embedded in the SolidWorks Task Pane feels incomparably more natural to a user than an external script window. If the automation feels like part of SolidWorks, people adopt it; if it requires opening a separate window, most of the time they simply do not use it. > Practical rule: validate the idea in Python, write the flow that will last in C#. The bridge between them is that both sides read the same rule set — so put the rules in data, not in code. How to make that transition and how to structure the add-in is covered in [writing a SolidWorks add-in with AI-assisted development](https://mehmetseyrimez.com/en/blog/yapay-zeka-ile-solidworks-eklentisi-yazmak) and in production measurement practices in [measuring automation ROI](https://mehmetseyrimez.com/en/blog/otomasyon-kazancini-olcmek). ## Where to start: your first script A concrete suggestion: let your first script **change nothing and only read.** A script that prints the open document's name, type and the feature names in the design tree takes ten minutes to write and teaches you two things at once: that the connection works, and how you navigate the object hierarchy. And it carries no risk. Your second script should read a global variable. The third should change one — but **on a copy of the file.** Testing on a live project is the most expensive way to learn. Follow that order and within a week you will have a working automation. More importantly, you will know why it works. ## Frequently Asked Questions **Can SolidWorks be automated with Python?** Yes. SolidWorks exposes its automation interface over COM, and Python's `pywin32` library bridges to `SldWorks.Application`. You call the same API surface as VBA or C# — only the language binding differs. **Does SolidWorks have a Python API?** There is no separate "Python API." Python uses the standard SolidWorks COM API through `pywin32`. Official documentation is written for the object model (`SldWorks`, `IModelDoc2`, `IPartDoc`, etc.), not for a Python-specific SDK. **How do I connect Python to SolidWorks?** Install 64-bit Python and `pywin32`, then use `win32com.client.Dispatch("SldWorks.Application")` or `GetActiveObject` to attach to a running session. Match Python bitness to SolidWorks. **Is pywin32 required?** For COM automation on Windows, yes — `pywin32` is the standard bridge. Alternatives still talk to the same COM ProgID; they do not remove the COM model underneath. **Can Python edit SolidWorks dimensions?** Yes — through dimension objects, equations, or global variables. Global variables are usually the most stable contract between script and model. **Can Python export SolidWorks drawings to PDF or DXF?** Yes, through `Extension.SaveAs` and format-specific options. Verify each export's return code; PDF success does not imply DXF success. **Can Python automate assemblies?** Yes, via `AssemblyDoc` and the same `IModelDoc2` entry point, but assembly logic differs from parts. Identify document type before applying operations. **Can Python replace a SolidWorks macro?** For exploration and one-off batch tasks, often yes. For team-wide, rule-heavy flows with UI inside SolidWorks, macros or add-ins are usually the durable home. **Why do I get errors connecting to SolidWorks from Python?** The most common cause is an architecture mismatch: you cannot connect to 64-bit SolidWorks from 32-bit Python, and the error does not say so. The second common cause is the COM type library not being generated, which makes the named constants unrecognised. **What units does the SolidWorks API use for dimensions?** System units — metres. Even if the document displays millimetres, a number written in code is read as metres; for 2400 mm you write 2.4. This is the most insidious bug in automation because the result is not always visible to the eye. **Should I update parameters through features or global variables?** Global variables. Feature-name-based updates go silently dead the moment something is renamed on the model side. A global variable sets a stable contract between script and model. **My script hangs on a dialog — what should I do?** The cause is a modal warning window opened by SolidWorks. Enable silent mode for opening and saving at the start of the run and restore it at the end; also have the script print the suppressed warnings as a report. **Python or C#?** Python for exploration and validating ideas — nothing else is this fast. C# / .NET for flows that go to production, that a team will use, and that must live inside SolidWorks; deployment, performance and interface all point to C#. **My batch run is slow — how do I speed it up?** The most common cause is rebuilding the model after every parameter change; rebuild once, after all parameters are written. The second is leaving screen updates on — turning them off in batch runs gives a clear speedup. ## Summary **SolidWorks Python scripting** is the fastest way to test an automation idea. Once the COM bridge is up, the full API is available through `SldWorks.Application` and `IModelDoc2`. Get three things right from the start: **think in metres**, **drive parameters through global variables**, and **check every result.** Without those three, a script that looks like it is working will quietly produce wrong output. And remember: if the flow you built quickly in Python is going to last, at some point it needs to move to the C# side. That is not a failure — it is a planned step. ---