Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Хотим детектировать аварию на другом конце RS485 шины.
Форум разработчиков электроники ELECTRONIX.ru > Интерфейсы > Форумы по интерфейсам > от ТТЛ до LVDS здесь
SWT-RUS
Сейчас используем чип с автоуправлением (Auto Direction) MAX13487. У него этой фичи (Fault detection) нет. Зато она есть у толпы других максимовских чипов https://para.maximintegrated.com/en/results...ult%20Detection . Комбинированного решения нет. Может кто уже сталкивался с такой необходимостью? Может есть какие то бюджетные способы внешним довеском детектировать аварию?
smalcom
Самовосстанавливающийся предохранитель в цепи питания приёмопередатчика и компаратор?
zltigo
Какое отношение вообще имеет эта практически бесполезная фича к "аварии на другом конце"?




QUOTE (smalcom @ Aug 23 2016, 10:18) *
Самовосстанавливающийся предохранитель в цепи питания приёмопередатчика и компаратор?

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

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

поспешил с выводами, рассмотрел только частный случай.
zltigo
QUOTE (smalcom @ Aug 23 2016, 11:10) *
поспешил с выводами, рассмотрел только частный случай.

sad.gif
Да и эта максимовская фича вообще исключительно для "частных случаев" - фигня маркетинговая sad.gif. То, что она сможет поймать, это отрыв собственно приемопередатчика от линии, при условии, что этот приемопередатчик не терминирован и замыкание линии непосредственно у этого приемопередатчика, но НЕ на дальнем конце. А оно вообще это надо?
gerber
Если "дальний конец" не отвечает - это и есть авария!
SWT-RUS
Цитата(gerber @ Aug 23 2016, 14:03) *
Если "дальний конец" не отвечает - это и есть авария!

Все не так просто в реальной жизни. Есть оборудование которое опрашивается с интервалами от раз в час до раз в сутки. Проблема в том что в работу оборудования постоянно "вмешивается" человеческий фактор, который благодаря оборудования остался без работы - постоянного обслуживания. Оборудование находится в помещениях куда необходимо обеспечить периодичекский доступ персонала. Когда случайно, когда намеренно кабели или отстегиваются или просто перебиваются. И когда в нужный момент ответа не поступает то это действительно и есть авария. Случится это может и через секунду после опроса который раз в сутки. То есть известно о проблеме станет через сутки. То есть люди из помещения уже ушли и туда снова придется отправлять ремонтную бригаду. А это деньги (заказчика). Раньше баловались тем что просто отключали питание - теперь это проблема решена. Оборудование работает еще несколько минут и успевает послать SMS. Тут же следует виртуальный "пинок" по телефону и человек бежит исправлять проблему - он еще не успел далеко уйти.

Мы нашли копеечное решение от TI. Если кому интересно выложу апноту. Мне бы еще что-нибудь аналогичное для RS232 найти. Чтобы хотябы приемником на стороне моено оборудования понимать что чужой передатчик отвалился.
Dmitry Dubrovenko
Цитата(SWT-RUS @ Aug 23 2016, 23:09) *
опрашивается с интервалами от раз в час до раз в сутки
Канэшна дико ызвыняюсь, но что-то ерунда какая-то.
Обмен в системе должен идти гораздо чаще, чем раз в сутки, даже при условии отсутствия какой-либо "полезной" информации.
smalcom
Цитата
Обмен в системе должен идти гораздо чаще, чем раз в сутки

согласен. ведь оборудование может "зависнуть", быть обесточено (как выше уже упоминалось).
rudy_b
Для RS232 можно измерять выходной ток передатчика при отсутствии пакетов. Вход приемника подгрузите несколькими килоомами. При обрыве/закоротке линии ток изменится.
zltigo
QUOTE (SWT-RUS @ Aug 23 2016, 23:09) *
Мы нашли копеечное решение от TI.

Только оно НЕ может является "решеним" хоть в сколь-нибудь общем случае 485 интерфейса. Чудес не бывает.


SWT-RUS
Цитата(zltigo @ Aug 24 2016, 12:51) *
Только оно НЕ может является "решеним" хоть в сколь-нибудь общем случае 485 интерфейса. Чудес не бывает.


Я действительно не уверен что это это будет работать на 100% но хочется верить. Оно действительно не совсем копеечное, но очень компактное если использовать чипы в корпусах VSSOP. Цена от наших китайских поставщиков очень привлекательная. Сможете сразу назвать изъяны решения?
smalcom
Приведённая схема покажет когда отпала "растяжка" линии. Если у вас на всех устройствах стоит "растяжка", то приведённый детектор ниччего не обнаружит.
SWT-RUS
Цитата(smalcom @ Aug 24 2016, 17:27) *
Приведённая схема покажет когда отпала "растяжка" линии. Если у вас на всех устройствах стоит "растяжка", то приведённый детектор ниччего не обнаружит.

У меня к счастью к одному порту подключено всего одно устройство. Поэтому меня этот вариант устраивает.
zltigo
QUOTE (smalcom @ Aug 24 2016, 17:27) *
Приведённая схема покажет когда отпала "растяжка" линии. Если у вас на всех устройствах стоит "растяжка", то приведённый детектор ниччего не обнаружит.

