📌 Diagnostic Buffer
در S7-300 / S7-400 —
✅قسمت دوم:
خب، تو قسمت قبل یه آشنایی کلی با Diagnostic Buffer داشتیم و گفتیم وقتی PLC با یه خطا یا اتفاق غیرعادی مواجه میشه، یکی از اولین جاهایی که باید سراغش بریم همین Diagnostic Buffer هست.
⚠️حالا بریم سراغ خود خطاها:
چیزی که مهمه اینه که وقتی وارد Diagnostic Buffer می‌شیم، فقط دنبال این نباشیم که ببینیم CPU روی چه خطایی گیر کرده.
باید از روی پیغام بفهمیم:
مشکل کجاست؟
مربوط به برنامه است؟
مربوط به آدرس است؟
مربوط به I/O است؟
یا اصلاً مشکل از یک Module یا شبکه است؟
🔰چند مورد خیلی رایج رو با هم بررسی کنیم.
🔹 1. FC Not Loaded
فرض کنید داخل برنامه یک FC رو صدا زدید، ولی اون FC داخل CPU وجود نداره یا Load نشده.
در این حالت ممکنه در Diagnostic Buffer با پیغامی مثل:
FC not loaded
مواجه بشید. (البته برای FB هم همین موضوع صحت دارد)
اینجا دیگه لازم نیست الکی دنبال مشکل سخت‌افزاری بگردیم.
اول باید خود FC و شماره اون رو بررسی کنیم و ببینیم واقعاً داخل CPU Load شده یا نه.
یکی از اشتباهات رایج هم اینه که برنامه رو روی PG داریم ولی تصور میکنیم حتماً همون برنامه داخل CPU هم هست.
این دو تا رو باید از هم جدا کنیم.
🔹 2. DB Not Loaded
این مورد هم خیلی شایع هست.
مثلاً برنامه داره به یک DB دسترسی پیدا می‌کنه ولی DB موردنظر داخل CPU وجود نداره.
در Diagnostic Buffer می‌تونه چیزی شبیه این پیام نوشته شود:
DB not loaded
پس اینجا مسیر عیب‌یابی تقریباً مشخصه:
ابتدا DB موردنظر رو پیدا میکنیم → شماره DB رو بررسی میکنیم → موجود بودنش در CPU رو چک میکنیم → در صورت نیاز دوباره Block رو Load میکنیم.
🔹 3. Area Length Error
💢اینجا یه نکته مهم وجود داره:
فرض کنید برنامه می‌خواد به یک محدوده از حافظه دسترسی پیدا کنه، ولی طول محدوده‌ای که درخواست شده با چیزی که واقعاً وجود داره یا قابل دسترسی هست، همخوانی نداره.
در این شرایط ممکنه با خطایی مثل:
Area length error
مواجه بشیم.
این خطا رو نباید با Address Error یکی بدونیم.
یعنی ممکنه آدرس درست باشه، ولی محدوده‌ای که برنامه داره می‌خونه یا می‌نویسه اشتباه باشه.
این تفاوت خیلی مهمه.
🔹 4. I/O Access Error
یکی دیگه از خطاهایی که در پروژه‌های واقعی زیاد باهاش برخورد میکنیم، خطای دسترسی به I/O هست.
مثلاً برنامه داره یک ورودی یا خروجی رو می‌خونه یا می‌نویسه، ولی CPU نمی‌تونه به اون I/O دسترسی داشته باشه.
ممکنه در Diagnostic Buffer پیغامی در رابطه با:
I/O Access Error
ببینیم.
اینجا باید چند مورد رو بررسی کنیم:
آدرس I/O درست هست؟
ابتدا بررسی میکنیم که Module مربوطه وجود داره (باید آدرس های تعریف شده در HWconfig را بررسی کنید) ؟
اگر Module در وضعیت سالم هست؟
آدرس Hardware Configuration با آدرس واقعی یکی هست؟
اگر Remote I/O داریم، ارتباط شبکه برقرار هست؟
یعنی صرفاً با دیدن عبارت I/O Access Error نباید سریع بگیم «پس کارت خراب شده».
اول باید مسیر رو مرحله‌به‌مرحله بررسی کنیم.
🔹 5. Address Error با Area Length Error فرق داره
این قسمت رو پیشنهاد می‌کنم خوب یاد بگیرید، چون در عیب‌یابی خیلی به کارتون میاد.
Address Error
بیشتر ما رو به سمت خود آدرس و معتبر بودن اون می‌بره.
ولی در:
Area Length Error
ممکنه آدرس شروع درست باشه، اما محدوده‌ای که داریم بهش دسترسی پیدا میکنیم مشکل داشته باشه.
پس وقتی پیغام رو می‌بینید، فقط ترجمه کلمه به کلمه اون کافی نیست.
باید ببینید CPU دقیقاً در چه قسمتی از برنامه و روی چه آدرسی به این وضعیت رسیده.
🔹 6. Module Fault
حالا می‌رسیم به خطاهایی که احتمالاً باید کمی جدی‌تر بررسیشون کنیم.
اگر Diagnostic Buffer یک خطای مربوط به Module Fault بده، باید خود Module رو بررسی کنیم.
اینجا مواردی مثل:
• وضعیت Module
• Power Supply
• ارتباط Backplane
• Configuration
• خطای Channel
• Diagnostic LED
باید بررسی بشن.
اگر Module قابلیت Diagnostic داشته باشه، اطلاعات بیشتری هم ممکنه در Module Information در اختیارمون قرار بگیره.
🔹 7. Wire Break و Short Circuit
در بعضی Module های ورودی و خروجی و مخصوصاً Moduleهایی که Diagnostic قابلیت‌های بیشتری دارن، ممکنه خطاهایی مثل:
Wire Break
یا
Short Circuit
گزارش بشه.
اینجا دیگه فقط برنامه PLC رو بررسی نمی‌کنیم.
باید بریم سمت سیم‌کشی و خود تجهیز.
مثلاً اگر یک سنسور روی یک ورودی داریم و Diagnostic Module اعلام Wire Break می‌کنه، باید سیم، ترمینال، سنسور و تغذیه رو هم بررسی کنیم.
پس یک اصل مهم:
هر خطایی که در Diagnostic Buffer می‌بینیم الزاماً مشکل نرم‌افزاری نیست.
🔧 حالا روش عیب‌یابی من چیه؟
من معمولاً این مسیر رو پیشنهاد می‌کنم:
September 15, 2026 1.4K
