Вопросы по Modbus

[linux_rulezz]

можно перевтыкать по другому, и все попутается

Если это - чужая железяка, то нечего "перевтыкать" по-другому. Каждому переходнику свой разъем USB, тогда будет стабильно по /dev/serial/by-path.
А если железяка своя, то вообще проблем нет идентифицировать. Я для всех своих более-менее свежих железяк в конфигурации даю возможность настраивать название интерфейса, чтобы потом udev-скрипт создавал /dev/[ifacename]_X вместо безликих /dev/ttyACMX с одними и теми же VID/PID.
Втыкаю три своих преобразователя CAN-USB в любые разъемы USB и могу однозначно идентифицировать. Да и не только CAN-USB: я по умолчанию везде в железяках использую VID/PID от ST'шных virtual serial device. Только по имени интерфейса и можно различить.
Отдельный случай - когда в одном устройстве несколько интерфейсов (я уже писал про свою "мультипортовую плату"), здесь единственный вменяемый способ различить интерфейсы - по разным их именам (например, /dev/canusb_0, /dev/rs232a_0, /dev/rs232b_0, /dev/rs485a_0, /dev/rs485b_0 и так далее для всех семи интерфейсов).

Кстати, свой CAN-USB я не так давно хорошо проапгрейдил. Решил: зачем там столько неиспользуемых ног (таки корпус-то 48-ногий!). На плате развел контактные площадки, чтобы ко многим ногам можно было подпаяться. И вторым интерфейсом USB сделал интерфейс работы со всем этим чудом. Можно сконфигурировать АЦП, ШИМ, UART, I2C и так далее. Ну и, понятно, тупым ногодрыгом GPIO. Дипсик неплохой Readme по коду сгенерил, разве что правил я его почти час, т.к. там кое-что он "забыл" упомянуть, а кое-что приврал.

[jcxz]

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

Не понял - какая связь между "дистанцией" и "протоколом связи"???
Или при чём тут "целостность"?
"Пакетную передачу" обеспечивают и все прочие протоколы. И гораздо проще.
А насчёт "очень легко" - это вы приврали. Учитывая то, что во многих МК нет даже возможности отследить реальное окончание символа. И для контроля межкадрового интервала нужно задействовать ещё таймер. А при использовании DMA для обслуживания UART-а, проблем становится ещё больше. На этом фоне любой другой протокол (SLIP, COBS, etc.) - много проще, быстрее и надёжнее. Modbus-RTU - это худшее что можно придумать.
Имхо - большинство начинающих лепят Modbus-RTU по одной единственной причине: Не знают ничего другого.

[jcxz]

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

Вы КИП-овец ТС-а что-ль??
При чём тут что там "вокруг вас"? какая связь? ТС выбирает протокол для какого-то своего девайса.
Да и если насчёт того, что "вокруг вас": SLIP использовался и используется также давным-давно вокруг. И он намного проще и удобнее Modbus-RTU. И не требует плясок с бубном с огромными задержками при работе через разного рода переходники. А значит - намного быстрее Modbus-а. И его можно легко инкапсулировать внутрь других протоколов и каналов связи.
COBS - ещё лучший протокол. Лишён недостатков SLIP. А Modbus-у до него как до Луны

[ejsanyo]

При чём тут что там "вокруг вас"? какая связь?

Ну так это...может потому и выбирает, что именно по работе оно ему ближе, чем всякое новомодное? А не в узости кругозора дело.

[~Dimon~]

Про Abs. max. по питанию в 4-проводке, так ни кто и не ответил
5....24 из стандарта - слишком расплывчато. Исправный импульсник может выдать 25, но если еще какой то гений воткнет напрямую две свинцовых батареи, будет 29.

Не понял - какая связь между "дистанцией" и "протоколом связи"???

Прямой связи нет, но если делать не велосипед, а что то стандартное, то Modbus-RTU/ASCII предполагает 485 или 422, от сюда и связь.
Целостность данных обеспечивает четность и CRC.
Насчет "легко" - это кому как конечно, написал самую простую реализацию RTU под Atmel AVR кажется за вечер.
Конец байта отслеживается по прерыванию, таймер используется, но у меня в большинстве поделок, тик-таймер 1000Гц уже есть, по разным причинам, на него реализация RTU и опирается. С DMA конечно не прокатит, но на кой он нужен, на типичных скоростях 9600/19200? Можно обойтись.

[tonyk]

