Вопросы по Modbus

[tonyk]

Межпакетный интервал может быть не обнаружен, при следующем стечении обстоятельств:

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

[linux_rulezz]

Ещё ни разу за 30 лет не встретил протокола для EIA-485, который существенно превосходил бы Modbus по эффективности обмена информацией

Для тех, кому не нравится "сырой CAN", придумали CanOpen. Но я предпочитаю "сырой". Первые три байта из четырех в запросе - код команды и индекс, в ответе четвертым байтом идет код состояния/ошибки; вторые четыре байта - данные. Хоть uint32_t, хоть float, хоть черт лысый. За глаза хватает для работы с железками на STM32.

чтобы заставить пользователя оборудования купить кроме оборудования ещё и уникальный ОРС-сервер.

Вот это - и есть гомосятина: заставлять пользователя кроме железа еще и софт покупать. Закапывать таких тварей надо!

Поэтому нужно правильно указать ведущему величину таймаута для каждого ведомо, тогда слипания пакетов не будет.

Это элементарно делается в конечном автомате. Не нужно никаких лишних таймеров заводить. Только SysTick для условного подсчета миллисекунд (кому миллисекунда - много, может сотни микросекунд считать).

[linux_rulezz]

Ну и да: в отличие от тупого модбаса, где медленно надо опрашивать все узлы по очереди, у меня в CAN в случае экстренных ситуаций устройство сразу выбрасывает в сеть данные об ошибке. Понятно, что порядок отправки сообщения зависит от идентификатора, но на скорости 250кбод с двумя десятками устройств в сети я ни разу на задержки больше нескольких микросекунд не натыкался. Да и можно для экстренных сообщений широковещательный ID давать, а реальный ID узла запихивать в верхние четыре байта.

[tonyk]

в отличие от тупого модбаса, где медленно надо опрашивать все узлы по очереди, у меня в CAN в случае экстренных ситуаций устройство сразу выбрасывает в сеть данные об ошибке

Модбас впервые появился в ПЛК, то есть устройствах как раз и предназначенных для управления, которое предполагает обработку аварийных ситуаций. Зачем нужна микросекундная задержка в передаче сообщения об ошибке, когда есть устройство, обрабатывающее нештатные ситуации? Не нужна. Поэтому и быстрой реакции на события от Модбас не требуется. Модбас предназначен для мониторинга оборудования, его конфигурирования и подачи команд ПЛК, которые этим оборудованием управляют. Ни кто же не ожидает от Хёндэ Гетц выдающихся внедорожных свойст.

[~Dimon~]

Пардон, я кажется обсчитался, к тому же ограничений два.
Нужно выполнить условие: 2,5T < порог < 4,5T.
Именно так, по тому что прерывание приходит в конце приема байта, а не в начале.
Порог должен быть кратен тику: 1, 2, 3... тика.
Для 19200,8,E,1
388Гц < тик < 698Гц
или
776Гц < тик < 1396Гц

Для скоростей выше 19200: (0,75ms + 1T) < порог < (1,75ms + 1T)

Правильно выбираем частоту тика, совставляем таблицу порогов для поддерживаемых скоростей, все.

Перековыриваю тот свой проект, тики у меня вообще бесплатные оказывается, АЦП непрерывно измеряет одно напряжение и сыплет прерывания 11077Гц, которые программно до 1007Гц делятся.

UPD:
Даже вот так:
tick*N > 2.5T, tick*(N+1) < 4.5T до и включая 19200.
tick*N > 0.75ms+1T, tick*(N+1) < 1.75ms+1T свыше 19200.
N >= 2
Не получается порог 1 тик, минимум 2.

[jcxz]

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

Т.е. - 8N1 нельзя?
Ну вот - ещё одно ограничение, ещё один минус в копилку прочих.

[jcxz]

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

Похоже это вы не поняли о чём идёт речь. Речь не про запрос/ответ. А про выделение кадров из потока байт. И режим работы необязательно может быть запрос/ответ.

[jcxz]

И да, нормальная скорость в CAN при линии до 250 метров - 200-250 Кбод. И не нужно уродоваться с софтварным подсчетом CRC!!!

