[Denis K 0]

Всем доброго времени суток!

 

Если кто работал с Modbus RTU, и использовал его в своих разработках, подскажите..

 

В спецификации указано, что межкадровая пауза равна 3.5 символа, а пауза между байтами в кадре не более 1.5 символа. Как я понимаю символ - это число от 0 до 15 (4 бита).

 

Вопрос - а сколько это будет в битах?

Если считать только данные - т.е. 8 бит на два символа, то получается 14 и 6 бит соответственно.

Или считать за два символа всю посылку со стартовым и стоповыми битами тоже, т.е. - 10/11 бит?

Тогда уже получится дробное число бит :07:

 

Заранее благодарен.

Изменено 8 ноября, 2008 пользователем Denis K

[rezident 0]

Как я понимаю символ - это число от 0 до 15 (4 бита).

Символ это один информационный символ в асинхронном канале - 7 или 8 бит данных, обрамленные старт-битом, битом четности и стоп-битами.

Вопрос - а сколько это будет в битах?

В зависимости от формата от 9 до 12 бит. Обязательны старт-бит, 7/8 бит данных и стоп-бит. Бит четности может быть, а может и не быть. Точно также как один или два стоп-бита.

Тогда уже получится дробное число бит :07:

А что вас так волнуют эти биты? Вас ведь время паузы интересует, а не просто биты. Ну и считайте его в размерности времени - в миллисекундах там всяких :laughing:

t(3.5)=3500*(START+DATA+PARITY+STOP)/BAUD, где START - старт-бит (одна штука), DATA - количество бит данных (7 или 8), PARITY - количество бит четности (0 или 1), STOP - количество стоп-битов (1 или 2), BAUD - скорость передачи. Результат (время паузы 3,5 символа) будет в миллисекундах.

Еще не следует забывать, что в спецификации ModBus over Serial line оговорена длительность символа - 11 бит (старт, 8 данных, четность, 1 стоп-бит) и минимальное время паузы тишины (3,5 символа) ограничено 1,75 мс и минимальной паузы между символами (1,5 символа) 0,75мс.

[Denis K 0]

А что вас так волнуют эти биты? Вас ведь время паузы интересует, а не просто биты. Ну и считайте его в размерности времени - в миллисекундах там всяких :laughing:

 

Конечно паузу будем считать в микросекундах, просто в битах проще понять принцип, без относительно скорости передачи.

 

Символ это один информационный символ в асинхронном канале - 7 или 8 бит данных, обрамленные старт-битом, битом четности и стоп-битами.

 

Как я понял из спецификации ModBus over Serial line (стр.12, п2.5.1),

символ - это 4-х битное шестнадцетеричное число от 0 до 15 (0..F).

А в 8 битах данных, т.е. одном байте содержится два символа.

 

t(3.5)=3500*(START+DATA+PARITY+STOP)/BAUD, где START - старт-бит (одна штука), DATA - количество бит данных (7 или 8), PARITY - количество бит четности (0 или 1), STOP - количество стоп-битов (1 или 2), BAUD - скорость передачи. Результат (время паузы 3,5 символа) будет в миллисекундах.

 

Т.е. получается что размер одного символа (в битах) - 0.5*(START+DATA+PARITY+STOP)

а не - 0.5*(DATA).

Как все-таки правильно?

 

Нашел на сайте НИЛ АП http://rlda.ru/ описание Modbus.

Они утверждают, что 3.5 символа это 14 бит, ну и 1.5 - 6 бит соответственно.

 

 

Еще не следует забывать, что в спецификации ModBus over Serial line оговорена длительность символа - 11 бит (старт, 8 данных, четность, 1 стоп-бит) и минимальное время паузы тишины (3,5 символа) ограничено 1,75 мс и минимальной паузы между символами (1,5 символа) 0,75мс.

 

Хорошо что написали об этом.

Как я понял, данные значения желательны и рекомендованны, но не обязательны к применению. И если контроллер на скоростях выше 19200 может отсчитать четко паузу в 3.5 символа, то пусть так и делает.

Или опять таки, для высоких скоростей надо использовать указанные выше значения для пауз?

Если так, то преимущество по скорости 57600 в сравнении к 19200 сходит на нет.

Так как пауза в 1.75 мс - это больше 9 переданных байт на 57600 и получается,

что если средняя длина сообщения или ответа будет 8 байт, то с паузой уже 17 байт.

Т.е. за секунду можно провести по максимуму около 150 актов обмена,

