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

=AK=

Свой
  • Постов

    3 234
  • Зарегистрирован

  • Посещение

  • Победитель дней

    5

Сообщения, опубликованные =AK=


  1. То что Вы написали, в случае практически любого протокола будет определено как не-данные: отсев будет либо по неправильному байту (не принят STOP), либо по неправильному адресу, либо по CRC, либо по содержимому пакета принятых байтов, либо по длине этого принятого пакета.

    А вы никогда не задумывались, что будет происходить при использовании ваших протоколов, если помех много и они приходят часто?

  2. вам осталось только назвать автомобиль с очень надежным RS-422 и без очень ненадежного CANа.

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

     

    При том, что CAN не очень помехоустойчив, он довольно надежен. Кроме того, он дешев в реализации. Построение аналогичной системы на RS-422 или оптоволокне обойдется дороже. А в автомобилестроении каждая копейка на счету, вот его и применяют.

  3. Почему-то все дружно забыли про PLC... да не тот, что ПЛК!!- Power Line Communications :)

    А про него все забыли. Поигрались и забыли. Ущемленный всякими ЭМС стандартами до полной убогости, и в результате дорогой, медленный, глюкавый. Всеобщий бардак в электропроводке делает результаты его применения плохо предсказуемыми: в одном доме работает, в другом нет, а в третьем работает, пока юзер не воткнет в розетку какую-то новую приблуду. Он вытеснен всякими RF, основные из которых я перечислил в начале треда.

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

    Буржуи в курсе, поэтому ничего "жизненно-критического" на него не возлагают и за панацею не держат. Для fly-by-wire используют более надежный MIL-SDT-1553 и иже с ним. Для drive-by-wire предназначены flex-ray и TTP, и т.п. Для таких ответственных применений CAN не прокатывает. Вот домашнюю автоматику на нем собрать - самое оно, для этого почти чего угодно сойдет.

  5. Хотел бы уточнить насчёт CAN. Да, физический уровень не фонтан (не Push-Pull, но как-то же надо разрешать коллизии), на большие расстояния не годится. Но вот на счёт плохого протокола поясните пожалуйста. Разве у CAN не жёстко задан протокол приёма с тишиной до и после пакета, подтверждением приёма, CRC, бит-стаффингом?

    Я говорил, что CAN, в силу своего слабоватого физического уровня, по помехоустойчивости не может тягаться с RS-485 c качественным протоколом. Его помехоустойчивость сравнима с помехоустойчивостью интерфейса на базе RS-485, где есть резисторы растяжки, но используется плохой протокол. "Жесткость" протокола, использование CRC и т.п. отнюдь не делают протокол автоматически "хорошим", а плохой физический уровень погубит любой протокол, как бы он ни был хорош.

     

    Когда-то давным-давно я лично наблюдал за мытарствами неких изобретателей самопальных протоколов, которые свято верили в силу резисторов растяжки на RS-485. Программист незнамо зачем (сам он не мог объяснить своих мотивов) переводил трансивер в 3-е состояние после каждого переданного байта, то есть, делал нечто напоминающее физический уровень CAN. На объекте система дико и регулярно глючила, надолго теряя связь, что по условиям задачи было недопустимо. Туда в командировку несколько раз посылали электронщика. Его действия сводились к уменьшению сопротивления резисторов растяжки и замене кабелей на все более дорогие экранированные витые пары. Частота глюков немного снижалась, однако оставалась заметной, система работала ненадежно.

     

    В случае CAN тишина до и после пакета позволяет уменьшить количество коллизий, однако никак не спасает от помех.

  6. Какие сказки про белого бычка? Че за знаки "ты идиот"?

    - а что не так с 485? -

    - Объяснил первый раз

    - И че делать? CAN?

    - Ответил

    - Изначально я спрашивал, что если не RS-485? - соврал; возможно это тролль?

    - Обьяснил второй раз.

    - какая связь между "резисторами подтяжки, помехоустойчивостью" и правильным протоколом? В чем разница между RS-485 и RS-422? На физическом уровне. Почему для RS-485 подтяжки надо, а для RS-422 Не надо?

    - Обьяснил третий раз.

    - Понятно. Спасибо. То бишь RS-422 самый стойкий к помехам? А CAN bus? - вроде бы дошло, но не совсем

    - Ответил

    - И при чем тут "правильный протокол"? - опять двадцать пять; oбщее поведение соответствует поведению тролля.

    - Обьяснил еще раз, однако отметил нарочитую тупость.

    - Не хамить воспитание не позволяет? - ну точно, тролль, вишь как обрадовался кормежке

    - совок он и есть совок, хоть куда переедь, из души не вытравить. - однозначно тролль, жирный и нахрапистый

     

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

    Это не является достаточным условием для помехоустойчивого протокола. Вполне обеспечивается, например, хорошим CRC. Однако никакой гарантии от глюкавости в условиях сильных помех не дает. Сообщение просто никогда не дойдет до адресата. Так что все-таки "остальные" пусть постоят тихонечко где-то в сторонке, они, действительно, даже до "гурманов" не дотягивают.

  7. имелось ввиду, что если выдерживать паузу с переключением на приём, после передачи полезной информации и постоянно вести обмен

    на линии - то устойчивость к помехам возрастает.

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

     

    Поэтому можно включить передатчик и выдерживать паузу до начала передачи пакета, при этом в самом пакете не должно быть больших пауз между байтами, а приемники при обнаружении пауз должны очищать свои приемные буфера. Так сделано в Modbus RTU, про который я упоминал.

     

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

     

    Некоторые (условно назовем их "остальные") использует протоколы....

    Выше я в общих чертах описал два существующих подхода к построению правильного протокола для RS-485. Других нет, так что "остальные" со своими растопыренными пальцами могут покурить в сторонке.

     

    Еще более некоторые (назовем их "гурманы"), предпочитают, чтобы их драйвер RS-485 не выдавал ложных переходов в микроконтроллер если линия в неопределенном состоянии. Они действуют двумя способами:

    1) применяют драйверы RS-485, которые при неподключенной линии выдают неактивный уровень в RX, например SN75LBC184

    2) применяют резисторы, "растягивающие" линию из неопределенного состояния в определенное.

    3) применяют (1) + (2) вместе.

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

  8. Для организации питания планируется поставить первичный БП подключенный к бортовой сети.

    ...

    Как оценить уровень ожидаемых помех?

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

  9. И при чем тут "правильный протокол"?

    При том, что сеть RS-485 с правильным протоколом настолько же помехоустойчива, насколько помехоустойчива связь по RS-422. Че-то до вас ничего не доходит, по пять раз прихoдится повторять. Сказка про белого бычка... :01:

  10. =AK=

    Вы смеетесь? Про 485 и 422? В устройствах что я смотрел микросхемы драйверов одинаковые.

    Разница первый полудуплекс второй полный.

    Мне больше плакать хочется, когда я снова и снова слышу наивное недоумение по этому поводу. :cranky: Да, разница именно в этом. Низкое выходное сопротивление постоянно включенного драйвера RS-422 очень эффективно давит наведенные в линии помехи. Давит намного эффективнее, чем вшивые резисторы растяжки. Настолько эффективнее, насколько ниже выходное сопротивление драйвера в сравнении с резисторами растяжки. RS-422 десятки и сотни раз более помехоустойчив, чем RS-485 с паршивым протоколом, который в плане помехоустойчивости полагается только нa растяжки.

     

    2. В чем разница между RS-485 и RS-422? На физическом уровне. Почему для RS-485 подтяжки надо, а для RS-422 Не надо?

    RS-422 - это "точка-точка", передатчик постоянно включен. А RS-485 - это шина, все передатчики большую часть времени выключены и линия свободно болтается, ловя любые помехи.

  11. Изначально я спрашивал, что если не RS-485?

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

     

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

  12. а что не так с 485?

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

  13. Это только "настольное" и "игровое" делается под USB... А промышленное и длительно-работающее - никогда.. Вот подвиснет ночью у Вам USB и что будете делать? Вручную кабель передергивать?

    Для конфигурирования оборудования USB применяется сплошь и рядом. Для управления оборудованием - нет. Собственно, точно то же самое было и с RS-232, для управления оборудованием его применяли разве что по недоумию. Впрочем, в таком случае и RS-485 был не впрок, чему есть масса примеров.

  14. 1. На источнике питания +2В. Осцилографом меряю напряжение на первичной обмотке, там 10Vpp. Я так понимаю это так индуктивность влияет ?

    Скорей всего так влияет индуктивность рассеяния. А вообще-то неплохо было бы на осциллограммку взглянуть.

     

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

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

     

    Супрессор - это разновидность стабилитрона. Диод+супрессор по сути не так уж сильно отличается от демпфирующей цепочки диод+(резистор||кондер).

  15. Он у меня перегревается (отпаивается от нагрева).

    У супрессора очень большая емкость, из-за чего ток 1 МГц лихо скозь него свиндячит и нагревает. У варистора, кстати, емкость еще больше.

     

    Поставьте последовательно с супрессором диод с малой емкостью. Тогда при старте емкость супрессора один раз зарядится и больше мешать не будет, а ток 1 МГц будет свиндячить через емкость диода и греть его.

     

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

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

    Абстрактно-теретицки сопротивление резистора в RC-цепочке должно быть равно внутреннему сопротивлению источника помехи, тогда помеха рассеится быстрее всего, с минимумом колебательности. Однако вас прежде всего должна интересовать не низкочастотная составляющая помехи, которая несет много энергии, однако сравнительно безвредна в смысле EMC. Поэтому в вашем случае большую пользу может принести просто конденсатор 1000 пФ в питании, параллельно снабберу.

     

    Не забывайте, что конденсаторы должны быть класса X или Y, т.е. безопасные для работы в цепях сетевого напряжения.

  17. здесь дело в том, что характер нагрузки заранее неизвестен и влезать в нагрузку, чтобы в нее встраивать искрогасящие схемы, никто не будет

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

     

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

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