ADM485 и ADM2490E в параллель не работают, Проблема с RS485 Опции

[DmitryDI]

Возникла проблема: на шину RS485 подключины приемники сигналов на микросхемах ADM485 и ADM2490E через 60м после источника сигнала, еще через 40м опять подключены два эти устройства, причем устройство на ADM485 на срабатывает. Пробовали и без согласующих резисторов и с ними. В чем проблема?

[firstvald]

Возникла проблема: на шину RS485 подключины приемники сигналов на микросхемах ADM485 и ADM2490E через 60м после источника сигнала, еще через 40м опять подключены два эти устройства, причем устройство на ADM485 на срабатывает. Пробовали и без согласующих резисторов и с ними. В чем проблема?

RS485 требует, на самом деле, дополнительной растяжки линий со стороны драйвера (Символьные протоколы иногда сдуру работают без этого, чисто байтовые - никогда(ну может только при передаче в одну сторону всегда и при условии что передатчик всегда занимает линию) ). Эти требования описаны в протоколе MODBUS (если заглянете на сайт modbus.org, то документ modbus over serial line, так кажется документ называется). Линию A надо затянуть на +5 на стороне передатчика через 500-600 Ом. Линию B в землю через такой же резистор. Между ними согласующий резистор в 120 Ом. И на другом конце согласующий резистор. Но, на практике возникает такая штука - линия , сопротивление транзисторов драйвера, какие то элементы защиты на стороне передатчика образуют такой делитель, что до приемника не доходит нужной разницы напряжений. В этом случае просто увеличиваем резисторы согласования Ом до 200-300.

[rezident]

В чем проблема?

Как подключена ADM2490E к линии RS485? Должны быть попарно соединены A с Y и B с Z. У вас так сделано?

RS485 требует, на самом деле, дополнительной растяжки линий со стороны драйвера (Символьные протоколы иногда сдуру работают без этого, чисто байтовые - никогда(ну может только при передаче в одну сторону всегда и при условии что передатчик всегда занимает линию) ). Эти требования описаны в протоколе MODBUS (если заглянете на сайт modbus.org, то документ modbus over serial line, так кажется документ называется).

Не грузите других ложными сведениями! "Растяжка" линий RS485 не является необходимым атрибутом ни интерфейса, ни RTU-ных протоколов. Даже MODBUS. Целостность передачи пакета обеспечивается необходимыми временными паузами до начала передачи и после окончания передачи пакета. Процедура такая
а) исходно трансиверы RS485 всех узлов находятся в режиме приема
б) трансивер RS485 передающего узла включается на передачу
в) выдерживается пауза на время установления переходного процесса в линии RS485
г) идет передача пакета
д) не выключая передатчика RS485, выдерживается пауза, необходимая для детектирования приемниками других узлов конца пакета
е) трансивер RS485 переключается в режим приема
И никаких растяжек при этом не требуется

[Harbinger]

Растяжки требуются (не всегда), чтобы избежать состояния break (ноль на RXD) в паузах (когда все трансиверы стоят на приёме).

[DmitryDI]

Как подключена ADM2490E к линии RS485? Должны быть попарно соединены A с Y и B с Z. У вас так сделано?
Не грузите других ложными сведениями! "Растяжка" линий RS485 не является необходимым атрибутом ни интерфейса, ни RTU-ных протоколов. Даже MODBUS. Целостность передачи пакета обеспечивается необходимыми временными паузами до начала передачи и после окончания передачи пакета. Процедура такая
а) исходно трансиверы RS485 всех узлов находятся в режиме приема
б) трансивер RS485 передающего узла включается на передачу
в) выдерживается пауза на время установления переходного процесса в линии RS485
г) идет передача пакета
д) не выключая передатчика RS485, выдерживается пауза, необходимая для детектирования приемниками других узлов конца пакета
е) трансивер RS485 переключается в режим приема
И никаких растяжек при этом не требуется

Спасибо за информацию.
ADM2490E и ADM485 соеденены A к A и B к В - они работают на прием и только слушают сигнал в линии. Скорее всего накосячили монтажники. Сегодня собрал все на столе - взял кабель 52 м. - все работает даже без терминаторов.

[firstvald]

Как подключена ADM2490E к линии RS485? Должны быть попарно соединены A с Y и B с Z. У вас так сделано?
Не грузите других ложными сведениями! "Растяжка" линий RS485 не является необходимым атрибутом ни интерфейса, ни RTU-ных протоколов. Даже MODBUS.

Читать стандарт. Смотреть на мекете. И не вводить в заблуждение других.

Растяжки требуются (не всегда), чтобы избежать состояния break (ноль на RXD) в паузах (когда все трансиверы стоят на приёме).

