Как да оптимизирате времето за сканиране и да отстраните грешките „Превишен watchdog“ на IC695CPU310

Разбиране на първопричината за грешката „Превишен watchdog таймер“ на RX3i

Грешка „Превишен watchdog таймер“ на PACSystems RX3i IC695CPU310 на GE Fanuc не означава автоматично, че процесорът няма достатъчна изчислителна мощност. Никога не трябва да отстранявате тази грешка просто чрез увеличаване на настройката на софтуерния watchdog таймер. Основната причина е неочаквано увеличение на времето за изпълнение на един цикъл на PLC програмата. Ненормални условия в циклите, прекомерни рекурсивни извиквания на функции или интензивни операции с паметта обикновено водят до тези забавяния.

Съгласно референтните указания на GE Fanuc за процесорите, софтуерният watchdog открива необичайни забавяния при завършването на цикъла. Диапазонът на конфигурируемия софтуерен watchdog е от 10 ms до 2550 ms, с настройка на стъпки от 10 ms. Полевите инженери винаги трябва да откриват програмното затруднение, което увеличава най-лошото време за цикъл, вместо да прикриват основни логически грешки чрез увеличаване на времевите ограничения.

Разграничаване между повреди на софтуерния и хардуерния watchdog

Инженерите трябва да установят точния хардуерен или софтуерен механизъм зад грешката, преди да променят кода.

• Повреди на софтуерния watchdog: Възникват, когато един цикъл на изпълнение надхвърли програмирания праг на watchdog-а. Типичните причини включват огромни цикли FOR или WHILE, рекурсивни функционални блокове, неограничени операции с масиви, интензивна обработка на низове, концентрирани Ethernet комуникации или директни записи в енергонезависима памет.
• Повреди на хардуерния watchdog: Те представляват вътрешен защитен механизъм на процесора, който се задейства. За разлика от софтуерните грешки, повредите на хардуерния watchdog често изискват пълен физически цикъл на изключване и включване на захранването при по-стари платформи като IC695CPU310.

Когато възникне неочаквано изключване, отворете таблицата с повреди в PAC Machine Edition (PME). Проверете описанието на повредата, кода на повредата, времевия печат и броя на възникванията. Пристъпете към оптимизация на логиката само ако диагностичният журнал изрично показва изтичане на времето на софтуерния watchdog.

Анализ на динамиката на циклите: среден цикъл спрямо максимален цикъл в най-лошия случай

Много инженери по автоматизация се фокусират единствено върху средното време за сканиране на програмата, което създава опасна „сляпа зона“. Система със средно време на цикъла от 18 ms лесно може да достигне 240 ms при определени условни задействания. Ако лимитът на watchdog-а е 200 ms, PLC ще премине незабавно в състояние на стоп поради грешка.

Условната логика с висока натовареност обикновено причинява тези случайни изключвания. Операции като изчисляване на дневни пакетни отчети, архивиране на исторически данни или масово копиране на паметта се изпълняват в рамките на един цикъл на сканиране и увеличават пиковото време за изпълнение.

Практически методи за намаляване на времето за сканиране на контролера IC695CPU310

Оптимизирането на циклите на сканиране поддържа контурите за управление бързодействуващи в предприятия за високоскоростно пакетиране, пречистване на вода и непрекъснато производство. Прилагайте следните инженерни техники, за да намалите пиковото време на цикъла:

• ⚙️ Въведете разделяне на времето за големи цикли: Никога не изпълнявайте огромни цикли FOR или WHILE в рамките на един цикъл на сканиране. Разделете обработката на масиви на по-малки части в няколко последователни цикъла чрез индекси на машина на състоянията.
• ⚙️ Проверете рекурсивните извиквания и функционалните блокове: Проверете дървото на извикванията на блоковете в PAC Machine Edition. Премахнете косвените рекурсивни извиквания, при които Функция A задейства Функция B, а тя по невнимание извиква отново Функция A при определени логически разклонения.
• ⚙️ Преминете от непрекъсната към събитийно управлявана обработка на данни: Избягвайте копирането или мащабирането на хиляди аналогови регистри при всяко сканиране. Изпълнявайте тежки математически формули и сортиране на масиви само когато флаговете за промяна на данните се задействат.
• ⚙️ Разпределете Ethernet и серийните комуникационни задачи: Разпределяйте активните комуникации като Modbus, SRTP или EGD в няколко цикъла чрез стратегия за последователно обхождане, вместо да запитвате всички външни възли едновременно.
• ⚙️ Ограничете записите във флаш паметта: Директните логически извиквания за запис на оперативни данни в енергонезависима памет отнемат значително процесорно време. Задействайте записите във флаш паметта периодично или при приключване на пакет, вместо при всеки логически цикъл.

Последователност за полево отстраняване на неизправности

Следвайте този методичен инженерeн процес, за да отстраните безопасно пиковете във времето за сканиране:

1. Установете произхода на повредата: Проверете таблицата с повреди в PME, за да потвърдите задействане на софтуерния watchdog.
2. Запишете базовите показатели: Запишете средното време на цикъла на процесора, максималния цикъл в най-лошия случай и текущата настройка на времевото ограничение на watchdog-а.
3. Проследете тесните места в кода: Потърсете неограничени цикли, непрекъснати трансфери на масиви, концентрирани комуникации и записи във флаш паметта.
4. Преструктурирайте логиката: Прилагайте машини на състоянията, алгоритми за разделяне на времето и събитийно управлявани логически блокове, за да разпределите изчислителното натоварване.
5. Преоценете производителността: Наблюдавайте пиковите времена за сканиране в продължение на няколко работни смени при максимално производствено натоварване.
6. Настройте резерв за watchdog-а: Задайте окончателния лимит на софтуерния watchdog малко над новоустановеното време на цикъла в най-лошия случай, за да поддържате надежден резерв за безопасност.

Практически сценарий: оптимизация на конвейерна система в линия за бутилиране

В предприятие за високоскоростно бутилиране на напитки, управлявано от контролер IC695CPU310, производствената линия периодично преминавала в стоп поради грешка на PLC на всеки няколко дни при смяна на смените.

Първопричината: По време на смяната на смените активна подпрограма на стълбовидната логика изпълнявала неограничен цикъл, който сортирал, актуализирал и копирал 4000 регистъра за проследяване на продуктите в архивен масив в рамките на едно сканиране. Това увеличило пиковото време на цикъла от нормалните 22 ms на 265 ms, надхвърляйки прага от 200 ms на софтуерния watchdog.

Решението: Нашият инженерен екип преструктурирал алгоритъма за сортиране в машина на състоянията с разделяне на времето, която обработвала по 200 регистъра на цикъл в продължение на 20 последователни цикъла. Тази промяна намалила максималното пиково време на цикъла от 265 ms на 38 ms и напълно отстранила проблема със задействането на watchdog-а, без да се променят хардуерните компоненти.

Често задавани въпроси (ЧЗВ)

В1: Нашият CPU310 редовно задейства грешки „Превишен watchdog таймер“. Означава ли това, че тактовата честота на процесора е твърде ниска и той трябва да бъде заменен?
Отговор: Не непременно. Смяната на процесора трябва да бъде последната ви възможност. Повечето грешки на watchdog-а произтичат от лошо структурирана програмна логика, неограничени циклични операции или внезапни комуникационни пикове. Можете да премахнете пиковете в циклите, като преструктурирате тежките изчисления в машини на състоянията с разделяне на времето в няколко логически цикъла. Обмислете хардуерен ъпгрейд само ако средното базово време на цикъла остане близо до капацитета на процесора след преструктуриране на кода.

В2: Можем ли безопасно да зададем софтуерния watchdog таймер на максималната му стойност от 2550 ms, за да избегнем задействанията?
Отговор: Въпреки че менюто за конфигуриране на процесора физически позволява стойност до 2550 ms, това е лоша инженерна практика. Удължаването на лимита до такава стойност прикрива критични логически грешки като безкрайни цикли или блокирали рекурсивни извиквания. В критична автоматизация на процеси блокирал процесор, който работи 2,5 секунди преди задействането на защитата, може да причини сериозни експлоатационни рискове и опасности за безопасността. Поддържайте лимита на watchdog-а малко над действителното време на цикъла в най-лошия случай, с разумен резерв за безопасност.

В3: Според полевия опит кой е най-добрият начин да се проследи кой конкретен блок причинява пиково увеличение на времето за сканиране?
Отговор: Използвайте диагностичните инструменти в PAC Machine Edition заедно с потребителски таймери за изпълнение. Вмъкнете отчитане на системен времеви печат преди и след подозрителни функционални блокове, за да записвате пиковата продължителност на изпълнение в регистрите за проследяване. Сравнете тези показания с журналите за състоянието на машината, за да установите кои производствени събития — като смяна на пакет, генериране на отчет или запитвания от HMI — задействат пиковото натоварване при сканиране.

Прозрения от автора и експертно мнение

„През годините, в които поддържаме оборудване за индустриална автоматизация в Ubest Automation Limited, често виждаме полеви екипи да се опитват да решат повредите на PLC watchdog-а чрез произволно увеличаване на настройките на таймера или закупуване на нов хардуер. При платформи като PACSystems RX3i пиковете във времето за сканиране почти винаги се дължат на неефективно управление на данните или неограничени комуникации. Дисциплинираният подход, поставящ софтуера на първо място, спестява значителен престой и удължава експлоатационния живот на съществуващия контролен хардуер.“
— Инженерен екип на Ubest Automation Limited

Търсите надежден хардуер на GE Fanuc и експертна поддръжка?

Независимо дали отстранявате неизправности в наследени системи или търсите резервни части за фабрична автоматизация, Ubest Automation Limited предлага тествани оригинални PLC компоненти, DCS модули и решения за индустриално управление.

Разгледайте оригиналните компоненти на GE Fanuc и PACSystems в Ubest Automation Limited.