44 подписчика

С чего всё начиналось

8 июня 20248 июн 2024

5 мин

Продолжение статьи "Игры кончились... Пора работать"

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

Как и упоминалось в предыдущей статье, проект логистики (конвейеры и накопители) подразумевает адресность. То есть изделие перемещается по конвейеру по своему маршруту. Но помимо этого необходимо взаимодействие с базой данных SQL. Исходя из этого, есть понимание, что ПЛК должен иметь на борту сетевой интерфейс (ethernet) для взаимодействия с сервером баз данных. Я вообще предпочитаю ethernet, но это моё субъективное мнение.

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

Так же планировалось использование панелей оператора WEINTEK, но они всеядны и поддерживают взаимодействие с широким кругом ПЛК. Ну и финальное требование - это цена и доступность в свете существующих реалий в стране на 2022 год.

В конечном итоге из трёх претендентов от Siemens, Omron и ОВЕН, победил ОВЕН.

Программируемый логический контроллер ОВЕН ПЛК 110-60

На тот момент у ОВЕНа сроки поставки значительно выросли. Ну не простаивать же нам из-за этого? Воспользуемся стандартным симулятором ПЛК от 3S Software - PLCWinNT.

ПЛК программируем в CoDeSys 2.3

У панели оператора от Weintek так же есть полноценный симулятор с сетевым взаимодействием.

Следует отметить, что изначально Unity я связывал с симулятором от Siemens. Поэтому, чтобы ничего не переделывать в Unity, я использовал симулятор ПЛК от Siemens в качестве "прокладки" между Unity и симулятором ПЛК PLCWinNT.

В итоге мы собрали необходимый набор:

Unity
симулятор ПЛК Siemens(необязательно)
симулятор ПЛК PLCWinNT
симулятор панели оператора от Weintek

И вот пока ожидалось прибытие "железа", работа шла полным ходом. Но гладко было на бумаге...

Заставить работать ОВЕН ПЛК 110-60 таким же образом, как и симулятор PLCWinNT не удалось ввиду невозможности одновременного подключения панели оператора Weintek (а их несколько в проекте) и среды программирования CoDeSys для отладки по проприетарному протоколу. Это обстоятельство вынуждало отказаться от использования проприетарного протокола и перейти полностью на Modbus. Перспектива переделки проекта не радовала совсем. Тем более какие еще "сюрпризы" может выкинуть ОВЕН ПЛК 110-60 настораживало всё больше и больше. Но "железо" приобретено и установлено, обратного хода уже нет. Дополнительно покупать ПЛК от Siemens не ожидалось.

На досуге, вооружившись поисковиком, стал искать решения использования персонального компьютера в качестве ПЛК. Кто "в теме", тот знает, что необходима система реального времени. На моё счастье нашлось решение от того же Siemens - софтПЛК WinAC RTX. Вот подробная инструкция по установке.

Этот софтПЛК выделяет одно ядро процессора, чтобы соблюдалось условие системы реального времени. Представляете какая мощь одного ядра процессора по сравнению с микроконтроллерами у "обычных" ПЛК?

Но и тут меня поджидал "сюрприз". Для того, чтобы софтПЛК мог работать с протоколом Modbus TCP, требуется дополнительная лицензия, которая прописывается непосредственно в проекте TIA Portal. Разумеется приобрести её не представлялось возможным. Ситуация прям-таки удручающая.

"Не в дверь, так в окно"

На ум пришло решение - написать программу для компьютера, которая будет конвертировать доступный для софтПЛК проприетарный протокол в Modbus и обратно. Сказано - сделано...

Дальше начались тесты производительности обмена по сети ethernet между софтПЛК и модулями ввода/вывода ОВЕН Мх210. Однако добиться удовлетворительных результатов производительности не удалось. Стабильность работы также была не на высоте. Изрядно поэкспериментировав в этом направлении, выяснилось, что программный конвертор протоколов вполне хорошо работает с одним модулем ввода/вывода. Ага! Вот это уже очень интересно!

Вот тут пришла идея - сделать на базе микроконтроллера ESP32 конвертор протоколов. Таким образом, чтобы на каждый модуль ввода/вывода работал свой конвертор (аналогия с личным переводчиком вполне уместна).

Распечатав на 3D-принтере корпус для микроконтроллера, получилось закрепить устройство на DIN рейку в электрошкафу.

Снабдив все модули ввода/вывода конверторами протоколов, перешел к тестам производительности обмена.

Длительность обмена между софтПЛК и модулями ввода/вывода (в миллисекундах)

Небольшое пояснение:

m35 - модуль ввода, 32 входа
m36 - модуль ввода, 32 входа
m37 - модуль ввода, 32 входа
m38 - модуль вывода, 24 выхода
m39 - модуль вывода, 24 выхода
m45 - ПЛК ОВЕН, 36 входов
m451 - ПЛК ОВЕН, 24 выхода

Как видно из диагностической информации, то ПЛК ОВЕН уступает по производительности обмена, по сравнению с модулями ввода/вывода. А вот модули ввода уступают по производительности модулям вывода, но это обусловлено наличием на них подключенных энкодеров, а значит и информации требуется передать больше.

Удовлетворившись такими показателями производительности обмена по сети ethernet для этого проекта, я перешел в привычную уже среду программирования TIA Portal и приступил к портированию проекта из CoDeSys.

Внедрение проекта производилось поэтапно и на момент написания статьи находится на этапе расширения. Поэтому, добавив в проект еще несколько модулей, диагностическая информация стала немного хуже, но пока вполне устраивает.

Небольшое пояснение:

m31 - модуль ввода, 32 входа
m32 - модуль вывода, 24 выхода
m33 - модуль вывода, 24 выхода
m40 - ПЛК ОВЕН, 36 входов
m401 - ПЛК ОВЕН, 24 выхода

Максимальная задержка между обменами уже немного начинает удручать, но по расширенной диагностике было выявлено, что такое происходит крайне редко. За день работы может возникнуть всего один-два раза. Но тем не менее есть над чем задуматься, чтобы поработать над уменьшением этих показателей. Однако, помимо таких разработок, в приоритете стоит сам проект логистики.

На этом статью завершаю. Постарался добавить немного конкретики к предыдущей статье.