Modbus RTU RS-485

[Tatiana]

Уважаемые профессионалы!
Подскажите пожалуйста, как можно обойти такую ситуацию:
Есть сеть RS-485, интерфейс MODBUS RTU, несколько slave и мастер, который опрашивает их последовательно. Slave - промышленный компьютер, RS-485 подключен к PCI -плате, расширителю последовательных портов BlueStorm/SP Opto (Connect Tech ). Пользователь при настройке сети упорно устанавливает одинаковые адреса у двух Slave-ов, и программа промышленного компьютера зависает.
Вопрос, как может Slave вычислить такую ситуацию и сформировать сообщение об ошибке?

[Jackson]

как может Slave вычислить такую ситуацию

Никак, от слова "совсем". Slave ничего не знает о других устройствах в сети ModBUS и узнать это у него нет никаких шансов.

и сформировать сообщение об ошибке?

Ответ выше.
В наших контролера в Slave есть ошибка таймаута: нет принятых корректных телеграмм в течение заданного времени - ошибка связи. Косвенно обращает внимание персонала на то что есть проблемы и надо идти разбираться. Но в случае дублированного Slave-адреса телеграммы будут приниматься корректно и не поможет даже это.

Пользователь при настройке сети упорно устанавливает одинаковые адреса у двух Slave-ов, и программа промышленного компьютера зависает.

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

Аналогично ситуации, когда первый же залетевший в дом дятел вызывает обрушение всего дома (когда этот дом строили криворукие программисты).

Отправлено спустя 1 час 28 минут 59 секунд:
Зависающая программа - это проблема программы, и не надо искать причины где-то в других местах. Нормальная программа, если сам ПК исправен, работает без остановки 24/7/365 и обрабатывает все ошибки периферии сама. Обработка ошибок - это тоже нормальная эксплуатация.

[Serex]

Вопрос, как может Slave вычислить такую ситуацию и сформировать сообщение об ошибке?

Теоретически можно такое провернуть, но для этого нужен толковый программист и эта задача явно выходит за возможности протокола Modbus RTU.
Если опрос Slave периодический, то можно с некоторыми интервалами делать паузу в ответах и слушать, что происходит на шине.
Если там есть какой-то другой ответ на опрос с нужным адресом, то формировать ошибку.

программа промышленного компьютера зависает.

Как может Slave зависать?!?! Присоеднись к мнению Jackson - это кривая программа. Видимо она начинает обрабатывать новые прерывания от Com-порта, пока не завершились старые. Все это уходит в бесконечную рекурсию и "Да восславиться Ctrl-Alt-Delete". Try..catch программист тот явно не знает ))

[Jackson]

Как может Slave зависать?!?!

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

[GrayCat]

Вообще, чисто физически возможность обнаружить коллизию при передаче в RS-485 есть: для этого нужно передающему слэйву слушать самого себя, и сравнивать "что переданно" и "что реально в линии". Но, это нужно чтобы:

1. аппаратно приёмник 485 не выключался на время передачи (а во многих схемах линия выключения приёмника объединена с сигналом включения передачи) ;
2. драйвер со стороны ОС поддерживал вычитывание во время передачи;
3. ну и в прикладной программе предусмотреть это дело.

Если речь о микроконтроллерных модулях своей разработки, то тут такое можно сделать. А в "фирменных" решениях -- вряд ли.

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

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

Есть версия, что это там настройка UART-а "с чётностью". Тогда при коллизии передачи от двух слейвов, обязательно будет портиться чётность у байтов, и вот тут уже воврос, как драйвер и прикладная программа обрабатывают такие "порченные" байты.

[Tatiana]

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

А вот как программно бороться с кривой сетью, и как доказать, что она кривая...

Есть версия, что это там настройка UART-а "с чётностью". Тогда при коллизии передачи от двух слейвов, обязательно будет портиться чётность у байтов, и вот тут уже воврос, как драйвер и прикладная программа обрабатывают такие "порченные" байты.