А ничего, что в столь назойливо рекламируемом вами CAN из 108 бит длины стандартного кадра, только максимум 64 бита можно использовать для данных? Т.е.: ~40% времени шины придётся отдать коту под хвост на передачу кучи ненужной управляющей инфы. И от этих 200кбод останется всего с гулькин нос 120кбод реальной полезной скорости данных. В то время как RS-485 не накладывает ограничений на формат кадра, а значит канал можно использовать максимально плотно, с минимальными потерями на служебные данные. Т.е. - при одинаковой полосе частот, на RS-485 можно получить на ~40% бОльшую скорость передачи.
Это вы конечно "забыли" упомянуть, рекламируя тут CAN.

Кстати - даже не 108 бит, а скорее всего больше. Из-за бит-стаффинга. На передачу данные может остаться всего около ~50% времени. Т.е. - в 2 раза медленнее RS-485.
И насчёт CRC - она там всего 15бит. Весьма слабо. А на RS-485 ничто не мешает использовать CRC32.

Да и можно для экстренных сообщений широковещательный ID давать, а реальный ID узла запихивать в верхние четыре байта.

Чего??? Что за "широковещательный ID"?
Предлагаете передавать с одним ID с разных узлов??? Т.е. - преднамеренно создавать коллизии на шине?
Это пожалуй верх говнокодерства!
Кто вас учил так "работать" с CAN?

[ejsanyo]

Хмм, тут мысль пришла: а можно ли попытку реализовать MODBUS рассматривать как этакий тест профпригодности контроллеров для работы UART-ом? И RS-485 в частности. Логика примерно такая, мол, "если некий чип оказался в плане периферии таким, что на нём легко и качественно реализовался MODBUS, то уж прочие-то протоколы и подавно на нём сделаются не хуже".

[~Dimon~]

А что там такого особенного надо?
Есть аппаратная поддержка Receive timeout и Transmit delay - отлично!
Нет - используйте свободный таймер, какую то другую незадействованную в проекте периферию, в качестве простейшего таймера, в крайнем случае тики (с некоторыми ограничениями).
Остальное там - обычно несущественные мелочи.

Т.е. - 8N1 нельзя?

Стандартом не предусмотрено, но если все устройства на шине поддерживают, можете себе настроить что угодно, пока милиционер не видит

Atmel AVR еще и 9N1 могут гонять.
По SPI запустить наверное то же можно, там вообще служебных бит нет, но формат ADU для SPI, и способ разделения кадров, изобретайте сами. Хотя может кто то уже придумал.

[tonyk]

Речь не про запрос/ответ. А про выделение кадров из потока байт.

Я прекрасно понимаю, о чём речь. Поэтому и сказал про таймаут на ожидание ответа от ведомого. Этот таймаут превышает длительность одного фрейма (обычно, больше удвоенной длительности фрейма), поэтому и нет проблемы с наложением фреймов. Даже если ведомый сделан на STM32 и определяет границу фрейма по IDLE, а не RTO, и сразу после приёма фрейма от ведущего начинает ему отвечать, то у ведущего достаточно времени на переключение трансивера с передачи на приём даже при скорости обмена 10Мбит/с. Поэтому не критична длительность паузы, 3.5 символа или 3.4.

Т.е. - 8N1 нельзя?
Ну вот - ещё одно ограничение, ещё один минус в копилку прочих.

Можно. В Стандарте это значение указано просто как рекомендованное. На практике чаще всего встречается как раз 8N1.

[jcxz]

Я прекрасно понимаю, о чём речь. Поэтому и сказал про таймаут на ожидание ответа от ведомого. Этот таймаут превышает длительность одного фрейма (обычно, больше удвоенной длительности фрейма), поэтому и нет проблемы с наложением фреймов. Даже если ведомый сделан на STM32 и определяет границу фрейма по IDLE, а не RTO, и сразу после приёма фрейма от ведущего начинает ему отвечать

Ещё раз: Вы так и не поняли о чём речь.
Попробуйте отложить клавиатуру в сторону, включить голову и немного подумать.
Как уже писал: Режим работы не обязательно может быть запрос/ответ. Может быть сначала отправка многих кадров в одну сторону и только потом ответы. Или просто отправка в одну сторону много кадров без ответных. Это может быть нужно при широковещательной передаче. Или при передаче больших массивов данных с максимальной скоростью.

