Устройство на RS485 странное поведение Опции

[xoz]

Доброго времени суток!!!
Есть устройство, описание приведено в прикрепленном файле. И ведет себя немножко странно:
Если в сети подключено одно устройство все работает как на алгоритме и без сбоев. Стоит подключить второе устройство оба устройства перестают отвечать. Но если посылать команды то они выполняются.
На данный момент у меня нет устройства чтоб подключить к сети для мониторинга и поэтому что творится на линии не знаю. Посоветуйте в какую сторону копать.

Сообщение отредактировал xoz - Aug 25 2009, 13:50

Эскизы прикрепленных изображений

 

[DpInRock]

описание

Это не описание. Вы ошиблись.

[rezident]

Если "это" интерфейс связи типа RS485, то очевидно, что проблема где-то в реализации протокола и/или управлении направлением драйвера RS485 или таймингами, связанными с этим процессом.

[xoz]

Это не описание. Вы ошиблись.

Безпроблем! Можно называть это как угодно главное я думаю суть понятна.

to rezident: Да это как раз таки на ADM 485 реализовано. С таймингами я довольно долго игрался
Наверно придется собрать чтонить анализирующее линию.

[_Pasha]

С таймингами я довольно долго игрался

У Вас там коллизии случайно не случилось?

[rezident]

С таймингами я довольно долго игрался
Наверно придется собрать чтонить анализирующее линию.

А какой протокол вы используете? Адресация в нем присутствует? Если да, то анализировать линию нет смысла. Оба/все ведомые принимают любой пакет/запрос, но отвечают только в том случае, если сетевой адрес в пакете совпадает с их собственным.
По поводу таймингов могу подсказать, что ведущий должен иметь два настраиваемых параметра:
а) время ожидания ответа ведомого (в него входит время, необходимое для передачи пакета запроса)
б) минимальное время перед началом передачи запроса
Соответственно у ведомого параметры:
а) максимальное время подготовки ответа (от получения запроса до начала передачи пакета ответа)
б) минимальное время перед началом передачи запроса
Дополнительные параметры для обоих (и ведущего и ведомого)
а) время между переключением трансивера RS485 на передачу и собственно началом передачи пакета
б) время удержания трансивера RS485 в режиме передачи после окончания передачи пакета
Реализовав все перечисленные опции, вы сможете поддержать почти любой используемый в сетях RS485 протокол связи типа "запрос-ответ".

[xoz]

А какой протокол вы используете? Адресация в нем присутствует? Если да, то анализировать линию нет смысла. Оба/все ведомые принимают любой пакет/запрос, но отвечают только в том случае, если сетевой адрес в пакете совпадает с их собственным.
По поводу таймингов могу подсказать, что ведущий должен иметь два настраиваемых параметра:
а) время ожидания ответа ведомого (в него входит время, необходимое для передачи пакета запроса)
б) минимальное время перед началом передачи запроса
Соответственно у ведомого параметры:
а) максимальное время подготовки ответа (от получения запроса до начала передачи пакета ответа)
б) минимальное время перед началом передачи запроса
Дополнительные параметры для обоих (и ведущего и ведомого)
а) время между переключением трансивера RS485 на передачу и собственно началом передачи пакета
б) время удержания трансивера RS485 в режиме передачи после окончания передачи пакета
Реализовав все перечисленные опции, вы сможете поддержать почти любой используемый в сетях RS485 протокол связи типа "запрос-ответ".

Да там адресация присутствует.
реализовывал следующим путем(так как только учусь пожалуйста не пинайте)
Расчитал примерное время передачи самого длинного пакета, создал таймер с запасом(период в 2 раза больше времени посылки) и действия разбил по "тик"ам таймера.
Ведущий
1 тик включаю на передачу
2 тик передаю данные
3 тик включаю на прием
4 тик ожидаю данные и отсылаю на обработку
5 тик включаю на передачу

Ведомый
1. включаю на прием жду приема
2. если запрос для меня запускаю таймер
3. 1 тик включаю на передачу
4. 2 тик передаю
5. 3 тик включаю на прием отключаю таймер

Это все без проблем работает если один ведомый

Но скорей всего мне надо будет пересмотреть весь алгоритм

[=AK=]

Да там адресация присутствует.
...
Это все без проблем работает если один ведомый

Расскажите, как реализована адресация.

Kаким образом ведомый знает, что текущая передача идет от мастера, а не от второго ведомого?

[xoz]

Расскажите, как реализована адресация.

Определены командные символы
#define REDY 0xFE //запрос на состояние
#define REPLY 0xF0 //ответ от ведомого
#define COMMAND 0xF5//команда
#define END 0xFA //конец передачи

Запрос на состояние: REDY (адрес 1 байт) END
Ответ от ведомого: REPLY (адрес 1 байт) (данные)END
Команда: COMMAND(адрес 1 байт)(тип действия 2 байта) END

скорость передачи 9600
Максимальная длина пакетов 9 байт

[=AK=]

Определены командные символы

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

[_Pasha]

скорость передачи 9600
Максимальная длина пакетов 9 байт

ПримИте такой протокол

Код

<адрес вызываемого> <длина пакета> <адрес вызывающего> <команда/статус> [данные] <crc8>

И не мучайтесь
Мин размер пакета 5 байт

[=AK=]

ПримИте такой протокол

Непонятно, чем он принципиально лучше. Для него остается в силе мой вопрос: что гарантирует отсутствие ложной реакции ведомого на данные, передаваемые другим ведомым?

