پلاگین اختصاصی تأسیسات در رویت، از کانکتورها تا قواعد دفتر

بیشتر افزونه‌های رویت المان‌ها را یکی‌یکی پردازش می‌کنند: یک دیوار را می‌خوانند، یک پارامتر را می‌نویسند و به المان بعدی می‌روند. المان‌های تأسیسات به هم متصل‌اند. هر لوله، داکت، سینی کابل، فیتینگ و تجهیز کانکتورهایی دارد و کار اصلی افزونه، حرکت از یک کانکتور به کانکتور بعدی است.

در Revit API، لوله یا داکت یک MEPCurve است و ConnectorManager آن، کانکتورهای المان را برمی‌گرداند. هر Connector داده‌هایی را در اختیار افزونه قرار می‌دهد: Flow، Direction، Domain، شکل و ابعاد مقطع (Radius، یا Width و Height)، IsConnected و AllRefs، یعنی کانکتورهایی که به آن متصل‌اند. با دنبال کردن AllRefs از یک پمپ، افزونه به تمام لوله‌ها و فیتینگ‌هایی می‌رسد که آن پمپ تغذیه می‌کند.

این پیمایش همان بخشی است که ابزارهای عمومی به‌ندرت متناسب با یک دفتر مشخص انجام می‌دهند. سیستم از کجا شروع می‌شود؟ انتهای یک انشعاب کجاست؟ کدام فیتینگ‌ها همراه با لوله سایزبندی می‌شوند؟ پاسخ این پرسش‌ها استاندارد دفتر است و افزونه بر اساس همین پاسخ‌ها نوشته می‌شود.

اولین افزونه معمولاً یکی از این کارها را انجام می‌دهد:

• سایزبندی بر اساس جدول دفتر. ابزار داخلی Duct/Pipe Sizing در رویت بر اساس سرعت یا افت اصطکاکی کار می‌کند. بسیاری از دفاتر از جدول خود یا یک ضابطه‌ی محلی استفاده می‌کنند و افزونه دبی را از کانکتورها می‌خواند، سایز را انتخاب می‌کند و در مدل می‌نویسد.
• نام‌گذاری و شماره‌گذاری سیستم‌ها، به‌گونه‌ای که هر سیستم در سراسر مدل و اسکجوال‌ها از یک الگو پیروی کند.
• کنترل کانکتورهای باز پیش از هر ارسال: هر کانکتوری که مقدار IsConnected آن false است و المان آن انتهای عمدی سیستم نیست.
• تگ‌گذاری گسترده‌ی لوله‌ها، داکت‌ها، تجهیزات و دستگاه‌ها بر اساس قاعده، با جانمایی تگ‌ها بدون هم‌پوشانی.
• جانمایی آویزها و ساپورت‌ها در طول مسیرها، با فاصله‌ی تعیین‌شده‌ی دفتر.
• انتقال داده به برگه‌های محاسبات و بازگرداندن نتایج به مدل، از طریق Excel یا یک پایگاه داده‌ی مشترک.

کاری را انتخاب کنید که تیم بیشتر از همه تکرار می‌کند و کمتر از همه درباره‌ی آن اختلاف نظر دارد. کاری که قاعده‌ی توافق‌شده دارد، خودکار می‌شود. کاری که قاعده ندارد، ابتدا به یک جلسه نیاز دارد.

در رویت ۲۰۲۶ تنظیمات هادی‌های الکتریکال تغییر کرد. این تنظیمات به پنجره‌ی مستقلی در Manage و MEP Settings منتقل شده‌اند و طبق راهنمای Symetri برای این نسخه، سایز هادی‌ها دیگر به جریان نامی یا داده‌های Ampacity وابسته نیست. نوع و سایز کابل هر مدار، مستقل از بار متصل یا جریان نامی وسیله‌ی حفاظتی تعیین می‌شود.

این تغییر برای دفاتری که با استاندارد کابل محلی کار می‌کنند، انعطاف ایجاد می‌کند. هم‌زمان، منطق سایزبندی اکنون بر عهده‌ی خود دفتر است. دفتری که به رفتار خودکار نسخه‌های قبلی متکی بود، یا مدارها را به‌صورت دستی سایزبندی می‌کند یا قاعده را مکتوب می‌کند: جدول استاندارد محلی، روش نصب و ضرایب اصلاحی مورد استفاده. قاعده‌ی مکتوب به افزونه‌ای تبدیل می‌شود که هر مدار را می‌خواند و کابل آن را تعیین می‌کند.

