Чему FBD научил меня.
Длиннопост. Речь пойдёт о программировании промышленных логических контроллеров.
Всю свою рабочую жизнь я занимался наладкой автоматических систем управления. Сначала это были только котельные и тепловые пункты, потом ещё разные газоиспользующие установки, а потом дело дошло и до автоматизированных производственных конвейеров, промышленных роботов и прочих прекрасных вещей. Использовал я всякие разные контроллеры. Это были Овен, Сименс, Дельта, Сенека. Просто восьмибитные микроконтроллеры и stm32.
Я всячески избегал FBD. CoDeSys позволял писать программы на паскале-подобном языке (ST). Это было близко и понятно. Хотя я и разбирался в принципиальных электронных схемах, я всё равно не любил использование FBD, уже хотя бы за то, что некоторые вещи просто не знал как реализовать. Использование графических языков всегда занимало массу времени, результат получался ниже среднего.
Где-то год назад я столкнулся с производителем Segnetics. Некоторые их контроллеры можно (сильно извратившись) программировать на плюсах. Однако, для этого надо пройти, как минимум, чистилище, а то и пару кругов ада. Поскольку я не хотел повышать уровень красноглазия - решил использовать стандартные методы, предоставляемые производителем. Нужно было делать несколько проектов для этих контроллеров.
Поначалу раздражало абсолютно всё в этом их SMLogix. Лишь через месяц-другой я начал привыкать. Ещё через месяц - одобрять. Дальше больше. Не могу сказать, что я "подсел" на FBD, но моё отношение к программированию контроллеров изменилось.
К счастью, у меня была возможность получать многие ответы от одного из сотрудников технической поддержки сегнетикса. Это оказался программист, способный сделать на фбд всё, что угодно(спойлер: юзер с самым большим количеством сообщений на их форуме).
После того, как я выполнил несколько реальных проектов на их контроллерах, пришло понимание, почему в лоджике нет возможности писать код внутри блока текстовым языком. Дело не в том, могут они это разрешить или не могут. Дело в том, что это не нужно. Составляя программу на фбд, программист не может прострелить себе ногу. А вот текстовые языки, в большинстве случаев, позволяют это сделать в пару строк, а то и в одну. А ещё бывает, что нога простреливается по незнанию, неумению, невнимательности, и ещё тысяча причин.
Самое главное, на мой взгляд, это знать, какими средствами (блоками) решаются те или иные задачи. Как это делать эффективно и к каким побочным эффектам это приводит. При тщательном подходе и продумыванию структуры проекта - вообще никаких неожиданностей не возникает. Всё будет работать именно так, как запроектировано.
Крутые примеры у меня есть. Приводить их здесь, конечно, не буду. Скажу только, что делал несколько проектов для их сенсорного контроллера. У заказчика были высокие требования к интерфейсу. Это было особенно "болезненно" для меня, так как я никогда не делал серьёзных интерфейсов ранее. Максимум менюшка со списками. А здесь нужно было и анимацию сделать, и всякие жестовые штуки (свайпы, пинчи и прочая вот эта ерунда).
Теперь скажу и о негативной стороне. В частности, когда нет заводской "из коробки" поддержки жестов - приходится танцевать с бубном в этом fbd. Не сказал бы, что реализация нормального "драйвера тач скрина" на фбд невозможна. Да, это не просто, но это выполнимо, и в конечном итоге, работает адекватно. В целом, новый продукт хоть и понравился, но софт заточен под старое. Что ж, лично я буду надеяться, что они-таки выпустят что-то новое, в плане приклада.
В итоге, вся вот эта простыня, написанная выше, написана с целью донести одну мысль: если есть задача программирования ПЛК и подобных задач, без всякой сложной математики, работы с базами данных и прочее - FBD подходит идеально. Время разработки программы сокращается, заработок в час растёт. А когда объект налажен и работает без сбоев - все довольны.
P.S. Написал некоторые вещи с использованием NodeJS, который запустил прямо на trim5. Изврат? Возможно... Но если очень хочется - то можно вообще не использовать штатные средства программирования. Linux же.
