اتصال شبیه‌ساز GX به Factory I/O از طریق OPC
یک راه‌اندازی پایدار برای راه‌اندازی مجازی میتسوبیشی، چیزی فراتر از تطبیق آدرس‌ها نیاز دارد. مسیر GX Simulator–OPC–Factory I/O را با مالکیت مشخص سیگنال‌ها، رابط‌های سازگار، شواهد زمان‌بندی و رفتار ...
راه‌اندازی مجازی زمانی ارزشمند می‌شود که صحنهٔ شبیه‌سازی‌شده مانند یک ماشین کنترل‌شده رفتار کند، نه یک پویانماییِ منفصل. برای یک پروژهٔ PLC میتسوبیشی، این امر به مسیر داده‌ای قابل‌ردیابی از شبیه‌ساز مهندسی GX، از طریق یک سرور OPC سازگار، تا تگ‌های Factory I/O نیاز دارد.
هدف صرفاً به حرکت درآوردن نوار نقاله نیست. یک راه‌اندازی مفید باید پیش از در دسترس بودن I/O فیزیکی، مالکیت آدرس‌ها، جهت سیگنال، رفتار توالی، اینترلاک‌ها، زمان‌بندی، واکنش به قطع ارتباط و منطق راه‌اندازی مجدد را اثبات کند.
یک نوار نقالهٔ مجازی کوچک می‌تواند پیش از رسیدن نقص‌های نگاشت، زمان‌بندی و بازیابی به تابلو کنترل واقعی، آن‌ها را آشکار کند.
پیش از نگاشت تگ‌ها، سازگاری نرم‌افزار را تأیید کنید
«GX Simulator» ممکن است به قابلیت‌های شبیه‌سازی مرتبط با نسل‌های مختلف GX Works و خانواده‌های CPU MELSEC اشاره کند. محصولات OPC نیز از نظر نسخه و پشتیبانی از OPC DA یا OPC UA با یکدیگر تفاوت دارند. گزینه‌های درایور Factory I/O ممکن است از همهٔ ترکیب‌ها به یک شکل پشتیبانی نکنند.
خانوادهٔ دقیق PLC، نسخهٔ GX Works، مؤلفهٔ شبیه‌ساز، محصول و نسخهٔ سرور OPC، نوع رابط و نسخهٔ Factory I/O را ثبت کنید. سپس بررسی کنید که سرور OPC بتواند به CPU شبیه‌سازی‌شده متصل شود. فرض نکنید روشی که با یک ماژول اترنت فیزیکی کار می‌کند، خودبه‌خود با یک شبیه‌ساز نرم‌افزاری نیز کار خواهد کرد.
میتسوبیشی MX OPC را نرم‌افزاری معرفی می‌کند که داده‌های کنترلرهای قابل‌برنامه‌ریزی MELSEC را از طریق OPC در دسترس قرار می‌دهد. سخت‌افزارهای جدیدتر MELSEC iQ-R نیز می‌توانند از ماژول سرور OPC UA داخلی استفاده کنند، اما این معماری با سرور اجراشده روی رایانه که به یک کنترلر شبیه‌سازی‌شده متصل است تفاوت دارد. این مسیرها را در یادداشت‌های طراحی و عیب‌یابی جدا نگه دارید.
پیش از پیکربندی نرم‌افزار، قرارداد داده را بنویسید
فهرستی از I/O ایجاد کنید که برای هر سیگنال یک ردیف داشته باشد. تگ Factory I/O، آدرس تجهیز میتسوبیشی، نوع داده، جهت، معنای مهندسی، حالت پیش‌فرض، حالت ایمن، نیازمندی به‌روزرسانی و مالک را درج کنید. در حالت معمول، شبیه‌سازی باید مالک وضعیت ورودی‌های میدانی باشد و منطق PLC مالک فرمان‌های عملگرها.
این قانون مالکیت مانع از آن می‌شود که دو برنامهٔ کاربردی یک نقطه را بنویسند. یک فوتوسل شبیه‌سازی‌شده می‌تواند یک تجهیز ورودی PLC را بنویسد، در حالی که PLC فرمان موتور را می‌نویسد و Factory I/O آن را می‌خواند. اگر هر دو طرف یک تگ را بنویسند، نمایش ممکن است چشمک بزند یا تصادفی به نظر برسد، حتی اگر تک‌تک اتصال‌ها از نظر فنی فعال باشند.
تجهیزات بیتی، کلمه‌ها، اعداد صحیح علامت‌دار، مقادیر ممیزشناور و آرایه‌ها به مدیریت صریح نوع داده نیاز دارند. یک کلاینت OPC ممکن است مقداری را با موفقیت نمایش دهد، در حالی که Factory I/O نوع داده یا ترتیب بیت نادرستی را تفسیر می‌کند. کار را با یک نقطهٔ بولی و یک کلمه که تغییر مقادیر آن کاملاً قابل‌تشخیص است آغاز کنید. فقط پس از اثبات جهت و مقیاس‌بندی، دامنه را گسترش دهید.
اتصال را به‌صورت لایه‌ای ایجاد و آزمایش کنید
ابتدا یک برنامهٔ حداقلی PLC ایجاد کنید و آن را در شبیه‌ساز GX پشتیبانی‌شده اجرا کنید. یک تجهیز داخلی مشخص را فورس یا تغییر وضعیت دهید و تأیید کنید که مانیتور نردبانی وضعیت مورد انتظار را نشان می‌دهد. این کار فعال بودن برنامه، CPU انتخاب‌شده و شبیه‌ساز را اثبات می‌کند.
در مرحلهٔ دوم، سرور OPC را برای همان کنترلر شبیه‌سازی‌شده پیکربندی کنید. فقط چند تگ آزمایشی ایجاد کنید. با استفاده از کلاینت یا نمای تشخیصی خود سرور، کیفیت، مهر زمانی، مقدار و قابلیت نوشتن را تأیید کنید. مقداری که «بد» یا «نامطمئن» علامت‌گذاری شده است، باید پیش از باز کردن Factory I/O در همین لایه اصلاح شود.
در مرحلهٔ سوم، کلاینت OPC در Factory I/O را پیکربندی کنید و تگ‌های تأییدشده را مرور یا وارد کنید. یک حسگر شبیه‌سازی‌شده و یک فرمان عملگر را نگاشت کنید. هر دو جهت را به‌طور مستقل تأیید کنید: ورودی صحنه را تغییر دهید و حافظهٔ PLC را مشاهده کنید، سپس خروجی PLC را تغییر دهید و صحنه را مشاهده کنید.
این روش لایه‌ای خطاها را از هم جدا می‌کند. اگر حافظهٔ GX تغییر نمی‌کند، مشکل از شبیه‌سازی PLC است. اگر GX تغییر می‌کند اما کلاینت OPC نه، پیکربندی سرور و آدرس‌دهی تجهیزات را بررسی کنید. اگر سرور OPC سالم است اما Factory I/O ثابت مانده، اتصال کلاینت، نام آیتم‌ها، سطح دسترسی و نگاشت تگ‌ها را بررسی کنید.
راستی‌آزمایی لایه‌به‌لایه، خطاهای پیکربندی PLC، سرور OPC و Factory I/O را جدا می‌کند.
زمان‌بندی میان سه سیستم مستقل را در نظر بگیرید
اسکن PLC، نظرسنجی سرور OPC، اشتراک کلاینت و به‌روزرسانی فیزیک Factory I/O در یک لحظه انجام نمی‌شوند. یک پالس حسگر که کوتاه‌تر از فاصلهٔ نمونه‌برداری ترکیبی باشد، ممکن است پیش از مشاهده توسط PLC ناپدید شود. بار شبکه یا رایانه نیز حتی روی یک ایستگاه کاری محلی می‌تواند نوسان زمانی ایجاد کند.
رویدادهای مهم باید طوری طراحی شوند که از نمونه‌برداری جان سالم به‌در ببرند. یک تجهیز شبیه‌سازی‌شده می‌تواند وضعیت خود را تا زمان تأیید حفظ کند، یا منطق PLC می‌تواند انتقال شناسایی‌شده را تا مصرف آن در توالی لچ کند. طولانی‌تر کردن همهٔ پالس‌ها برای نمایش آسان است، اما ممکن است نقص‌های پردازش لبه را پنهان کند. رفتار آزمایش را با حسگر فیزیکی مورد انتظار و سرعت تولید هماهنگ کنید.
به‌جای فرض کردن اینکه نرخ به‌روزرسانی پیکربندی‌شدهٔ OPC کل تأخیر است، تأخیر مؤثر سرتاسری را اندازه‌گیری کنید. وقتی زمان‌بندی برای توالی اهمیت دارد، انتقال صحنه، مهر زمانی OPC، مشاهدهٔ PLC، تصمیم خروجی و اقدام نهایی صحنه را ثبت کنید.
برای OPC DA و محدودیت‌های ایستگاه کاری برنامه‌ریزی کنید
OPC DA کلاسیک از فناوری COM مایکروسافت استفاده می‌کند. وقتی همهٔ برنامه‌ها تحت یک حساب ویندوز و روی یک رایانه اجرا می‌شوند، راه‌اندازی معمولاً ساده‌تر است. پیکربندی‌های توزیع‌شده مشکلات هویت DCOM، مجوزها، فایروال و حساب سرویس را ایجاد می‌کنند. اتصالی که به‌صورت تعاملی کار می‌کند، ممکن است پس از راه‌اندازی مجدد و اجرای سرور OPC تحت حسابی دیگر از کار بیفتد.
OPC UA از مدل امنیتی متفاوتی با نقاط پایانی، گواهی‌ها و سیاست‌ها استفاده می‌کند. این فناوری از DCOM اجتناب می‌کند، اما همچنان به اعتماد گواهی، مجوزهای کاربر و مدل‌های دادهٔ سازگار نیاز دارد. از رابطی استفاده کنید که نرم‌افزار انتخاب‌شده واقعاً پشتیبانی می‌کند و DA و UA را صرفاً برچسب‌هایی قابل‌جایگزینی در نظر نگیرید.
حالت‌های خطا و راه‌اندازی مجدد را عمداً آزمایش کنید
در حالی که نوار نقاله فعال است، کلاینت OPC را قطع کنید. شبیه‌ساز PLC را متوقف کنید. سرور OPC را راه‌اندازی مجدد کنید. Factory I/O را با خروجی‌هایی که پیش‌تر روشن بوده‌اند دوباره باز کنید. ماشین نباید صرفاً به دلیل بازگشت مقادیر قدیمی یا اتصال دوبارهٔ کلاینت، حرکت خطرناک را از سر بگیرد.
واکنش به کیفیت نامطلوب، قطع ارتباط و مقادیر راه‌اندازی را تعریف کنید. بسته به فرایند، فرمان‌ها ممکن است خاموش شوند، در همان وضعیت نگه داشته شوند یا با توقف کنترل‌شده مدیریت شوند. ورودی‌ها ممکن است به یک بیت صریح سلامت ارتباط نیاز داشته باشند تا PLC بتواند حالت کاذب واقعی را از دادهٔ در دسترس‌نبودن تشخیص دهد.
همچنین راه‌اندازی سرد، راه‌اندازی گرم، حفظ شمارنده، ناهماهنگی دستور ساخت، حسگرهای مسدود، ورود هم‌زمان و بازنشانی اپراتور را آزمایش کنید. وضعیت اولیهٔ هر تگ قابل‌نوشتن و توالی لازم برای ورود به حالت خودکار را مستند کنید.
سلول مجازی را به سکوی آزمایش تبدیل کنید
از موارد پذیرش تکرارپذیر استفاده کنید: هیچ عملگری پیش از مجوزهای شروع فعال نشود؛ برای هر محصول یک شمارش انجام شود؛ توقف در هدف به‌صورت کنترل‌شده انجام گیرد؛ برای حسگر مسدود مهلت زمانی اعمال شود؛ در صورت قطع ارتباط خطا اعلام شود؛ و پس از اتصال مجدد، بازیابی قابل‌پیش‌بینی باشد. روندهای تگ و سوابق قبول/رد، شواهد قوی‌تری نسبت به تصاویر ثابت از یک صحنهٔ در حال حرکت ارائه می‌کنند.
گزینه‌های کنترلر میتسوبیشی را می‌توانید در مجموعهٔ Mitsubishi Electric بررسی کنید و سخت‌افزارهای گسترده‌تر کنترلر را در بخش PLC & PAC Systems ببینید.
OPC فقط لایهٔ انتقال است. ارزش مهندسی زمانی آشکار می‌شود که سلول مجازی به محیطی تکرارپذیر برای آزمایش رفتار PLC، مالکیت سیگنال، فرض‌های زمان‌بندی، واکنش به خطا و منطق راه‌اندازی مجدد تبدیل شود؛ مواردی که به ماشین فیزیکی منتقل خواهند شد.