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

=AK=

Свой
 Профиль  Обзор контента

  • Постов

    3 299

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

  • Посещение

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

    7

 Тип контента 

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

  2. Опубликовано · Пожаловаться

    схема(которая выше на пару постов), может подойти для выносной кнопки - может кто нибудь пояснить - это так или нет?

    Схема, приведенная в посте №4, годится для любых кнопок, и встроенных, и выносных. Надо только сделать такие поправки и пояснения:

    - выбросить диоды, они не нужны

    - R26 увеличить хотя бы до 100...220 Ом

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

  3. Опубликовано · Пожаловаться

    А где ваше утверждение, что клок-стретчин на уровне битов работает? Вы все еще это утверждаете?

    Несомненно, работает. Прочитайте, наконец, спецификацию I2C (который уж раз прошу), в данном случае - раздел 8.1. :1111493779:

     

    Если до вас опять не дойдет, попросите кого-нибудь перевести вам следующую фразу из раздела 8.3: "the clock synchronization mechanism can be used to enable receivers to cope with fast data transfers, on either a byte level or a bit level." :twak:

     

    стретчинг делает слейв - мастер должен только следить за этимх

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

     

    бодаться с таким упрямцем как вы

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

  4. Опубликовано · Пожаловаться

    Cпасибо, но я не нуждаюсь в ваших поправках. После каждого БАЙТА.

    Извольте. Но в этом случае предлагаемая вами система не способна ничего прочитать из удаленного слэйва. Она у вас write-only, и, вдобавок, игнорирует Ack, поскольку, к моменту генерации нерастянутого 9-го клока в байте, Ack от слэйва никак не успеет дойти через IP (надо полагать, фиктивный Ack мастеру вы собираетесь подсовывать своим "фальшивым слэйвом"). :cranky:

     

    Не занудствуйте. любое время, хоть 100ms.

    Ну, раз уж начинает проясняться, что у вас система однонаправленная (искалеченный вариант write-only), то этот вопрос, действительно, становится неактуален. Предположение, что вы имели ввиду такую... м-м-м... странную систему (что, очевидно, вызвано вашим тотальным непониманием, как работает I2C - иначе такая странная система и в страшном сне не приснилась бы) , полностью объясняет и вашу неспособность отличить предлагаемое вами решение "через IP" от нормального удлинителя I2C, и ваши основания для утверждений о "работоспособности" и "прозрачности" вашего решения, и ваше искреннее недоумение при мысли, что мастеру зачем-то надо растягивать генерируемый им клок. Предлагаю вам сделать следующий шаг и разработать систему think-only - ей вообще не будет нужно ни проводов, ни эфира. :lol:

  5. Опубликовано · Пожаловаться

    Что касается по-подробнее, то что вам не понятно -- после приема каждого байта

    Бита

     

    приемник имеет право удерживать клок в нуле на время обработки этого байта. Что еще надо объяснять? IP-вставка будет тормозить передатчик на время пока данные уйдут на другой конец и реальный приемник не отпустит клок

    Вот величину этого времени и надо объяснить. Конкретно - назовите цифру, которая гарантирует, на ваш взгляд, работоспособность предлагаемого вами варианта. Желательно - с объяснением, почему вы назвали именно такое время.

     

    Считаете, что это не прозрачно

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

    - Мастер, не умеющий делать clock stretching

    - Даталоггер, которому требуется обеспечить запись в EEPROM за определенное время

  6. Опубликовано · Пожаловаться

    Вы немножко на шаг вперед думать можете? Тормозить мастера может фальшивый слейв, самостоятельно, пока не дождется ответа от реального слейва.

    Распишите подробнее, как это, по-вашему, должно происходить.

     

    Нелепо его к памяти по I1C через интернет подрубать.

    Странно. Это же ваша собственная идея была, которую вы высказали в посте №38. А сейчас продолжаете спорить, что она работоспособная - вот даже "фальшивый слейв" придумали.

     

    Интересная аберрация сознания...

  7. Опубликовано · Пожаловаться

    В I2C нет никаких требуемых времен. И слэйв и мастер могут торомозить работу другой стороны чтобы подогнать под свою скорость.

    Хи-хи... Я же вас просил - изучите I2C, прежде чем нести ахинею. В этом режиме слэйв не успеет через IP затормозить мастера в момент непосредственно после старта. Потому что тормозить он обязан быстро, иначе мастер убежит - не догонишь.

     

    Сценарий-то вы предложили явно нелепый.

    Опять хи-хи. Я вам такой даталоггер могу живьем показать. Уже лет 15 выпускается серийно.

     

    Ладно, я свое мнение уже высказал по данному вопросу.

    Как выяснилось, ваше мнение сформировалось вследствие элементарного недостатка знаний.

  8. Опубликовано · Пожаловаться

    А я думаю получится. Почему это нет?

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

     

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

     

    А тормозить они у вас будут в любом случае, независимо от реализации. Вот представьте себе устройство (даталоггер), которое, скажем, раз в 100 мс читает и пишет несколько байт в I2C EPROM. Теперь вы эту EPROM выносите наружу и связываете с мастером I2C через IP, используя любой имеющийся на рынке экспандер I2C. Будет у вас такой даталоггер работать? Нет.

  9. Опубликовано · Пожаловаться

    Вы тут долго спорили что интерфейсы и протоколы это разные вещи

    Вы обмишулились. Спутали меня с моим оппонентом. Перечитайте сообщение №25 еще раз внимательнее, если до вас не дошло.

     

    I2C спецификация включает как электрическую часть, так и формат данных

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

     

    Какой это к черту I2C? Вы его еще в IP запихайте и скажите что у вас I2C на тыщи километров работает.

    А вот через IP прозрачно для I2C мастера никак не получится. Изучайте I2C. Если так и не поймете, почему через не получится - обращайтесь, я объясню.

     

    Как общаться? Между собой - никак. Центральная управляющая программа должна быть на ПК.

    Вредный совет. Так, конечно, в принципе делать тоже можно, но это наименее предпочтительный вариант, в силу своей ненадежности, наихудшей из возможных. ПК выключили - все встало.

  10. Опубликовано · Пожаловаться

    межвитковую ёмкость при каких условиях следует учитывать? и как с ней бороться, правильнее мотать?

    От задачи зависит. Для сетевого транса - бессмысленно ее учитывать, а для вторичной обмотки транса высоковольтного импульсного БП - обязательно придется учитывать.

     

    Для борьбы с вредным влиянием емкости применяют такие способы:

    - разбивают обмотку на секции

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

    - увеличивают расстояние между витками используя провода в более толстой изоляции (ПЭВШО и т.п.)

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

  11. Опубликовано · Пожаловаться

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

    Измените диаметр провода - и получите тот же эффект, поскольку геометрия катушки слегка изменится. А за счет разброса проницаемости сердечника неопределенность индуктивности от образца к образцу будет намного больше, чем разница за счет намотки одним проводом или многими, или разница за счет намотки проводом другого диаметра.

  12. Опубликовано · Пожаловаться

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

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

     

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

  13. Опубликовано · Пожаловаться

    L/N

    Чушь, будет L

     

    плюс поправка на взаимную индуктивность согласно включенных катушек.

    Их коэфф. связи равен единице, поэтому поправка равна нулю. Иначе была бы разница, мотаешь катушку литцендратом или обычным проводом. А разницы нет.

     

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

  14. Опубликовано · Пожаловаться

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

    Такая же, как при намотке одним проводом.

  15. Опубликовано · Пожаловаться

    Пообщался я с преподом, и убедил его что I2C на 100 метров не пойдет, фронты будут размыты и в реале я не чего не получу,

    Убедили? А жаль. :) Есть вариант и с I2C: если использовать буфера P82B96 (предпочтительно - добавив к ним быструю гальваническую развязку), то I2C на 250 метров будет работать. :rolleyes:

     

    Идеально было бы скомбинировать их с ADM2482E, которые являются трансиверами RS485/RS422 с гальв. развязкой. На противоположном конце можно поставить приемопередатчики RS422 без развязки, например, ADM3077E Тогда для связи двyх устройств потребуется 4 витых пары, что не проблема: в обычном Эзернет кабеле (категории 5 или 6) как раз 4 витых пары. Получите простое решение. C огромной помехоустойчивостью. ;)

     

    post-2483-1273547088_thumb.png

     

    PS: Имейте ввиду, это всего лишь идея. Реализуема она или нет - я пока точно не знаю. Скорей всего, реализуема (ну, может, резисторы подтяжки к питанию надо добавить на сигнальные линии между P82B96 и трансиверами RS422), но чтобы сказать точно, надо внимательно читать даташиты, а мне лень... :)

    в этом контроллере шина MBUS апаратная там только битики правильно выставить и протокол у нее стандартный

    В каком контроллере? И какой MBUS вы имеете ввиду, вот этот? http://www.m-bus.com/

  16. Опубликовано · Пожаловаться

    Подразумевается частое тех. обслуживание коробки с платой.

    Персонал, проводящий техобслуживание, - это не пользователь. От пользователя нельзя требовать, чтобы он использовал антистатический коврик и надел антистатический браслет.

     

    Доступ к разъёмам на плате может быть тоже не редким... как снаружи так и изнутри устройства...

    Никто не говорит о "редкости". Доступ или есть, или его нет.

     

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

  17. Опубликовано · Пожаловаться

    Забили тему спамом, не дав никому посоветовать студенту.

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

     

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

  18. Опубликовано · Пожаловаться

    Как я понимаю, если происходит разряд человек-край платы (разъём), то ток статики по защитному кольцу стекает на заземление (если плата заземлена, конечно).

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

    Никогда в жизни не встречал Ethernet-устройств, в которых в штатном виде плата была бы доступна для касания. :cranky:

     

    Поймите простую вещь: устройство должно работать в том виде, в каком его сконструировали работать. Если это плата в составе PC - она должна быть вставлена в РС, а сам компьютер должен быть собран. Если это плата в составе другого устройства - оно должно находиться внутри соответствующего корпуса. И т.д.

     

    По этой причине у человека нет доступа к самой плате. Ни к краю платы, ни к середине ее. У человека есть доступ только к тем элементам, которые находятся снаружи: к корпусу, к разъему, к передней планке, если она есть. И это все.

     

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

     

    Это Микрель решил, а не Каршенбойм :)

    Статья подписана Каршенбоймом, а не Микрелем. Бог весть откуда он нахватал того, что там написано. Но в любом случае он автор, ему и отвечать за написанное.

     

    А как он будет распространяться, если попадёт на заземлённый контур? Наверное потечёт туда, где потенциал минимален...

    Да кто ж вас знает, что у вас за устройство. Как оно сконструировано - так и будет распространяться.

     

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

     

    А разряд, попавший на корпус разъема - тоже должен найти свой путь на землю. Если вы обеспечите ему прямой путь на переднюю планку и далее на корпус РС - проблемы не будет. А если вы через пресловутый "контур" уведете его на разъем PCI - плата будет глючить и выгорать.

  20. Опубликовано · Пожаловаться

    "Рулить" направлением передачи по RS485 из прикладной программы под Виндой - это конечно "классное решение". А самое главное - надежное и быстрое...

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

     

    Из вашего высказывания можно понять, что вы думаете, будто прикладная программа на PC работает медленно и/или ненадежно. Вынужден вас разочаровать: это ваше мнение тоже ошибочно.

     

    А так, люди даже через интернет устройствами по MODBUS управляют.

    Неужто это как-то подтверждает высказанную вами ошибочную мысль, будто "Интерфейсный и протокольный уровни не должны быть связаны между собой"? Одна только эта фраза непреложно свидетельствует, что вы никогда ничего не слышали об эталонной семиуровневой модели ISO/OSI и, соответственно, не представляете как взаимодействуют между собой различные уровни интерфейса. Каковой (интерфейс) разве что только дремучие кустари от электроники способны низвести до одного только физического уровня и отождествить с ним.

  21. Опубликовано · Пожаловаться

    С какой стати преобразователь интерфейсов должен ориентироваться на использование именно протокола MODBUS? Что, других нет что-ли?

    Есть, несомненно. Существуют тысячи самопальных протоколов.

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

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

     

    И почему, при использовании протокола MODBUS, Вы решили что обязательно будет использоваться RS485? Интерфейсный и протокольный уровни не должны быть связаны между собой.

    "Это ваши смешные фантазии" (с) Очень наивно пытаться строить уровень Data Link, который ничего не знает и знать не хочет о PHY.

    Соответствено, тот же Модбас в документе "MODBUS over serial line specification and implementation guide V1.02" черным по белому пишет в разделе 3: MODBUS solution over serial line should implement an electrical interface in accordance with EIA/TIA-485 standard ( also known as RS485 standard). This standard allows point to point and multipoint systems, in a ”two-wire configuration”.

     

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

    Угу, как же. Вы лучше на фиг.14 в упомянутом документе внимательно посмотрите.

     

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

    Нет, не так. Я отличаю "преобразователь интерфейсов, который не способен полностью соответствовать спецификации Модбас" от "преобразователь интерфейсов, который способен полностью соответствовать спецификации Модбас". Вам нравится первый - пользуйтесь на здоровье. Только не врите, будто он обеспечивает помехоустойчивую связь.

     

    А мне бывает нужен второй. В котором трансивер RS-485 включается на передачу не от глупого "автомата", а по сигналу (одному из сигналов управления модемом в RS-232), который сформирует мой софт.

     

    Самое смешное состоит в том, что этот ваш недоделанный EL203 почти наверняка имеет лишний приемник RS232 на плате, который вы не могли дотумкать, куда и зачем применить. И вся "цена вопроса" - лишний джампер, при помощи которого выбирается источник сигнала управления передатчиком RS485: от "автомата" или непосредственно от RS232 :rolleyes:

  22. Опубликовано · Пожаловаться

    Опять все в кучу - интерфейсы и протоколы...

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

     

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

    - всякий протокол вполне уместно назвать интерфейсом,

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

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

     

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

  23. Опубликовано · Пожаловаться

    "Смешались в кучу кони, люди", интерфейсы с протоколами, подтяжки с развязками... :) Полный бардак в Вас в голове, уважаемый...

    Иными словами, для вас слишком сложно то, что я рассказал, вы потеряли нить. :laughing: К счастью, то, что пишется на форуме, читают многие. Вы не поняли - другие поймут.

     

    P.S. Драйвер RS485 переключается на передачу только по команде устройства, на котором он установлен. Либо автоматически, при начале передачи (как это сделано в указанных преобразователях). От состояния линии RS485 и количества помех на ней этот процесс не зависит. Совсем. И никак.

    А я про репитер рассказывал. В каталоге продукции вашей кустарной мастерской это EL200, если вы не знаете что такое репитер. Вы думаете, что он "устанaвливается на какое-то устройство" и "получает от него команды"? Если так, вы ошибаетесь. :01:

     

    Что же касается вашего преобразователя RS232-RS485, то с ним совсем другая проблема. Как я уже говорил, он резко снижает помехоустойчивость связи, когда работает в составе сети на базе RS-485. Допустим, все узлы такой сети работают с протоколом Модбас RTU. Однако тот узел, на котором стоит ваше изделие EL203, не полностью соответствует спецификации Модбас RTU: в отличие от нормальных узлов, он не формирует правильной преамбулы. Поскольку преамбула от него формируется резисторами, а не включенным в течении определенного интервала передатчиком RS-485, как того требует протокол Модбас RTU. В результате этого в условиях сильных помех все узлы разговаривают друг с другом как ни в чем не бывало, а сообщения от этого узла все время теряются. :twak:

  24. Опубликовано · Пожаловаться

    Особенно интересен опыт в практическом применении RS-485.

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

     

    В одном случае это обошлось компании, помимо подмоченной репутации, в кругленькую сумму: инженеру специально под эту задачу купили "карманный" осциллограф Fluke (в те времена, 15 лет назад, это была очень дорогая игрушка) и несколько раз посылали в командировку на площадку заказчика, в Китай, где была установлена глючащая система - в надежде, что он на месте пофиксит проблему. Инженер тоже не любил думать, нo был большой мастак танцев с бyбном, поэтому каждый раз уменьшал номинал подтягивающих резисторов, камлал и молился. A когда возвращался из командировки - через некоторое время заказчик снова сообщал, что объект глючит. Oбъект - портовый кран высотой с десятиэтажный дом, глюк заключался в том, что кран время от времени "вставал": блокировки системы безопасности ложно срабатывали от помех на шине RS-485 и отрубали ему моторы. :krapula:

     

    Кстати, в те годы как раз получили распространение "автоматические преобразователи RS-485 - RS-232" и "автоматические репитеры RS-485" с развязкой. Как известно, и те и другие используют один и тот же принцип работы. Тот инженер, по ламерству своему, поставил в систему такой репитер для дополнительной развязки. Он тоже, как и вы, думал, что развязка - это панацея и гарантия помехоустойчивости. Oн не догадывался, что этот репитер реально привносил дополнительные проблемы, поскольку менял направление обмена невпопад, из-за помех.

     

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

     

    А приведенная вами ссылка, увы, к помехоустойчивости имеет весьма отдаленное отношение. ;)

  25. Опубликовано · Пожаловаться

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

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

     

    Вообще-то, преобразователи стоят с двух сторон, как правило.

    С чего бы это? :biggrin:

     

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

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