[tonyk_av 39]

5 minutes ago, jcxz said:

Фрейминг в Modbus-RTU делается только на основе межкадровых пауз.

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

[Arlleex 160]

6 минут назад, quark сказал:

Не выделен из чего?

Ту длину, что указана в ответах на запросы, использовать до приема, выделения и сверки КС всего кадра нельзя.

А когда кадр принят, она (длина), по факту, и не нужна уже.

[jcxz 215]

2 минуты назад, tonyk_av сказал:

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

Тогда это уже не Modbus-RTU, а что-то своё, доморощенное.

https://en.wikipedia.org/wiki/Modbus

Цитата

• Modbus RTU (Remote Terminal Unit) – used in serial communication, and is the most common implementation available for Modbus. Modbus RTU makes use of a compact, binary representation of the data for protocol communication. The RTU format follows the commands/data with a cyclic redundancy check checksum as an error check mechanism to ensure the reliability of data. A Modbus RTU message must be transmitted continuously without inter-character hesitations. Modbus messages are framed (separated) by idle (silent) periods.

Читаем выделенное.

[razrab83 21]

1 час назад, tonyk_av сказал:

Вот поэтому устройства со стандартными протоколами не требуют его описания. Достаточно в характеристиках указать поддерживаемый протокол(ы). И всё.

вы не сможете указать в хар-ках девайса: поддерживается протокол Modbus. 

Вы должны будете описать физику шины (RS232/485/ttl3.3), битрейт, старт/стоп. описать как менять битрейт, если есть ограничение на 19200 - то и их указать... а теперь самое вкусное))) - вы должны описать все регистры и поддерживаемые функции из протокола, а также если есть пользовательские функции (а модбас это допускает) - будьте любезны и их. 

 

например у девайса состояние системы из 50 параметров. я в своем самописном протоколе опишу структуру и пакет с фиксированым заголовком в 3 байта и далее структура. 

вы в готовом модбасе укажите, что использовать модбас, а потом всё состояние из 50 параметров раскидаете на регистры. надо передать флоат в 4-х байтах, у вас это будет два регистра, мл часть флоата в регистре 0х1000, старшая в 0х1001. и так про каждый параметр. 

а если нужно текст передать переменной длинны, то это тот ещё гемор в модбас. в моём протоколе придуманным за 5 минут состояние передать или текст... - не вопрос. Сделать описание передачи текста - бумажной работы меньше, чем в вашем готовом модбас. 

 

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

[quark 48]

6 минут назад, jcxz сказал:

Из потока символов на линии.

Из какого потока символов? Пока не отправите запрос - там нет никакого потока. Пауза по стандарту. Начало потока - это начало пакета.

[jcxz 215]

1 минуту назад, quark сказал:

Из какого потока символов? Пока не отправите запрос - там нет никакого потока. Пауза по стандарту. Начало потока - это начало пакета.

Вы вообще читаете что вам пишут? Ещё раз:

25 минут назад, jcxz сказал:

Какого запроса? При чём тут какой-то запрос? Вы - ведомое устройство, подключились в линию в произвольный момент, там идёт какой-то обмен уже. Как найти "первые байты" пакета?

[quark 48]

4 минуты назад, Arlleex сказал:

Ту длину, что указана в ответах на запросы, использовать до приема, выделения и сверки КС всего кадра нельзя.

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

[tonyk_av 39]

Just now, jcxz said:

Тогда это уже не Modbus-RTU, а что-то своё, доморощенное.

Ничего подобного.

Есть работающая сеть Модбас. Решил заказчик поставить мастера в своём дата-центре, а на объекте контроллер с радиомодемом. Как, с какими задержками проходит сигнал- ему было пофиг, а то что фрейм мог быть разбит на несколько частей, приходящими с интервалами в 15-20 минут, так то мелочи. Трафик стоит дорого, частота опроса низкая, поэтому терять фреймы нельзя. И таких объектов у него сотни, а нужно всё подключить к удалённому мониторингу. Вот и приходится драйверу собирать фрейм из кусочков, прежде чем послать в сеть или отдать мастеру в обработку.

[quark 48]

Только что, jcxz сказал:

Вы вообще читаете что вам пишут? Ещё раз:

