آشنایی با پروتکل‌های PROFINET

PROFINET به عنوان یکی از استانداردهای کلیدی در ارتباطات صنعتی مبتنی بر اترنت، زیرساخت قدرتمندی برای دیجیتالی شدن تجهیزات صنعتی و اتصال بین فناوری اطلاعات (IT) و فناوری عملیاتی (OT) فراهم می‌کند. این شبکه از پروتکل‌های ارتباطی متنوعی پشتیبانی می‌کند که برای کاربردهای مختلف طراحی شده‌اند. شناخت این پروتکل‌ها برای طراحی و اجرای سیستم‌های اتوماسیون صنعتی، امری ضروری است.

انواع پروتکل‌های PROFINET در شبکه‌های صنعتی

PROFINET سه سطح مختلف از ارتباط را برای انتقال داده در شبکه صنعتی فراهم می‌کند:

• پروتکل NR (Non-Real Time)

• پروتکل RT (Real Time)

• پروتکل IRT (Isochronous Real Time)

بررسی پروتکل NR در ساختار ارتباطی PROFINET

پروتکل NR یا Non-Real Time، ساده‌ترین نوع ارتباط در PROFINET است که برای کاربردهایی استفاده می‌شود که حساسیت زمانی در آن‌ها اهمیت ندارد. این نوع ارتباط به صورت غیربرنامه‌ریزی‌شده انجام می‌شود و بیشتر برای دانلود برنامه، ارتباط PG/OP و تبادل داده‌های غیر بحرانی مناسب است.

ویژگی‌ها و کاربردهای پروتکل NR در شبکه PROFINET

پروتکل NR در انتقال فایل‌ها، ارتباط با HMI، و دریافت پارامترهای سیستمی کاربرد دارد. تاخیرهای زمانی در این نوع ارتباط قابل تحمل بوده و معمولاً بالای 100 میلی‌ثانیه هستند.

بررسی پروتکل RT از مجموعه پروتکل‌های PROFINET

پروتکل RT یک گام بالاتر از NR محسوب می‌شود و امکان تبادل داده‌ها با زمان پاسخ سریع‌تر (بین 1 تا 10 میلی‌ثانیه) را فراهم می‌کند. این پروتکل برای بسیاری از کاربردهای کنترلی در سطح کارخانه مناسب است.

کاربردهای صنعتی RT در بستر شبکه PROFINET

پروتکل RT در کنترل درایوهای سرعت متغیر (VFD)، تبادل داده‌های فرآیندی، و تجهیزات IO به‌طور گسترده استفاده می‌شود. زیمنس معمولاً از RT به عنوان استاندارد ارتباطی پیش‌فرض یاد می‌کند.

تأثیر سنکرون نبودن RT بر عملکرد پروتکل‌های PROFINET

از آنجا که RT سنکرون نیست، زمان تأخیر می‌تواند متغیر باشد و این موضوع باعث می‌شود برای کاربردهایی که به زمان‌بندی دقیق نیاز دارند، مانند همگام‌سازی محورهای حرکتی، مناسب نباشد.

معرفی پروتکل IRT در ارتباطات دقیق PROFINET

پروتکل IRT برای کاربردهای بسیار حساس به زمان طراحی شده است. در این حالت، تأخیر در انتقال داده کاملاً قابل پیش‌بینی و پایدار است. این ویژگی، IRT را برای پروژه‌های پیشرفته موشن کنترل ایده‌آل می‌سازد.

نقش IRT در هماهنگی سرووها در شبکه PROFINET

IRT امکان سنکرون‌سازی بسیار دقیق بین چند محور را فراهم می‌کند. مثلاً اگر دو سروو موتور نیاز به هماهنگی در حد میکروثانیه داشته باشند، IRT دقیق‌ترین گزینه است.

مزایای زمان‌بندی دقیق در پروتکل‌های PROFINET

در IRT، تأخیر انتقال داده‌ها در محدوده 250 میکروثانیه تا 1 میلی‌ثانیه باقی می‌ماند. این ثبات باعث عملکرد پیش‌بینی‌پذیر در حلقه‌های کنترلی می‌شود.

سخت‌افزار مناسب برای اجرای پروتکل‌های PROFINET پیشرفته

برای استفاده از IRT، به سخت‌افزاری نیاز دارید که از این قابلیت پشتیبانی کند. PLCهای S7-1500، سری G2 از S7-1200، و سیستم‌های ET200SP از IRT پشتیبانی کامل دارند.

قابلیت‌های تکمیلی در ساختار شبکه PROFINET

مدیریت مصرف انرژی با قابلیت PROFIenergy در PROFINET

با استفاده از PROFIenergy می‌توان در زمان‌های غیرضروری برخی تجهیزات را به‌صورت خودکار خاموش کرد.

