Перейти к содержанию
    

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

Доброго времени суток!!!

Есть устройство, описание приведено в прикрепленном файле. И ведет себя немножко странно:

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

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

post-42655-1251208011_thumb.jpg

Изменено пользователем xoz

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

to rezident: Да это как раз таки на ADM 485 реализовано. С таймингами я довольно долго игрался :wacko:

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

А какой протокол вы используете? Адресация в нем присутствует? Если да, то анализировать линию нет смысла. Оба/все ведомые принимают любой пакет/запрос, но отвечают только в том случае, если сетевой адрес в пакете совпадает с их собственным.

По поводу таймингов могу подсказать, что ведущий должен иметь два настраиваемых параметра:

а) время ожидания ответа ведомого (в него входит время, необходимое для передачи пакета запроса)

б) минимальное время перед началом передачи запроса

Соответственно у ведомого параметры:

а) максимальное время подготовки ответа (от получения запроса до начала передачи пакета ответа)

б) минимальное время перед началом передачи запроса

Дополнительные параметры для обоих (и ведущего и ведомого)

а) время между переключением трансивера RS485 на передачу и собственно началом передачи пакета

б) время удержания трансивера RS485 в режиме передачи после окончания передачи пакета

Реализовав все перечисленные опции, вы сможете поддержать почти любой используемый в сетях RS485 протокол связи типа "запрос-ответ".

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А какой протокол вы используете? Адресация в нем присутствует? Если да, то анализировать линию нет смысла. Оба/все ведомые принимают любой пакет/запрос, но отвечают только в том случае, если сетевой адрес в пакете совпадает с их собственным.

По поводу таймингов могу подсказать, что ведущий должен иметь два настраиваемых параметра:

а) время ожидания ответа ведомого (в него входит время, необходимое для передачи пакета запроса)

б) минимальное время перед началом передачи запроса

Соответственно у ведомого параметры:

а) максимальное время подготовки ответа (от получения запроса до начала передачи пакета ответа)

б) минимальное время перед началом передачи запроса

Дополнительные параметры для обоих (и ведущего и ведомого)

а) время между переключением трансивера RS485 на передачу и собственно началом передачи пакета

б) время удержания трансивера RS485 в режиме передачи после окончания передачи пакета

Реализовав все перечисленные опции, вы сможете поддержать почти любой используемый в сетях RS485 протокол связи типа "запрос-ответ".

Да там адресация присутствует.

реализовывал следующим путем(так как только учусь пожалуйста не пинайте)

Расчитал примерное время передачи самого длинного пакета, создал таймер с запасом(период в 2 раза больше времени посылки) и действия разбил по "тик"ам таймера.

Ведущий

1 тик включаю на передачу

2 тик передаю данные

3 тик включаю на прием

4 тик ожидаю данные и отсылаю на обработку

5 тик включаю на передачу

 

Ведомый

1. включаю на прием жду приема

2. если запрос для меня запускаю таймер

3. 1 тик включаю на передачу

4. 2 тик передаю

5. 3 тик включаю на прием отключаю таймер

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Да там адресация присутствует.

...

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

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

 

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 байт

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

скорость передачи 9600

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

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

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

И не мучайтесь :)

Мин размер пакета 5 байт

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Обертка пакета тоже давно устоялась.

Но "мы пойдем другим путем!" "Какую будем делать ширину ЖД?"

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Обертка пакета тоже давно устоялась.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Как в Модбасе?

или на 89 миллиметров шире?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...