26 минут назад, jcxz сказал:

Какого запроса? При чём тут какой-то запрос? Вы - ведомое устройство, подключились в линию в произвольный момент, там идёт какой-то обмен уже. Как найти "первые байты" пакета?

А вы, вообще, читаете, что вам пишут? Обсуждается применение MODBUS со стороны ПК как ведущего устройства.

А вы уже какое-то ведомое устройство сюда приплели, которое подключается в произвольный момент.

[tonyk_av 39]

6 minutes ago, razrab83 said:

Вы должны будете описать физику шины (RS232/485/ttl3.3), битрейт, старт/стоп. описать как менять битрейт, если есть ограничение на 19200 - то и их указать... а теперь самое вкусное))) - вы должны описать все регистры и поддерживаемые функции из протокола, а также если есть пользовательские функции (а модбас это допускает) - будьте любезны и их.

Я прекрасно знаю, что и как нужно описывать, ибо документации написал достаточно. И перечитал ни мало.

Just now, quark said:

Обсуждается применение MODBUS со стороны ПК как ведущего устройства.

А вы уже какое-то ведомое устройство сюда приплели, которое подключается в произвольный момент.

На самом деле, не важно, с какой стороны смотреть.

[jcxz 215]

6 минут назад, tonyk_av сказал:

Вот и приходится драйверу собирать фрейм из кусочков, прежде чем послать в сеть или отдать мастеру в обработку.

Предположим - этот удалённый девайс запустился после того как уже обмен по сети идёт. Или например: работал-работал нормально, а потом часть данных потерялась (так как радиоканал).

Как предлагаете "собирать фрейм" удалённому?

 

PS: Ведь получится как в басне:  "Если бы губы Никанора Ивановича да приставить к носу Ивана Кузьмича..."  

[razrab83 21]

2 минуты назад, tonyk_av сказал:

Ничего подобного.

Есть работающая сеть Модбас. Решил заказчик поставить мастера в своём дата-центре, а на объекте контроллер с радиомодемом. Как, с какими задержками проходит сигнал- ему было пофиг, а то что фрейм мог быть разбит на несколько частей, приходящими с интервалами в 15-20 минут, так то мелочи. Трафик стоит дорого, частота опроса низкая, поэтому терять фреймы нельзя. И таких объектов у него сотни, а нужно всё подключить к удалённому мониторингу. Вот и приходится драйверу собирать фрейм из кусочков, прежде чем послать в сеть или отдать мастеру в обработку.

ну вы и описываете что-то доморощенное. 

 

Это холивар двух подходов к модбас. Очень часто новички не анализируют паузы. кадру выделяют на "лету", т.е. сначало что-то там анализируют, потом сверяют CRC. Встречал даже так... Принял первый байт - это адрес. Адрес не мой - значит это не мне. Далее делает разбор пакета и даже не считает CRC. Зачем его считать, если пакет не мне? А то, что в адресе может быть ошибка и адрес нельзя анализировать до приема всего пакета и проверки CRC - об это не думают. 

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

[Arlleex 160]

5 минут назад, quark сказал:

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

К непрерывному потоку мусора нужно быть готовым и в случае отсутствия защитного смещения у RS-485. Защитное смещение зло - но меня иногда любезно просят его запаивать. Что делать.

А для гарантированного отделения начала RTU-кадра передатчик должен активировать выход на определенный интервал (точных цифр не помню, но я всегда выдерживаю DE трансивера активным 2 UART-фрейма).

[jcxz 215]

7 минут назад, quark сказал:

А вы, вообще, читаете, что вам пишут? Обсуждается применение MODBUS со стороны ПК как ведущего устройства.

А вы уже какое-то ведомое устройство сюда приплели, которое подключается в произвольный момент.

Фрейминг на кадры должен быть единообразен. Вне зависимости - ведомое это устройство или ведущее, ПК или МК.

[quark 48]

5 минут назад, razrab83 сказал:

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

2 минуты назад, jcxz сказал:

Фрейминг на кадры должен быть единообразен. Вне зависимости - ведомое это устройство или ведущее, ПК или МК.

 

У вас при приеме в ПК все паузы потеряются. Хуже того - могут появиться лишние. Там не годится этот метод.