Форум РадиоКот

Практики АСУ, прошу советов...

1. Какой супрессор лучше ставить на входе питания?
Стандарт оговаривает питание 5...24в, допуски не указаны.
1.5KE33A - уже страшно за 78M05/78L05.
1.5KE30A - может подкоротнуть, если напряжение будет близко к 30в.
Или LDO сменить, но тогда на какую? Что бы в любой подворотне продавалась, имела версии хотя бы 3.3, 5, 12в.

2. Дефолтный Slave address в стандарте не указазан.
Читал что "Многие устройства поставляются с завода со slave address = 1, не назначайте этот адрес рабочим устройствам", насколько это правда и "хорошая практика"?

3.
MODBUS over Serial Line Specification and Implementation Guide V1.02
3.2 Data Signaling Rates
Требует реализации 9600 и 19200, 19200 требует ставить по дефолту.
При этом в
5 Implementation Classes
Минимальная реализации 9600, если 19200 реализовано (Что??? Уже не обязательно?) - дефолтная скорость 19200.
Так какую скорость лучше ставить дефолтной? Как там у большинства устройств с завода?

4. Распространенные ОС, не способны контролировать при передаче и измерять при приеме межбайтные интервалы RTU.
Программы полагаются на логическую структуру, но это уже не стандарт а самоходный гусеничный костыль.
Мост на ASCII (или TCP), единственно верный путь самурая, или есть еще какие то реализации?

5. Есть какие то стандартные/общепринятые реализации проброса I2C и подобных шин поверх Modbus?

1 - Смысл ставить на входе питания, когда почки отказали защищать надо информационные линии? Или вы там ещё питалово вытащили в интерфейс? Ну а по линиям в приличном обществе ставят хотя бы SM712. Есть и более навороченные защиты, но это уже сами прогуглите, если требуется.
2 - хорошая практика делать - его перенастраиваемым удобно и легко. Самый универсальный вариант - ставят "пианино", на котором можно "наиграть" в бинарном коде от 1 до 254 хотя бы, а комбинацию "255" обзывают как "юзерский адрес". Который настраивается прямо через сам MODBUS через специальный регистр. Так будут довольны и любители железных настроек, и полностью удалённого управления. Ну и можно будет откатить девайс на известный адрес, если софтово настроенный вдруг позабыли совсем.
А все остальные "правила" - в общем-то блажь конкретных производителей.
3 - чем больше заложите вариантов, тем лучше, юзер вам спасибо скажет. И сделайте скорость настраиваемую через этот же самый MODBUS. На практике у юзеров самые разные предпочтения, одни любят помедленнее, 1200 им подавай. Другим и 115200 мало.
4 - на практике ощущение создалось такое, что на всю эту времянку не забивают только старые буржуйские ПЛК. Остальные как-то не парятся. Мост такой можете намутить и сами, mbusd вроде бы времянки проверяет. Но вообще, если есть возможность, лучше исходить из того, какой именно девайс будет стоять мастером совместно с вашим прибором, и непосредственно с ним в связке тестить. Некоторые, по опыту скажу, очень любят бомбить ваш девайс запросами, как бешаные. Так что тестируйтесь и в таком режиме. Из неплохо зарекомендовавшего себя для этого порекомендую ModbusMaster. Прога немного кривая, но люто быстрая, и в этом её фишка. Но сразу предупреждаю: со всякими USB-переходниками ставьте Timeout не менее 20 мс, на любой скорости! А то будут сбои на ровном месте, потому что переходник не справится. С "железным" RS-232 + переходник на RS-485 можно изгаляться пожёще.
5 - конечно же нет. Там даже на проброску float никаких стандартов нет, ибо замшелое легаси.

1. Я про питание маломощных устройств от линии, 4-проводка.
Это проще и безопасней, особенно если они ни с чем более не соединены.

4. У меня ведомый контролирует межбайтные и межпакетные интервалы (прошивку писал сам), за несколько лет на 9600 - ошибок не замечено.
Мастер - FreeBSD с libmodbus из портов, USB переходник на CH341.
Но все это, в какой то момент, конечно же может начать глючить, если ОС вдруг решит отправить пакет не одним куском, ни кто ни чего не гарантирует.

С адресом проблемы не будет, если устройство поддерживает стандарт: достаточно подключиться к устройству напрямую и дать широковещательную команду установки адреса. Потом - "стучаться" уже по этому адресу... Главное - правильно стандарт поддерживать, а не как китайцы (которые в некоторых устройствах вообще не реагируют на широковещательные команды, а в некоторых - шлют на запросы с ID=0 ответ!).
Что до скорости, некоторые микроконтроллеры умеют в "автонастройку" бодрейта. Так иной раз даже удобней, чем фиксированную скорость задавать.
С таймаутами заморачиваться не нужно: только очень старые устройства, которые действительно были на телефонные линии рассчитаны, требуют четких таймаутов. Я в STM32 просто по IDLE конец пакета распознаю. А на ПК нужно в зависимости от бодрейта выставлять время ожидания в select().

Но, если есть возможность вместо этого дерьма использовать CAN, лучше вообще с модбасом не связываться! Унылое древнее говно.

~Dimon~ писал(а): Вт сен 08, 2026 10:35:21ОС вдруг решит отправить пакет не одним куском

С чего бы вдруг? Если порт аппаратный, то гарантированно куски до 4кБ размером будут отсылаться атомарно. Вот если целиком посылка в буфер не влезет, то возможны и задержки. Но я сильно сомневаюсь, что задержка будет заметна на таких черепашьих скоростях (вы ж не на 3Мбод работаете).
Другое дело - USB-переходник. Там всякое возможно. Но чаще всего меньше 32Б буферы не делают. Т.е. для большинства нужд достаточно будет. Если нет - можно на том же STM32 или каком угодно другом МК сделать свой переходник USB-модбас, где заложить буфер нужного размера. Получил по USB полностью пакет, дернул DMA, и "одним куском" отправил. А при приеме, как я уже выше говорил, по IDLE определять конец пакета. Заодно и CRC можно на МК считать, чтобы упростить работу с железяками из терминала напрямую (хотя, мой tty_term вполне себе сам контрольную сумму в режиме модбаса считает).

~Dimon~ писал(а): Вт сен 08, 2026 10:35:21 1. Я про питание маломощных устройств от линии, 4-проводка.
Это проще и безопасней, особенно если они ни с чем более не соединены.

Довольно спорное и ситуативное утверждение. "Если с той стороны источник питания хороший, чистый, гальванически изолированный от всего". "Если проводка качественная, но при этом не слишком длинная". И ещё ряд всяких "если". Вообще в приличном обществе, по возможности, ставят не КРЕН-ку наружу входом торчать, а изолированный DC-DC модуль достаточной мощности, обвешивая его по входу цепочками из фильтров, варисторов и супрессоров. Иначе требования ЭМС не пройдёте! Диодный мост по входу тоже лучше поставьте. Чтобы юзеру не загоняться о полярности питания.

Зачем изолировать питание, без изоляции линий данных?
Если полная развязка - тогда да, изолированный DC-DC, но нужно что то популярное и вечное (физический формат модуля), что бы при ремонте через 10...15 лет, можно было легко найти аналогичную замену, не пускать вход бубен, клей, и провода.

linux_rulezz писал(а): Вт сен 08, 2026 10:46:34 С чего бы вдруг? Если порт аппаратный, то гарантированно куски до 4кБ размером будут отсылаться атомарно.

8250 и 16450 не имели FIFO, у 16550 оно всего 16 байт, переходники - там как реализуют..., но у USB 1/2 вроде максимальная транзакция 64 байта?
Главное, если в документации на write(), или чем там байты отправляются, нет гарантии что они будут отправлены неразрывно, то гарантии нет, хотя обычно проблем не возникает.

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

USB 1/2 вроде максимальная транзакция 64 байта?