شروع سریع تجهیزات در شبکه PROFINET با Prioritized Startup

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

اهمیت درک کامل پروتکل‌های PROFINET برای مهندسان اتوماسیون

شناخت تفاوت‌های NR، RT و IRT و توانایی پیاده‌سازی هرکدام بر اساس نیاز پروژه، یک مهارت حرفه‌ای برای مهندسین اتوماسیون به‌شمار می‌رود.

جمع‌بندی نهایی درباره انتخاب پروتکل‌های PROFINET

انتخاب درست بین پروتکل‌های PROFINET تأثیر مستقیمی در سرعت، دقت، و پایداری سیستم کنترلی شما دارد. تسلط بر مفاهیم تئوری و عملی آن‌ها، به‌ویژه در پیاده‌سازی روی PLCهای زیمنس، یک مزیت رقابتی مهم برای هر متخصص اتوماسیون محسوب می‌شود

بررسی تفاوت FC و FB در دنیای پیچیده‌ی اتوماسیون صنعتی مدرن، برنامه‌نویسی PLC با کارایی و انعطاف‌پذیری بالا، اهمیت زیادی دارد. TIA Portal زیمنس به عنوان یک پلتفرم مهندسی یکپارچه، رویکرد برنامه‌نویسی ماژولار را تسهیل می‌کند. این رویکرد، برنامه‌ی PLC را به بخش‌های کوچک‌تر و قابل مدیریت‌تر تقسیم می‌کند که به بهبود نگهداری، عیب‌یابی و توسعه‌ی سریع‌تر پروژه کمک می‌کند.

برنامه‌نویسی ماژولار در TIA Portal بر پایه‌ی بلوک‌های مختلفی از جمله OB (Organization Block)، FC (Function)، FB (Function Block) و DB (Data Block) استوار است. این بلوک‌ها، ستون فقرات یک برنامه‌ی ساختاریافته در زیمنس هستند. انتخاب صحیح بین FC و FB، یک تصمیم استراتژیک برای پایداری و کارایی بلندمدت پروژه‌های اتوماسیون به شمار می‌رود.

---

آشنایی با بلوک‌های برنامه‌نویسی در TIA Portalو تفاوت FC و FB

پیش از ورود به جزئیات FC و FB، بهتر است نگاهی اجمالی به بلوک‌های اصلی برنامه‌نویسی در TIA Portal داشته باشیم:

• OB (Organization Block): این بلوک‌ها، نقاط ورود اصلی برنامه به CPU هستند و جریان اجرای برنامه را کنترل می‌کنند. OB1 به طور پیش‌فرض، بلوک اجرای چرخه‌ای است.
• FC (Function): توابع، بلوک‌های کدی هستند که وظایف مشخصی را انجام می‌دهند اما حافظه را بین اسکن‌ها حفظ نمی‌کنند (stateless). نتایج آن‌ها صرفاً به ورودی‌های فعلی بستگی دارد.
• FB (Function Block): بلوک‌های تابعی نیز مانند FCها هستند، اما می‌توانند داده‌ها را به صورت داخلی از طریق نمونه‌ها حفظ کنند (stateful). آن‌ها برای عملیات‌های با وضعیت طراحی شده‌اند و می‌توانند مقادیر را بین چرخه‌های اسکن PLC نگهداری کنند.
• DB (Data Block): بلوک‌های داده، برای ذخیره‌سازی داده‌ها استفاده می‌شوند. Global DBها برای دسترسی عمومی و Instance DBها (IDB) برای داده‌های خاص یک FB کاربرد دارند.

---

توابع (Functions – FC) در TIA Portal: بلوک‌های بدون حافظه

تعریف و ویژگی‌های اصلی FC

توابع (FC) در TIA Portal زیمنس، بلوک‌های کدی برای انجام وظایف خاص هستند که ویژگی بارز آن‌ها عدم وجود حافظه داخلی ماندگار است. این یعنی FCها هیچ داده‌ای را از یک چرخه‌ی اسکن PLC به چرخه‌ی بعدی حفظ نمی‌کنند. آن‌ها مانند زیرروال‌ها عمل کرده و هر بار که فراخوانی می‌شوند، با مقادیر اولیه برای متغیرهای موقت خود شروع به کار می‌کنند. پس از اتمام اجرا، مقادیر متغیرهای موقت از بین می‌روند و برای فراخوانی بعدی مجدداً مقداردهی اولیه می‌شوند. این ویژگی، رفتار FC را بسیار قابل پیش‌بینی می‌کند و تضمین می‌کند که خروجی آن فقط به ورودی‌های فعلی‌اش بستگی دارد.

