ModBus RTU паритет EVEN и NONE будут дружить?

[Sergy6661]

Всем привет, Товарищи.
Тут вопрос нарисовался- на шине RS 485 ModBus RTU работает устройство (расходомер) с фиксированными параметрами 8-E-1, на эту же шину необходимо добавить еще один расходомер, но у него тоже фикс. параметры 8-N-1, собственно вопрос- будут работать устройства на одной шине с разными настройками паритета?

[Ryzhij]

Это ещё не протокол Modbus. Это пока ещё канальный уровень последовательного асинхронного интерфейса.
И нет, устройства с такими настройками дружить не будут.

Отправлено спустя 3 минуты 5 секунд:
Мастер перед опросом второго прибора должен будет изменить настройки связи своего порта.

[Jackson]

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

А потом изменить настройки порта обратно под первое устройство. И так каждый раз инициализировать порт с новыми настройками. Не всякое устройство (мастер) способно это делать на лету.

[keysansa]

А потом изменить настройки порта обратно под первое устройство. И так каждый раз инициализировать порт с новыми настройками. Не всякое устройство (мастер) способно это делать на лету.

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

[Ryzhij]

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

Абсолютно нелогичный вывод. Бит чётности будет воспринят либо как стоп-бит, либо приводëт к ошибке приëма.
Повторю ещё раз:
- До протокола Modbas и разбора всей посылки с определением адреса дело даже не дойдёт.

[Jackson]

Но это не "на лету", Это опрос двух устройств. Адрес меняется, почему бы не менять и настройки?

А Вы попробуйте. В компе получится, а в половине ПЛК и панелей - нет.

[petr2off]

Может карма у меня плохая, но в случае Modbus rtu у меня все вразу получалось наверно в 20% случаях. Остальные 80% это танцы с бубном. Посмотрите к примеру панель Weintek - теоретически одного драйвера Modbus RTU достаточноЮ но их там больше. Потому как у каждого производителя может быть свое понятие Modbus RTU. К примеру,сто бы прикрутить панель Weintek к контроллеру Контар - пришлось у них докупать их драйвер. Как щас помню - 5000 рублей отдали.
Идея садить на одну веревку девайсы от разных производителей - идея прямо скажем, так себе и 100 пудово карантирует танцы с бубном, даже при идентичных параметрах последовательного порта. А если еще и параметры разные - то это уже какие то Половецкие пляски будут.
Как сказал Jackson - пробуйте, может и получится, главное в бубен бить сиильно и ритмично :)

[I_m]

Идея садить на одну веревку девайсы от разных производителей - идея прямо скажем, так себе и 100 пудово карантирует танцы с бубном

Прям уж 100? Не преувеличивайте.

[petr2off]

Это я приуменьшаю.

[keysansa]

Это я приуменьшаю.

Трудности - закаляют.

[petr2off]

Ага, еще как закаляют.
Допустим, у меня есть контроллер Контар и Теплосчетчик - какой то. Я подкачиваю драйвер контара,для простоты пусть будет у меня стандартный Modbus RTU на счетчике. И я все это нат одну веревку вешаю, COM1, Естественно мне нужно будет 2 контроллера в проекте заводит, с разными драйверами и на COM1 оба вешать. Есть у меня глубокие сомнения - что эта схема заработает. Скорей всего нужно бутет писать матерый скрипт - работы с COM портом, где периодически выполнять коннект и дискогннект с разными параметрами и самому разбирать пакеты ввода - вывода.
Есть такая байка чем старый инженер отличается от молодого.
У молодого куча вопросов - как, зачем, почему, а если так ?
У старого один вопрос - Нахрена ?
Вешаешь на 2 веревки COM1 и COM2, на каждую свой, работающий драйвер, и тратишь усилия на решения проблемы управления устройством, а не на нетривиальные интерфейсные задачи.

[Joshua]

"Дружба" устройств с разными настройками чётности сильно зависит от самих устройств, как они обрабатывают биты на шине.
Мне кажется, с настройками 8-E-1 должны заработать оба устройства. Просто устройство с дефолтными 8-N-1 будет игнорировать проверку бита чётности, главное, чтобы выдавалось 11 бит на символ.

Modbus_over_serial_line_V1_02.jpg

Прямо сейчас у меня есть два устройства одного турецкого производителя, один работает только с 8-N-2. А второму что 8-N-1, что 8-N-2. Если поставить второму 8-x-1 и бит чётности выставить неважно какой (even-odd-none-mark-space) - всё равно работает. В итоге просто поставил на оба 8-N-2.

[Ryzhij]

Мне кажется, с настройками 8-E-1 должны заработать оба устройства.

Разумеется! Но как это соотносится с исходной информацией

устройство (расходомер) с фиксированными параметрами 8-E-1

вот в чем вопрос!

[VADR]

Это уже, я так думаю, нюансы реализации конкретных устройств у конкретного производителя. Ведь по идее - как оно должно работать:
1. Отправляющаяя сторона (это может быть и мастер, посылающий запрос, и слейв, на него отвечающий) формирует каждый отправляемый байт в соответствии со своими настройками. То есть: если выставлен параметр контроля чётности не N - считает чётность и выставляет 0 или 1 в соответсвующем месте. Или просто выставляет 1, если контроль чётности отключен. И добавляет нужное количество стоп-битов.
2. Принимающая сторона получает этот байт и проверяет в соответствии со своими настройками: правильная ли там чётность, если не N, или стоит ли там 1, если N. И сколько там стоп-битов. И если там что-то чему-то не соответствует - обмен данными не работает. Но. Если разработчик устройства не был достаточно добросовестным - он мог просто забить на проверку и принимать только 8 информационных бит (всё равно после посылки должна быть пауза, за время которой все чётности и стопы пролетят - зачем заморачиваться?). И тогда ему пофиг кто и что отправил - примет всё. Кроме того, даже если разработчик не был столь ленив - разные люди по-разному понимают отсутствие контроля чётности. В ориганальных стандартах rs-232 и 485 количество информационных бит может быть от 5 до 8, бит чётности существует только если не N (иначе его просто нет), и стоп-битов может быть 1, 1.5 или 2. Если в настройах установлено N - проверка этого бита просто не делается совсем. В modbus rtu это дело несколько модифицировано: информационных бит всегда 8, а при настройке N ставится дополнительный стоп-бит (единица), в результате длина пакета всегда 11 бит. Так вот некоторые разработчики эту единицу вместо бита чётности проверяют, а некоторые - нет.
3. А потом они меняются местами...

