[rezident 0]

Разруливается весьма легко: У каждого устройства свой период повторной передачи в случае неполучения подтверждения.

Хе-хе. А как же это согласуется с вашим требованием минимальной задержки передачи любого сообщения? ;)

[Diusha 0]

Хе-хе. А как же это согласуется с вашим требованием минимальной задержки передачи любого сообщения? ;)

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

[bill_vs 0]

А сколько устройств на линии по максиму? Может и проблемы нет…

 

Вам надо определять исправность удалённых устройств? При опросе это получается почти даром.

[Diusha 0]

А сколько устройств на линии по максиму? Может и проблемы нет…

 

Вам надо определять исправность удалённых устройств? При опросе это получается почти даром.

Устройств немного - от 2 до 10 (периферийных). Надо определять наличие их.

Проблемы в смысле "беда", конечно, нет. Есть проблема в смысле "задача", для решения которой надо взвесить все ЗА и ПРОТИВ, а для этого услышать побольше мнений.

Изменено 23 февраля, 2010 пользователем Diusha

[Andron_ 0]

тут вот так вот на пальцах можно бесконечно долго рассуждать...

 

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

 

а то можт у вас у одного устройства пакет 25кБ, а у другого 10 байт...

[bill_vs 0]

... Есть проблема в смысле "задача", для решения которой надо взвесить все ЗА и ПРОТИВ, а для этого услышать побольше мнений.

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

 

Первый вариант (все - мастера) значительно сложнее программно.

Второй проще.

Если у Вас максимум 10 устройств и время доставки должно быть 50 мс, значит на каждый опрос не более 5 мс. При скорости 19200 можно отправить ответ около 8 байт. Хватит? Сколько надо?

Если надо 1000 байт, то при одновременном возникновении желания поговорить с главным, за 50 мс надо передать 10000 байт. Т.е. скорость должна быть более 0.2 Мбит/с. А с коллизиями и того больше…

[ASN 0]

Diusha

А если длина линии (в смысле ёмкость) большая? Её "пробить" надо. Простыми резисторами в этом случае не обойдёшься.

Алгоритм работы простой:

- опрос состояний всех устройств (их два - длинный адрес при инициализации и короткий в рабочем цикле);

- ответ каждого устройства словосостоянием (4 байт обычно достаточно) (после получения запроса все slave отключают приём на фиксированное время - один выходил на передачу);

- при необходимости запрос дополнительных данных от выбранного устройства.

Про "отрисовку".

Кто является мастером? ПЭВМ? Работает под Win? Время реакции Win (со слов системного программиста) около 50 мс + всякие графические примочки.

На круг обычно выходит около 1 секунды. За это время можно переслать уйму данных.

Узким местом, как правило, оказывается "человеческий фактор" - оператор просто не успевает обрабатывать такой поток информации.

IMHO, Вам предоставили достаточно информации, чтобы принять правильное решение ;)

[Diusha 0]

IMHO, Вам предоставили достаточно информации, чтобы принять правильное решение ;)

Да! Информации достаточно. Склонился в сторону 2-го варианта, на самом деле уже давно, специально не говорил ;)

Самый веский аргумент, ИМХО:

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

Всем большое спасибо! :beer:

[galjoen 0]

Если так боитесь коллизий и скорость передачи у вас небольшая - включите драйвера RS-485 так, чтобы они только 0 передавали, а 1 за счёт резисторных растяжек формировалась.

По крайней мере гляньте на автомобильный стандарт J1708. Там драйвера RS-485 именно так включены. К плюсам такого решения ещё и возможность мультимастерности и соединения сети звездой. А расплата за это всего одна - скорость 9600. Но работает, в непростых автомобильных условиях, очень стабильно. Если скорость устроит, то ИМХО для вас это лучший вариант.

[Ruslan1 17]

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

 

Назовите мне модель драйвера RS-485, для которого коллизия является нештатной и который от этого крякнется. Я эту фирму буду обходить стороной. :)

 

Как правило в даташите пишут нечто подобное (это из ST485): "Current limiting and thermal shutdown for driver overload protection".

 

так что производители гарантируют.

[Сергей Борщ 132]

Назовите мне модель драйвера RS-485, для которого коллизия является нештатной и который от этого крякнется. Я эту фирму буду обходить стороной. :)

У Sipex в даташитах специфицирован только ток КЗ по выходу и макс. рассеиваимая мощность корпуса. Про коллизию не нашел ни в одном даташите. Есть защита от КЗ, но это как бы совсем не коллизия.

