Pull to refresh

Comments 16

Очень Узкоспециализированный...

Вы бы хоть картинки добавили, чтоб было понятно о чём вообще речь.

Так а архитектура ПО здесь где ? Разделили работу между коллегами, это не про архитектуру.

Что в итоге?

...

Теперь каждый может открыть программу каждого и понять, что она там накуролесил. 

Как и предполагалось, коллективное "накуролесил". Хорошо, если за панельку один человек отвечает.

В производственных панелях оператора дизайн UI - отдельный головняк. Как пример - типовая экранная клавиатура с кнопками 5х5 миллиметров - это же не для пальцев!

Приятный цвет, отсутствие вырви глаза или диких контрастов. Все просто: Зеленый — Вкл, Красный — Выкл, Синий — Интерактив, Серый/Белый — Текст.
Это все просто, пока Ваша система — первая у данного заказчика. В противном случае Вы услышите «А у нас в системе ХХХ, с которой мы уже работаем ХХХ лет, красным цветом отображается аварийное состояние и мы к этому привыкли. Поменяйте цветовую схему.» Ну или что-то в этом духе. А потом Вы будете до посинения согласовывать эту цветовую схему, потому, что сразу набежит десяток человек со своим уникальным «пользовательским опытом». В итоге родится какое-то компромисное решение, но оно скорее всего будет именно из разряда «вырви глаз».

DI- Дискретный вход;

DQ- Дискретный выход;

Позвольте узнать, как у вас получилось буквосочетание DQ? Всегда стандартом де факто я считал DO. Это наследие какой то библиотеки?

Тоже резануло глаз, видимо у автора вместо digital output (DO), digital quit.

Иногда DQ используют, чтобы показать high-side выход - выход с напряжением, а не сухой контакт.

Хотя согласен, AQ - не совсем AO :))

Если коротко, то обозначение Q определено для обозначения выхода стандартом IEC 61131-3 (см. секция 2.4 - переменные). Ну или ГОСТ Р МЭК 61131-3-2016 - там тоже выход это Q.

Скажем, если выход у нас байтовый, то пишут QB (для слова будет QW, для двойного слова QD). Если бы выход (output) обозначался как О, то получилось бы ОВ, что в общем логично, но проблема в том, что сочетание ОВ уже было зарезервировано для Organization Block, потому решили изменить O на Q. Я так думаю, что тон изначально задали немцы, поскольку у них Input/Output/Organization Block - это Eingang/Ausgang/OrganisationsBaustein и проблем с коллизиями обозначений нет, и OB уже занято. Ну есть ещё теория, что O уж слишком на ноль похожа, но я полагаю, что это именно с OB связано и кто-то из Сименса явно повлиял на это.

Тоже использую формулировку DQ, не единожды сталкивался с тем что среда не дает объявить такую переменную как "DO" воспринимая ее как инструкцию "Делай".
Как правило используем структуру такого типа:

достаточно высветить код ошибки в статусе (Ошибка - 401) и запомнив этот код, перейти мать его в код лист! Где все описано подробнейшем образом.

и через абзац:

инструкцию не читают... Добавить инструкцию на понятном, простом и разговорном языке прямо в панель, это не долго.

Вы там как-нибудь бы уж определились rtfm или не rtfm. Во-вторых, особенно прикольно когда у тебя вываливает пяток ошибок с пачкой шестизначных номеров - вот это классно запоминать их все идти и читать. Бонусом т.к. мы на объекте АСУ ТП, то до ближайшего блокнота с ручкой может быть 10-15 минут хода. В третьих, представим что у нас в обслуживании 5-10-15 систем у каждого свое кодирование ошибок - ну такое себе.

Приятный цвет, отсутствие вырви глаза или диких контрастов. Все просто: Зеленый - Вкл, Красный - Выкл, Синий - Интерактив, Серый/Белый

Всегда, согласовывается с заказчиком. ВСЕГДА. Т.е. есть системы, где НЕ работающий механизм это авария.

Я бы добавил от себя вот что:

Отработка критичных аварийных ситуаций только внешней автоматикой, релейной или электронной, но без применения каких-либо программных анализаторов. Например, реакция на сигнал "ПОЖАР" - отключение вентиляторов, включение аварийных клапанов - никакого ПЛК, только электромеханика.

Кнопки "Пуск" и "Стоп", тем более, "Аварийный останов" должны быть "железные". Это не только отучает тыкать в экран, но и освобождает его для его прямой функции - индикации состояния объекта управления.

Если панель оператора не является частью ПЛК, это ещё одно звено, понижающее надёжность и оперативность. Мне сейчас трудно вспомнить конкретные ситуации, которые привели к таким выводам, но они были и не зависили от производителя ПЛК.

Дизайн - это очень сложный вопрос, дизайн это во-первых - вопрос функциональности, во-вторых - эргономики и только в третьих - эстетики. Это не то же самое, что дизайн мобильника или телевизора. Речь идёт об управлении технологической системой, имеющей серьёзные отличия от бытового прибора.

Delta прекрасные контроллеры. Помню их по серии DVP-PS, у меня даже дома их есть парочка. Но с какими бы я не работал, а это много разных - и Delta и Овены и КОНТАР и Siemens и многие другие - их надёжность никогда нельзя принимать в 100% вешая на них отработку ситуаций, которые могут стоить жизни человеку.

Полностью поддержу. АСУТП и ПАЗ разделяются обычно. и подходы там разные. Хотя бы в том, что в ПАЗ - логика инверсная.

Создать стандарт предприятия в плане программирования ПЛК это конечно здорово, но кто будет смотреть за соблюдением этого стандарта (или этих правил)? А за несоблюдение этих правил - наказывать?

А вообще по поводу стандарта программирования ПЛК. Может у Delta уже есть такой документ? И не надо ничего нового самим придумывать. Нужно лишь придерживаться рекомендаций фирмы-разработчика? Например у Сименса есть "Programming style guide for SIMATIC S7-1200/ S7-1500", где в общих чертах изложены рекомендации к настройкам среды и названию переменных.

Sign up to leave a comment.

Articles