Вообще там используются Fail Safe приемники, которые как раз для того, чтобы УРОДСТВА в виде растяжек НЕ ИСПОЛЬЗОВАЛИ даже те, кто неспособен ничего сделать БЕЗ УРОДСТВА.
Так что сие чудное решение занимающееся дополнительным детектированим входного сигнала в зоне -10..+10 mV вообще неведомо для чего предназначено. Ни для чего реально разумного дополнительное знание, что входное напряжение находится в этой зоне, использовано быть не может.
Оно будет в этой зоне если НЕТ ОБМЕНА и при обрыве линии и при коротком замыкании линии.
alex_zhuravlyov
Цитата(SWT-RUS @ Aug 23 2016, 23:09) *
Когда случайно, когда намеренно кабели или отстегиваются или просто перебиваются. И когда в нужный момент ответа не поступает то это действительно и есть авария.

возможно, более простым вариантом, будет использование еще одного провода в кабеле? на него можно подать какое-то контрольное напряжение и измеряя его детектировать проблему?
khach
Видел параноидальную схему с двумя АЦП на каждую линию 485 шины и двумя ключами на подтягивающие резисторы для подачи тестового тока смещения 10-20ма. Перед этим была схема с двумя компараторами, но она давала слишком много ложных срабатываний. Вариант со встроенным рефлектометром был отвергнут как слишком сложный.
Еще прорабатывался вариант с токовыми датчиками на каждую линию, но отвергнут как нетехнологичный. Схема по мотивам драйвера ADSL линии типа такой

Это все придумывалось для интерфейса энкодера, где пропадание сигнала грозило очень большими неприятностями, а дубляж энкодеров не работал по другим причинам.
smalcom
Мне кажется всю эту сверхзадачу можно решить "токовой петлёй".
Dmitry Dubrovenko
Ребяты, вы о чём?!
Какие третьи провода и токовые петли в 485-м?
А сверхзадача такая легко решается нормальным протоколом. sm.gif
smalcom
почитайте тему. человек хочет именно аппаратное решение. про протокол уже говорили.
Dmitry Dubrovenko
Цитата(smalcom @ Aug 27 2016, 14:23) *
почитайте тему
Сами-то читали?
Человек хочет 485-й.

А вообще, не очень понятно.
Если ТС занимается разработкой, так что мешает как-раз малость подправить в консерватории, т.е. в протоколе?
А если он не занимается разработкой, так что он вообще сможет исправить?
smalcom
Читал конечно
http://electronix.ru/forum/index.php?showt...t&p=1444852
SWT-RUS
Цитата(smalcom @ Aug 27 2016, 18:42) *

Речь идет о сборе данных домовых теплосчетчиков. Кто в курсе тот понимает размер зоопарка протоколов. biggrin.gif
По поводу RS232. Нашлась одна подходящая опция - выход INVALID в чипе MAX3243. Пин идет вниз когда все приемники отдыхают. Но эта косточка 8-миканальная и стоит дороже чем я рассчитывал. Может кто встречал подобное на простых драйверах типа 2 приемника и 2 передатчика?
SWT-RUS
.
smalcom
А вы не пробовали поднимать потенциал общего, который уходит к удалённому устройству... щас набросаю схемку
HardEgor
Цитата(SWT-RUS @ Aug 27 2016, 22:52) *
По поводу RS232. Нашлась одна подходящая опция - выход INVALID в чипе MAX3243. Пин идет вниз когда все приемники отдыхают. Но эта косточка 8-миканальная и стоит дороже чем я рассчитывал. Может кто встречал подобное на простых драйверах типа 2 приемника и 2 передатчика?

там же MAX3221/MAX3223
khach
А что именно предполагается детектировать? Молчание удаленной стороны детектируется протоколом. А вот обрыв одной из жил витой пары, замыкание жил между собой или на землю, отсутствие питания удаленной стороны- события часто встречающиеся и не всегда детектируемые самопрослушкой.
Если линия однонаправленная, то полноценная self health диагностика возможна только со стороны передатчика. Тогда нужна третья линия, чтобы сообщить об ошибке на другую сторону.
При использовании энкодеров (неинтеллектуальный протокол, вернее его отсутствие) и передатчики на удаленной стороне для сообщения об ошибках делали импульсный флуд на линии индекса. Я понимаю, что это не случай ТС, но может какие идеи будут полезными.
При молчащей другой стороне мы проверяли постоянные уровни на линиях при выключенном передатчике. Если питание удаленной стороны включено и там терминиация с подтяжками к питания и земле то по уровням на линии это было видно. Потом переводили линию в активное состояние и подавая 0 и 1 измеряли равенство (симметрию) втекающих и вытекающих токов по дифф линии. На основании этого можно было принять решение об обрыве-кз линии. Потом можно было грубо оценить емкость линии по задержке фронта приемника самопрослушивания относительно фронта передатчика. При этом раздельно измерялась задержка фронтов в дифференциальном канале и по каждой линии относительно общего провода. Был вариант с инжекцией слабого синуса в линию и постоянный контроль емкости линии.
SWT-RUS
Цитата(khach @ Aug 28 2016, 12:42) *
А что именно предполагается детектировать?...

В идеальном случае хотели выловить обрыв хотя бы одной жилы и замыкание в интерфейсах RS232 и RS485.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2024 Invision Power Services, Inc.