а на скорости в 19200, с паузами в 3.5 символа - около 90.

Как то не шустро получается, а хотелось бы использовать по максимуму.

Изменено 9 ноября, 2008 пользователем Denis K

[Denis K 0]

Всем привет!

 

Есть необходимость реализовать Modbus RTU на PIC18.

Может кто делал, сталкивался, разбирался.

 

Так же есть вариант использования своего протокола,

скорее всего на основе Modbus.

Но как его доработать пока не определился.

 

Заранее спасибо за любую информацию и советы!

:a14:

Изменено 9 ноября, 2008 пользователем Denis K

[MrYuran 17]

FreeModbus

 

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

По аналогии можно и под пик портировать.

[IVANS 0]

...

Есть необходимость реализовать Modbus RTU на PIC18.

Может кто делал, сталкивался, разбирался.

...

Для пиков натыкался на такой пример, посмотри может пригодится.

PIC.ZIP

[rezident 0]

Конечно паузу будем считать в микросекундах, просто в битах проще понять принцип, без относительно скорости передачи.

Сами себе противоречите. Пауза имеет размерность времени, зачем биты-то?

Как я понял из спецификации ModBus over Serial line (стр.12, п2.5.1),

символ - это 4-х битное шестнадцетеричное число от 0 до 15 (0..F).

А в 8 битах данных, т.е. одном байте содержится два символа.

Т.е. получается что размер одного символа (в битах) - 0.5*(START+DATA+PARITY+STOP)

а не - 0.5*(DATA).

Как все-таки правильно?

Правильно так, как я в предыдущем сообщении описал. Если вас смутил абзац

When devices communicate on a MODBUS serial line using the RTU (Remote Terminal Unit) mode, each 8–bit byte in a message

contains two 4–bit hexadecimal characters. The main advantage of this mode is that its greater character density allows better data

throughput than ASCII mode for the same baud rate. Each message must be transmitted in a continuous stream of characters.

то там про отличия режимов RTU и ASCII сообщение идет речь. В RTU в каждом символе передается один байт информации, а в ASCII в каждом символе только одна тетрада (полубайт).

Нашел на сайте НИЛ АП http://rlda.ru/ описание Modbus.

Они утверждают, что 3.5 символа это 14 бит, ну и 1.5 - 6 бит соответственно.

Фтопку подобные переводы! :( Есть стандарт ModBus - им и руководствуйтесь.

Хорошо что написали об этом.

Как я понял, данные значения желательны и рекомендованны, но не обязательны к применению. И если контроллер на скоростях выше 19200 может отсчитать четко паузу в 3.5 символа, то пусть так и делает.

Или опять таки, для высоких скоростей надо использовать указанные выше значения для пауз?

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

Если так, то преимущество по скорости 57600 в сравнении к 19200 сходит на нет.

Так как пауза в 1.75 мс - это больше 9 переданных байт на 57600 и получается,

что если средняя длина сообщения или ответа будет 8 байт, то с паузой уже 17 байт.

Т.е. за секунду можно провести по максимуму около 150 актов обмена,

а на скорости в 19200, с паузами в 3.5 символа - около 90.

Как то не шустро получается, а хотелось бы использовать по максимуму.

ModBus весьма старый и дурацкий протокол. непонятно зачем вообще вы его возжелали использовать? Если у вас есть такое требование в ТЗ, то понятно. Если же только потому что других протоколов не знаете, то советую посмотреть описание протоколов типа SLIP, Wake и сравнить их эффективность и удобству реализации по сравнению с ModBus.

 

P.S. на скриншоте из спецификации пояснение к определению символа (char, character).

[Denis K 0]

Спасибо! Вообщем все понятно.

:beer:

 

Что касается других протоколов, то чем уж так сильно лучше WAKE чем Модбас? Да и че в нем дурацкого? Кроме того что-то я не встречал пока промышленных устройств с WAKE.

Может конечно не там искал :)

 

А кроме WAKE какие еще есть конкуренты у Модбаса?

[bovolk 0]

Что касается других протоколов, то чем уж так сильно лучше WAKE чем Модбас? Да и че в нем дурацкого? Кроме того что-то я не встречал пока промышленных устройств с WAKE.

А кроме WAKE какие еще есть конкуренты у Модбаса?

 