[Dog Pawlowa]

Определены командные символы

Кодовая таблица ASCII существует десятки лет, STX, ETX,ETB давно определены и стандартизованы европейскими стандартами.
Обертка пакета тоже давно устоялась.
Но "мы пойдем другим путем!" "Какую будем делать ширину ЖД?"

[=AK=]

Кодовая таблица ASCII существует десятки лет, STX, ETX,ETB давно определены и стандартизованы европейскими стандартами.
Обертка пакета тоже давно устоялась.

Обертка пакета и коды символов - это мелкие "рюшечки", та малая составляющая протокола, которая мало на что влияет. Если у топикстартера фундаментальная проблема с протоколом, то смена этих рюшечек ему точно совсем никак не поможет.

[SSerge]

"Какую будем делать ширину ЖД?"

Как в Модбасе?
или на 89 миллиметров шире?

[DpInRock]

Тогда все понятно.
Вы делаете сеть. Физический уровень вам делает микросхема. А вот канальный вы даже и не думали делать. Сразу перепрыгнули на уровень приложения.
Люди вовсе не от скуки рисуют многоуровневую систему протоколов для сетевого общения.

[Dog Pawlowa]

Если у топикстартера фундаментальная проблема с протоколом, то смена этих рюшечек ему точно совсем никак не поможет.

Конечно, это брюзжание

У топикстартера проблема с инструментарием.
Осциллограф позволит узнать, кто послал посылку, кто ее получил, кто не получил, а кто зажал ответ.
Нет осциллографа - светодиоды помогут.
Нет светодиодов - тестер (проверить сигнал направления после посылок).
Нужно учиться отлаживать программу и находить собственные ошибки. Любым доступным способом.

Ничего нет - ну что ж - будем учить строить автоматы состояний приемо-передачи.
Типа такого...  Dmb_mast.pdf ( 23.2 килобайт ) Кол-во скачиваний: 260


Легкой жизни не будет!

[MrYuran]

Легкой жизни не будет!

Ну почему, если подключили второе устройство и всё упало - то тут всё просто.
У нас круче было.
512 модулей в сети RS-485 (только не говорите, что это невозможно), управляют решёткой ФАР.
Всё работает. Но есть одна команда, которая загружает в память модуля массив из 8кБ.
И каждый раз на одном и том же байте (где-то после первой тысячи) происходит сбой и пара-тройка байт пишется с ошибками.
И что только не пробовали.
Согласовывали, резисторы вешали, земли выравнивали, даже конденсатор вешали (крайняя мера, всегда помогало!)
А тут ни в какую.
Дело происходило в последний день (вернее, уже ночь) перед сдачей (или несдачей) системы.
На кону пара сотен миллионов (рублей).
Из 6 присутствующих трое были начальники отделов, и они жутко мотивировали.
Иногда забегал зам главного инженера и тоже добавлял мотивации.

Помог крутой ажилент (тогда ещё HP) за $7000, с памятью на мегасемпл и функцией мегазум.
Рассмотрели коллизию, поняли причину.

Рвали волосы, посыпали головы пеплом...

[Dog Pawlowa]

даже конденсатор вешали (крайняя мера, всегда помогало!)

да ... Действительно все меры ...

[xoz]

Легкой жизни не будет!

О легкой жизни и не мечтал

Тогда все понятно.
Вы делаете сеть. Физический уровень вам делает микросхема. А вот канальный вы даже и не думали делать. Сразу перепрыгнули на уровень приложения.
Люди вовсе не от скуки рисуют многоуровневую систему протоколов для сетевого общения.

О канальном уровне где можно посмотреть? Хотяб краткое разъяснение что это и зачем.

[_Pasha]

Непонятно, чем он принципиально лучше.

Тьфу! Забыл. Там был 9-битный протокол. Адрес, соотв. с 9-битом == 1.

Для него остается в силе мой вопрос: что гарантирует отсутствие ложной реакции ведомого на данные, передаваемые другим ведомым?

Адрес получателя.

[rezident]

О канальном уровне где можно посмотреть? Хотяб краткое разъяснение что это и зачем.

Сетевая модель OSI

[=AK=]

Тьфу! Забыл. Там был 9-битный протокол. Адрес, соотв. с 9-битом == 1.

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

[_Pasha]

Для полного счастья ему не хватает только преабулы перед первым байтом (адресом) и жестко оговоренных таймаутов

Таймаут общий за счет того, что слейвы обязаны ответить.
А про прембулу перед адресом - не понял, зачем?
ЗЫ: в первом посте о протоколе - забыл отдельно сказать, что слейв отвечает так же, только вместо команды выдает статус

Код

<адрес> <длина пакета> <адрес отправителя> <статус> [данные] <CRC8>

ЗЗЫ: адрес общего вызова 0х00. Если пакет подписан адресом отправителя 0х00, то на него никто из слейвов не имеет права отвечать.

[Rst7]

А про прембулу перед адресом - не понял, зачем?

Ну например в виде байта 0xFF для борьбы с шумами линии, когда она в неактивном состоянии. После передачи 0xFF все приемники станут в одинаково готовое состояние для приема байта адреса в независимости от предыдущих помех на линии.

[=AK=]

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

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

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

[_Pasha]

Спасибо, понятно. Я это давным-давно обозвал "продувкой линии" и теория потому прошла мимо.