Часть 2, приоритеты и базовые сигналы
Часть 1,введение (отправил в политоту из-за двусмысленных высказываний, ибо было сложно удержаться)
Приоритеты команды
Итак, вы решили взяться за благое дело и сэкономить пару дефицитных рупей на найме программиста и запилить всё своими руками. Что же для этого надо?
1) скачайте среду разработки
2) откройте среду разработки
3) закройте среду разработки и идите искать программиста
Для начала, давайте проясним одну вещь. То что я рассказываю не является аксиомой. Это концепция архитектуры, позволяющая сделать максимально гибкое и устойчивое решение, позволяющее безболезненно изменять различные прослойки кода внутри проекта, не роняя завод.
Итак, помните, я говорил что всё есть сигнал? Я наврал. Всё есть объект.
Вход - это объект.
Выход - это объект.
Бутылка - тоже объект, но более высокого порядка.
А дальше мы начинаем собирать пирамидку из кубиков:
- базовые сигналы нижнего уровня, дискретные и аналоговые
- простые устройства
- сложные устройства
- технологические участки
- технологические линии
- производственные участки
...
- планирование производства
Вот всё что лежит до троеточия и будем рассматривать. Начнём с базиса, но перед этим - а кто здесь главный? Ты, я? оператор? директор? да пошёл ты в жопу, директор! Главная здесь ОНА:
Мне лень рисовать пирамидки маслоу, поэтому обойдёмся блок-схемами. ГОСТы - для слабаков! Главное, чтобы было понятно...
УХ, ебать! Но это лёгкий вариант, извините.
Глобальные переменные
Обратите внимание на "Глобальные переменные". Что в них входит? А всё, что проходит красной нитью через весь код и существует в единственном экземпляре:
- Аварийный останов
- Общий сброс аварий
- Общий режим эмуляции
- Общий перевод в автоматический режим всех устройств (очень полезно, если оператор любит пошарить ручками где надо и забывает что делал в недрах нашей системы)
Как оно выглядит в объявлении переменных? Вот так:
All_Block:BOOL; //аварийная остановка
All_Reset :BOOL; //сброс всех аварий
All_Sim :BOOL; //общий режим эмуляции
All_Auto :BOOL; //перевести всё в автоматический режим
sys :system; //системные переменные
sec :REAL; //длительность одной секунды
Обратите внимание, на две последние переменные. Это наша опора и поддержка, которую мы будем гонять вместе с первой четвёркой по всем проектам.
sec - длительность секунды в часах, да, я знаю что считать в REAL повышает нагрузку на CPU, но пардон, у вас мощности позволяют то в 2к2+ году
sys - структура системных переменных, которая собирает в себя базовые компоненты, реализация которых отличает у разных производителей:
- флаг TRUE
- флаг FALSE
- импульсы с разным весом, которые живут ровно 1цикл программы
- прочая мелочёвка
Опс, опять что-то новенькое. 1 цикл программы. Да-да, ваш код всегда исполняется от начала и до конца сверху вниз, слевана право. За всякие go_to я лично вырываю руки, ибо нехер.
Итого, на текущий момент у меня в sys лежит:
Дану ёб твою мать, скажете вы, что это за херня? И будете правы!
- x - не потому что хуй, а потому что ON и OFF зарезервированы системой и их нельзя просто так применять;
- Hand - флаги, что хотя бы одно устройство данного типа переведено в ручной режим;
- Alm - флаги, что хоть одно устройство данного типа находится в аварии;
- Any - сборный флаг для всех флагов, привязанных к типам устройств;
- V - Valve, а не то что вы подумали. Клапан, заслонка, задвижка;
- M - не мудак, к сожалению, а Motor. Вентилятор, транспортёр, всё что вращается - всё Motor. Я иногда делю на MD и MDA, дикрестное и дискретно-аналоговое управления, но это личные заморочки, не более;
- DTL - DataTimeL.. хз что за L, типовая структура формата год-месяц-дата-час-минута-секунда, которую мы будем использовать при работе с расписанием и всем, что требует проверки системного времени.
Ну наконец-то! А где код-то? Хрена вам, а не код. Рано.
На очереди ещё одна структура, которая будет всегда и везде, обеспечивая работу вон той страшной картинки наверху, обычно я называю её CMD:
УправлениеУра! Наконец-то! Мы добрались! И теперь...
Видите вон там странный Alarm, которого раньше не было? Видите? И он есть!
А всё почему? Да потому что...
1) мы делаем универсальный код, который будет применим для всего и вся
2) программа - это не только программа, это ещё функциональный блоки функции
В чём же разница? Если кратко - функциональный блок может иметь свои внутренние, приватные, переменные, а функции - работает только с внешними и временными.
СтопЭ. временные и внутренние - какая в пень разница?
Внутренняя - сохраняет своё значения при переходе на новый цикл программы.
Временная - теряет своё значение может содержать случайную величину при переходе на новый цикл программы.
Таким образом, если вы внутри функции делаете А+Б=С и по значению С принимаете решение КАЖДЫЙ раз вызывая функцию, то можно использовать временную. А если делаете А+Б = С один раз и больше к этому не возвращаетесь, только читая С, то нужна внутренняя переменная. И опять таки... если вы хотите сохранить значение С при перезапуске контроллера - будьте добрый, сделать её энергонезависимой, т.е. Retain.
Вернёмся к Alarm. Для функциональных блоков (FB) и функций (FC) есть следующие виды переменных:
- входные - можно только читать
- выходные - можно только записывать
- входные-выходные - как тугая попка трапа, можно и читать и изменять значение
Это очень важно, когда у вас одна и та же внешняя переменная передаётся разныеFC/FB а вы сидите и хлопаете глазками, почему значение теряется посреди программы. Да потому что вы проебались и привязали не к тому типу. Наиболее наглядно сие видно в графических языках:
Слева- входные (input) и входно-выходные (input-output) переменные, справа -выходные.
Фух, разобрались, теперь вызовем нашу страшную функцию:
Драйвера, устройства и состояния
Расширим очко овертона терминологию: драйвер. Нет, это не виндовый драйвер. Но близко. Это некий алгоритм и набор переменных, описывающий работу базового или типового устройства. Входа, выхода, насоса, клапана. Оно беспечивает автомномный контроль:
- безопасности
- аварий
- ручного и автоматического управления
- наработки
Включает в себя все необходимые для жизни параметры и настройки, коих дофига и больше. Но это мы рассмотрим потом. Или не рассмотрим. Если микроскоп вдруг сломается.
Выглядит управление дискретным входом следующим образом:
Итак, для работы драйвера нам необходимы:- CMD - структура команд, рассмотрена выше- cfg - структура параметров- state - структура состоянийДискретный вход слишком прост и отдельный набор состояний ему не нужен. Состояния включают в себя коды аварий, подсчёт наработки, вспомогательные плюшки для удобства отображения оператору "что тут происходит, мамочки, почему оно встало?!"use_NC...
NC - нормальной закрытый сигнал
NO - нормально открытый сигнал
Например, у вас есть дверь. Стоит датчик, контролирующий что "дверь закрыта".
Есликогда она закрыта сигнал = 0, а при открытии двери сигнал = 1, это нормально открытый сигнал.
Если когда она закрыта сигнал = 1, а при закрытии двери сигнал = 0, то это нормально закрытый сигнал.
Применение того или иного типа сигнала должно быть продиктовано соображениями безопасности. Например, аварийный стоп - должен быть нормально закрытым сигналом. Есть сигнал - всё хорошо, пропал - всё плохо. Почему так? Потому что Вася уронил топор на кабель и сигнал пропал - вы должны отключить всю систему, чтобы бедного Васю не намотало, превратив в инвалида пожизненно. Да-да, безопасность Васи - Ваша ответственность!
А если это не критичный сигнал, требующий контроля целостности сигнальной линии, то можно смело ставить нормально открытый датчик. Но это теория, а на практике ныне - что найдёте, то и поставите. Сорян.
УУУ, сука, сколько буков то! А это только начало! И я не ответил на главный вопрос - на кой хер нам вообще различать на уровне драйвера тип сигнала? В алгоритме основном поправим, да и делов то. НЕТ! Хватит! Не усложняйте себе жизнь!
Вам, как программисту, должно быть глубочайше насрать какой там тип датчика -сработал это всегда = 1, не сработал это всегда = 0. И именно эту задачу унификации решает драйвер дискретного входа. УНИ-ФИ-КА-ЦИИ, а не загрузки процессорного времени бесполезным хламом. Так менеджеру и ответите, что вы ускоряете дальнейший цикл разработки, ага.
ТаймерыАвтор, ты заебал, где код драйвера? Да вот он, только работать он у вас не будет:
А почему - угадаете? Не, вы не тупые, вы умные. Просто я хитрожопый и вместо системных таймеров использую самописные. Нахуа-хуа? Да потому что системные кривые. И их мало. И каждый системный таймер можно использовать только один раз(если они аппаратные, как в старых ПЛК).
Почему использовать системный таймеры, это грех:
- если вы измените во время работы таймера уставку времени и она окажется меньше, чем уже прошедшее время с момента запуска таймера, то он встанет раком
- нет паузы
- нет сброса
- нет контроля % отсчитанного времени
- и, самое главное, время в формате Time, которое очень неудобно выводить на панель оператора
Самописный таймер решает все эти задачи. Как вы уже догадались, там потребуется структура переменных для него и FC, вот они для самого простого таймера, который используется в драйвере выше:
И весь этот охреневший объём кода вам нужен в промышленном контроллере только для того, что проверить нажатие кнопочки или срабатывание маленького геркончика. Очень мило, не правда ли?)
Благодарю за терпение, забыл важную картинку и не смог отредактировать пост. В прошлом варианте поста были вопрос на тему, почему pulse_01s и pulse_1s имеют тип BOOL и как вообще эта мерзость должна работать. Не зря в начале было сказано об архитектуре, именно её мы затронем третьей части историй после кружечки кофе и предложим своё видение "как оно должно работать", что, естественно, не претендует на истину и даже не носит рекомендательного характера, потому что код каждого программиста индивидуален и уникален, но если мы сможем писать хотя бы так, чтобы сосед слева мог его прочитать - это уже хорошо.