Исправный импульсник может выдать 25, но если еще какой то гений воткнет напрямую две свинцовых батареи, будет 29.

Вы Стандарты до конца читайте.
Стандартный ИИП для сети =24В выдаёт, обычно, напряжение 21-30В (понятно, откуда такие цифры?), поэтому для промышленных применений DC/DC имеют вход 18-36В. Подавать в длинную линию для питания 5В- глупость. Обычно там 12В или 24В. Дабы не ломать голову, я часто применяю DC/DC с входом 9-36В.

Modbus-RTU/ASCII предполагает 485 или 422,

Вы не путает 2W и 4W варианты 485-го?
422- это точка-точка, а не шина.

[ejsanyo]

Про Abs. max. по питанию в 4-проводке, так ни кто и не ответил

А что отвечать, разве есть какой-то единый стандарт на такие вещи? Когда я делал питалово в том же кабеле, что и RS-485, у меня это вообще было 27В с полной гальванразвязкой. И расчётом на то, что длина кабеля будет до 500 метров, и заказчег может сдуру долбануть туда 500В мегаомметром, когда контролит сопротивление изоляции! А то и все 1500, хоть и недолго! Да и требования ЭМС по критерию А с нас никто не снимал. Как, сможете реализовать, или для ваших условий это слегка избыточно? В общем, делайте исходя из конкретного ТЗ. Или хотя бы ориентируясь на условия, в которых ваш девайс вынужден будет работать.

[tonyk]

Конец байта отслеживается по прерыванию

Дичь какая. Возьмите STM32 с полноценным UART, в котором есть RTO- и забудьте о таймерах. Ещё в полноценных UART в STM32 есть автоматическое управление сигналом направления трансивера. Как вариант, можно использовать трансиверы с автоопределением направления приёма-передачи.
Одно из удобство Модбас состоит в том, что программа получает одно прерывание при приёме фрейма, и два при отправке фрейма, причём ни какие таймеры не_нужны, всё делает аппаратура UART. Но это в случае использования UART с поддержкой Модбас-подобных протоколов.

[jcxz]

Конец байта отслеживается по прерыванию, таймер используется, но у меня в большинстве поделок, тик-таймер 1000Гц уже есть, по разным причинам, на него реализация RTU и опирается.

Во-первых: не во всех МК есть такое прерывание. Во многих есть только прерывание опустошения буфера передатчика.
Во-вторых: Даже на 19200 бод отслеживать нужно интервал = 1/(19200/10) = ~0.5мсек. Даже ещё точнее. Как именно вы умудряетесь его отслеживать при помощи общего таймера на 1кГц?

С DMA конечно не прокатит, но на кой он нужен, на типичных скоростях 9600/19200? Можно обойтись.

На кой все эти ограничения и сложности, если можно взять SLIP или COBS и забыть об этих ограничениях и сложностях? И таймер не нужен и DMA можно спокойно задействовать (когда понадобится) и скорость не ограничивать потому что "так получилось, а теперь уже переделывать поздно".
DMA кстати очень полезен в случае батарейного питания. А вот постоянно колбасящий высокочастотный таймер - вреден.

А ещё можно спокойно запихнуть поток в TCP-сокет (и пробросить через WiFi) или в прозрачный Bluetooth-канал или ещё куда. И не бояться что кадры поломаются. Потому как сегодня нужно одно, а завтра захочется подключить по-другому.
С Modbus-RTU вы себя "анально огородили". Как любит выражаться один из участников этой темы.

[ejsanyo]

Про Abs. max. по питанию в 4-проводке, так ни кто и не ответил

Хотя ладно, на самом деле кое-что есть, конечно, что условно можно подбить под вашу тему. Могу вспомнить, например, требования РМРС (хот и не уверен, что вам это актуально). У вас будет аккум, говорите? Тогда закладывайте для "морских котиков" работоспособность в диапазоне + 30...– 25 % от номиналки. И, если не касаться экзотики и всяких нюансов, вроде криворуких электриков, как уже говорилось, то это практически самый плохой сценарий из реально встречающихся. У атомщиков, вроде бы, требования не такие злые, но вот прямо сейчас ГОСТ не припомню...

[~Dimon~]

Что то вы не то считаете.
По стандарту 8,E,1 или 8,N,2, это 11 бит а не 10.
Пусть будет 19200, длина байта 0,573мкс.
1,5T = 0,86мкс, хотя эти интервалы можно и не отслеживать, зачем?
3,5T = 2,0мс, нет новых байт в течении 2-х тиком - конец пакета.
Для 19200 уже неочень, но для 9600 точно достаточно.
Можно тики чаще сделать, или считывать значения счетчика таймера, что повысит точность на 2-3 порядка если нужно.

