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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

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

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

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

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

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

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

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

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