Растяжки нужны в общем случае всегда. Иначе, даже на символьном протоколе, в том случае, если перед посылкой не выдаются несколько фиктивных байт, UART приемника может не понять первого байта из-за того, что при занятии линии передатчиком в линии может быть все что угодно. Я уже указал, что без растяжек теоретически можно обойтись, если драйвер все время занимает линию. Но, на практике стандарты modbus и profibus, использующие RS485, требуют растяжки (поляризации). В profibus даже требуется поляризация как на передающем, так и на удаленном конце линии.

Сообщение отредактировал firstvald - Dec 17 2009, 12:19

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

 

[rezident]

Читать стандарт. Смотреть на мекете. И не вводить в заблуждение других.

Хотите прослыть самым просвещенным, тогда прочитайте раздел 3.4.6 Line Polarization и дайте цитатку, где написано что растяжка не просто желательна (чтобы не ловить мусор с линии), а именно обязательна для применения. Причем обязательна для каждого узла, а не желательна для всей сети в целом.

Растяжки нужны в общем случае всегда.

В общем случае растяжка лишь слегка облегчает жизнь программисту, но при этом ухудшает балансировку (волновое согласование) линии и устойчивость к синфазным помехам (особенно на длинных дистанциях). А также уменьшает надежность узла приемопередатчика, т.к. требует коммутации (конфигурации) каждого узла в отдельности. Т.е. это "костыль" для программиста, а не обязательное требование стандарта (EIA/TIA-485-A).

Я уже указал, что без растяжек теоретически можно обойтись, если драйвер все время занимает линию.

В своем сообщении #3 я указал алгоритм управления драйвером RS485 при котором растяжка не требуется. Более того, я настаиваю, что любой алгоритм передачи в сети RS485 должен учитывать эти паузы, а софт должен сразу подразумевать настраиваемые таймауты. Мы неоднократно уже сталкивались с тем, что сторонним разработчиком приходилось "допиливать" свой софт, добавляя эти задержки. Особенно в тех случаях, когда софт изначально разрабатывался и тестировался для RS-232, а потом просто в схеме трансивер RS232 заменялся на трансивер RS485 (или ставился в дополнение к первому).

[firstvald]

Так потому и приходится допиливать софт, что вы свою сеть по своему организовали! И что делать с простейшей штучкой, как преобразователь RS232-485? Он линию займет только когда от компа через него посылка пойдет. Или вы его будете дергать 3 ногой через RTS?

[Guest_@Ark_*]

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

Растяжка (точнее - защитное смещение), конечно, не является обязательной по стандарту. Но ее отсутствие, по мимо неудобства программирования, дает ряд неприятных моментов:
1) В паузах (когда все передатчики выключены) может наблюдаться "мусор" на линии, который все устройства вынуждены обрабатывать, отвлекая на это свои ресурсы.
2) Возможно самопроизвольное возникновение состояния "Break" на линии. Поэтому, будет невозможно использовать эту функцию для каких-то полезных целей. А там, где она необходима - будет невозможно использовать такую линию.
3) Выдержка дополнительной паузы от включения приемника до начала передачи, приводит к дополнительным временным издержкам при обмене, что снижает общий трафик.
4) В системе со многими ведущими усложняется определение занятости линии и увеличивается время разрешения конфликтов.
Вывод простой: Хотя защитное смещение и не обязательно по стандарту, его отсутствие может заметно снизить эффективность канала и, как следствие, всей системы в целом. Поэтому, чтобы от него отказаться - нужны серьезные аргументы в пользу такого решения.

[rezident]

Так потому и приходится допиливать софт, что вы свою сеть по своему организовали!

Откуда такой вывод последовал?

И что делать с простейшей штучкой, как преобразователь RS232-485? Он линию займет только когда от компа через него посылка пойдет. Или вы его будете дергать 3 ногой через RTS?

В тех конверторах-репитерах RS232-RS485-RS485, что я проектировал, дополнительных сигналов управления не требуется. Хотя не отрицаю, что опциональная растяжка там предусмотрена.

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

Блин! Да не отказаться от растяжки. Используйте ее на здоровье, если вам хочется/требуется. Я всю полемику веду к тому, что нужно так проектировать устройство, чтобы оно и без растяжки работало! Потому, что растяжка линии RS485 опциональна. Неужели я непонятно поясняю?

[Guest_@Ark_*]

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

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

[rezident]

Нет, не нужно так проектировать. В большинстве случае, проще и правильнее поставить растяжку, чем добиваться чтобы все работало и без нее.

Вольному воля... И я почему-то не очень удивляюсь такому принципу, а также тому факту, что при таком подходе потом софт "допиливать" приходится.
В качестве примера могу привести зеленоградский радиомодем Спектр в котором таки наконец ввели упомянутые мной паузы-таймауты, и теперь многие проблемы, связанные с особенностями обмена радиомодем<->сеть RS485, устраняются простым конфигурированием таймаутов в самом радиомодеме.

[Guest_@Ark_*]

И я почему-то не очень удивляюсь такому принципу, а также тому факту, что при таком подходе потом софт "допиливать" приходится.