FCها می‌توانند چندین ورودی و خروجی داشته باشند. همچنین می‌توانند یک مقدار بازگشتی (Return Value) نیز داشته باشند. آن‌ها الگوریتم‌های مشخصی را اجرا کرده و مقادیر را بر اساس ورودی‌ها و منطق داخلی بازمی‌گردانند.

انواع پارامترها در FC یکی از  مهمترین تفاوت FC و FB

• IN (Input – ورودی): برای انتقال داده‌ها از بلوک فراخواننده به FC. این پارامترها فقط خواندنی هستند و تغییر در داخل FC بر متغیر خارجی تأثیر نمی‌گذارد.
• OUT (Output – خروجی): برای انتقال نتایج از FC به بلوک فراخواننده. FC باید حداقل یک مقدار اولیه به خروجی‌ها اختصاص دهد.
• IN_OUT (Input/Output – ورودی/خروجی): امکان انتقال داده به FC، تغییر آن در داخل FC، و سپس بازگرداندن مقدار تغییر یافته به متغیر خارجی را فراهم می‌کنند.
• TEMP (Temporary – موقت): متغیرهای داخلی که فقط برای چرخه‌ی اجرای فعلی FC استفاده می‌شوند. آن‌ها ماندگار نیستند و پس از اتمام بلوک از بین می‌روند.
• Constant (ثابت): متغیرهای موقتی با مقادیر ثابت و از پیش‌تعریف‌شده.

نکته مهم: هنگام فراخوانی FCها، باید تمام پارامترهای رسمی آن‌ها را با پارامترهای واقعی پر کنید؛ نمی‌توانید هیچ پارامتری را نادیده بگیرید. این یک تفاوت کلیدی با FBها است.

کاربردهای رایج FC

با توجه به ویژگی بدون حافظه بودن، FCها برای وظایفی مناسب هستند که نیازی به حفظ وضعیت بین چرخه‌های اسکن ندارند. این بلوک‌ها برای منطق‌های ساده و تکراری ایده‌آل هستند. برخی از کاربردهای رایج عبارتند از:

• عملیات‌های ریاضی و منطقی ساده (مانند جمع، تفریق، ضرب، تقسیم).
• مقیاس‌بندی مقادیر آنالوگ (تبدیل مقادیر خام ورودی آنالوگ به واحدهای مهندسی).
• محاسبات تبدیل واحد.
• تشخیص لبه ساده.
• کنترل‌های ساده و بدون حافظه.
• مدیریت آلارم‌های ساده.

استفاده از FCها برای وظایف بدون وضعیت، کد را ساده‌تر و خواناتر می‌کند و عیب‌یابی را تسریع می‌بخشد.

مثال عملی: مقیاس‌بندی ورودی آنالوگ با استفاده از FC

یک مثال رایج، مقیاس‌بندی یک ورودی آنالوگ است. فرض کنید می‌خواهید مقدار خام 0-27648 از یک سنسور دما (4-20mA) را به -30.0 تا 70.0 درجه سانتی‌گراد مقیاس‌بندی کنید.

مراحل ایجاد FC:

1. ایجاد پروژه و افزودن PLC: یک پروژه‌ی جدید ایجاد کرده و CPU و ماژول آنالوگ مورد نظر را اضافه کنید.
2. افزودن Function (FC) جدید: در درخت پروژه، به “Program blocks” رفته و یک “Function (FC)” جدید با نام مناسب (مثلاً “Scale_Temperature”) و زبان دلخواه (LAD یا SCL) اضافه کنید.
3. تعریف پارامترهای FC: در بخش “Interface”، پارامترهای ورودی (IN) مانند Analog_Input_Raw، Min_Raw_Value، Max_Raw_Value، Min_Eng_Unit، Max_Eng_Unit و یک پارامتر خروجی (OUT) به نام Scaled_Output را تعریف کنید. همچنین می‌توانید یک متغیر موقت (TEMP) برای محاسبات میانی مانند Temp_Normalized_Value در نظر بگیرید.
4. پیاده‌سازی منطق مقیاس‌بندی: منطق مقیاس‌بندی را در FC پیاده‌سازی کنید. برای مثال در SCL:

   Scaled_Output := (INT_TO_REAL(Analog_Input_Raw) - INT_TO_REAL(Min_Raw_Value)) /
                    (INT_TO_REAL(Max_Raw_Value) - INT_TO_REAL(Min_Raw_Value)) *
                    (Max_Eng_Unit - Min_Eng_Unit) + Min_Eng_Unit;
   

5. فراخوانی FC در OB1: FC را به OB1 کشیده و پارامترها را به تگ‌های واقعی متصل کنید.
6. کامپایل و دانلود: پروژه را کامپایل و روی PLC دانلود کنید.

این مثال نشان می‌دهد که FCها چگونه کد را برای وظایف Stateless ساده می‌کنند. بلوک “Scale_Temperature” مستقل و قابل استفاده مجدد است، بدون نگرانی در مورد تداخل حافظه یا نیاز به Instance DB.