Обходите.

 

Как правило в даташите пишут нечто подобное (это из ST485): "Current limiting and thermal shutdown for driver overload protection".

 

так что производители гарантируют.

Согласен, многие гарантируют.

И тем не менее: вы считаете, что доводить систему до срабатывания защиты - это нормально? Или вы считаете, что возможные периодические временные отказы связи из-за thermal shutdown - это штатный режим работы системы?

[Diusha 0]

включите драйвера RS-485 так, чтобы они только 0 передавали, а 1 за счёт резисторных растяжек формировалась.

А не знаете, нет ли микосхемки, совместимой по выводам с МАХ485, только с открытым коллектором?

 

Назовите мне модель драйвера RS-485, для которого коллизия является нештатной и который от этого крякнется. Я эту фирму буду обходить стороной. :)

 

Как правило в даташите пишут нечто подобное (это из ST485): "Current limiting and thermal shutdown for driver overload protection".

Из портянки на МАХ485:

"Drivers are short-circuit current limited and are protected against excessive power dissipation by thermal shutdown circuit"

Провел эксперимент: замкнул А и В. Секунд через 7 микросхема (в ДИПе) нагрелась градусов до 45, дальше температура не росла; thermal shutdown не было; ток 100 мА.

Не лучший вариант...

 

Из той же портянки:

"The receiver input has a fail-safe feature that guarantees a logic-high output if the input is open circuit."

Я правильно понял, имеется в виду, что если линия болтается в воздухе, то "фича гарантирует", что на выходе приемника болтанки не будет? Но тогда непонятно, как фича догадается, что это наводки, а не сигнал?

[Ruslan1 17]

У Sipex в даташитах специфицирован только ток КЗ по выходу и макс. рассеиваимая мощность корпуса. Про коллизию не нашел ни в одном даташите. Есть защита от КЗ, но это как бы совсем не коллизия.

Обходите.

 

Согласен, многие гарантируют.

И тем не менее: вы считаете, что доводить систему до срабатывания защиты - это нормально? Или вы считаете, что возможные периодические временные отказы связи из-за thermal shutdown - это штатный режим работы системы?

1. про Sipex: Спасибо за информацию, это для меня новость. Такие микросхемы просто нельзя применять. Так как в случае замыкания линии, что вполне вероятно и периодически случается в полевых условиях, система выйдет из строя.

2. Коллизии и КЗ: Это разные уровни модели :) Если спуститься на физический уровень, то для RS-485 коллизией является в том числе и КЗ, так как передача одновременно нуля и единицы в линию двумя драйверами приводит к замыканию линии через выходные каскады этих драйверов (источники тока).

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

Кстати, до такого перегрева довести драйвера простейшими короткими коллизиями вряд ли получится, тут считать нужно.

[Andron_ 0]

2Ruslan1

 

Т.о. вы считаете, что система может строиться из расчета, что коллизии являются нормальным режимом логики, а драйверы их выдержат?

[Ruslan1 17]

Из портянки на МАХ485:

"Drivers are short-circuit current limited and are protected against excessive power dissipation by thermal shutdown circuit"

Провел эксперимент: замкнул А и В. Секунд через 7 микросхема (в ДИПе) нагрелась градусов до 45, дальше температура не росла; thermal shutdown не было; ток 100 мА.

Не лучший вариант...

Как не лучший? просто недогрели его, никакого шутдауна и не произошло. Штатная работа, генератор тока выдает свои 100 мА, нагрев и рассеивание тепла уравновесились при температуре корпуса 45 градусов. Хотите шутдауна- погрейте феном или паяльником.

 

Из той же портянки:

"The receiver input has a fail-safe feature that guarantees a logic-high output if the input is open circuit."

Я правильно понял, имеется в виду, что если линия болтается в воздухе, то "фича гарантирует", что на выходе приемника болтанки не будет? Но тогда непонятно, как фича догадается, что это наводки, а не сигнал?

Не надо ни о чем догадываться. Представьте себе резисторы большого номинала (точнее генераторы маленького тока), которые тянут линию в неактивное состояние. То есть вместо болтанки на входах будет неактивный уровень. Любому сигналу эти резисторы незаметны.

 

2Ruslan1

 

Т.о. вы считаете, что система может строиться из расчета, что коллизии являются нормальным режимом логики, а драйверы их выдержат?

 

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

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