Как стать автором
Обновить

Комментарии 14

Ага, постоянно сталкиваюсь с подобным. То программист про выравнивание не знал(и прога глючит в неожиданного местах чуть ли не от простой перекомпиляции), то компилятор к мк сделает код для fpu, а fpu не включен был. В общем небывалый кайф ловишь, когда к причине докапываешься…
Спасибо за статью, навеяла воспомнинания о Ачинском глиноземном комбинате и автоматической системе пожаротушения разрабатывавшуюся на адамах, много схожих проблем было, от выравнивания до помех на линиях искажавших пакет так что и контрольная сумма не спасала.
Жаль что подобные материалы на Хабре редкость и почти что неформат.
Пожалуйста. Рад, что понравилось.
.
А ошибки связи — IMHO отдельная проблема.
Про связь часто забывается в первую очередь. И вспоминается в последнюю, когда все остальные варианты уже отброшены.

В общем наверное это можно обьяснить тем, что системный блок с гигабайтами ПО вызывает гораздо больше опасений, чем какой-то провод…
И провод этим ловко пользуется.
А завтра операторы изменят уставку номер 1, она не влезет в байт, зато влезет в соседний, и изменит уставку номер 2, и я не могу отвечать за последствия (с)
Если такая ошибка имела место, значит не все предусмотрели на этапе программирования. Защита «от дурака» то должна быть.
Ну на то она и ошибка, чтобы быть какой-то не очень правильной :)
Программировались одновременно SCADA и ПЛК, часть ограничений была наверху, часть из-за кнопок в ПЛК.
Несогласованность.

В принципе можно было просто запретить ввод времен больше 255 секунд, и это было-бы самым правильным решением. Но эксплуатация спросила нечеловеческим голосом — Где мы вам новую механику возьмем, ироды?
И пришлось разбивать на 2 независимых слова.
Просто если параметр может превысить выделенную под него память, то и памяти надо выделять чуть больше, надежность системы важнее. Выделили бы под время 2 байта с жестким ограничением и их хватило бы всем :)
И на этапе тестирования полезно погонять с максимальными-минимальными значениями, даже без железа, столько ошибок может вылезти. Вот мое начальство недооценивает такие игрушки, но я делаю все равно :)
Какое оборудование и сеть, кстати, что идет битва за трафик?
> Выделили бы под время 2 байта с жестким ограничением и их хватило бы всем :)

Так один байт — уже был чуть ли не с двойным запасом :)
Старое оборудование 1970 кажется года наложило свои коррективы.

Просто чем старше обьект, тем порой больше в нем самопального и неожиданного…
Там же, если память не изменяет, подготовились к насосной станции (десяток водяных насосов + что-то по мелочи), приехали, развернулись… и с любопытством обнаружили, что порядка 3 лет назад вместо части насосов, местные протащили небольшую трубу к соседнему обьекту.
Долго бегал там с бумагами, согласовывал новые алгоритмы, призывал на головы проектировщиков всякое страшное…
В общем как говорил один знакомый: знал бы где упаду — соломы было-бы до горизонта :)

> И на этапе тестирования полезно погонять с максимальными-минимальными значениями, даже без железа, столько ошибок может вылезти.

Полностью согласен.
По поводу тестирования без железа правда есть нюансы.
У GE нет эмулятора ПЛК например.

> Какое оборудование и сеть, кстати, что идет битва за трафик?

GE Fanuc (в настоящее время GE) PAC Rx3i.
В общей сложности было порядка десяти CPU310.
Сеть — сотня.

Постоянно приходится учитывать, что следующим шагом возможно дальнейшее расширение системы, причем в непонятных объемах. Поэтому спокойнее бывает всё по возможности минимизировать, и не так сильно волноваться за будущее.
В общем получить необходимое и достаточное :)
По-хорошему, так сильно паковать и не стоило: плюшкинизм какой-то :)
Отдельный регистр под статусы, отдельный — под уставку таймера, отдельный — под текущее значение таймера.

Или бились за уменьшение объёма данных с целью сэкономить на лицензии для SCADA? ;)
Не без этого.

Ну и как в анекдоте про Раскольникова «пять бабушек — уже рубль» :)
Устройств было в общей сложности много, так что экономия получалась ощутимой.
Задавайте уставки в минутах и все :)
У нас тут бит аварийной скорости взлива залипал в контроллере, а потом через полгода при определенных обстоятельствах вызывал аварийную остановку агрегатов. Вот это расследование было )
У нас лет 7 назад были метания в этом направлении. В конечном итоге остановились на секундах.
Милисекунды излишне точно, минуты на каком-то из обьектов для эксплуатации показались недостаточно точными…
Не ГОСТ конечно, но менять все равно не очень хочется :)

Да и визуализация — она все-таки IMHO вторична.
Если ПЛК работает, но не отображает на АРМ состояния — это пол беды.
Гораздо хуже если он отображает всё корректно, но работает не так, как надо.
Поэтому упор был именно на алгоритмы, а вывод на экран добивался в конце, по мере сил.

Несанкционированный АО агрегата — это сильно.
Могу только посочувствовать.
А подтверждения от сменных операторов?
Все само останавливалось. Есть событие — аварийная скорость взлива, а скорости в реале нет )
Думаю, данной проблемы не было бы, будь реализована проверка типа данных в среде программирования ПЛК (или здесь речь о низкоуровневом программировании?).
Вопрос к специалстам: в каких средах ПЛК делается проверка типа данных (например: типа INT, LONG, CHAR и т.д.), а в каких нет?
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории