Инструкцията ONS може да работи точно според предназначението си, докато изходът до нея изглежда така, сякаш никога не се активира. Привидното противоречие се дължи на времето на сканиране: ONS пропуска преход от false към true за едно програмно сканиране, докато OTE записва стойността в своята дестинация въз основа на условието на стъпалото всеки път, когато то бъде оценено. Когато са свързани последователно, дестинацията е true за едно сканиране, а след това отново става false.

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

Зелената онлайн подсветка може да бъде пропусната, когато състоянието true продължава само едно изпълнение на задачата.

Какво всъщност гарантират ONS и OTE

Rockwell Automation определя ONS като инструкция, която прави останалата част от стъпалото true за едно сканиране, когато входното условие на стъпалото се промени от false на true. Нейният бит за съхранение запомня дали предходната логика вече е била true. Този бит принадлежи на детектора на фронт и не бива небрежно да се споделя с друга еднократна импулсна инструкция.

OTE има различен договор. Тя задава своя целеви бит, когато условието на стъпалото е true, и го изчиства, когато условието е false. Справочникът на Rockwell за битовите инструкции в Studio 5000 разграничава активирането за едно сканиране чрез ONS от поддържаното и ретентативното поведение на OTE, OTL и OTU.

При сканирането, което открива нарастващия фронт, ONS пропуска непрекъснатостта на стъпалото и дестинацията на OTE става true. При следващото сканиране входът може все още да е true, но ONS блокира непрекъснатостта, защото фронтът вече е бил обработен. След това OTE изчиства дестинацията си. Резултатът е валиден импулс с продължителност едно сканиране, а не неизправна бобина.

Защо импулсът изчезва от полезрението

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

Физическият изход добавя още една граница. Контролерът обновява изходните си данни, комуникационният модул прехвърля данните по собствен график, а свързаното устройство има електрическо и механично време за реакция. Импулс, който съществува в образа на контролера за едно сканиране, може да е твърде кратък, за да достигне надеждно до полевото устройство или да го задейства. Точното поведение зависи от периода на задачата, обновяването на модула, мрежовата конфигурация, изходния хардуер и товара, а не от универсален праг в милисекунди.

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

Изберете схемата според необходимото поведение на състоянието

Използвайте импулс с продължителност едно сканиране за събитие

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

Наименувайте го съответно — Start_Request_Pulse е по-ясно от Pump_Start. Рутината за състоянието или оборудването трябва да приеме заявката, да провери разрешаващите условия, да установи собствеността и да създаде поддържаната команда за работа.

Използвайте самоподдържащо се уравнение за поддържана неретентативна команда

Ако събитие за стартиране трябва да поддържа бит за работа, докато не стане true логика за стоп, повреда или блокировка, самоподдържащо се уравнение за състояние може да управлява една OTE. Командата остава true, защото битът за състоянието участва в собственото си поддържащо условие, а не защото ONS остава true.

Подредете условията за стоп, повреда, режим и разрешаване така, че приоритетът им да е еднозначен. Избягвайте да начертаете клон, който заобикаля самата блокировка, предназначена да спре оборудването. Един собственик на изхода е по-лесен за преглед от няколко стъпала, които записват в един и същ BOOL.

Еднократният импулс трябва да заявява промяна на състоянието; поддържаната логика трябва да управлява командата към оборудването.

Използвайте OTL и OTU само с изрично определена собственост върху нулирането

OTL задава бит, а OTU го изчиства. Това може да бъде чист модел от събитие към състояние, но всеки път за задаване трябва да има прегледан път за нулиране. Определете какво се случва при първо сканиране, смяна на режима, изтегляне, рестартиране на процесора, загуба на обратна връзка и преминаване към състояние на повреда. Никога не приемайте, че операторският бутон за стоп е единственото условие, което трябва да освободи командата.

При сложно оборудване автоматът със състояния обикновено е по-ясен от разпръснати инструкции за фиксиране и освобождаване. Той осигурява едно място, където да се дефинират поведенията Idle, Starting, Running, Stopping и Faulted, както и разрешените преходи между тях.

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

Първо потвърдете, че логиката преди ONS действително преминава от false към true. Ако вече е true, когато рутината започне да се изпълнява, може да няма нов фронт, който да бъде пропуснат. Проверете дали рутината се сканира непрекъснато, извиква се условно или е поставена в задача, която е блокирана.

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

Трето, проследете целевата дестинация на OTE. Друга OTE, OTL, OTU, произведен таг, псевдоним или външен запис може да промени същия бит по-късно в сканирането или в друга задача. Документацията на Rockwell за OTE изрично предупреждава за операнди, които биват презаписвани. Определете един собственик на крайната команда и нека другите рутини заявяват промени чрез отделни тагове.

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

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

Пример от приложението: избор на водеща помпа

Рутина за водеща/резервна помпа може да генерира еднократен импулс, когато Помпа 1 стане избраната водеща единица. Този фронт не бива да се свързва директно към физическия изход. Той трябва да заяви стартиране от модула за оборудването на помпата. След това модулът проверява автоматичния режим, разрешаващите условия, състоянието на изключване, минималното време в изключено състояние, потребността на процеса и наличността, преди да зададе поддържана команда за работа.

Обратната връзка трябва да премести състоянието от Starting към Running, а изтичането на времето за стартиране трябва да създаде реакция при отказ. Заявката за стоп и повредите трябва да преместят състоянието към контролирано спиране или незабавно изключване според проектното решение за процеса. Това разделяне не позволява мимолетно събитие за избор да се превърне в единственото нещо, което поддържа командата към двигателя.

За друг пример за превръщане на булева логика в поддържаема стълбовидна структура вижте коригираното ръководство за XOR с три превключвателя и логика за нечетен паритет. Опциите за контролери и I/O могат да бъдат разгледани и чрез PLC и PAC системи.

Проверката на дизайна е собствеността

Редакционен поглед: повтарящата се грешка не е неразбирането на еднократния импулс, а позволяването на бит за събитие да се представя за състояние на оборудването. Детекторите на фронт отговарят на въпроса „настъпи ли този преход?“. Логиката на състоянията отговаря на въпроса „какво трябва да прави машината сега?“. Разделянето на тези въпроси създава код, който се пуска в експлоатация по-лесно, по-безопасен е при рестартиране и е много по-малко уязвим към промени с дублирани бобини.

Често задавани въпроси

Активира ли ONS следващата OTE?

Да, за сканирането, при което входното условие на стъпалото се променя от false на true. При следващото сканиране ONS блокира стъпалото, докато входното условие първо не се върне към false и след това отново не премине към true.

Защо не виждам как OTE се включва онлайн?

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

Трябва ли да заменя OTE с OTL?

Само ако ретентативното състояние е действителното изискване и всяко условие за освобождаване е изрично проектирано. За много команди към оборудване автомат със състояния или самоподдържащо се уравнение с един собственик OTE е по-лесен за одит.

Могат ли две инструкции ONS да споделят един и същ бит за съхранение?

Не бива. Битът за съхранение записва историята на фронта. Споделянето му свързва двете инструкции и може да накара едното стъпало да потисне очаквания импулс на другото.

Може ли OTE с продължителност едно сканиране да управлява физически изход?

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