А чуть подробнее не расскажете, как у вас кабель уложен? Топология какая, в виде звезды, или все-таки одна линия с небольшими отводами? 40 м - это суммарная длина кабеля со всеми отводами или макс. расстояние между самыми дальними концами? Терминаторы на дальних концах стоят?
Топология звезда. Одна линия - один интерфейс. Ни каких ответвлений нет. Изгибы специально не формировал в поворотах, но в кабель канале или под потолком есть трассы, на них просто подвешивал кабель. Терминаторы стоят в модулях ввода-вывода. Включал на последнем модуле. Модули на одной линии соединены шлейфом. максимальная длина. Отводов нет. Только шлейф.
Сколько лучей у звезды? Каждый луч звезды можно назвать ответвлением, если в этом луче нет терминатора На таких скоростях даже резкие изгибы и петли ни на что не влияют. То есть, у вас в каждом луче стоит терминатор? Сколько лучей и звезды - столько терминаторов? У Cat5/Cat6 волновое сопротивление равно 100 Ом, т. е. оптимальное сопротивление терминаторов 100 Ом. А у вас какое сопротивление терминаторов?
RS-485 не разрешает и не запрещает никакую топологию, хоть точку-точку, хоть шину, хоть кольцо, хоть звезду, хоть самую замысловатую кракобряку. Он вообще ничего не говорит о топологии. Он оговариваривает только уровни сигналов.
На контроллере два интерфейса rs485, один rs232 и eth0. Rs485 расходятся на разные шкафы управления, в которых стоят модули IO На последних модулях есть всьроенные резисторы если это последний элемент. Я их и включал. Номинал резисторов не знаю. Волновое сопротивление utp не знаю. Допускаю, что не оптимально, но все идеально работает третий год. Отдельная тема eth0. Это связь с внешним миром через openhab. Rs232 чисто для модема
Сколько лучей у звезды? Сколько этих шкафов, неужто это такой большой секрет? Как я уже говорил, волновое сопротивление любых UTP или STP кабелей категории 5 и категории 6 (т.е. всех стандартных Ethernet кабелей, с экраном и без экрана, гибких и жестких) всегда равно 100 Ом. Это один из основных параметров, который дает кабелю право называться Cat5 или Cat6 (т.е. Category 5 или Category 6). Полное согласование нужно если вы работаете на больших скоростях и/или на большие расстояния. При малых размерах сети и/или на малых допускается работать с частичным согласованием или даже вообще без согласования. Интерфейсы домашней автоматизации KNX, C-bus, VelBus работают на малых скоростях. Они позволяют проложить порядка 1 км кабеля с произвольной топологией. Согласование частичное, где-то в середине сети ставится один терминирующий резистор, причем для KNX и C-bus его сопротивление даже не равно волновому сопротивлению кабеля. У вас, судя по всему, тоже получилось частичное согласование: в сети с топологией "звезда" с неизвестным числом лучей у вас стоят резисторы в каждом луче. Величина резисторов, скорей всего, 120 Ом, потому что таково типичное волновое сопротивление кабелей, обычно применяемых для RS-485. Разница 120 Ом или 100 Ом невелика, каждый ваш луч оказался почти идеально согласован на одном конце. Поэтому у вас в сети нет отражений. Потенциальная проблема только в одном: каждый терминирующий резистор создает нагрузку для работающего передатчика RS-485. Любой передатчик RS-485 гарантированно способен потянуть два терминирующих резистора. Реально передатчики RS-485 делаются с изрядным запасом, они вполне способны потянуть и три терминирующих резистора. Если у вас терминирующих резисторов больше (т.е. больше лучей у звезды), это создаст определенный напряг для передатчиков. Из строя не выйдут, поскольку в них встроена защита от короткого замыкания, однако амлитуда выходного сигнала упадет, начнут слегка греться, помехоустойчивость связи снизится, и т. п.
С мобильника неудобно писать. На одном интерфейсе плк подключен один шкаф управления. В нем шлейфом модули io. Второй интерфейс - второй шкаф.
То есть, у вашей "звезды" всего два луча? Тогда это не звезда, а шина (bus). То есть, вы создали хорошо согласованную шину RS-485. На 40 метров ода у вас скроей всего и на скорости 1 Мбит/сек будет работать без проблем. Шлейфы из-за их малой длины сильно ни на что не влияют.
Если @Smith2007 еще интересно по-обсуждать про задержки - еще в прошлом году при выборе концепции я сделал эксперимент, чтобы оценить задержки исполнения команд в моей системе. Как раз, в первую очередь, чтобы не возникали недоразумения с рутинными операциями типа управления светом от настенных выключателей, тач панелей или по датчикам движения - уже согласились, что тут задержка в 1с уже критична. Система состояла из датчика движения Z-wave, реле Z-wave, OpenHAB на Распберри, MQTT брокера на нем же, и планшета с CommandFusion, подключенного сперва по Rest API, а затем через MQTT. Были оценены следующие задержки: - от момента срабатывания датчика до включения реле - от момента нажатия виртуально кнопки на планшете до включения реле - от момента включения реле по одной из причин выше, до обновления статуса реле на планшете - от момента публикации контрольной команды в брокере MQTT до включения реле. Во всех указанных случаях задержка не превышала 0,2секунды... но при запуске OH могло пройти 2 или даже 10 секунд, пока первая команда не отработалась. Опрос через REST API грузит сеть, поэтому перешел на MQTT, так как поллинг не требуется. Далее были опробованы сценарии или правила OH. И тут, как и подобает всем системам, написанным юзерами, не подозревающими что такое реал-тайм, вылезли косяки. Не отрабатывает OH правила в нужном реал-тайме. То есть если указанный функционал по включению света от датчика движения выполнить с помощью правил, получаем весь набор приколов - в первый раз он долго думает пока включит свет, потом задержки могут быть от 0 и до пары секунд. Если долгое время правило не выполнялось - опять ждем. В общем весь набор с динамической памятью, ее освобождением, кешем и т. д. У меня есть жалюзи, где угол поворота определяется задержкой от 0 до 1,5с. Ессно точное управление ими с помощью такого правила не сделаешь. Но с другой стороны, по эскпериментам выше выходит, что I/O операции или транслирование протоколов OH делает вполне неплохо и достаточно шустро. Поэтому мой план - контроллер автоматизации запустить на Codesys, который будет общаться через MQTT с OH (Модбас, ессно, отдыхает, по указанным @_AK_ причинам. Даже TCP нужно поллить, а это задержка и нагрузка сети), а OH уже в свою очередь будет транслировать команды в Z-wave сеть.
При разработке C-bus и KNX было принято, что максимальная величина задержки должна быть не более 300 мс. Задержки больше, чем эта, раздражают. Типичная задержка самого интерфейса должна быть менее 100 мс, поскольку всегда набегают всякие дополнительные задержки, типа подавления дребезга контактов кнопок и т. п.
В Вашем случае задержки вызваны настройками OH. Слишком большое время опроса. Если ставить маленькое - действительно начинают вылазить всякие нехорошие глюки. Все это говорит лишь о том, что ресурсов RPi крайне мало для работы с real-time приложением, под управлением обычной linux системы да еще и на интерпретаторе клона явы. Представьте сколько кода нужно выполнить дохленькому процессору, что бы отработать один CONTACT... Тогда уж хотя бы qnx нужно вкорячить Я в своей системе пошел таким образом, что всем управляет PLC. OH только настройки можно задать, параметры посмотреть и некоторые режимы работы переключить. Ну и в одном месте можно принудительно вкл-выкл освещение. Т. е. в реале мне скорость отклика OH совершенно не важна. На PLC программа освещения запускается с периодом 300 мс. Время выполнения программы около 2 мс (она довольно простая). "Умных" датчиков нигде не ставил. Все датчики аналоговые 4-20 мА. В шкафу установлены модули IO. Кнопки заведены на дискретные входы контроллера. ПО контроллера отрабатывает нажатие.
@Smith2007, я так понимаю, что у Вас OH связан c PLC по Modbus TCP. В этом и есть основная проблема - Modbus TCP работает по принципу периодического поллинга мастером (OH) слейва (PLC). Насколько я помню, у вас период опроса где-то 300мс. Это уже создает задержку изза опроса. В худшем случае до 300мс. Если PLC программа крутится с периодом тоже 300мс, то из-за того, что поллинг и выполнение ПЛК программы не синхронизированы, у вас в худшем случае задержка может быть до 600мс. Поправьте меня, если у вас другие тайминги. Как вы уже говорили уменьшать период опроса мало смысла, так как это увеличивает нагрузку на процессор и сеть. Теперь насчет ресурсов RPi и моего эксперимента. Еще раз - я хотел проверить время реакции OH при транслировании сигналов и команд из одного интерфейса в другой и только при этом. Никаких сценариев и правил. То есть команда зашла через MQTT, Wi-Fi или TCP/IP и вышла через Z-wave. И наоборот. В этом случае ресурсов Rpi, криворукости явы и линукса вполне достаточно, чтобы транслирование выполнялось без существенных задержек - как я уже сказал - менее 0,1с на все. Конечно real-time там нет - например после старта первые команды транслируются с существенной задержкой. Это связано, скорей всего с динамической инициализацией памяти, что есть зло для реал-тайма и я собираюсь разработчиков ОН в этом смысле попинать - пусть испраляют. Но потом все работает отлично. Именно по этому я решил, что у меня связка OH-PLC будет работать по другому, чем у вас. PLC остаются функции управления и автоматизации, но I/O менеджментом будет заниматься OH. То есть в отличии от Вашей реализации у меня OH находится на два уровня ниже - между ПЛК и I/O. Задача OH в моей системе - привести все различные интерфейсы умного дома - z-wave, wifi, internet, к одному протоколу, и сделать все внешние сигналы доступными для PLC. С этим, как я уже говорил, он справляется на ура. PLC должен считывать предоставляемую информацию и обрабатывать алгоритмы автоматизации и выдавать команды, которые OH уже будет транслировать в команды для соответствующих интерфейсов УД. То есть ПЛК непосредственно управлять через свои входы/выходы не будет. Скажу для чего это все - я хочу использовать ПЛК в своей системе. Но в вашем случае у вас должны быть проложены дискретные провода к каждой точке - это недостаток. Я же отказываться от удобства тех же беспроводных интерфейсов не хочу. Также KNX можно привязать тем же образом, не используя супердорогие Ваго ПЛК с KNX на борту. Ну и последнее - ессно что же насчет протокола связи OH - PLC. В моем случае его латентность более критична, чем в вашем, так как это низкий уровень. Я смотрел OPC UA и MQTT, так как оба из них не используют поллинг для опроса. OPC UA хорош для ПЛК, он нативен для Codesys, но к сожалению для него нет поддержки ни в одной системе УД. Поэтому остается MQTT - он нативен для УД, но пока еще нет полностью рабочего стека под Codesys. Я работаю сейчас над адаптацией стеков из интернета. Возможно Вам тоже стоит подумать над уходом с Modbus? Помимо задержек, там еще и сама конфигурация оставляет желать лучшего - списки адресов и типов переменных - это уже прошлая эра.