Можно. В Стандарте это значение указано просто как рекомендованное. На практике чаще всего встречается как раз 8N1.

Значит все расчёты ~Dimon~ - коту под хвост. Где он рассчитывает на минимум 11 бит. И его код будет глючить.

[jcxz]

Atmel AVR еще и 9N1 могут гонять.

Использование всяких экзотических режимов UART неизбежно ведёт к проблемам у конечного пользователя. Что, в свою очередь, неизбежно ведёт к отправке такого проблемного девайса в мусорку.
Надо везде стараться пользоваться 8N1.
Я где-то слышал, что даже 8N2 (и вообще режимы с двумя стоп-битами) в каком-то железе не работают. И в реальности при установке режима с 2-я стоп-битами, работает режим с 1 стоп-битом. Не помню где это читал.

[linux_rulezz]

Предлагаете передавать с одним ID с разных узлов??? Т.е. - преднамеренно создавать коллизии на шине?

УМВР ☺
В любом случае, "мультимастер" на CAN, даже несмотря на уйму служебных данных в пакете, отлично кроет убогий модбас!
Чесслово, я бы расстреливал из гранатомета тех, кто в 21 веке использует modbus rtu вместо CAN или какого-либо другого вменяемого протокола.
А уж китайцы с их релюшками, которые на широковещательный адрес отвечают - вообще сволочи. Похоже, они вообще не подразумевают, что в шине может быть больше одного "раба".

Понятно, что тот же ethernet даже на 10Мбод (если, конечно, не TCP, а сырой UDP) куда шустрей. Но, увы, не так-то много МК с поддержкой ethernet. Да и, насколько я знаю, в интернетах не существует вменяемой baremetal свободной библиотеки для работы с UDP или TCP. Самому придется писать.

[~Dimon~]

В некотором железе и BREAK не работает, но это кривое железо.

Значит все расчёты ~Dimon~ - коту под хвост. Где он рассчитывает на минимум 11 бит. И его код будет глючить.

С чего это?
Меняется 8N1 на 8N2, и что? Параметр T меняет свое численное значение, пересчитайте допуски по частоте тиков, расчитайте пороги, сами формулы не меняются.
У меня один порог, который должен быть гарантированно >1,5T и меньше 3,5T, при любых стечениях фаз тиков и прерываний UART, для выполнения этого условия и расчеты.
По тому что мой код по тикам работает.

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

[tonyk]

Ещё раз: Вы так и не поняли о чём речь.
Попробуйте отложить клавиатуру в сторону, включить голову и немного подумать.
Как уже писал: Режим работы не обязательно может быть запрос/ответ. Может быть сначала отправка многих кадров в одну сторону и только потом ответы

Приплыли. Вы почитайте для начала Стандарт на Modbus/RTU, потом дискутируйте.
В Modbus/RTU строго сначала идёт запрос от ведущего, а потом ответ от ведомого. Ведущий ждёт ответ в течении времени, указываемого для ведомого. Максимальное время ответа ведомого указывается многими производителями. Если за указанное время ответ от ведомого не пришёл, то только тогда ведущий посылает следующий запрос. И никак иначе. Хотя есть широковещательные запросы, но они не_требуют ответа.
Судя по вашей реплике, вы путаете Modbus/RTU с Modbus/TCP, для котором описанная ситуация является нормальной, поэтому в фрейме Modbus/TCP есть поле с номером транзакции.

[tonyk]

В любом случае, "мультимастер" на CAN, даже несмотря на уйму служебных данных в пакете, отлично кроет убогий модбас!

Modbus/RTU не используют там, где нужен мультимастерный режим, хотя этот режим не сложным образом реализуется через специальные шлюзы. В мультимастерном режиме хорошо работает Modbus/TCP.

[tonyk]

Значит все расчёты ~Dimon~ - коту под хвост. Где он рассчитывает на минимум 11 бит. И его код будет глючить.

С чего бы это? При задании межпакетной задержки одним из параметров расчёта как раз является длительность символа в битах.

[~Dimon~]

Которая в терминологии стандарта и моей формуле обозначена буквой "T", видимо не все догадались.

UPD:
Еще 1,5 стоповых бита и 5 бит данных, не все UART поддерживают.