А это с какой стороны посмотреть. Не всегда есть возможность "софт допилить" или устройство доработать. И при переходе, например, с RS232 на RS485 заниматься адаптацией конечных устройств или программ на ПК к особенностям канала, я считаю совершенно неправильным подходом. Подробности процесса обмена по каналу его конечных "пользователей" (устройств, программ) никак касаться не должны. По возможности, конечно. В идеале все должно работать как и работало, не замечая смены канала. Без дополнительных таймаутов и перенастроек.

[Harbinger]

2) Возможно самопроизвольное возникновение состояния "Break" на линии.

Бодался как раз с этим.
МК серии LPC900 имеют вроде полезную фичу - по breakdetect запускается бутлоадер. Но очень интересно получается, когда бутлоадера нет, а вектор прописан. Влетает невесть куда.

[rezident]

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

Извините, но это утверждение сродни надеждам, что при смене пола с мужского на женский транссексуал сможет зачать и родить ребенка. Чтобы софт "ничего не заметил" недостаточно только лишь одной замены трансивера. В то время как при разумном написании софта, заранее предполагая различия в линиях и интерфейсах связи, чаще всего можно действительно обойтись только лишь заменой трансивера. Кстати, если вы не догадываетесь, то при необходимости (за надобностью) значения задержек можно сделать равными нулю

[Guest_@Ark_*]

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

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

[rezident]

Конечно, для управляющих программ на ПК, это особо ничего не стоит. А вот для простых конечных устройств на МК такая универсальность может вылиться в существенное увеличение их стоимости.

Отнюдь! Софтовая настройка/адаптация имеет только временные затраты, а аппаратный универсализм обходится весьма недешево еще и в материальном плане.

[Guest_@Ark_*]

Отнюдь! Софтовая настройка/адаптация имеет только временные затраты, а аппаратный универсализм обходится весьма недешево еще и в материальном плане.

Так я именно об этом и говорю: аппаратный универсализм - например, работа по RS485 как с растяжкой так и без нее - обходится весьма не дешево...

[rezident]

Так я именно об этом и говорю: аппаратный универсализм - например, работа по RS485 как с растяжкой так и без нее - обходится весьма не дешево...

Я вашу терминологию видимо не совсем понимаю. Я лично под "аппаратным универсализмом" подразумеваю аппаратные издержки (доработки, схемотехнические ухищрения - ту же самую отключаемую растяжку RS485), необходимые для устойчивой работы устройства при одном и том же софте, не имеющем программных настроек для разного типа интерфейсов.
Мне, например, сегодня техник, обслуживающий пожарные датчики в нашем здании, пожаловался. Отечественные адресные датчики дыма имеют ДИП-переключатели для настройки адреса, поэтому приходится к каждому под потолок лазить и адреса вручную выставлять. Аналогичные немецкие (вроде) имеют программную настройку адресов и после монтажа достаточно одну кнопку нажать для регистрации его в системе. Конечно же, импортные стоят дороже, ибо за удобство и бренд нужно платить. Но себестоимость электроники у тех и других примерно одинаковая. То бишь получается, что всего лишь "продуманность" софта позволяет создавать дополнительную стоимость.

Сообщение отредактировал rezident - Dec 18 2009, 19:42

[Guest_@Ark_*]

Я вашу терминологию видимо не совсем понимаю...

Если растяжка в устройстве должна подключаться/отключатся по ситуации - то это уже не аппаратный универсализм, с моей точки зрения. Это скорее аппаратная адаптация - пользователь (установщик) должен ее делать "руками", понимая для чего и зачем. Аппаратный универсализм - это когда есть ли растяжка или ее нет -
все едино. Программное обеспечение устройства должно брать на себя все издержки такого решения.

Мне, например, сегодня техник, обслуживающий пожарные датчики в нашем здании, пожаловался. Отечественные адресные датчики дыма имеют ДИП-переключатели для настройки адреса, поэтому приходится к каждому под потолок лазить и адреса вручную выставлять. Аналогичные немецкие (вроде) имеют программную настройку адресов и после монтажа достаточно одну кнопку нажать для регистрации его в системе.

Ну и совершенно правильно, назначение адресов в системе - совсем не дело монтажника. В данном случае, дип переключатели - это не универсальность, а бестолковое решение...

[rezident]

Универсальный - подходящий ко всем случаям. Если что-то нужно менять/подключать/отключать/регулировать в железе/аппаратуре, то это уже не аппаратный унивесализм. Если под одно и то же железо (аппаратный UART в обсуждаемом случае) нужно менять софт, то это не софтовый универсализм.
И вообще предлагаю закончить обсуждение. Топикстартер ответ на свой вопрос уже получил, а мы тут получается оффтопим.

[Guest_@Ark_*]

И вообще предлагаю закончить обсуждение. Топикстартер ответ на свой вопрос уже получил, а мы тут получается оффтопим

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