Размер транзакции значения не имеет. Все равно данные сначала накапливаются в буфере, а затем отправляются по последовательному порту...
Вот все и зависит от реализации конкретного переходника.
А транзакция - у меня и по 10 байт были, когда я на одном STM32F103 семь CDC замутил (восемь не выйдет, т.к. контрольную точку нужно всегда иметь). Буфер под конечные точки отдельный, поэтому особо не разгонишься.
Из готового могу ссылку на свое дать: делал на F303 "многоинтерфейсную" плату (три изолированных 485, два изолированных 232, один изолированный CAN и один изолированный 422 или SSI). Т.к. все возможные конечные точки задействованы, то для конфигурации у меня предусмотрена перемычка: если ее снять, появится CDC-интерфейс для конфигурирования устройства (начальная скорость CAN-шины, поля для iInterface - чтобы были /dev/что-то-тамX, а не /dev/ttyACMxx..).

~Dimon~ писал(а): Вт сен 08, 2026 13:39:57 Зачем изолировать питание, без изоляции линий данных?

Очевидно за тем, чтобы в случае проблем с первичным питанием ничего такого гарантированно не прилетело в интерфейс. И чтобы всякие паразитные "земляные петли" не образовывать с интерфейсом. А то потом будете ловить "разрывы" на ровном казалось бы месте. Впрочем, понятное дело, что всё это ситуативно. Если вы прям точно-точно уверены, что отсутствие гальванразвязки ничего не испортит, то в чём проблема? Но жизнь-боль настойчиво подсказывает, что как правило лучше перестраховаться.
И само собой, если ваш девайс смотрит наружу не только питанием и MODBUS-ом, изолировать трансивер интерфейса тоже, как правило, приходится!

~Dimon~ писал(а): Вт сен 08, 2026 13:39:57 Если есть какие то популярные реализации?

Мм...что-то типа этого? Сам собирать в жизни не пробовал, просто нагуглилось.

Вспомнилось.
Переходники 232-485, могут использовать RTS для включения передатчика.
Не все ПО поддерживает данный метод, но он хорошо известен.
А вот более-менее стандартного способа сигнализации о границах пакета в сторону хоста, вроде бы нет?
Я могу своим переходником подергать CTS или DCD например, но это будет уже моя частная реализация, ни одна чужая программа этого не поймет.

~Dimon~ писал(а): Пн сен 07, 2026 20:33:44Мост на ASCII (или TCP), единственно верный путь самурая, или есть еще какие то реализации?

Единственный верный путь: Вообще отказаться от Modbus-RTU. Тем более, если речь идёт о работе напрямую с ПК, а не между 2-мя какими-то вашими устройствами.

Что-ж этот ущербный Modbus как мёдом намазан??? Что каждый начинающий сразу тащит его... Есть же нормальные протоколы, работающие с любыми задержками в канале.

~Dimon~ писал(а): Вт сен 08, 2026 10:35:21если ОС вдруг решит отправить пакет не одним куском, ни кто ни чего не гарантирует.

И отправит.
Единственное верное решение тут: Писать свой драйвер. Уровня ядра. В котором жёстко контролировать времянки. Если уж так нужен этот Modbus.
Иначе это будет ловля падающих ножей: поймал, не поймал, в ногу воткнулся....

~Dimon~ писал(а): Вт сен 08, 2026 17:04:46А вот более-менее стандартного способа сигнализации о границах пакета в сторону хоста, вроде бы нет?

Если так хочется именно Modbus-RTU и не хочется писать драйвер ядра, то можно сделать свой отдельный девайс. Мост между Modbus-RTU и ПК. Между этим устройством и ПК кадры передавать в каком-то нормальном протоколе. Т.е. - сделать трансляцию протоколов.

Да, но это "частная реализация", ни одна чужая программа не поймет.

jcxz писал(а): Вт сен 08, 2026 17:26:52 Что-ж этот ущербный Modbus как мёдом намазан???

Согласен, что RTU реализован дурацки, видимо это было во времена MS-DOS, когда ПО легко могло контролировать тайминги.
В остальном, мне кажется, что Modbus местными котами сильно недооценен, и именно RTU.
Он очень легко реализуется на микроконтроллерах, обеспечивает пакетную передачу, контроль целостности данных, дистанцию до 1200м.