محدودیت حافظه FC و تایمرها/کانترهادر تفاوت FC و FB

یک اشتباه رایج، استفاده‌ی مستقیم از تایمرها یا کانترها در FC بدون مدیریت صحیح حافظه است. چون FCها حافظه ماندگار ندارند و متغیرهای موقتشان پس از هر چرخه‌ی اسکن از بین می‌روند، تایمر/کانتر به درستی کار نمی‌کند. هر فراخوانی، تایمر/کانتر را ریست می‌کند. برای حل این مشکل، باید از بلوک‌های تابعی (FB) یا تخصیص حافظه سراسری (Global DB) برای تایمرها/کانترها استفاده کرد.

---

بلوک‌های تابعی (Function Blocks – FB) در TIA Portal: بلوک‌های با حافظه

تعریف و ویژگی‌های اصلی FB

بلوک‌های تابعی (FB) در TIA Portal زیمنس، برخلاف FCها، قابلیت حفظ حافظه داخلی را دارند. این ویژگی کلیدی، FBها را برای پیاده‌سازی منطق‌هایی که نیاز به حفظ وضعیت (Stateful) یا داده‌ها بین چرخه‌های اسکن PLC دارند، ایده‌آل می‌سازد. هر بار که یک FB فراخوانی می‌شود، نیاز به ایجاد یک بلوک داده‌ی نمونه (Instance Data Block – IDB) همراه با آن فراخوانی خاص دارد. این IDB شامل تمام پارامترهای استاتیک (Static) FB است و این پارامترها در هر زمان توسط هر بلوک دیگری قابل دسترسی هستند.

FBها معمولاً برای کنترل عملیات وظایف یا دستگاه‌هایی استفاده می‌شوند که عملیاتشان در یک چرخه‌ی اسکن کامل نمی‌شود، مانند کنترل موتورها، شیرها یا ماشین‌های گام‌به‌گام که نیاز به حفظ وضعیت شروع/توقف یا موقعیت دارند. با طراحی FB برای وظایف کنترل عمومی، می‌توان آن را برای چندین دستگاه با انتخاب IDBهای مختلف مجدداً استفاده کرد. این قابلیت استفاده مجدد همراه با حفظ وضعیت، FBها را به ابزاری قدرتمند برای برنامه‌نویسی ماژولار و شیءگرا تبدیل می‌کند.

یکی دیگر از موارد تفاوت FC و FB  است که در FB می‌توان هنگام فراخوانی آن، برخی از پارامترها را نادیده گرفت. FB فضایی را در IDB برای پارامترها رزرو می‌کند و می‌تواند مقدار اولیه را از IDB بردارد. این به برنامه‌نویس اجازه می‌دهد تا تنها پارامترهای مورد نیاز را متصل کرده و بقیه را به مقادیر پیش‌فرض بسپارد.

انواع پارامترها در FB

FBها از تمام انواع پارامترهای FCها (IN, OUT, IN_OUT, TEMP, Constant) پشتیبانی می‌کنند. اما ویژگی متمایز، معرفی نوع پارامتر جدیدی به نام STAT (Static) است.

• STAT (Static – استاتیک): متغیرهای داخلی FB که مقادیرشان بین چرخه‌های اسکن PLC و حتی پس از اتمام اجرای FB حفظ می‌شوند. در IDB مربوط به آن نمونه‌ی خاص از FB ذخیره می‌شوند. آن‌ها “حافظه” FB را تشکیل می‌دهند و می‌توانند برای ردیابی وضعیت، شمارنده‌ها، تایمرها یا هر داده‌ای که باید حفظ شود، استفاده شوند. اگر نیاز به حفظ مقادیر بین چرخه‌ها دارید، باید از متغیرهای استاتیک استفاده کنید.

بلوک‌های داده‌ی نمونه (Instance Data Blocks – IDB): انواع و مدیریت

 دیگر تفاوت FC و FB در   حفظ حافظه در FBها هستند. هر فراخوانی از یک FB، یک IDB منحصربه‌فرد ایجاد می‌کند که ساختار آن از رابط FB تولید می‌شود. این IDB محل ذخیره‌ی پارامترهای IN, OUT, IN_OUT و STAT برای آن نمونه‌ی خاص است. TIA Portal سه روش اصلی برای ذخیره‌سازی نمونه‌های FB ارائه می‌دهد:

• Single Instance Data (داده‌ی نمونه‌ی تکی): رایج‌ترین روش. هر بار که FB را فراخوانی می‌کنید، TIA Portal یک IDB جدید و مستقل برای آن فراخوانی ایجاد می‌کند.
• Multi-Instance Data (داده‌ی چند نمونه‌ای): زمانی استفاده می‌شود که یک FB در داخل FB دیگری فراخوانی شود (FB والد، FB فرزند را فراخوانی می‌کند). داده‌های FB فرزند به جای IDB مستقل، در ناحیه‌ی استاتیک (STAT) IDB مربوط به FB والد ذخیره می‌شوند.
• Parameter Instance (نمونه‌ی پارامتری): امکان ارسال یک نمونه از FB به عنوان یک پارامتر IN_OUT به بلوک فراخواننده (مانند FC یا FB دیگر). انعطاف‌پذیری بالایی در زمان اجرا فراهم می‌کند.

دسترسی به داده‌های IDB: داده‌های IDB قابل دسترسی هستند. داخل FB، دسترسی به داده‌های نمونه مانند دسترسی به داده‌ی داخلی است. با این حال، به طور کلی توصیه نمی‌شود که مستقیماً به داده‌های IDB از خارج از FB دسترسی پیدا کنید، به ویژه برای نوشتن. این کار کپسوله‌سازی را نقض کرده و عیب‌یابی را دشوار می‌کند. بهتر است داده‌ها از طریق رابط FB (پارامترهای IN, OUT, IN_OUT) منتقل شوند.

مدیریت حافظه ماندگار (Retentive Memory) در FBها

دیگر تفاوت FC و FB  قابلیت‌های FBها است، توانایی حفظ مقادیر متغیرهای استاتیک (STAT) حتی پس از قطع و وصل برق PLC است. این ویژگی برای حفظ وضعیت ماشین، شمارنده‌ها، تایمرها و داده‌های حیاتی در صورت خطای برق یا راه‌اندازی مجدد ضروری است.

نحوه‌ی پیکربندی حافظه ماندگار:

• بلوک‌های با دسترسی بهینه (Optimized Block Access): در ویرایشگر رابط، ستون “Retain” وجود دارد که می‌توانید برای هر تگ (IN, OUT, IN_OUT, STAT) وضعیت “Retain” (ماندگار) یا “Non-retain” (غیرماندگار) را انتخاب کنید.
• بلوک‌های بدون دسترسی بهینه (Non-Optimized Block Access): در این حالت، IDB مربوطه ستون “Retain” قابل ویرایش دارد و انتخاب “Retain” برای هر تگ، باعث ماندگاری تمام تگ‌ها می‌شود.

ملاحظات حافظه ماندگار:

• حافظه ماندگار در PLCها محدود است. تنها تگ‌های حیاتی را ماندگار علامت‌گذاری کنید.
• مقادیر ماندگار پس از راه‌اندازی PLC بازیابی می‌شوند. با این حال، باید منطق مناسبی در OB100 (بلوک راه‌اندازی) برای مقداردهی اولیه صحیح در نظر گرفت.
• تغییر ساختار FB ممکن است نیاز به مقداردهی اولیه مجدد IDB داشته باشد.

کاربردهای رایج FB

FBها به دلیل قابلیت حفظ حافظه و امکان ایجاد نمونه‌های مستقل، برای پیاده‌سازی “اشیاء” یا ماژول‌های کنترلی پیچیده‌تر که نیاز به حفظ وضعیت دارند، ایده‌آل هستند.

• کنترل موتورها (Motor Control): یک FB می‌تواند تمام منطق مربوط به یک موتور (شروع/توقف، وضعیت، خطاها، تایمرها) را در خود جای دهد.
• کنترل شیرها (Valve Control).
• کنترل‌کننده‌های PID (نیاز به حفظ مقادیر داخلی مانند خطای قبلی).
• ماشین‌های حالت (State Machines): برای پیاده‌سازی منطق‌های ترتیبی که وضعیت فعلی را حفظ می‌کنند.
• مدیریت آلارم‌های پیچیده: نیاز به حفظ وضعیت آلارم (فعال، تأیید شده) و تاریخچه.
• ماژول‌های دستگاهی (Device Modules): برای هر دستگاه فیزیکی یک FB اختصاصی.

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

مثال عملی: کنترل موتور با حالت‌های عملکردی با استفاده از FB

در این مثال، یک FB برای کنترل موتور با حالت‌های شروع، توقف و خطا، با حفظ وضعیت، پیاده‌سازی می‌شود.

سناریو: کنترل موتوری با دکمه‌های Start/Stop، فیدبک وضعیت، و ورودی تشخیص اضافه بار (Overload Fault). موتور باید وضعیت روشن/خاموش را حفظ کند و در صورت توقف یا خطا متوقف شود.

مراحل ایجاد FB:

1. ایجاد پروژه و افزودن PLC.
2. افزودن Function Block (FB) جدید: در درخت پروژه، یک “Function Block (FB)” جدید با نام (مثلاً “Motor_Control_FB”) و زبان (SCL) اضافه کنید.
3. تعریف پارامترهای FB: در بخش “Interface”، پارامترهای ورودی (IN) مانند Start_Button، Stop_Button، Overload_Fault و پارامترهای خروجی (OUT) مانند Motor_Output و Motor_Running_Feedback را تعریف کنید. برای حفظ وضعیت، متغیرهای استاتیک (STAT) مانند Motor_State، Fault_Active و تایمرهای Start_Delay_Timer و Stop_Delay_Timer را اضافه کنید. (متغیرهای STAT باید Retain باشند تا وضعیت خود را حفظ کنند).
4. پیاده‌سازی منطق کنترل موتور (SCL): شامل منطق مدیریت خطا، منطق شروع/توقف با حفظ وضعیت (استفاده از Motor_State و تایمرهای Multi-Instance) و تخصیص خروجی.
5. فراخوانی FB در OB1 و ایجاد Instance DB: FB “Motor_Control_FB” را به OB1 بکشید. TIA Portal درخواست ایجاد Instance DB را می‌کند (مثلاً “Motor1_DB”). این IDB تمام متغیرهای STAT و پارامترهای IN, OUT, IN_OUT را برای این نمونه خاص ذخیره می‌کند. پارامترها را به تگ‌های واقعی متصل کنید. برای کنترل موتور دوم، FB را دوباره کشیده و IDB جدیدی ایجاد کنید (مثلاً “Motor2_DB”).
6. کامپایل و دانلود.

این مثال نشان می‌دهد که FBها چگونه اجازه می‌دهند دستگاه‌های فیزیکی به عنوان “اشیاء” مستقل با رفتار و وضعیت داخلی خود مدل‌سازی شوند. هر فراخوانی یک “نمونه” مستقل ایجاد می‌کند. این رویکرد به شدت به کاهش “کد اسپاگتی” کمک کرده و برنامه را برای مقیاس‌پذیری و نگهداری بسیار آسان‌تر می‌سازد.

---

تفاوت‌های کلیدی و ملاحظات انتخاب FC و FB

انتخاب بین FC و FB یکی از تصمیمات اساسی در طراحی برنامه‌ی PLC ساختاریافته است. این انتخاب بر کارایی، نگهداری و مقیاس‌پذیری تأثیر می‌گذارد. تفاوت‌های اساسی در نحوه‌ی مدیریت حافظه و پارامترها دارند.

---

جدول مقایسه و تفاوت FC و FB

ملاحظات عملکردی و بهینه‌سازی

• زمان اسکن و سربار CPU: FCها سربار کمتری دارند و برای وظایف ساده‌تر می‌توانند سریع‌تر باشند. FBها نیاز به کپی پارامترها به/از IDB دارند که کمی زمان بیشتری می‌برد. در PLCهای مدرن، این تفاوت معمولاً ناچیز است.
• اشغال حافظه: FCها از حافظه‌ی کمتری استفاده می‌کنند. FBها برای هر فراخوانی یک IDB ایجاد می‌کنند که فضای بیشتری اشغال می‌کند. این باید در طراحی حافظه‌ی پروژه در نظر گرفته شود.
• قابلیت استفاده مجدد و استانداردسازی: FBها برای “اشیاء” یا ماژول‌های کنترلی با وضعیت برتری دارند و به استانداردسازی کد و ایجاد کتابخانه‌ها کمک می‌کنند. FCها برای منطق‌های ساده و بدون وضعیت بسیار قابل استفاده مجدد هستند.
• عیب‌یابی و نگهداری: برنامه‌های ساختاریافته آسان‌تر قابل عیب‌یابی هستند. در FBها، عیب‌یابی منطق‌های پیچیده با وضعیت ساده‌تر است، زیرا داده‌های یک نمونه در IDB متمرکز شده‌اند. FCها برای عیب‌یابی منطق‌های بدون وضعیت بسیار ساده‌اند.

---

بهترین شیوه‌های برنامه‌نویسی ماژولار با FC و FB

برای بهره‌برداری حداکثری از مزایای برنامه‌نویسی ماژولار، رعایت بهترین شیوه‌ها ضروری است.

قانون کلی انتخاب بلوک

• از FB استفاده کنید زمانی که نیاز به حفظ وضعیت یا داده‌ها بین چرخه‌های اسکن دارید (مانند تایمرها، کانترها، ماشین‌های حالت).
• از FC استفاده کنید زمانی که وظیفه بدون وضعیت است و خروجی فقط به ورودی‌های فعلی بستگی دارد (مانند محاسبات ریاضی، مقیاس‌بندی).

استفاده از UDTها (User-Defined Data Types)

