Comments 15
Многие ПЛК позволяют реализовать подпрограммы.
А некоторые ещё и позволяют делать "библиотечные типы"
но Вы наверняка и сами это знаете.
Код обширный, даже возникает соблазн его запустить и проверить)
Даже несмотря на возможность создавать подпрограммы, функциональные блоки, функции и т. д., многие не хотят разбираться в новых возможностях и "по красоте" переписывать старые куски кода. Я в таких случая обычно с 0 всё делаю, но это не всегда возможно по времени и желанию.
Спасибо за практический пример - добавлю на него ссылку в статье.
Правда когда это на реальном контроллере не заведется круто уже не будет.
В MATLAB я и начал разработку, чтобы не изучать глубоко языки ПЛК и их библиотеки.
Отсюда и результат: многословный плохо поддерживаемый код. ST+SFC — всё что Вам нужно было изучить. Два дня на вхождение, если неплохо знаете MatLab.
Какой-то сильно серьезный заплет для такой простой задачи, еще и Matlab тут, с таким справится даже ПР100 на FBD я думаю, и сразу же в симуляции можно все проверить.
Я одним ПР200 двумя шторами управлял :)
управление было как в этом варианте
Сценарий 1 управления одной кнопкой
1.Нажали кнопку и отпустили - движется вверх
2.Нажали кнопку - остановка
3.Нажали кнопку - движется вниз
4.Нажали кнопку - остановка
Переход к пункту 1
правда ещё с этой кнопки можно было отметить верхнее и нижнее положение шторы (для настройки).
Хороший, скорее всего, пример.
Однако вот что не понятно, а почему все реализовано в одном огромном блоке? Если можно отдельно описать каждый из способов, потом результат завести в какой-нибудь блок сравнения, где согласно приоритетов будет уже один управляющий сигнал, который и будет заходить fb управления рольставнями.
При таком подходе мы получаем три блока управления, которые можно использовать. Блок выбора приоритетного сигнала, который тоже можно где угодно использовать и блок управления самими рольставнями. Где, хотя бы, можно легко изменить нужную логику.
Потому что я не писал там сам ни строчки кода.
Это все сгенерировал MATLAB.
Вернее MATLAB сгенерировал полный текст компонента для ПЛК в виде XML файла с STL программой. Мне оставалось лишь импортировать этот файл в среду разработки WAGO и потом вызывать его как стандартный компонент.
А в статье я дал сам код STL без всего содержимого XML файла, поскольку оно не существенно.
Т.е. на самом деле тот исходник я не то что не изучал, но даже не смотрел вовсе. Он не представляет никакого интереса. Я с ним непосредственно не работаю и не рефакторю.
Этот исходник полностью рабочий поскольку он протестировал неоднократно и даже укладывается в цикл 10 мс для ПЛК средней производительности.
Интерес представляет только исходная диаграмма в Stateflow. Только в ней я меняю логику, меняю даже архитектуру просто создавая, удаляя, совмещая или разделяя разные автоматы состояний. И вот по поводу нее и стоило бы подискутировать. Правильно ли я идентифицировал состояния, правильно ли изолировал их, правильные ли условия в переходах и нет ли где-то избыточности. Может быть сам дизайн диаграммы недостаточно читабелен, может иерархия блоков недостаточная или избыточная. Как диаграмма приспособлена для рефакторинга. Вот только такие вопросы важны если вы работает с No-Code технологией типа MATLAB - Simulink - Stateflow.
Кстати сейчас только заметил что не все блоки модели раскрыл для обозрения.
Если будут пожелания могу выложить на Github этот проект, хотя это будет стоить мне времени.
Интересно что выдаст матлаб, если запихнуть в него уравнение для получения температуры по сопротивлению Pt1000 например. На FBD это довольно большое кол-во блоков, на ST пару строчек.
На STL такое делать не пробовал.
У семейств ПЛК либо есть отдельный специализированный модуль сразу это вычисляющий, либо я делаю свою плату с микроконтроллером и там уже генерю для него исходники не на STL, а на чистом C++. И поскольку использую ARM Cortex, то там с учетом мат.сопроцессора MATLAB выдаст это одной строкой. Правда файлов в итоге получиться много, так как MATLAB не генерит примитивные сниппеты, а генерит полностью законченные проекты с функцией main, API, всеми объявлениями своих типов, хидерами и проч.
А как отлаживать такой сгенеренный код?
Никак.
Отлаживается модель в MATLAB-е, а не сгенерированный исходник.
Для того на верхнем уровне у меня и изображена модель в окружении тестовой оснастки в которую входят генераторы последовательностей тестовых сигналов, блоки тестовых констант, блоки визуализации сигналов на выходах и проч.
Тут просто надо довериться сгенеренному коду. С другой стороны все же доверяются компиляторам, интерпретаторам, библиотекам и т.д.
Понятно что такое доверие не сразу возникнет. Нужен некоторый опыт применения и разграничения: что делать в матлабе, а что кодить напрямую.
Модель самой рольставни вы не делали? Использование Simulink PLC Coder это же часть Model Based Design, где все начинается с модели объекта управления.
Что вы подразумеваете под моделью?
На каком уровне детализации?
Получить точную модель физических рольставней нереально.
Сам движок рольставней - черный ящик.
Отчасти потому модельный подход Stateflow и применен. Поскольку были опасения за слишком частые изменения архитектуры конечных автоматов управления. Так оно и произошло. Вместо двух состояний двигателя - включен, выключен, появилось много состояний. И это от того что модель рольставней упирается во множество неопределенностей. Модель меняется после каждых неудачных натурных испытаний.
С другой стороны частично логическая модель мотора у меня представлена блоком Motor.
В этом блоке отражены основные состояния мотора с его коммутирующими элементами насколько удалось идентифицировать эти состояния.
Тут надо понять что у меня нет никакой обратной связи от рольставней. Поэтому управление идет по внутренней модели выполненной в блоке Motor.
Как сделать 240 килобайт исходников на ПЛК для управления одними рольставнями