Нет, без четности, два стоп-бита

[Jackson]

Прям страшно, до чего не любят бедных программистов.

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

Вопрос как раз был от программиста.

Ну, значит ответ по адресу дошёл. :) Извините если резковато, но зато правда. Если бы Вы то же самое спросили у наладчиков в процессе сдачи объекта, то ответ был бы таким что его тут нельзя публиковать (цензура). Это правда жизни.

Давайте разбираться. Ответная телеграмма слейва содержит в себе контрольную сумму. Когда два слейва одновременно работают на передачу, то обе телеграммы (от одного и от другого) неминуемо искажаются так, что контрольная сумма точно не совпадёт. Мастер получает недействительную телеграмму (с неверной контрольной суммой) и просто её игнорирует, считает что ничего не получил.
А если телеграмма приходит вдруг сама по себе (телеграмма принята, разобрана, но данные продолжают поступать) - всё это тоже игнорируется. Нарушена последовательность бит (один стоп-бит например потерялся) - игнорируется. Телеграмма не соответствует запросу (например запросили содержимое 10-ти регистров, а получили в ответ значения 5-ти или 15-ти регистров) - игнорируется. В общем, игнорируется всё, кроме ожидаемого ответа. А раз ответ на запрос не получен - ошибка таймаута. Запрос повторяется заданное кол-во раз, и если корректный ответ так и не получен - значит с устройством связь потеряна. Генерируете аларм по этому поводу (или выставляете флаг - не знаю, что Вы программируете) и пусть персонал идёт разбирается.
Разве так нельзя сделать?

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

Что программируете, если не секрет?

[MuadDib]

В лаборатории два таких слейва с одинаковыми адресами живут дружно, хором отвечают Modtest-у.

А вот как программно бороться с кривой сетью, и как доказать, что она кривая...

Не надо бороться с кривой сетью. Проблема скорее всего в софте. Вы работаете с коммуникационным портом. Следует всегда ожидать, что из него могут прийти "кривые" данные. В вашем случае источником стал включенный параллельно слейв с тем же адресом, но это частный случай. Помехи, не то устройство подключили, поврежденный порт у одного из устройств на шине - да что угодно. Программа не должна зависать от некорректных входящих данных, каким бы ни был их источник.

Не зная, что у вас за система (какая ОС? какой драйвер используется?), о причинах глюка можно гадать до бесконечности. Если вы пишете только прикладную программу и используете готовый драйвер последовательного порта, то вы не работаете напрямую с такими вещами, о которых пишут коллеги выше (прерывания, старт- и стоп-биты и т.д.). В таком случае вам надо провести ревью собственного кода и попытаться понять, может ли ваш прикладной код в принципе зависать при некорректных входных данных. Раз не удается воспроизвести проблему у себя, можно попытаться создать подробные логи на системе у заказчика для изоляции бага (если отношения с заказчиком позволяют). Параллельно имеет смысл написать производителю BlueStorm/SP Opto. Возможно, они сталкивались с чем-то подобным, и у них есть обновленные драйверы на такой случай.

Если же у вас самописный драйвер (или вы работаете под чем-нибудь типа MS DOS), в первую очередь надо анализировать ваш собственный драйверный код. Судя по описанию, эта плата последовательных портов очень навороченная, и от нее можно ожидать различные проблемы.

[Jackson]

Не надо бороться с кривой сетью.

Вот это главное. Не надо бороться с внешним миром. Программа должна работать в тех условиях которые есть, а они могут быть разные. Ключевое слово - работать. Дублированные слейвы на модбасе - это далеко не единственная из прелестей, которые случаются на объектах постоянно, и это не приводит к зависанию контроллеров и компов. Павел Евгеньевич всё верно выше написал. Шерстите код. На объект такое поставлять нельзя (и показывать тоже нежелательно - репутация упадёт до плинтуса).