UDTها برای تعریف ساختارهای داده‌ای پیچیده و استانداردسازی تبادل داده بین بلوک‌ها بسیار مفید هستند. هنگام انتقال مقادیر زیادی از داده‌ها به/از FBها، آن‌ها را در یک UDT گروه‌بندی کرده و UDT را به عنوان پارامتر IN_OUT به FB ارسال کنید. این کار کارآمدتر است (ارسال اشاره‌گر). UDTها در ایجاد FBهای چند نمونه‌ای که نیاز به آرایه‌ای از ساختارهای داده‌ای مشابه دارند، نقش حیاتی دارند.

پرهیز از دسترسی مستقیم به IDBها

اگرچه امکان دسترسی مستقیم وجود دارد، اما به شدت توصیه نمی‌شود، به ویژه برای نوشتن. این عمل کپسوله‌سازی FB را نقض کرده و عیب‌یابی را دشوار می‌کند. همیشه داده‌ها را از طریق رابط FB (پارامترهای IN, OUT, IN_OUT) منتقل کنید.

مدیریت خطا (Error Handling)

مکانیزم‌های مدیریت خطای TIA Portal برای ساخت سیستم‌های مقاوم ضروری هستند:

• مکانیزم EN/ENO: برای تشخیص و مدیریت خطاهای زمان اجرا در سطح بلوک. ENO وضعیت اجرای صحیح را نشان می‌دهد.
• پارامتر RET_VAL: بسیاری از دستورات و بلوک‌ها کدهای خطای خاصی را در صورت مشکل برمی‌گردانند.
• دستورات GET_ERROR و GET_ERR_ID: اطلاعات دقیق‌تری در مورد خطاها ارائه می‌دهند (در S7-1200/1500).
• بلوک‌های سازمان‌دهی خطا (Error OBs): مانند OB85، OB121 و OB122. اگر این OBها وجود داشته باشند، CPU در صورت خطای مربوطه به جای رفتن به حالت STOP، آن‌ها را اجرا می‌کند.

نکات مربوط به تغییرات آنلاین

تغییرات در منطق FC معمولاً بدون نیاز به ریست حافظه قابل دانلود هستند. تغییرات در FB (اگر ساختار رابط یا STAT تغییر کند) ممکن است نیاز به دانلود مجدد IDB و ریست شدن مقادیر داخلی داشته باشد. از ابزارهای “snapshot” برای پشتیبان‌گیری و بازیابی استفاده کنید.

استانداردسازی و مستندسازی

ایجاد استانداردهای برنامه‌نویسی برای نام‌گذاری، ساختار بلوک‌ها و استفاده از پارامترها خوانایی و قابلیت نگهداری کد را به شدت افزایش می‌دهد. مستندسازی کامل هر FC و FB (هدف، پارامترها، منطق داخلی) برای برنامه‌نویسان آینده و پرسنل نگهداری ضروری است.

---

نتیجه‌گیری و توصیه‌ها

درک تفاوت FC و FB سنگ بنای برنامه‌نویسی ماژولار، کارآمد و قابل نگهداری در اتوماسیون صنعتی است.

خلاصه تفاوت‌های اصلی: تفاوت محوری در قابلیت حفظ حافظه است.

• FCها بدون حافظه (Stateless): برای وظایف ساده و محاسباتی بدون نیاز به حفظ وضعیت.
• FBها با حافظه (Stateful): از IDB برای ذخیره‌ی متغیرهای STAT استفاده می‌کنند. مناسب برای کنترل دستگاه‌ها/فرآیندهای پیچیده‌تر و قابلیت فراخوانی چند نمونه‌ای را فراهم می‌کنند.

اهمیت برنامه‌نویسی ماژولار: با استفاده صحیح از FC و FB، نه تنها به سازماندهی بهتر کد کمک می‌شود، بلکه به طور مستقیم بر کاهش زمان مهندسی، بهبود عیب‌یابی و نگهداری، و افزایش قابلیت استفاده مجدد از کد تأثیر می‌گذارد. این رویکرد به توسعه‌ی سیستم‌های اتوماسیون قوی‌تر و انعطاف‌پذیرتر کمک می‌کند.

توصیه‌های عملی در بررسی تفاوت FC و FB

• انتخاب آگاهانه: بر اساس نیاز به حفظ وضعیت تصمیم بگیرید. نیاز به حافظه دارید؟ از FB استفاده کنید. وظیفه‌ی شما بدون حافظه است؟ FC گزینه‌ی مناسبی است.
• استفاده از UDTها: برای ساختاردهی و تبادل کارآمد داده‌ها، به ویژه در FBها.
• حفظ کپسوله‌سازی: از دسترسی مستقیم به داده‌های IDB از خارج از FB پرهیز کنید.
• مدیریت حافظه‌ی ماندگار: تنها تگ‌های حیاتی را ماندگار علامت‌گذاری کنید و منطق راه‌اندازی (OB100) را برای مقداردهی اولیه پس از قطع برق برنامه‌ریزی کنید.
• مدیریت خطا: از مکانیزم‌های مدیریت خطای TIA Portal استفاده کنید.
• استانداردسازی و مستندسازی: استانداردهای برنامه‌نویسی را رعایت کرده و بلوک‌های خود را به دقت مستندسازی کنید.

با رعایت این اصول و شیوه‌های برنامه‌نویسی، مهندسان اتوماسیون می‌توانند از پتانسیل کامل TIA Portal زیمنس بهره‌مند شده و راه‌حل‌های کنترلی پیشرفته‌ای ارائه دهند.

چرا مقایسه TIA Portal و SIMATIC Manager اهمیت دارد؟

در دنیای اتوماسیون صنعتی، انتخاب بین دو نرم‌افزار کلیدی شرکت زیمنس یعنی SIMATIC Manager (STEP 7 Classic) و TIA Portal می‌تواند مسیر پروژه شما را تعیین کند. این مقاله با رویکردی کاربردی، مقایسه‌ی دقیق، تاریخچه، نسخه‌های جدید، و ارتباط آن‌ها با نسل جدید صنعت یعنی Industry 4.0 را بررسی می‌کند.

کاربرد SIMATIC Manager در پروژه‌های سنتی

بسیاری از کارخانه‌ها همچنان از PLCهای سری S7-300 و S7-400 استفاده می‌کنند که با SIMATIC Manager هماهنگ هستند. اما پروژه‌های جدید به ابزارهایی با گرافیک بهتر، امنیت بالاتر، شبیه‌سازی و ارتباط مدرن نیاز دارند. اینجاست که تفاوت TIA Portal با SIMATIC Manager خود را نشان می‌دهد.

Industry 4.0 چیست و چه ربطی به TIA Portal دارد؟

Industry 4.0 یعنی نسل چهارم اتوماسیون: هوشمند، متصل، سریع و قابل تجزیه‌وتحلیل. TIA Portal دقیقاً برای چنین محیط‌هایی طراحی شده و نقش مهمی در پیاده‌سازی الزامات Industry 4.0 ایفا می‌کند.

قابلیت‌های کلیدی TIA Portal در راستای Industry 4.0:

• پشتیبانی از PROFINET، OPC UA و I-Device

• اتصال به فضای ابری زیمنس (MindSphere)

• پشتیبانی از Digital Twin

• امنیت داخلی شبکه و مدیریت کاربران

• قابلیت Multi-user برای همکاری تیمی

مقایسه TIA Portal و SIMATIC Manager به‌صورت جدول

تاریخچه نسخه‌های نرم‌افزارهای زیمنس

SIMATIC Manager:

• 1995: اولین نسخه برای S7-300

• 2004: نسخه 3

• 2010: نسخه 5 (آخرین نسخه رسمی)

• 2015: توقف توسعه رسمی

TIA Portal:

• 2010: نسخه V10

• 2014: نسخه V13 با پشتیبانی از S7-1500

• 2020: نسخه V17 با شبیه‌سازی بهتر

• 2023: نسخه V19 با مدیریت نقش کاربران

• 2024: نسخه V20 با پشتیبانی از نسل دوم PLCهای G2

TIA Portal یا SIMATIC Manager؛ کدام انتخاب بهتری است؟

اگر پروژه‌ای قدیمی دارید که با PLCهای سنتی اجرا شده، SIMATIC Manager کافی‌ست. اما برای توسعه پروژه‌های مدرن، اتصال شبکه، امنیت و Industry 4.0، انتخابی جز TIA Portal وجود ندارد. مقایسه TIA Portal و SIMATIC Manager نشان می‌دهد که آینده اتوماسیون صنعتی با TIA Portal گره خورده است.

نتیجه‌گیری؛ چرا باید TIA Portal را جدی بگیرید؟

TIA Portal فقط یک نرم‌افزار نیست، بلکه یک پلتفرم کامل برای مهندسی آینده‌نگر محسوب می‌شود:

• طراحی PLC و HMI در یک محیط

• شبیه‌سازی، امنیت شبکه و کار تیمی

• پشتیبانی از پروتکل‌های مدرن مثل PROFINET و OPC UA

• هماهنگ با Industry 4.0 و اتصال به کلود

• ابزارهایی برای مدیریت نسخه و نقش کاربران

اگر قرار است با پروژه‌های واقعی، حرفه‌ای و صنعتی کار کنید، تسلط به TIA Portal یک ضرورت است. برای یادگیری اصولی و پروژه‌محور این نرم‌افزار، به دنبال آموزش‌هایی باشید که کاربرد عملی را در اولویت قرار می‌دهند.