CAN во многих микроконтроллерах просто нет.
Если у вас одно устройство - можно подцепить его по RS-232 со своим частным протоколом (и не далее нескольких метров).
Потом появляется еще одно - втыкаем еще один переходник, потом третий, потом лопата!
Китайские переходники часто не имеют серийного номера, и devd говорит что у него лапки, ни чем помочь не может, разбирайтесь сами, что вы тут понавтыкали.
Не поднялся первый по счету переходник - все номера устройств tty сдвинулись, не работает вообще все.
На Винде - не в тот USB воткнули - новое устойство, новый COMxx, а в программе другой прописан...
С Modbus этих проблем нет.

CAN во многих микроконтроллерах просто нет.

В 40-50-рублевых STM32F103 есть. Да и вообще, полно ведь МК с поддержкой CAN. Зачем мучиться с этим убогим модбасом? Мало того, что скорость низкая, так еще и мультимастер нельзя в силу "физиологии" 485...
Ну, а что до "втыкаешь USB, и не поймешь, какой из /dev/ttyACMx - твой", то элементарно можно либо использовать стандартные /dev/serial/by-path или /dev/serial/by-id, либо использовать имя интерфейса (которому соответствует индекс iInterface) с правилом udev (можно и не полагаться на него, а тем же libusb искать среди USB-устройств нужное — наверняка, такой способ и в маздае проканает).

Я про то, что два китайских переходника без сериек - различить невозможно, перевтыкал в USB гнезда как то по другому, и все перепуталось.
Это если использовать подключение по нескольким 232.
Если Modbus - переходник может быть единственным, и нет проблем.

Мультимастер на 485 возможен (CSMA/CD, CSMA/CA), даже Modbus наверное можно докостылить, даже не меняя логики ведомых, но это уже нестандарт.
И далеко не всегда оно надо.

Ставить STM32 ради какой нибудь LM75A - то же так себе, тут ATtiny хватит, и питание прямо с шины (4-х проводка), без развязок, это ж термометр просто.

jcxz писал(а): Вт сен 08, 2026 17:26:52 Что-ж этот ущербный Modbus как мёдом намазан???

"А случаи, они бывают разные."© Если вы КИПовец или АСУ ТП-шник, то всякие MODBUS-ы и GPIB-ы вокруг вас были, есть, и ещё очень очень долго будут есть. Потому что вся эта куча аппаратуры на этом построена, и не получится так просто взять всё это и заменить. И в этом контексте, чисто для тренировки на кошках бывает полезно вкорячить его туда, где оно не особо требуется. С другой стороны, если для вас такие заморочки не актуальны, никто не запретит вам делать на чём угодно, хоть на MQTT через WireGuard.

два китайских переходника без сериек - различить невозможно

Для этого есть /dev/serial/by-path: путь зависит от того, в какое гнездо USB воткнута железяка.

~Dimon~ писал(а): Вт сен 08, 2026 17:04:46 Переходники 232-485, могут использовать RTS для включения передатчика.

А помните ли вы схемы, в которых RX-TX переключается автоматом? Есть, например, чипы вроде MAX13487. Могу со своей стороны подтвердить, что в жизни это работает, но только при одному условии: если вы подтяните линии А и В по всем правилам RS-485 внешними резюками, к плюсу и земле. Иначе эти чипы могут жутко сбоить.
Мне лично больше понравилась схема на таймере в режиме перезапуска...уже не помню, где её в первый раз увидел.

Здесь сильно загоняться с подтяжками не обязательно, всё и так будет работать. И понятно, что постоянную времени C1 R4 нужно выбрать такой, чтобы она была с запасом больше длительности передачи байта, но меньше интервала между пакетами.

Знаю про это.
Последовательно с R2 ставят кондер 1нФ, что бы уровни были растянуты до 5в, а терминация нужна на переменке, кондер ей не мешает.
У меня именно так и смонтировано.

linux_rulezz писал(а): Вт сен 08, 2026 19:55:32 Для этого есть /dev/serial/by-path: путь зависит от того, в какое гнездо USB воткнута железяка.

В который раз говорю - можно перевтыкать по другому, и все попутается.
Пьян я может был, или там не подлезешь, куда воткнулось - туда и будет.
Не фатально конечно, можно и конфиги поправить, но это недостаток.