تقریباً هیچ‌کدام از خطاها در فرمول سایزبندی رخ نمی‌دهند:

• واحدهای داخلی. Revit API طول را همیشه به فوت ذخیره می‌کند، صرف‌نظر از واحدهای پروژه. قطری که ۰٫۱۶۴ خوانده می‌شود، ۵۰ میلی‌متر است. تبدیل همیشه با UnitUtils.ConvertFromInternalUnits انجام می‌شود.
• واحدهای مشتق. دبی، سرعت و فشار در واحدهایی ذخیره می‌شوند که بخشی از آن‌ها بر پایه‌ی فوت است. در نتیجه، مقدار دبی تا پیش از تبدیل، بر حسب لیتر بر ثانیه نیست.
• جهت کانکتور. In، Out یا Bidirectional. پیمایشی که جهت را نادیده بگیرد، به سمت بالادست سیستم حرکت می‌کند و لوله‌ی اصلی را بر اساس یک انشعاب سایزبندی می‌کند.
• فیتینگ‌هایی با بیش از دو کانکتور. سه‌راهی یا چهارراهی، پیمایش را به چند مسیر تقسیم می‌کند. بدون ثبت کانکتورهای پیمایش‌شده، پیمایش یک سیستم حلقوی هرگز به پایان نمی‌رسد.
• سایز نامی و سایز واقعی. DN 50 و قطر خارجی لوله دو عدد متفاوت‌اند و جدول دفتر بر اساس یکی از آن‌ها نوشته شده است.
• المان‌های اشتراکی که در اختیار کاربر دیگری هستند. افزونه نمی‌تواند آن‌ها را تغییر دهد و باید آن‌ها را گزارش کند.

هیچ‌کدام از این موارد دشوار نیست. همه‌ی آن‌ها در اولین پروژه‌ی واقعی ظاهر می‌شوند و هیچ‌کدام در مدل نمونه دیده نمی‌شوند.

برای یک پروژه، یک اسکریپت اختصاصی Dynamo اغلب کافی است: دبی‌ها را از یک اسکجوال می‌خواند، با جدول تطبیق می‌دهد و سایزها را در مدل می‌نویسد. این روش ارزان‌ترین راه برای ارزیابی این است که آیا قاعده‌ی دفتر واقعاً مکتوب شده است یا نه.

پلاگین اختصاصی زمانی ارزش هزینه‌ی خود را دارد که پیمایش‌ها بزرگ شوند، یک قاعده در همه‌ی پروژه‌ها اجرا شود، چند کاربر در یک مدل اشتراکی از آن استفاده کنند و افزونه در هر نسخه‌ی جدید رویت به کار خود ادامه دهد. برنامه‌نویسی Revit API نشان می‌دهد چنین ابزاری چگونه ساخته می‌شود.

اگر کار تأسیسات دفتر شما بیشتر تگ‌گذاری و اسکجوال‌سازی روی محتوای استاندارد رویت است، احتمالاً یک افزونه‌ی آماده از Autodesk App Store این کار را انجام می‌دهد، و به ما یا شرکتی مانند ما نیازی ندارید.

شرح کار مفید برای یک پلاگین تأسیسات در دو صفحه جا می‌شود:

• خود قاعده: جدول سایزبندی، الگوی نام‌گذاری یا استاندارد تگ‌گذاری، همراه با منبع آن.
• دسته‌هایی که افزونه تغییر می‌دهد: Pipes، Ducts، Cable Trays، Conduits، فیتینگ‌های آن‌ها و تجهیزات.
• آنچه افزونه می‌نویسد، در کدام پارامتر، و آنچه هرگز تغییر نمی‌دهد.
• گزارش المان‌به‌المان مواردی که قاعده روی آن‌ها قابل‌اجرا نبوده است.
• یک مدل پروژه‌ی واقعی برای تست، شامل دشوارترین سیستم آن.

با این اطلاعات، برآورد هزینه بر اساس دامنه‌ی کار انجام می‌شود. هزینه‌ی توسعه پلاگین رویت نشان می‌دهد قیمت چگونه از این دامنه به دست می‌آید و این کار در قالب خدمات توسعه پلاگین رویت انجام می‌شود.