В общем, моё мнение: заработать может, но полагаться на это нельзя :). Через какое-то время, возможно, поменяют устройство на другое (или заменят прошивку устройства, а там окажется более строгая реализация протокола) - и всё встанет колом.

[I_m]

Естественно мне нужно будет 2 контроллера в проекте заводит, с разными драйверами и на COM1 оба вешать.

Контар по Modbus RTU сам умеет прекрасно опрашивать те же теплосчётчики, например. А 3-е устройство какое? Панель вайнтековская? Они же вроде как с Контарами через tcp/ip умеют работать, не? Впрочем, тут не компетентен.

[Sergy6661]

Всем привет, Товарищи! Поздравляю всех с выходом из очередного Нового года.
Вообще моя проблема решилась (пока), т.к расходомер все равно на объекте, просто товарищи по работе не очень внимательно мануал изучили, в общем есть там возможность переключения на 8-N-1.
Но вот такие варианты тоже имеют место быть-

Но. Если разработчик устройства не был достаточно добросовестным - он мог просто забить на проверку и принимать только 8 информационных бит (всё равно после посылки должна быть пауза, за время которой все чётности и стопы пролетят - зачем заморачиваться?). И тогда ему пофиг кто и что отправил - примет всё.

Примет и разберет информационную часть ответа.

[Jackson]

Может карма у меня плохая, но в случае Modbus rtu у меня все вразу получалось наверно в 20% случаях. Остальные 80% это танцы с бубном.

Не в карме дело. В понимании его работы.

Идея садить на одну веревку девайсы от разных производителей - идея прямо скажем, так себе и 100 пудово карантирует танцы с бубном, даже при идентичных параметрах

Не-а. Для того и сделан Модбас чтобы быть универсальным, и, как правило, всё получается. Не получается сходу когда произвдоители устройств косячат. Или когда хард кривой.

Трудности - закаляют.

И отнимают время. Впустую. Будешь закалённый, но преждевременно постаревший. :)

Вообще моя проблема решилась (пока), т.к расходомер все равно на объекте, просто товарищи по работе не очень внимательно мануал изучили, в общем есть там возможность переключения на 8-N-1.

Вот именно. Чаще всего проблемы, которых у кое-кого тут 80% из ста случаев, именно так и решаются. И тем же путём они просто не создаются.

Но вот такие варианты тоже имеют место быть

Я б просто попробовал да и всё. Зависит от устройств в конкретном сочетании и рассуждать в теории можно бесконечно. Теория данные не опросит.

[AlexandrGr]

всё равно после посылки должна быть пауза

В каком месте и зачем должна быть пауза?

[VADR]

В каком месте и зачем должна быть пауза?

Между окончанием стопового бита одного байта и началом стартового следующего байта. Там, если мне память не изменяет, должно быть не менее 1.5 времени одного бита (и стартовый - тоже полуторный по времени). Для того, чтобы различать байты - они же потоком идут. Нужен какой-то ориентир, чтобы распознать начало/конец байта.

[VaBo]

Старт-бит такой же длины, как и все последующие, внутри сообщения байты идут без каких-то специальных пауз, непрерывно. Ошибка не накапливается, потому что идет привязка к каждому новому старт биту (USART - синхронно/асинхронная передача). Сообщения делятся по паузе длительностью в 3,5 символа.

[Jackson]

Сообщения делятся по паузе длительностью в 3,5 символа.

А символ - это аж два байта. Так что всё зависит от конкретной реализации устройства: оно чётко проверяет стоп-бит и бит чётности или ему всё равно. МодбасПулу, например, не всё равно - сами легко убедитесь в этом.

И ответ на вопрос уже давно дан: либо каждый раз переинициализировать драйвер порта, если это вообще возможно, либо надеяться на то, что устройства у автора настолько кривые, что формат сообщений им до лампочки и не зависит от настроек драйвера порта. Если всё не кривое, то два устройства с 8-N-1 и 8-E-1 одновременно не будут опрашиваться, придётся переинициализировать драйвер порта. А если что-то кривое, то вообще всё что угодно может не работать по любой неизвестной причине - оно же кривое - тогда будет удачей если вообще хоть что-то будет работать.

Сам вопрос некорректен. От того какой там протокол - ModBUS или что-то другое - это вообще не зависит.

[I_m]

А символ - это аж два байта.

1 байт. 2 - это экзотика.

Отправлено спустя 1 минуту 32 секунды:

МодбасПулу, например, не всё равно - сами легко убедитесь в этом.

До модбаспула и ему подобных биты чётности и прочие биты не доходят. Не его уровень.

[Jackson]

До модбаспула и ему подобных биты чётности и прочие биты не доходят. Не его уровень.

Об этом и речь. Торопился, некорректно написал. Имел в виду что простая проверка на ПК например МодБасПулом покажет.