Главное преимущество Modbus, что он поддерживается SCADA-ми! Правда, по сравнению с "WAKE" мне не понравилось наличие интервалов тишины для синхронизации пакетов. В описании "WAKE" про паузы между пакетами ничего не сказано, но они также должны присутствовать! А как же иначе определить где стартовый бит в байте если передавать сплошняком? Но не понравилось то, что в обоих протоколах нет какого-то флага повторного запроса от Мастера, в случае потери ответа подчиненного. Для чего это надо? Например, поступила команда "Запустить ракету". Запустили и ответили "ОК", но ответ не пришел и мастер повторяет команду. Что, запускать еще одну??? Т.е. подчиненный должен знать-- это повтор предыдущей команды или новая команда. Решается это циклическим номером сообщения, если номер не увеличился, то повтор.

Изменено 14 ноября, 2008 пользователем Bovolk

[rezident 0]

Главное преимущество Modbus, что он поддерживается SCADA-ми!

Для SCADA пофиг протокол. SCADA обычно работают через OPC server. Реализуйте в OPC-сервере поддержку любого другого протокола и SCADA даже не узнает об этом.

Правда, по сравнению с "WAKE" мне не понравилось наличие интервалов тишины для синхронизации пакетов. В описании "WAKE" про паузы между пакетами ничего не сказано, но они также должны присутствовать! А как же иначе определить где стартовый бит в байте если передавать сплошняком?

В сетях, основанных на RS-485, в принципе не может не быть пауз. Для переключения драйверов прием/передача и установления линии всегда требуется определенное время.

Но не понравилось то, что в обоих протоколах нет какого-то флага повторного запроса от Мастера, в случае потери ответа подчиненного. Для чего это надо? Например, поступила команда "Запустить ракету". Запустили и ответили "ОК", но ответ не пришел и мастер повторяет команду. Что, запускать еще одну??? Т.е. подчиненный должен знать-- это повтор предыдущей команды или новая команда. Решается это циклическим номером сообщения, если номер не увеличился, то повтор.

Использовать modbus в ракетах это жесть!

[bovolk 0]

Для SCADA пофиг протокол. SCADA обычно работают через OPC server. Реализуйте в OPC-сервере поддержку любого другого протокола и SCADA даже не узнает об этом.

 

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

 

В сетях, основанных на RS-485, в принципе не может не быть пауз. Для переключения драйверов прием/передача и установления линии всегда требуется определенное время.

 

Это была наживка! А если гарантированно есть паузы, то накой здался БАЙТСТАФФИНГ??? По паузам и будет определятся начало пакета, что и сделано в Modbus.

 

Использовать modbus в ракетах это жесть!

 

Ну, я утрировал. Вместо ракеты может быть Задвижка, удаленный счетчик какого-то процесса, или дозатор, да мало ли еще чего. Кстати, эту идею со счетчиком сообщений я почерпнул, когда расковыривал протокол фирмы "Nokia" обмена телефона с PC, т.е. далеко от ракет, а сделано!

Изменено 14 ноября, 2008 пользователем Bovolk

[rezident 0]

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

Ну да, а визуализацию интерфейса в SCADA кто делает? Ваша консьержка что ли?

Это была наживка! А если гарантированно есть паузы, то накой здался БАЙТСТАФФИНГ??? По паузам и будет определятся начало пакета, что и сделано в Modbus.

Потому, что паузы могут быть заранее неопределенной длительности и быть обусловлены совершенно разными причинами. И если для протоколов, использующих специальные маркеры начала/конца пакета, эти задержки/паузы не очень критичны, то для ModBus RTU они основополагающие. Кстати, именно для ModBus RTU, потому как для ModBus ASCII, использующего именно символы-маркеры, насколько я помню есть только одно ограничение - паузы между символами не более 1 с.

Ну, я утрировал. Вместо ракеты может быть Задвижка или удаленный счетчик какого-то процесса, да мало ли еще чего. Кстати, эту идею со счетчиком сообщений я почерпнул, когда расковыривал протокол фирмы "Nokia" обмена телефона с PC, т.е. далеко от ракет, а сделано!

Это протоколы не того уровня. Modbus это скорее канальный уровень, а повторы-ошибочных пакетов, разделение-склеивание пакетов, контроль целостности это уже транспортный уровень согласно сетевой модели OSI. Хотя эта модель тоже весьма условна.

[Denis K 0]

С Модбасом все понятно. Старая, надежная, широко распространненая штука.

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

А есть еще распространненые протоколы?

Я если чесно не слышал, да и про WAKE, тоже недавно узнал.