Пром. площадка шахты или ЦОФ, где уголь в вагоны грузят - ага, Wi-Fi

[tonyk]

Что то вы не то считаете.
По стандарту 8,E,1 или 8,N,2, это 11 бит а не 10.

Стартовый бит забыли.

Можно тики чаще сделать

А можно взять подходящий МК.

[~Dimon~]

Не забыл, пересчитайте внимательно.
Глянул в исходники, таймаут стоит 5мс для 9600, задается снаружи в тиках.
Для 19200 лучше конечно поднять до 2кГц тики, а то точность так себе.
Выше 19200 стандарт рекомендует фиксированные интервалы 0,75 и 1,75мс (уже независимо от скорости).

МК под решаемую задачу в первую очередь выбирается, а то некоторые тащут STM32 для одного простого датчика вроде термометра, там и 2313 хватит.

[~Dimon~]

Еще мысль, в качестве микро-таймера, можно запрягать неиспользуемые в проекте интерфейсы (I2C, SPI), может даже получится сам USART в режиме передачи "в никуда". Тогда и тики не нужны, надо подумать...

[jcxz]

Что то вы не то считаете.
По стандарту 8,E,1 или 8,N,2, это 11 бит а не 10.

8N1 = 10 бит.

Пусть будет 19200, длина байта 0,573мкс.
1,5T = 0,86мкс, хотя эти интервалы можно и не отслеживать, зачем?
3,5T = 2,0мс, нет новых байт в течении 2-х тиком - конец пакета.

Пускай хотя бы 2 мс - как отследите общим таймером 1кГц?
Вы же по прерываниям считаете?
Фаза прерываний не совпадает ведь с границами символов.

Для 19200 уже неочень, но для 9600 точно достаточно.
Можно тики чаще сделать, или считывать значения счетчика таймера, что повысит точность на 2-3 порядка если нужно.

Не "можно", а "нужно". Иначе - передатчик вправе начать передачу след. кадра через 3.5T. А ваш грубый таймер не позволит определить что первый символ относится к новому кадру, а не продолжение старого.
Ну т.е. - надо всё-таки отдать таймер под это дело. О чём я и говорил - Ресурсов требуется больше для Modbus-RTU.

[~Dimon~]

8N1 = 10 бит.

8N2 по стандарту, если не использовать четность.
В норме 8E1, оба варианта дают 11 бит.

1,5T = 0,86мс. Если в течении одного полного тика, не пришло ни одного байта - интервал точно более 1,5T.
Но отвечать (если запрос вам), надо не ранее чем через 2 тика (2мс = 3,5T).
Все так?

UP:
Точнее, 1 тик мы уже прождали. Нужно подождать еще один тик, и можно отправлять ответ.
На 19200 если.

[~Dimon~]

Посчитал самый пакостный случай с фазами байт и тиков.
2 тика минус 1T = 3,49T.
Межпакетный интервал может быть не обнаружен, при следующем стечении обстоятельств:
1. Скорость 19200.
2. Кто то очень сильно (очень-очень!) рискнул, отправив пакет с интервалом менее 3,49T по моим часам.
3. Крайне неудачное совпадение фаз прерываний по тикам и принятым байтам.
4. Один из слившихся пакетов адресован мне, или броадкаст который я должен был увидеть.
Еще возможна ложная накрутка счетчиков ошибок CRC и нехватки буфера приема (зависит от конкретной реализации).

Но если такая мелкая халтура недопустима, то конечно можно переделать.

[linux_rulezz]

некоторые тащут STM32 для одного простого датчика вроде термометра, там и 2313 хватит.

Дык, 40 рублей за микроконтроллер - вполне нормально… И там, кстати, есть CAN на борту! Не нужно себя насиловать идиотским говном мамонта, коим является модбас! Его придумали в ту доисторическую эпоху, когда телефонные линии вынуждали выдерживать адские паузы…
И да, нормальная скорость в CAN при линии до 250 метров - 200-250 Кбод. И не нужно уродоваться с софтварным подсчетом CRC!!!1111
А еще и мультимастер!!1111
Короче, модбас - это не только пережиток прошлого, но и конкретный такой сигнальчик в сторону использующего его разработчика. Гомосятина, в общем…