РЕКЛАМА НА ФОРУМХАУС Просто не надо подходить к программированию ПЛК, как к написанию компьютерной программы. Там логика исполнения совсем другая, и, что самое смешное, гораздо быстрее воспринимаемая теми, кто программированием вообще никогда не занимался, чем теми, кто в прошлом был суперпрограммистом. Как пример - электрик со знанием релейной логики, может быстрее наваять нужную ему логику в LD, чем программист на ST. Скажу как мне видится такой интерфейс/протокол: - физический уровень - Ethernet с возможностью как соединения звездой через свитч, так и последовательно от устройства к устройству (при этом при отсутствии питания конкретного узла, встроенный в каждое устройство трехпортовый свитч должен все равно работать) или Wi-Fi, если по воздуху - Протокол - MQTT поверх этого всего с стандартизированными профилями для различных устройств (то есть стандартные названия топиков для конкретных функций) - Протокол не должен конфликтовать с другими протоколами по той же сети (возможность работать в одной сети с обычными Ethernet устройствами) - При проводном Ethernet - PoE для питания сенсоров/выключателей. Актуаторы от PoE берут энергию только для коммуникатора из первого пункта. - Каждое устройство должно иметь DHCP и встроенный вебсервер для настройки. - Какой-то конфигуратор, позволяющий обнаруживать все эти устройства по сети и конфигурировать их.
25 лет назад я тоже рисовал эти релейные диаграммы в институте на лабораторных работах. Но мир меняется и нужно как-то идти в ногу со временем, а не тащить старый чумадан без ручки в светлое будущее. Но вот как-то в codesys этого не увидел. Да, были потуги внести в продукт ООП. Не прижилось и в общем-то все мы понимаем почему. Если код не сложный - мне вообще фиолетово на чем писать - пару вечеров на освоение языка. Но тут логика работы выходит за все разумные рамки. Конечно приспособиться можно - но лично меня это несколько напрягает. Аналогичную логику можно было бы реализовать через объекты, асинхронные вызовы или типа того. Код был бы гораздо структурированнее и доступнее. Но за неимением другого - приходится довольствоваться этим. наверное где-то так, еще бы я добавил в девайс usb вход для задания сетевых адресов, вай-фая и т. д.
Мне сейчас больше нравится менее развесистое дерево топиков но c json упаковкой параметров Что-то типа:
Это получается 11 миллисекунд на опрос состояния одного устройства, ещё надо забрать состояние и отправить что-то на исполнительное устройство. Желаемый цикл опроса 150 миллисекунд, хотелось бы 100, но и так остаётся время на 1 промах. Итого 150/11 - 4 = 9.6 устройств с входами. Тут не этаж, тут максимум комната
Если закрыть глаза на стоимость данного решения и убрать вот эту жесть Не ну реально, десятки устройств и у каждого свой способ конфигурации. Вопрос с бэкапом настроек для каждого устройства наверное даже рядом не пробегал. то получается AllJoin. Только пока счастливых обладателей невидно. А до того были умодробительные профили для ZigBee, тоже не взлетело.
И как это все 1 кнопкой обходятся для таких задач? Вывести картинку на телевизор по WiFi Direct занимает 5 секунд, но у нас свой путь, по граблям. У нас как-то клиенты пришли, с просьбой - на вашем сенсоре крутилка есть, для настройки, уберите её к бубуям вообще. Оказалось что покупатели их машин крутят что не положено, а потом говорят - оно сламалася, само. Дешёвое устройство может быть только массовым. Массовое устройство должно быть простым. ИМХО.
забываем, что 16 входов в одном регистре и тянутся за один заход. У меня на весь дом 6x16DI+6x16DO. Чего гадать - через месяц скажу точно.
Логика написания программ под IEC 61131-3 специально заточена под автоматизацию и не является устаревшей. Слушайте, мне аж интересно стало, что Вы там пытаетесь реализовать, что вам такая логика не подходит?
В файле пример правильного кода программы, которая читает из одного com-порта и записывает в другой. Не многовато ли кода для в общем-то несложной операции? А вот пример работы с com-портом на lua. Код: local Serial = require('periphery').Serial -- Open /dev/ttyUSB0 with baudrate 9600, and defaults of 8N1, no flow control local serial = Serial("/dev/ttyUSB0", 9600) serial:write("Hello World!") -- Read up to 128 bytes with 500ms timeout local buf = serial:read(128, 500) print(string.format("read %d bytes: _%s_", #buf, buf)) serial:close() Согласитесь, что разница есть и не малая.
Разница в основном в том, что в правильном коде во-первых отрабатываются все ошибочные ситуации при работе с COM-портами. Во вторых этот код не блокирует работу контроллера. Т. е. он может вызываться в основной программе в цикле и он не будет ее блокировать. Ваш же код на LUA может вывалиться в ошибку на любой комманде и вы ничего не узнаете - открыл ли этот код порт, написал ли он туда что-то или нет. Типичный десктоперско-программистский подход - я вызвал функцию, а как она отработала, мне пофиг. С железом так не пройдет. И если вы добавите в свой LUA код всю диагностику, как в правильном коде, то получится тоже не мало строк. И это еще неизвестно, что там с блокировкой - подвесит ваш local Serial = require('periphery').Serial контроллер на пару секунд - и ваши ворота дальше, чем нужно уедут. Так в системах реального времени не делается.
Я вполне понимаю, что логика работы ПЛК строится на неблокируемых циклах. В этом основное отличие от обычных программ. Но альтернативы в асинхронных вызовах в программировании тоже никто не отменял. Да там тоже непросто и есть масса вариаций. Но код намного прозрачнее, чем все гнать в основном цикле с выбором действий по case. Насчет обработки ошибок - я делал логирование ошибок mqtt для зонта. Код: local status,err_msg =pcall(_mqtt_exchange) if not status then print(string.format('Date:%s Error: %s', os.date("%Y-%m-%d %X"),err_msg)) mqtt.err_tick=mqtt.err_tick+1 end для бытового применения варианта вполне достаточно. Вы спросили, что мне не нравится - я ответил. Можно писать программы для ПЛК? конечно можно, но манеры программирования совсем другие.
По недельному опыту - китайские железки работают нормально. Пока траблов не увидел. Говен 210 постоянно уходит в астрал, после перезагрузки какое-то время работает - потом опять астрал. Проверил на codesys - стоит автоподключение. Попробовал для codesys RPI клиента клиента Janz MQTT стоимостью 50 евротугриков+НДС. Пробовал трайл версию. Результат такой же, что и с бесплатной библиотекой. При пакетной передаче нескольких сообщений - отдельные сообщения теряются. Похоже проблема где-то в codesys. Задержка в 10-20 мс проблему решает. Выглядит конечно не комильфо - но работает.
По поводу программирования: оказывается есть софтина FLProg для ардуины. Обещают визуальное программирование без знания языков программерских. Любопытно насколько это работает и может помочь чайникам вроде меня?
На форуме про ардуино, упоминание FLProg вызывает гнев и бурление. Основной аргумент, то что никто не знает какой код скрывается за этим "визуальным программированием". Считается, что неоптимизированный и глючный. В любом случае, когда Вы напишете свою программу и будете вылавливать глюки, листинг Вы можете выложить и кто-нибудь его даже посмотрит. А картинки рассматривать бестолку. Вы все-таки думаете в сторону ардуино? Посмотрите что такое Arduino Mega Server. И ПЛК, и веб-интерфейс в одном флаконе. Хотя та же Распберри, гораздо быстрее мощнее и надежнее. Я для себя вижу ардуино только в том случае, если требуется некоторый девайс с функционалом, который нельзя купить за разумные деньги. Например, думаю о том, чтобы научить сигнализацию говорить разные сообщения через динамики. В штатной сигналке такого нет и готового решения тоже нет. Поэтому буду пробовать на ардуино.
Я вполне догадываюсь об этом. Это такая особенность человечества. Вот это основной вопрос! Это действительно так или "считается"? Если считается то кем? Возмущенными ценителями чистого кода, или любому это ясно? Тут можно вспомнить как первые компы юзали с командной строкой, или, например, Автокад, где команды вбивались. Теперь благополучно кликают мышкой не думая о чистоте команды. У меня в голове нарисовалась довольно сложная система использования водяного солнечного коллектора. Неплохо бы включать насос по гистерезису между датчиками температуры, включать соленоидные клапаны, насосы. Если брать на али готовые программируемые термостаты с гистерезисом между датчиками то получается примерно 10 т. р. (~ пять термостатов). На эти денюжки можно замутить ардуину с кучей датчиков. Вот думаю: что же лучше/проще/надежней? Другой вариант купить термостаты с одним датчиком и сделать все проще и дешевле, но не так точно по температуре + немного доп управления руками.