Comments 65
Уважение коллегам по цеху средств автоматизации.
По поводу изменений в WB8:
- добавили mod4 и убрали один usb-c — это отлично, НО — верните второй обычный usb для подключения внешних устройств!!! место есть, вместо кнопки FW… как часто в реальной жизни её используют? её можно и внутри корпуса разместить, если очень надо будет — то снять верхнюю крышку и иглой куда нибудь тыкнуть
- что стало с А4? как в и 7 версии только D, без А? или картинка — фотошоп от 6 версии? ))
- хватит заливать проблемы увеличением ресурсов контроллера (минимум памяти увеличили, наверняка и проц другой будет), лучше оптимизируйте свой софт. уже сколько лет везде плачут что ваш же wb-rules "из коробки" без настроек пользователя проц жрёт как не в себя
- не стоит каждый год плодить новую версию контроллера, вы ж не эппл чтоб такое себе позволять, а после прочтения хвалебного поста про изобретение WB-USB485 (да и поличному опыту обмена) понимаешь что первые полгода вообще новые устройства лучше не брать, т.к. там прям гарантированно будут проблемы и будут появляться новые ревизии железа их устраняющие...
мне очень нравится сам контроллер WB с версии 3.5, но накипело!
В 7.4 будет A1-A4, как и в 6.x.
Картинка - фотошоп конечно.
вопрос в другом и про 8.х а не про 7.4
в 6.х А1-А4 настраиваются AI\DI\DO
в 7.х без внятного объяснения сделали A1-A3 AI\DI\DO а вот A4 только DI\DO
в 8.0 что в итоге будет?
без внятного объяснения
каналов АЦП в процессоре не хватило, куда уж более внятно.
WB8.x делается на базе WB7.4, и в том и в другом будут аналоговые входы на A1-A4.
а что поменялось в 7.4 по сравнению с 7.3 что стало хватать АЦП внезапно?
Добавили Embedded контроллер, который теперь управляет питанием контроллера и у него на борту есть свой довольно точный АЦП.
Мы в WB7 убрали A4 не от хорошей жизни. Он проектировался в 2021м году, когда с компонентами было сложно и в тот момент решение отказаться от ещё одного дефицитного компонента казалось верным. По этой же причине и пропал второй USB — хабы было сложно купить.
Ну а почему перестал выпускаться WB6, мы рассказывали весной прошлого года, хотя планировали производить ещё как минимум год: https://wirenboard.com/ru/pages/wbce2022-report-wb/
внутри теперь есть отдельный МК (у нас называется Embedded Controller), который управляет питанием. Аналоговые входы тоже заведены на него.
В линуксе, естественно, всё это скрыто: клиенты как читали готовые вольты из MQTT (ну или /sys/bus/iio), так и будут. Даже все пути и форматы остались те же.
1) А что вы подключаете к USB-A в контроллере? Это правда интересно, мы не особо понимаем применение даже одному порту. Кнопка FW снаружи выведена, чтобы монтажники в полях в рукавицах могли втыкать флешку с прошивкой и обновлять контроллеры, ничего не разбирая.
2) A4 вернётся уже в WB7.4, ещё и сами входы станут точнее
3) А какие проблемы? wb-rules на чистом WB7 сейчас потребляет ну процентов 5 процессора. Если там куча правил написана и куча каналов опрашивается, то может и больше потреблять, но тоже не половину.
Ресурсы контроллера увеличиваем в первую очередь ради стороннего софта: HomeAssistant, разное коммерческое стороннее ПО. Плюс такие системы покупают обычно на многие годы эксплуатации, и, поэтому, запас по ресурсам очень нравится клиентам.
4) По-моему эппл очень даже хороший пример для подражания :) На самом деле WB7 вышел в декабре 21-ого, а WB8 планируется в декабре 23-его, это два года разницы.
5) Про первые полгода и хвалебный пост: ну так про проблемы вы знаете, потому что мы про них пишем посты и ведём публичную еррату. Да и ревизии мы делаем, чтобы исправлять найденные проблемы или решать проблемы с доступностью, а не просто разводить руками.
Не брать новые устройства первые полгода - это ваше право, но даже с этой стороны получается, что чем раньше мы устройство сделаем, тем раньше первые полгода пройдут :)
открою страшную тайну, если идти в промышленную автоматизацию, то там дофига железяк, который дают подключение по usb и по факту у них обычный usb-serial чип, который подхватывается ядром линуха и даёт обычный ttyUSBx интерфейс, через него можно прекрасно опрашивать это устройство. тут и экономия на внешнем интерфейсе для этого устройства (есть ещё производители которые за него отдельные деньги хотят), и ускорение опроса
так же ups подключить очень полезно, я подключаю usb ble свисток для получения данных с ble датчиков. с встроенным ble проблемы есть, даже в 7.3 (хоть и редко стало), но всё ещё есть, а вот с внешним свистком — вообще ни разу проблем не было…
и серьёзно, монтажник в поле в рукавицах обновляет прошивку контроллера???
тут я вижу два варианта, или этим вы признаёте что прошивки\софт кривой и его приходится достаточно часто обновлять в поле, или бурно фантазируете
в реальной жизни или всё работает и его никто не трогает, или на объект едет специально обученный человек с ноутбуком и без руковиц
всё для удобства клиента! есть типовой проект, рассчитано на железку с одними параметрами, потом тебя ставят перед фактом — всё, теперь вот так и старых железок не будет, ты тратишь время, переделываешь, доставляешь модули\шмодули и тут на тебе — теперь всё как было.
да ладно, 5%??? из принципа найду свободный 7.3 со стоковой прошивкой и покажу вывод что это не так.
тот же НА у меня на 6е на даче прекрасно работает. да, старт дико долгий, но потом когда всё закешировалось не более 35%, на 7е старт быстрый и 7-18% загрузка проца
вот пример с 7.3.1
и что такое делает это wb-rules, а он не трогался тут совсем, вообще, ничего пользовательского нет?
ну сказать… мемчик есть про это — "ни… я нового, но стоить будет в 2 раза дороже"
и если подрожать — то тому что у них софт очень сильно оптимизирован под железо, само железо зачастую слабее чем у конкурентов, но софт решает!
про проблемы я знаю не только из поста, а из за того что покупаешь новую железку, т.к. старая уже не производится и её нет на складе, и тут же ловишь проблему, например с каном, узнаешь что это подтверждённая проблема и надо менять.
по хорошему — вам бы внутри тестить лучше, а ещё лучше отправлять тестовые образцы своим основным заказчикам и интеграторам на тесты, так шансы узнать о проблемах выше, чем начать продавать и потом получать негативный фидбек. но, как вы говорите, это ваше право, использовать конечных пользователей как дешевых тестеров (вы платите только за две пересылки)
открою страшную тайну
ну так может вы всё-таки напишите примеры реальных устройств, которые вам нужно подключать? Мне не надо страшную тайну открывать, мне нужны сценарии использования. Дальше мы на них смотрим и думаем, как улучшать продукт.
и серьёзно, монтажник в поле в рукавицах обновляет прошивку контроллера???
тут я вижу два варианта, или этим вы признаёте что прошивки\софт кривой
О господи. Мы: сделали обновление прошивки удобнее. Вы: 'ага! то есть признаёте, что софт кривой!". Ну зачем так?
Кстати у нас можно собирать готовые образы прошивку с нужным клиентским софтом и конфигами. Часто клиенты эти прошивки делают после отгрузки, часто что-то в них меняют. Если залить это может любое щитовое производство или любой электрик без специального образования, ноутбука, кабеля, софта и т.п. - это удобно.
всё для удобства клиента! есть типовой проект, рассчитано на железку с одними параметрами, потом тебя ставят перед фактом — всё, теперь вот так и старых железок не будет, ты тратишь время, переделываешь, доставляешь модули\шмодул
В феврале 2022-ого кое-что случилось, из-за этого продавать старый WB6 до последнего клиента мы не могли. Но продавали, по-моему, вплоть до июня: времени купить было достаточно.
Зато мы умудрились переделать всю логистику и перенести производство проц. модуля в Россию, и контроллеры (уже WB7) поставлялись без перерывов. Приоритетом было именно это, по-моему это лучше, чем сохранить 100% совместимость, но отправлять клиентов ждать поставок год или пока NXP снова начнёт i.mx6ull в РФ возить. Этого бы пришлось ждать долго.
По внешним интерфейсам в WB7 отличие в меньшую сторону было только по количеству аналоговых входов. Это коснулось очень мало кого, но если вас всё-таки коснулось - это действительно неприятно.
и и тут на тебе — теперь всё как было.
подождите, но ведь если кто-то не столкнётся с теми же проблемами, что и вы - это хорошо, а не плохо? Вроде как надо радоваться за коллег, а не наоборот.
ну сказать… мемчик есть про это — "ни… я нового, но стоить будет в 2 раза дороже
Новый WB8 будет дешевле WB7 в такой же конфигурации, потому что там используется более новая и дешёвая память LPDDR4.
ну так может вы всё-таки напишите примеры реальных устройств
конкретно — контроллеры управления дизельной электростанцией, насосом, турбиной. модель не принципиальна, важна суть, что внутри usb преобразователь на базе cp210x или подобного и ядро его видит и даёт ком порт, через который можно по модбасу устройство опрашивать. реальный кейс, тот же apc ups, чтоб с него данные снимать, а не ставить модуль mod-rs232 и через него читать. ble usb stick… но я уже повторяюсь...
часто что-то в них меняют
это не ответ на вопрос — как часто на рабочем и сданном объекте меняется прошивка?
когда идёт отладка и пусконаладка — понятно, но это всё не в поле, а на столе делается и тут можно и шнурком подключиться (даже если в поле), а вот именно в поле как часто это делается? у вас есть статистика, или это смелое предположение что ну очень нужно?
это мне сейчас напоминает старую дискуссию про переход на usb-c разъёмы (вроде как все переходят на него, но многие именно промышленные железки как имели на борту usb-b так и имеют и не понимаю про что речь) и аналогично про usb-c разъём аля-сетевая карта. было объяснение что очень удобно, подключился и вот тебе сетевой интерфейс в системе… ну такое себе… и снова — как часто это используется в поле? на столе — да, для дико ленивых у кого нет usb-ethernet конвертера и лишний провод пугает — это вариант, а в остальном...
мысль посетила — сделайте на сайте у себя голосовалку, по типу "вот функция обновления прошивки с usb носителя", и вопрос "использовали ли её после сдачи объекта" + ответы "ни разу", "один раз", "постоянно". так же с usb сетевой и другими моментами, дико интересно посмотреть результаты, может действительно это дико востребованные за пределами вашего офиса функции.
Зато мы умудрились переделать всю логистику и перенести производство проц. модуля в Россию
тут молодцы, можно только порадоваться и признать что работали оперативно и на уровне
Новый WB8 будет дешевле WB7
посмотрим, хорошо если будет так!
а пока почитал новость про разработку 7.4 и две фразы заставили задуматься:
Останутся четыре универсальных входа-выхода A1-A4
PoE через модули расширения. По умолчанию PoE больше нет
не шаг ли это в сторону "оголения" контроллера, когда будет "дешевле" продаваться "пустая" платформа, а все остальное (что есть и к чему привыкли) исключительно в виде доп модулей за доп деньги?..
Про обновление с USB. Да. Это реально часто используется. Живой кейс: многоквартирные дома. Где есть XX вариантов настроек для каждой из XX "комплектаций" квартир.
И монтажник, подключив оборудование - заливает в контроллер готовый образз именно для этой "комплектации", просто вставляя одну из XX флешек со связки.
так прошу прощения — это процедура заливки образов — постоянная операция в процессе эксплуатации, или же всё таки "монтажник" и "подключив оборудование" это делает один раз?
разницу в частоте использования чувствуете?
если он один раз при установке оборудования это делает, то можно и крышку снять для нажатия на кнопку
а если это происходит раз в неделю или типа того — то уже проблема в другом и надо её решать иначе..
По разному, к сожалению. Не у каждого интегратора есть понимание как оптимально оркестровать хосты. Ну и вообще осознания такой необходимости.
Да, я бы сделал проще. Монтажник подключает контроллер (адрес получается по dhcp) и сообщает его серийник (например) диспетчеру. Тот указывает в базе соответствие номера (или типа) квартиры-серийнику и ansible (например!) проводит настройку.
по хорошему — вам бы внутри тестить лучше
Тестировать лучше - это всегда полезно, мы тратим на это много ресурсов. Недавно, например, внедрили автоматизированные интеграционные тесты полного набора ПО контроллера на железках, в дополнение к обычным юнит-тестам и интеграционным тестам отдельных сервисов.
То, что доходит до клиентов и ерраты - это обычно уже фатальная комбинация нескольких маловероятных причин. Мы стараемся на такие штуки делать 8D-отчёт и вносить изменения в процессы.
На примере проблемы с CAN: отдельно проверили и поменяли трансивер, отдельно вносили изменения в схему - пропустили разные уровни. Специальный автоматизированный тест CAN все устройства проходили. Сдерживающие меры там еррата, отключение CAN в софте, отзыв и гарантийная замена контроллеров; а корректирующие - изменения в процедуру замены компонентов и явная проверка уровней внутри при тестировании образцов новых ревизий.
а ещё лучше отправлять тестовые образцы своим основным заказчикам и интеграторам на тесты
Мы двумя руками за, но как вы правильно заметили, наши клиенты не очень любят быть тестерами. К сожалению, редко кто соглашается проверять новые железки, а если и соглашаются - отзывов обычно очень мало и они приходят очень поздно.
Так что мы надеемся только на свои силы в тестировании.
А как арбитраж в процессе сканирования работает на физическом уровне? Ведь это не CAN или 1W, где есть явно выделенные доминантные и рецессивные состояния шины. В RS485 состояния равноправны, и если выходной драйвер включен, он будет очень настойчиво подтягивать шину к желаемому состоянию. Кроме того, в этот момент устройство не может принимать.
Получается, арбитраж должен работать не на уровне UART протокола, а ниже - например, устройства с нулевым и с единичным битом серийного номера должны передавать этот бит в разное время, чтобы не возникало конфликта и было время послушать остальных. Вот интересует, как именно эту проблему решили.
В статье было описание протокола, может пропустили. Если очень кратко, то на каждый бит там выделено временное окно чуть больше одного байта. В этом окне рецессивное состояние - это отсутствие передачи (idle), доминантое - передача 0xFF. Это занимает больше времени, зато не требует ни переделки железа, ни необходимости работать на уровне битов. Для мастера (ПЛК) к тому же нет и требований по таймингам, поэтому он работать может на любом железе, ОС и за шлюзами.
Интересно, как это будет работать с USB - RS485 конверторами?
Если ПЛК (мастер) подключен через USB-RS485, то прекрасно работает: он в арбитраже не участвует, требований по времени к нему нет.
Я про то, что у USB-RS485 вы не сможете задавать тайминги на уровне бит/байт как в ПЛК, соответственно ваш протокол прибит к вашей же аппаратной реализации. В этом нем ничего удивительно, так как вендорлок, это один из способов защиты своей поляны. Просто он не совместим со "стандартным Modbus", как вы пишите в статье.
До вендор-лока еще очень далеко, потому как для реализации слейва достаточно любого МК.
В том числе и в случае с USB-конвертером, никто не мешает этому МК отвечать на арбитраж аппаратно (где тайминги важны), а все остальное делегировать хосту.
Всё правильно, не сможем. Но это не нужно, здесь у ПЛК (мастера) нет необходимости выдерживать какие-либо тайминги. Работает и через переходник, и через шлюз, как угодно.
Вот прямо сейчас запустил с ноута референс-сканер из репозитория через USB-RS485 - работает.
вендорлок
Сейчас у нас в опенсорсе не только полные спеки, но и простая референсная реализация на C, и наш настоящий сервис, который работает на контроллере. Это более чем достаточно для поддержки протокола в своём софте на ПЛК/компьютере.
Библиотека для МК пока доступна для партнёров за деньги, но там роялти 100р с устройства и это явно сильно меньше, чем мы зарабатываем, продавая свои. Так что это явно не ради вендорлока делается.
Если уж Modbus, то TCP.
Вообще же, как по мне, то тот же Profinet намного удобнее.
У Modbus TCP, профинет и прочее это банально очень дорого. Хороший трансивер RS-485 стоит $0.2, хороший МК с UART стоит $0.65. Ethernet - это сразу МК от $1.0, физический уровень от $0.7, трансформаторы и разъём ($1). Ещё всё это занимает место на плате, разъёмы увеличивают габариты корпуса, а клиенты вынуждены ставить шкафы со свичами и коммутировать всю систему звёздочкой. Какую это создаёт ценность для пользователя? Заплатят ли они нам больше денег, если мы так сделаем?
Поэтому решение мне кажется надуманным. Сами придумали якобы проблему, сами её решили. Все равно эти устройства не смогут передавать одновременно, чтобы сократить время ответа, а арбитраж шины, это тоже время.
У шины Модбас, когда в ней работают более двух сотен устройств, проблема не со скоростью ответа от каждого из них, а с назначением адресов для каждого устройства (в том числе, возможные дублирования адреса в случае ошибок при конфигурации).
Все равно эти устройства не смогут передавать одновременно,
расширение протокола для того и сделано, чтобы передавало только то устройство, которому есть что передать. Если это снижает трафик на шине в сто раз и данные приходят за 50мс, то что в этом плохого?
проблема <...> с назначением адресов для каждого устройства (в том числе, возможные дублирования адреса в случае ошибок при конфигурации)
А это мы тоже решили, тоже есть в статье и в протоколе:
быстрое сканирование находит без перебора все устройства, даже с дублирующимися адресами
адресация по уникальному длинному серийнику позволяет поменять Modbus адрес при конфликте адресов
расширение протокола для того и сделано, чтобы передавало только то устройство, которому есть что передать. Если это снижает трафик на шине в сто раз и данные приходят за 50мс, то что в этом плохого?
В снижении трафика ничего плохого нет.
Вот только "есть что передавать" может относится к каким нибудь умным устройствам, которые сами решают, есть данные для передачи или нет. Но это частности, а в общем случае считывается текущее значение с контроллера, которое есть всегда (например, чтение регистра).
А адресация по длинному серийнику, это уже не совместимое с Modbus расширение протокола. (которые делают практически все, кому это действительно требуется)
в общем случае считывается текущее значение с контроллера, которое есть всегда (например, чтение регистра).
Ну вот если значение регистра не изменилось с последнего опроса, то его и не надо отправлять. Всё очень просто, никакого особого ума у устройств не прибавилось, а работает сильно быстрее.
А адресация по длинному серийнику, это уже не совместимое с Modbus расширение протокола.
Эта адресация нужна только на этапе пусконаладки или вообще сборки щита, только чтобы расставить адреса.
Ну и что значит несовместимое? Естественно, если чего-то в протоколе не было, то и устройства сделанные давно это не поддерживали и работать так не будут.
Но даже это расширение совместимое с Modbus по протоколу: там зарезервированный адрес получателя + код функции для vendor-specific use + модбасовская контрольная сумма. А вот уже в полезной нагрузке сам серийник и прочие команды. Т.е. незнакомое с этим расширение устройство или ПЛК обязаны его распознать как валидный Modbus фрейм и проигнорировать, потому что это сообщение не для них, да и соответствующую функцию они не поддерживают. Шлюзы должны это как валидный Modbus-фрейм передавать дальше.
В быстром Modbus мастер просто спрашивает: что у кого есть нового?
Окей. Мастер спросил "у кого чего нового" и затем пропустил либо не зафиксировал чей-то ответ. Как произойдёт исправление этой ошибки?
Там есть подтверждение приёма
а что за аналоговый сенсор - по виду металл боченок с 3\8 резьбой, левый верхний угол картинки аналоговых устройств ? Датчик давления ? Можно про него ?
Эту картинку рисовал я, но очень давно. Модель не скажу, но это был датчик давления на 4...20 мА.
Интересно про арбитраж:
" Подробнее можно прочитать в открытой спецификации.
Все устройства начинают отвечать одновременно, но при этом они понимают, что не одни на шине. И выигрывает арбитраж (право отправить сообщение) то устройство, у которого меньше серийный номер."
Правильно понимаем, что если кто то другой сделает устройство с такой же спецификацией... у него будет свой отчёт серийных номеров.
И если пересечение с одним "сторонним" производителем ещё как то достаточно сложно найти одинаковые номера,
то в случае если такую спецификацию начинают использовать "маленькие разработчики" штучных устройств с серией меньше 100, то тут уже пересечений серийников у разных производителей может быть уже достаточно много. что нивилирует преимущество открытости спецификации ? или оно как то решается другим образом?
Наш план - просто выдавать блоки серийников для организаций и очень маленькиме блоки для очень маленьких разработчиков. Битов там много, на всех хватит.
Наверно тогда и эта таблица выданных блоков должна быть открыта и постоянно обновляться? ;)
Хотя я почти понимаю логику WB - что открыто а что нет, и логику формирования того что открыто а что нет. Когда нибудь надо будет засесть и поспрашивать.
Наверно тогда и эта таблица выданных блоков должна быть открыта и постоянно обновляться? ;)
Ну сейчас-то в таблице одна запись. Большой ценности в публичной таблице префиксов нет, нам наоборот важнее мотивировать производителей регистрировать префиксы, чтобы они не пересекались. А открытая таблица мотивирует выбрать себе префикс самому.
Вообще первым делом мы наверное выделим явный публичный префикс для DIY, т.к. вряд ли одна DIY железка окажется в одной сети с другой.
И выигрывает арбитраж (право отправить сообщение) то устройство, у которого меньше серийный номер.
принцип как в I2C, или как-то иначе? Т.е. молотим на шину, у кого первый нулевой бит, тот и проиграл?
Когда количество произведенных устройств перевалит за 4млрд мы будем вопервых очень рады. А во вторых просто сделаем новую команду сканирования в которой арбитраж будет происходить по еще более длинному серийнику.
Извините за лень, но запросы "ты кто" и "что нового" получаются широковещательные?
Мы на шине, типа открытого коллектора, использовали свой протокол поиска, взяв за основу алгоритм поиска 1-Wire. Всё устройства изначально не имеют короткого адреса. Неадресованные устройства отвечают на специальную команду проверки наличия неадресованных устройств зажимом линии к земле на некоторое время. Главный контроллер ожидает спада линии в течении некоторого времени. Если зажим линии произошёл, значит начинается процесс опроса битов серийного номера. Главный шлёт запрос с номером бита серийника. Если ответ зажимом линии произошёл, значит у кого-то на шине он равен нулю. Если ответа нет, значит единица. В зависимости от ответов, формируется серийник, которому посылается команда назначения адреса. Получив адрес, такое устройство становится адресованным и больше не отвечает на запрос наличия неадресованных устройств на шине. Поиск заканчивается после того, как прекратятся ответы на запрос наличия неадресованных устройств. Так как шина поддерживала горячую замену устройств, главный контроллер периодически посылал запросы в шину о наличии новых устройств.
это правда, что WirenBoard отдает аналоговые переменные по OPC UA только как float двойной точности (double) и это никак не изменить в настройках ?
А будете ли вы выпускать WirenBoard на RISC-V ))))?
Мастер отправляет один запрос с просьбой всем устройствам ответить, а устройства последовательно отвечают мастеру и сообщают информацию о себе.
В RS485 если 2 устройства будут одновременно отвечать, то возникнет коллизия.
Как устройство с наименьшим адресом 0x00F00D00 в данной шине узнает, что оно должно отвечать первым?
Технически это коллизия и будет. Но изза того что несколько устройств почти одновременно передают один и тотже байт с точки зрения электричества это не страшно. А с точки зрения протокола все передачи доминантные. Все молчания рецессивные. К томуже если устройство желает передать данные, но произошел рассинхрон и приемник обнаружил чужой стартбит, то передачи даже не будет. Зато все кто передавать не планировал точно узнают была в этот момент передача другими устройствами или нет.
Все устройства начинают отвечать одновременно, но при этом они понимают, что не одни на шине. И выигрывает арбитраж (право отправить сообщение) то устройство, у которого меньше серийный номер. На примере выше три устройства начали передавать информацию, и в какой-то момент они понимают, что серийный номер больше, чем у соседей.
Вы что сделали программную реализацию UART на GPIO+HW Timer, чтобы была возможность после каждой установки бита на проводе UART_TX проверять, что показывает обратная связь на проводе UART_RX?
Тогда да, в случае несовпадения выставленного бита с прочитанным можно переключить RS485 трансивер в высоко омное состояние.
Достаточно очевидная идея. С таймером пришлось конечно заморочится. Однако с GPIO мы поступили проще. В качестве доминантного/рецессивного слота используется сам USART фрейм который просто передает FF в случае доминантного бита или молчит в случае рецессивного. Немножко теряем время, зато используем все аппаратное и не морочим голову приемнику на стороне линукса. несколько фреймов FF в начале он без проблем отфильтрует.
Вы случайно не пробовали реализовать вот этот алгоритм
https://habr.com/ru/articles/752292/
сканирования адресов в RS485?
нет не пробовали. у линукса (который выступает мастером) очень сложно делать вещи вроде 'мастер переводит пин UART_RX в GPIO input', мы старались сделать так чтобы мастер оперировал лишь уартом. ито не критичным ко времени.
Однако, на самом деле не обязательно переключать функции GPIO c UART на GPIO. Если у Slave(ва) адрес совпал с маской, то он может прижать шину просто отправив несколько раз 0x00. Мастер увидит это как принятие пакета с неправильной контрольной суммой или UART периферия выдаст прерывание по Overrun и поймет, что это ACK сигнал на маску.
вышла новая статья в которой в том числе описана физика работы шины 485 и там объяснено что такое увы не работает. физика не позволяет "прижать шину"
Тут коллеги-автоматчики пощщупали WirenBoard и ужаснулись высказали ряд замечаний.
Основное - не планируется ли к выпуску модификация с предустановленным CodeSys (или аналогичной средой разработки на базе языков IEC 61131-3) ?
Чтобы полностью скрыть от прикладного программиста Linux'овые внутренности контроллера, и дать программисту-автоматчику возможность сразу начать работать в привычной для него FBD-подобной среде разработки?
Контроллер в металлическом корпусе, быстрый Modbus и другие новости