Хочу добавить к WB6.5 ещё пару портов RS485 так как четырёх штатных не хватает. Попробовал подключить в I2C шину SC16IS752 он успешно обнаружился с помощью i2cdetect -y 1 с адресом 4d. Нашёл похожую инструкцию для RaspberyPI. https://www.raspberrypi.org/forums/viewtopic.php?t=146908&start=25
Помогите пожалуйста адаптировать её для WB6.5
Если я правильно прочитал документацию, есть готовое решение в виде Ethernet->Modbus адаптера. Должно работать “из коробки”.
https://wirenboard.com/wiki/index.php/WB-MGE
1 лайк
решительно не рекомендую использовать sc16is752 и подобное. Подключите лучше по USB что-нибудь, работать будет гораздо быстрее и стабильнее.
1 лайк
Usb на базе FT4232H (например USB-COM485-PLUS4) и есть решение которым пользуюсь последние пару лет. Всё устраивает (кроме отсутствия комплектного корпуса) хорошо стабильно работает. Просто подумал сделать в виде модуля расширения, но если говорите эти чипы стабильностью не блещут придётся отказаться от этой идеи. Не планируете ли вы в дальнейшем предусмотреть штатную возможность наращивания количество портов RS485? Мне бы например хотелось иметь вдвое или втрое больше портов чем есть сейчас.
1 лайк
Добрый день!
Честно говоря, раньше особо не думали. А подскажите, пожалуйста, для какой задачи могут понадобиться больше 4 портов?
Если коротко и в двух словах, то надоели длинные гирлянды устройств (более пяти в линию) RS485.
Ну а если подробней и не лень читать тогда попробую изложить с примерами и плюсами и минусами каждого варианта подключения. Занимаюсь внедрением и обслуживанием системы диспетчеризации на предприятии где около 40 котельных различного масштаба от районного до отапливающих одно или два здания. Среди них как с постоянным присутствием персонала, так и полностью автоматические без него. Ещё пару лет назад тоже думал что два или три порта на объект это вполне достаточно и именно так и делал. И действительно, если посмотреть чисто теоретически, то стандарт RS485 позволяет объединить в одну линию до 32 устройств, а с использованием повторителей гораздо больше. Но на практике ситуация совсем не такая уж радужная. Устройства с различными протоколами обмена, сильно отличающейся возможной максимальной скоростью подключения, не желающие делить линию с кем то ещё и от этого зависающие. С обслуживанием в течении длительного времени обязательно найдётся или устройство которое зависнет и эту линию положит или человек который в этом поможет.
Теперь несколько примеров чтобы пояснить вышесказанное:
-
Соединяем пару ТРМ212 пару ТРМ202 сюда же вешаем МВ110 и на этом месте уже скорей всего самого начала начнутся проблемы, что МВ110 то виден в такой сети, то нет. Но даже если с помощью подтягивающих резисторов и терминаторов запустить такую сеть проработает она стабильно меньше недели. Так как все ТРМ202 в модбас протоколе выпущенные до 2018 (почти десять лет Овен не признавал и не хотел исправлять эту проблему) года зависают, находясь в сети с другими устройствами.
-
Лето, отопительный сезон окончен. Оборудование интенсивно снимается то в поверку, то в ремонт. А на этой линии сидят ещё устройства, которые диспетчер должен постоянно видеть. Вот и получается что например сняли последнее устройство в линии, а провода просто оставили висеть в воздухе, превратив свободный конец линии в гигантскую антенну для ловли различных помех. В результате вся линия неработоспособна. Или такого же результата можно добиться просто случайно закоротив линию, но это хотя бы видно сразу и легко обнаруживается.
-
Инженеру нужно получить удалённый доступ к прибору коммерческого учёта тепла или газа с помощью заводской программы этого прибора (настройка, диагностика, ремонт). Для этого приходится временно отключить от диспетчерской системы всю линию, где находится данный счётчик. А ведь в эти 15-20 минут тоже может что то случится и увидит диспетчер это только по возвращении линии.
Таким образом я пришёл к выводу что количество устройств на линии надо стараться свести к минимуму одно, или в крайнем случае два. Бонусом здесь получаем возможность перестановки устройств без смены его сетевых настроек, что очень удобно. Вот и получается что нужно 10-12 портов на объект .
1 лайк
Понял. Подумаем.
Я тоже выскажу свое “За”
В моем случае получается так:
- Сначала на этапе строительства заводишь все слаботочные кабеля в единый узел коммутации.
- Потом, что бы создать последовательную шину (вместо звезды) создаешь зигзагообразные петли через дополнительные пары в кабеле,увеличив при том общую длину шлейфа в 2 раза.
К тому же, подключив устройства на разные порты мы еще и время реакции уменьшаем.
По крайней мере - сенсоры и исполнительные устройства я однозначно на разные порты rs485 подключаю.
Уже никто не вспомнит, наверное, что Ethernet тоже первоначально был протоколом общей шины. Вначале устройства подключались к общему коаксиальному кабелю. потом появились хабы. Потом все их вытеснили коммутаторы.
2 лайка
Поддержу тему, тоже думаем об увеличении количества шин. Так как одно зависшее устройство может отключить буквально пол системы, так как сейчас шины две. И поломку искать сложнее, так как длина цепи и девайсов на ней больше.
Кроме этого, интересует возможность временного отключения wb-mqtt-serial от конкретных шин без остановки других.
Добрый день!
В целом, аргументы понял, будем учитывать при дальнейшей разработке.
Но сюда вы точно можете добавить ещё две через Модуль расширения WBE2-I-RS485-ISO .
А это разве не решается снятием галочки Enable port в настройках порта?
У меня есть пара пожеланий для дальнейшей разработки.
-
Возможность использовать все UART порты процессорного модуля. Тот же модуль3 Uart на нём есть а вывода на клеммы нет и под RS485 никак не использовать.
-
Предлагаю сделать модули RS485 предназначенные для установки слева от основного модуля (Как например на Сименс S-1200 модули входов выходов справа а GPRS модуль предназначен для установки слева). На такой же разъём расширения вывести линии USB шины и туда подключать 4 портовые модули на основе FT4232H.
1 лайк
Для этого нужно перезагрузить wb-mqtt-serial? Хотелось бы “на лету”, например, во время сканирования шины или записи ИК команд.
Перечитал некроветку…
Ну, вот “сейчас” оно неактуально просто потому что в wb-mqtt-serial добавлен RPC.
Можно вполне себе произвольные наборы байт отправлять в шину и ждать/не ждать от устройств ответа. Пример: Шаблон для электрокарниза - #6 от пользователя BrainRoot
Кстати, можно работать с устройствами на скорости отличающейся от скорости порта.
1 лайк
Эта тема была автоматически закрыта через 7 дней после последнего ответа. В ней больше нельзя отвечать.