Коня и трепетную лань: openPLC и wb-mqtt?

Издрасьте.

Меня постоянно подклевывают старой закалки АСУТПшники на тему, можно ли на горячо любимом мною вайрене писать из-под кодесиса. Боюсь, кардинально эти вопросы решаются только уголовно наказуемым деянием…
Видел и здесь ветку про codesys runtime и ваши ответы, которые понимаю и принимаю, opensource forever!

Поколупал в виртуалке openPLC. А вполне может быть, знаете ли! Максимум того, что есть в кодесисе, присутствует и в опенсорсе. Если бы не pub/sub ядро, не обточенное под стейт-машины.

Интересуюсь вашим мнением, дорогие авторы. Имеет ли смысл пытаться свести два мира вместе? То, что технически это реально, сомнений не вызывает, абер придется, конечно, поприседать.

Вот про это?

Да, тут основная препона - это так называемые авторские права.

Ну с опенсорсом такой проблемы нет, и это прекрасно.
Скорее вопрос про синхронизацию действий двух систем: очевидно придется дописывать мостик, чтобы обе делили доступ к железу.
Надо понять, одному ли мне это нужно. :thinking:

Мне кажется, что лучше смотреть в сторону Beremiz, он как-то живее.

Мне не кажется, судя по поломанному сайту и датам релизов, но тут, ясно, дело вкуса.
Надо поковырять поплотнее, вдруг удастся объединить. Тем же Wago вроде как удалось, хотя (вроде бы) mqtt там «на сдачу».
Доложусь, как руки дойдут.

1 лайк

Для себя оформил два взаимоисключающих варианта подхода имплантации openPLC в экосистему WB.

  1. Периферией напрямую управляет рантайм openPLC. Для WB он будет доступен либо как внешний модуль через modbus/tcp, либо напрямую через вновь написуемый драйвер mqtt. Преимущества: будет работать и не падать. Недостатки: рушится относительно стройная имеющаяся система конфигурирования железа, надо будет по факту придумывать новую, чтоб процесс не превращался в серьезный алогичный геморрой (хоть и одноразовый).
  2. Периферией, как и сейчас, напрямую управляют имеющиеся демоны wb-mqtt-*, а рантайм openPLC, посредством вновь написуемого драйвера mqtt, ворочает ею через очередь москиты. Преимущества: ничего в экосистеме менять не надо, достаточно добавить маппинг-таблицу переменная:топик в случае работы с рантаймом, а в случае не-работы и вовсе ничего не трогать. Недостатки: работа с железом через несколько слоев текущего софта альфа-стадии, чья отказоустойчивость еще очень далека от приемлемой; невозможность гарантировать время реакции даже приблизительно.

Сижу кумекаю. Включайтесь, кому небезынтересно.

Потыкал OpenPLC. В идеале думал как вариант избаваиться от ЦПУ в целом, переложить задачу автоматизации на ПК, который всё равно будет.
WIndows Runtime на сегодняшний день не умеет в MQTT и пока в зачаточном состоянии режим “онлайна” (отладки) приложения, что конечно добавляет массу неудобств. Если бы был MQTT и вменяемый онлайн - можно было бы рассматривать OpenPLC поближе. А так все равно интересное решение.

Он и для контроллера (arm) рантайм не особо хочет в mqtt к сожалению. Недавно (несколько месяцев назад) пробовал его - но сыроват откровенно.Надо снова пощупать.