Комментарии 157
А мне вообще телетайпная 100mA токовая петля вспомнилась. Та, правда, 10 км по физлинии вытягивала.
Да, только решает проблему энергосбережения. Если станции нечего передавать, она может просто молчать и это никак не влияет на работу остальной сети.
То он ждет окна и передает.
Причем наихудшее время ожидания окна можно высчитать, в отличии от CSMA/CD.
Причем в статье об этом написано.
> она может просто молчать
> он ждет окна и передает

Или я плохо читал — или определимся с понятиями «станция» и «молчать».
Если «станция» == координатор, то оно не может «молчать», т.к. обязано раздавать токены.
Причем в статье об этом написано.
Что вы пытаетесь мне доказать?
Если вы не понимаете, зачем нужна эта абстракция нужна, то все просто — она не для вас.
Поясните, пожалуйста, по режиму 10BASE-T1L. У вас вот такие пункты:

  • до 10 промежуточных разъёмов (и два оконечных)
  • режим работы точка-точка



Зачем нужны промежуточные разъемы, раз режим «точка-точка»?

По режиму 10BASE-T1S. С одной стороны, вроде бы и вкусно (Ethernet, работающий в multipoint режиме), а с другой — расстояние 25 метров для пром автоматики вообще ни о чем. Для автомобилей может быть и сойдет. Ну и в характеристиках у вас тоже противоречие:

  • до 4-х промежуточных разъёмов (и два оконечных)
  • ...
  • дальность действия до 25м в режиме мультипоинт (до 8 узлов)



4 промежуточных разъема и 2 оконечных — это ведь шесть узлов? Тогда откуда возьмутся 8 узлов? Или 6 узлов — это ограничение «физики» протокола, а 8 узлов — это теоретический предел для логики протокола, с применением каких-нибудь повторителей?
Зачем нужны промежуточные разъемы, раз режим «точка-точка»?

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

до 10 промежуточных разъёмов

Учитывайте переходное сопротивление контактов. Вот и появляется ограничение.
Да, видимо, действительно речь идет о стыках. Просто и в режиме 10BASE-T1L, и в режиме 10BASE-T1S в описании обозначены «промежуточные разъемы», но назначение у них, выходит, разное. Отсюда и вопрос возник.
Не только переходное сопротивление, но и прерывается повив, тем самым ухудшается защищенность линии.
Про промежуточные разъемы скорей — стыки, не оконечные устройства на проводе.
Ну… формально, в статье витуху от 485-й и описали:) Тоже 1 витая пара, тоже 1 км дальность… Коммутаторов добавили только. И разъёмов теперь закупать придётся за тонны денег.
И я так чувствую, что модбас, из-за его простоты, будут и по этому кабелю гонять.
Гонять супермедленный MODBUS RTU там, где можно быстрый MODBUS TCP — преступление, ящитаю.
Если у вас витая пара километр длиной, то по ней и TCP скорее всего будет не то чтобы очень быстрый. А MODBUS RTU можно и через сокет в гигабитной сети гонять, вообще никаких проблем. Собственно M. TCP это почти RTU, только выкинули ненужное поле адреса и контрольной суммы.
мда. а теперь смотрим с другой стороны.
ставить дорогую железяку с поддержкой большого стека протоколов TCP/IP + Ethernet-модуль взамен дешевого преобразователя UART-485, который эффективно вешается на любой микроконтроллер весьма и весьма невыгодно.
особенно если даже скорости в 9600 за глаза хватает.
Здесь Ethernet это уровень RS485, TCP/IP стек городить не обязательно, достаточно обойтись раздачей Ethernet–адресов.
modbus TCP почему-то говорит об обратном.
если у вас есть прикладной опыт, то посчитайте стоимость указанных выше решений.
Даже «супермедленный MODBUS RTU» работает значительно быстрее, чем меняются измеренные физические параметры.
мерять
Измерять. Там, где используется ModBus, его скоростей вполне достаточно. Для процесса вполне годится, а вот для motion control — нет.
То же самое с последовательными интерфейсами 232/485.
А они все ещё нас переживут.

Не очень понятно — старые Modbus, can, rs485 — довольно легковесные протоколы в программном смысле, поэтому с ними любая ардуина справится. А для этого протокола предлагается морочиться со всеми dhcp, tcp/ip и остальными уровнями osi на каждом копеечном датчике температуры?

Нет, не обязательно. Так же заранее раздаёшь MAC-адреса и посылаешь Ethernet-кадры выбранного формата. Остальные протоколы более верхнего уровня делаются по необходимости. Тот же Modbus можно использовать, даже не в TCP-варианте.
И чем оно тогда функционально лучше RS-485, который также точно доставит фрейм от точке к точке? И стоят ли эти улучшения необходимости ставить коммутаторы, какие-то специальные разъёмы, трансформаторы развязки, PHY, контроллеры с поддержкой Ethernet? В то время как для RS-485 хватает любого контроллера с UART и копеечной обвязки.
Тем что фреймы дальше можно запихнуть в обычный ethernet без необходимости конвертации как в случае RS485. В теории добавить в ethernet чип новый стандарт явно проще и дешевле при массовом производстве.
А чем обычный Ethernet лучше обычного RS-485 там, где вся задача — 2 байта переслать и зачем вообще датчикам в сеть? А если действительно надо, то не проще ли поставить один конвертер вместо запихивания всего стека в каждый датчик?
Более массовый. Упрощается и унифицируется сеть. Какой еще стек? tcp/ip? А зачем? Вы можете данные передавать прям в фрейме ethernet, для датчиков tcp/ip городить не надо.

Более массовый.
В промышленности RS-485 куда более массовый.
Упрощается и унифицируется сеть.
Упрощается ли? На RS-485 можно повесить до 32 (или 128) абонентов, не нужны никакие коммутаторы.
Какой еще стек?
Я про аппаратный стек — контроллер с поддержкой Ethernet, PHY, трансформаторы, разъёмы…
tcp/ip? А зачем? Вы можете данные передавать прям в фрейме ethernet, для датчиков tcp/ip городить не надо.
Модбас — стандартный протокол, который понимают ПЛК, анализаторы, всякий софт… запихать данные прямо в фрейм — это колхоз, который никто не оценит. Причём довольно дорогой колхоз, если пихать локалку в каждый датчик, маршрутизатор в каждый кондиционер. А ради чего? Если уж городить сеть, то надо использовать преимущества сети. Хотя бы пользоваться стандартными протоколами наподобие MODBUS-TCP.
В промышленности RS-485 куда более массовый.

Ethernet еще более массовый. Он применяется практически везде. Как итог если RS-485 заменить на ethernet конечные устройства будут еще дешевле.

Упрощается ли? На RS-485 можно повесить до 32 (или 128) абонентов, не нужны никакие коммутаторы.

При этом у вас один коллизионный домен и скорость делится на всех. Если этого не достаточно вы тянете еще один провод. Тут сразу предлагается так делать. Какой вариант удобнее и лучше сильно зависит от окружения.

Я про аппаратный стек — контроллер с поддержкой Ethernet, PHY, трансформаторы, разъёмы…

Ну дак и в RS-485 он есть.

Модбас — стандартный протокол, который понимают ПЛК, анализаторы, всякий софт… запихать данные прямо в фрейм — это колхоз, который никто не оценит. Причём довольно дорогой колхоз, если пихать локалку в каждый датчик, маршрутизатор в каждый кондиционер.

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

А ради чего? Если уж городить сеть, то надо использовать преимущества сети. Хотя бы пользоваться стандартными протоколами наподобие MODBUS-TCP.

Зачем там TCP? Проще уж MODBUS-over-Ethernet гонять. TCP/IP требует дополнительно еще IP и TCP.

Я уж молчу про экономию на персонале. Такую сеть могут обслуживать те же люди что обслуживают ethernet сеть.
Ethernet еще более массовый. Он применяется практически везде.
У многих вендоров есть свои вариации на тему эзернета. Профинет и иже с ним. Вот только есть требования по риалтаймовости и прочие нюансы, поэтому промышленный эзернет — не тоже самое что бытовой. Железки там свои.
Как итог если его заменить на ethernet конечные устройства будут еще дешевле.
С какого перепугу? От перехода на эзернет датчик или контроллер не станет массовей. Скорее станет менее, т.к. брать не будут т.к. станет гораздо дороже.
При этом у вас один коллизионный домен и скорость делится на всех. Если этого не достаточно вы тянете еще один провод. Тут сразу предлагается так делать.
Ну, офигенная логика. А если достаточно? Довольно часто нужно обращаться к оборудованию раз в час. Или раз в день. Зачем тянуть 32 провода там где можно и один?
Ну дак и в RS-485 он есть.
Обвязка RS-485 — это копеешная горстка деталей. Драйвер, оптопарки и любой клеммник. Цепляется к любому МК с UART (читай — к любому МК). Причём развязка и требуется не всегда. Это на порядок-другой дешевле чем эзернет.
Почему колхоз то? Обычное решение.
В нормальном оборудовании это не обычное решение, а как раз таки колхоз. Используются только типовые решения и стандартные протоколы.
Еще раз унификация здорово тут перевешивает все минусы.
Разумеется, унификация ещё как нужна. Именно поэтому стандартный модбас, который поддерживается всем чем угодно — живее всех живых, а всякие крутые протоколы используются время от времени. А вот унификация промышленных датчиков и офисной сетки никому особо не нужна.
Это как раз попытка эти вариации привести к одному стандарту. Плюс проще требования к кабелю.

С какого перепугу? От перехода на эзернет датчик или контроллер не станет массовей. Скорее станет менее, т.к. брать не будут т.к. станет гораздо дороже.

Зависит от цены добавления.

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


Сейчас колхоз завтра стандарт.

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

Ethernet это вообще говоря уже давно не про офисную сеть. На нем сейчас строят сети масштабов города.
Это как раз попытка эти вариации привести к одному стандарту.
Ну, будет единый и что? Всё равно требования к промышленной сети несколько другие. На скорость как правило наплевать, гарантированное время частенько нужно. Приоритеты всякие нужны. Отсюда собственно и растут вариации от всяких вендоров.
Плюс проще требования к кабелю.
С чего это? При желании, RS-485 прекрасно работает по обычной компьютерной витухе. В тоже время промышленный эзернет часто тянется суровым специальным кабелем. Даже в статье упомянуты «проводники 18AWG (0.8мм2)». Всё зависит от условий.
Сейчас колхоз завтра стандарт.
Запихать аппликейшен-специфик структуру прям в эзернет-фрейм, без всякого протокола-обёртки — это и есть колхоз, а не стандарт и не завтрашний стандарт. А вот MODBUS-TCP таки какой-никакой стандарт.
Ну, будет единый и что?

Дешевле и доступнее решения.

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

С того что вместо кабеля с 8 витыми проводниками, будет кабель с 2 витыми проводником. И у RS-485 тоже есть требования к кабелю, по любой веревке работать не будет.

Запихать аппликейшен-специфик структуру прям в эзернет-фрейм, без всякого протокола-обёртки — это и есть колхоз, а не стандарт и не завтрашний стандарт. А вот MODBUS-TCP таки какой-никакой стандарт.

Ох. Я вам предложил MODBUS over ethernet. MODBUS-TCP требует еще поднятия tcp/ip стека что тут явно избыточно будет. А вот положить MODBUS прям в фреймы вполне ок.
Человек не разделяет Ethernet, IP, TCP. Хорошо хоть не жалуется что теперь HTTP-сервер придётся поднимать, для датчика. Тоже ведь по «проводам с RJ-45» работает.
Как показывает мой опыт, то RS-485 работает по гнилому телефонному кабелю, до полукилометра точно. У меня PTZ камера в поле на столбе по телефонному кабелю получала управление и передавала видео через симметрирующее устройство.
А вот обычный Ethernet лагает при любом удобном случае.
Вопрос скорости же. Тут смысл в том что можно положить одну витую пару и работать будет. К примеру в вашем случае не требовалось бы симметрирующее устройство и подача питания.
А если нет возможности в прокладке кабеля, а есть только гнилой телефонный? Сейчас так вообще есть AHD и HDCVI который может передавать видео, аудио, тревожные сигналы и команды управления по одному коаксиалу. А если прокладывать кабель на большое расстояние, так сразу брать оптику.
У охранно-пожарных сигнализаций группа датчиков и исполнителей сидит на одном двужильном проводе по которому идёт питание и информация.
По факту с 802.3cg ещё один нишевый стандарт. Я так вообще зарёкся внедрять новое оборудование. Не хочу краснеть перед клиентом когда оно начинает лагать и не справляться со своей задачей в том месте где старое работало как часы.
А вот унификация промышленных датчиков и офисной сетки никому особо не нужна.

Это унификация сетей АСУТП предприятия, где можно использовать похожее оборудование для связи, контроля и ограничения доступа.

Обычно Ethernet сеть уже развёрнута, настроена и понимается безопасниками. Сейчас в местах стыков с оборудованием ставят переходники/агрегаторы, что дорого и неудобно.
Поэтому добавление ещё одного физического канала оправдано, так как позволяет использовать все существующие решения, которых в ethernet–мире накоплено множество.
Зачем унифицировать с Ethernet сотню, а то и тысячи кабелей, которые идут из шкафов с ПЛК ко всяким мелким датчикам?
Связь шкафов с диспетчерской и объектов между собой другое дело, но там можно пустить (и пускают) обычный Ethernet, без всяких непонятно зачем нужных четвертушек.
Чтобы выкинуть шкаф к примеру. Вместо шкафа с конвертером можно будет поставить ethernet-коммутатор. С этой же целью например добавлено еще и питание там. Это позволяет к примеру сразу же по это же паре запитывать и управлять устройством.
ПЛК — это не конвертор, а контроллер. На нём выполняется сама логика техпроцесса, с аппаратным резервированием, всякими фейлсейфами и прочими нюансами промышленной железки. Позабирать всю ответственность у локальных контроллеров и превратить в тупоконверторы — отличный способ выстрелить себе в ногу.
Кроме того у контроллера помимо интерфейсов данных ещё куча дискретных и аналоговых портов, их тоже все в коммутатор втыкать?
Позабирать всю ответственность у локальных контроллеров и превратить в тупоконверторы — отличный способ выстрелить себе в ногу.

Вы уж определитесь.

То у вас
Зачем унифицировать с Ethernet сотню, а то и тысячи кабелей, которые идут из шкафов с ПЛК ко всяким мелким датчикам?


То у вас отличный способ выстрелить в ногу. Если у вас уже есть кабель какая разница чем он заканчивается? Что так у вас обрыв вызывает проблемы что так.

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

А это тут причем? Как бы говорили про замену RS-485, а закончили за упокой.

Ну и я более чем уверен что при замене аналоговых и X10-X25 на RS-485 говорили ровно тоже самое что сейчас при вопросах на RS-485 и Ethernet.

К тому же тут скорее обратная ситуация будет наблюдаться, когда датчики будут все умнеть и умнеть и ПЛК будет все ближе и ближе к тому чем он рулит. И в этом случае как раз использование такого ethernet вполне подойдет.
Чтобы не тянуть тысячи кабелей, где будет достаточно одного. Например, если датчики разнесены по большой территории, вполне естественно воспользоваться более мощной инфраструктурой, чем либо тянуть напрямую, либо городить локальные узлы агрегации.
Уже давно никто не тянет тысячи кабелей там, где можно обойтись одним: Fieldbus.
Я уж молчу про экономию на персонале. Такую сеть могут обслуживать те же люди что обслуживают ethernet сеть.

О, да! Этим мы знатно прибавим головной боли одминам:)
Пусть не забывают страдать :) Ну и обычно одмины эти же имеют общение и с другими железяками.
Ethernet еще более массовый. Он применяется практически везде. Как итог если RS-485 заменить на ethernet конечные устройства будут еще дешевле.
Интересно, как вы всё легаси замените? Новый протокол — недостаточная причина, чтобы заменить то, что уже надёжно работает 10+ лет и ещё в два раза больше проработает. А скрещивать легаси с новым протоколом — Б-же упаси от такого геморроя.
Я уж молчу про экономию на персонале. Такую сеть могут обслуживать те же люди что обслуживают ethernet сеть.
Обслуживать новую сеть будут те же самые люди, которые обслуживали её до перехода.
Интересно, как вы всё легаси замените? Новый протокол — недостаточная причина, чтобы заменить то, что уже надёжно работает 10+ лет и ещё в два раза больше проработает.

Так же как и везде. Как только легаси станет сложно найти заменят на новый протокол.

Обслуживать новую сеть будут те же самые люди, которые обслуживали её до перехода.

Люди часто меняются быстрее железяк.
Так же как и везде. Как только легаси станет сложно найти заменят на новый протокол.
Приведу пример. Simatic Step5, Step7. На нём есть тьма установок, которые работают десятилетиями. И их никто не будет переделывать только потому, что появилась новая киллер-фича. Заменять систему управления на действующем объекте будут только от безысходности.
Представьте себе, что водоканал или электросети объявят: мы на неделю-две останавливаем оборудование для замены системы управления (а это очень маленький срок) потому, что появилась новая киллер-фича и наша нынешняя система её не поддерживает.
Автоматика — штука довольно инертная. Новый протокол сам по себе, это не хорошо и не плохо. По сравнению с ModBus по 485 это неоправданно сложно, но есть и другие применения. Более-менее внедряться это начнёт лет через 10.
10 лет вполне нормальный срок. К этому моменту уже технология устоится и будет стоить так же как rs-485. Более того будут аналогичные бухтения по замене его на новую технологию :)
10 лет — это оптимистичная оценка появления этой технологии в оборудовании для промышленной автоматики. Потом уже, как-нибудь, дело дойдёт до первых внедрений. Сколько времени уйдёт, пока это станет массовым и повсеместным — никто не знает. Не 10 лет точно.
А, вообще, ответьте на вопрос (себе, в первую очередь). Сколько времени вы готовы просидеть, скажем, без воды — пока водоканал заменит существующую систему на новую. Допустим, неделя (это очень оптимистично) уйдёт на монтаж/демонтаж, а пусконаладка — как Б-г даст. И всё это ради того, чтобы переехать с 485 на новоявленный интерфейс. При чём, сейчас всё работает, а с новым интерфейсом ещё хз сколько глюков будет и сколько времени уйдёт на их устранение.
Рад снова повидать ваши комментарии, коллега.

Вообще не ясны эти потуги плодить стандарты. Уже есть великолепные Profibus, Profinet, MB TCP. К чему городить что-то новое… не ясно.
А Profinet IRT и вовсе тихо смеётся с этой поделки
Рад снова повидать ваши комментарии, коллега.
Но мы в меньшинстве. Секта иллюминатов :)))
А Profinet IRT и вовсе тихо смеётся с этой поделки
С ним и сравнивать бесполезно. Хотя, у него физическая среда — тот же Ethernet. Кто его знает, может, он по этой двустволке заработает без каких-либо плясок с бубном.
Кто его знает, может, он по этой двустволке заработает без каких-либо плясок с бубном.

Profinet'у необходимы полнодуплексные 100 мегабит, так что двустволка в пролёте.

8 узлов в промышленности тоже смех вызывает.
В целом, какой-то новый мертворожденный никому не нужный стандарт.

Э-э-э, а там точно каждому устройству нужны все 100 мегабит? Боюсь представить какие каналы нужны ему на аплинке...

где вся задача — 2 байта переслать
на пару-тройку километров в полевых условиях ;)
При этом желательно несколько сотен раз в секунду, полсотне-сотне устройств, с гарантированной доставкой, контролем риалтайма, периодически рассылая конфигурацию устройствам которые только присоединяются к этому празднику жизни и автоматики.
И действительно, что такого трудного? Ах да, и это все в относительно агрессивных EMI-условиях (ощутимо агрессивнее офиса), в резервированном кольце с попутно работающими человеко-машинными панельками на той же шине. :-)
В Modbus по RS-485 нет аппаратного фрейминга. Да вообще аппаратной поддержки очень мало. МК должен постоянно мониторить сеть, чтобы что-то принять или передать.
А CAN и все, что поверх ethernet реализованы аппаратно. Выплюнул пакет в чип и забыл.

Учитывая, что сейчас большая часть умного дома вообще на wifi. Кажется это не такая уж большая проблема. Появится новый Arduino. Его и так уже теснит ESP. Ждём развития и беспроводных вариантов, там похоже побеждает Zigbee. Может появится какой-то то новый WiFi LE. Что то BLE в массы не идёт…

Вчера была статья про впиливание в WiFi IoT с низким потреблением. Если сделают частью стандарта и будут пихать во все потребительские чипы, zigbee и прочие просто умрут.
Проблема в том, что очень мало людей понимает, чем отличается глупый дом от промышленной автоматики. Вы пишете про умный дом, ардуино (Atmel), ESP. В самом начале статьи — Profibus, ModBus, CAN, HART. Вы понимаете, что это непересекающиеся множества?
А для этого протокола предлагается морочиться со всеми dhcp

Ну на Raspberry Pi DHCP поднять можно, вот встает вопрос свичей, куда новый стандарт воткнуть можно будет, или этот разъем в RG-45 войдет?
На raspberry pi-то можно поднять DHCP, вопрос про аппаратуру и софт на другом конце, где датчики и прочая мелочевка, типа датчиков открытия дверей в автомобиле.
Не говоря уже о том, что rPI — это для домашних энтузиастов, а протокол предлагают для замены промышленных протоколов, например, CAN в автомобиле, а там совсем другие технологии нужны.
Ответ saag:
А можно подключить этот коммутатор прямо в локальную сеть предприятия, если в дальние дали уже протянута сеть по оптоволокну. Воткнуть там в него датчики, а показания с них смотреть здесь. Прямо по сети. Без конвертеров интерфейсов и шлюзов.
То есть, вроде как, физически это обычный Ethernet и должен маршрутизироваться обычными Ethernet-свичами.
«полевая шина» — Profibus, Modbus, CC-Link, CAN, FlexRay, HART

Половина из них — протоколы. Более того, используются в разных ситуациях.
В общем, у нас было 5 несовместимых между собой протоколов. Давайте создадим единый стандарт…
Ну, совести ради с бытовой электроникой же получилось, за 20 лет везде стоит micro-usb, включая зубные щетки и шуруповерты.
Даже с microUSB проблемы: у меня есть кабели, который внешне не отличаются, но в одних есть data-линии, в других — нет.
По-моему, на баше когда-то давно было, но не нашёл. В общем, пожелание человеку, который придумал такие кабели — чтоб у него член был только, чтобы мочиться :)
Еще есть проблема 2038 года. Возможно, именно из-за нее будет обновление всего парка устройств с сопутствующими интерфейсами.
Не получилось. До сих пор на аудиоплеерах, автомобильных видеорегистраторах и некоторых других устройствах стоят mini-USB, на смартфонах micro-USB (при чём есть с длинным и коротким разъёмом), type-C и lightning.
Про Apple не скажу, но type-C кажется во всех новых Android-смартфонах вытеснил обычного micro-USB.
Только если это крупный бренд, мелкие продолжают на micro сидеть.
И уже есть предложения использовать его как замену I2C в серверах, коммутаторах и прочей электронике.
Ethernet для межблочных соединений в коммутаторе? Ему ведь тоже понадобятся коммутаторы. We need to go deeper!
И уже есть предложения использовать его как замену I2C в серверах, коммутаторах и прочей электронике.

Круто! при первом чтении статьи не заметил. Это шина I2C что-ли? Они там обкурились заменять её? Эта шина предназначена для обмена информацией между микросхемами.
Зато можно ставить стандартные коммутаторы которые при таких раскладах будут иметь гигантские тиражи и стоить дешевле грязи :D
это заблуждение! уже 20 лет как микроконтроллеры копеешные но чтото не видно в них гигабайта флеши и гигабайта оперативы. все в десятках килобайт измеряется. Я имею ввиду то что реально популярно. Уникальные процы есть но и цена у них никак не копеечная.
А для реализации полноценного ethernet стека 10 килов оперативы никак не хватит.
про квадратную шину вообще не хочу ничего говорить — ей достаточно одного сдвигового регистра и 10-ток вентилей и уже всё работает. цена вопроса.
кроме того надежность. все знают как езернет умирает при попадании молний или статики — он не всегда просто тухнет он иногда начинает срать в сеть гигабайтами в секунду — так и вижу как я на предприятии эту хрень внедрил а потом пол цеха лягло изза щелчка статики. а изза паралельных подключений — попробуй найди того поганца PHY в котором навернулся… мде… фантазии у вас
Речь очевидно про SMBus. Правда, врядли с ней кто-то будет так извращаться. Не столь уж важная шина чтобы так усложнять.

Они это называют 10BPE (Backplane Ethernet), делать собираются на основе 802.3cg. Для замены I2C/SMBus, MDIO, CAN. Ожидаемая стоимость контроллера 1-2 доллара. Dell уже проводила эксперименты, как 802.3cg работает на дорожках печатной платы. Так что есть вероятность, что сигнал будет передаваться прямо по плате, без витой пары. "Группа по интересам" состоит из представителей Dell, CISCO и Microsemi.
Вот ссылочка на документ

типа ds18b20 (I2C) с встроенным Ethernet? И какого размера станет микросхема? Кроме 3-х ножек добавятся две ручки для переноски? :)))

DS по 1-Wire работает. BME280 — по I2C. Показания счётчика электричества берутся через RS-485. Экранчик подключается через SPI. Данные на сервер уходят по Wi-Fi.


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


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

Пардон, с DS промахнулся. Давно не ковырял просто на столе валялся и попался на глаза.
Но суть моего коммента в другом есть много датчиков миниатюрных размеров с встроенным интерфейсом и Ethernet может увеличить их размеры (за счёт трансформатора) раза в 2.
Кроме того количество устройств на линии. Например пожарная сигнализация «Бирюза» — кольцевые шлейфы RS485, на одном кольце 126 датчиков (127 сам контроллер линии и при обрыве шлейфа из Slave превращается в Master с 0-м адресом). Так вот типовая 12-ти этажная общага на этаж приходилось два кольца делать (126 датчиков не хватало). Теперь цена — считаем 250 на этаж, 12 этажей итого 3000 датчиков (это реальная цифра, мы в Минске такую монтировали).
Итого стоимость только датчиков вырастет на 6000$.
Думаю заказчик будет не совсем рад, ему до лампочки какой интерфейс главное цена. А учитывая тендерную систему закупок, у нас в Белоруссии, государство ему просто не разрешит это покупать.

Согласен. При тысячах датчиков разумно выбирать вариант с дешёвыми датчиками.

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

А можно подключить этот коммутатор прямо в локальную сеть предприятия, если в дальние дали уже протянута сеть по оптоволокну. Воткнуть там в него датчики, а показания с них смотреть здесь. Прямо по сети. Без конвертеров интерфейсов и шлюзов.

Т.е. можно эту шину как-то втыкать в обычный ethernet? Полагаю, нужен мост. Правильно?
У вас фреймы одинаковые, ничего конвертировать не надо, смысл в этом. Это аля как из оптики в медь перекладывают и обратно. Устройства потупее чем конвертер.
Фреймы-то одинаковые, а пара одна. Т.е. полудуплекс. Значите, конвертер нужен.
Устройства потупее чем конвертер.

Ни о чём не говорит. Что внутри конвертера?
Значите, конвертер нужен.

Нет не нужен. Это обычный коммутатор. Любой управляемый коммутатор позволяет изменять скорость порта хоть 10мбит полу-дуплекс ставьте.

Ни о чём не говорит. Что внутри конвертера?

Конвертер из RS-485 подразумевает наличие интерфейса RS-485 и ethernet интерфейса, плюс дополнительная логика нужна как упаковывать будем. И самое веселое нет стандарта. В случае ethernet у вас банальный коммутатор который имеет порты с разными средами и все. А пакеты он получает и отправляет одинаковые.
Понял, спасибо! Только как, интересно, будет работать трансформатор внутри коммутатора Ethernet и конденсаторы у этой шины с другой стороны?
Там отдельный обычно контроллер на каждый порт. Весь ethernet давно же p2p
> Т.е. полудуплекс
Написано дуплекс или полудуплекс для T1S и только дуплекс для T1L. Одна пара — давно не ограничение для дуплекса (примеры — ADSL и обычный гигабитный ethernet).
в режиме мультипоинт (до 8 узлов)

EtherCAT в этом случае гораздо интереснее (кроме цены)
Почему-то не вспомнили, что у Ethernet довольно большой latency, поэтому он не очень удобен в пром. автомитизации. Чтобы отправить пару байт нужно: 7 байт преамбулы + 15 байт заголовка + 2 байта CRC + 12 байт паузы между пакетами.
Ethernet коммутируемый, так что задержки в нём вообще непредсказуемы. Поэтому и придуманы стандарты вроде Profinet.
да, неплохо задумано. Но в текущей ситуации это будет как на картинке.
image
А вот этот машинный контроллер лет 20 без Type C будет выпускаться
А если из него убрать USB, то он и не пострадает :)
Type-С неудобен как минимум тем что занимает значительно большую площадь на плате чем тот же microUSB. И там где достаточно обычного USB2.0 он еще очень долго будет присутствовать.
Да, появляются. Недавно подключал новый монитор от Lenovo, на борту USB 3.0 type-B. Сотрудник в чей кабинет ставили тот монитор спросил, нет ли шнура для принтера, а так как мне этот USB не был нужен в принципе, то предложил ему. А на принтере оказался USB 2.0 type-B.
Наконец-то сбудется мечта телефонистов — «а можно сразу 4 IP-телефона через один кабель подключить?»
Нормальная тема. Само собой не про КИП это всё. Надо что-то нетребовательное подключить в офисе, докупил SFP, воткнул в сетку и погнал.
про видеокамеры не очень ясно: это какого качества видео должно быть чтоб 1.2мега в секунду?
Прежде всего – он работает по одной витой паре, а не по четырём

100 мегабит и 10 мегабит, всегда работали по двум витым парам а не по четырем.
10 мегабит раньше вообще работал по одной «витой паре» — коаксиалу. Ага, и еще мультипоинт… Не прошло и пятнадцати лет…
Ага, вот только он на километр не мог. И у него очень существенные ограничения для нынешних времён. На тонком коаксиле не больше 30 устройств в одном сегменте, органичения по длине сегмента, нужно выдерживать кратность 2,5 м между точками подключений и т.п.
Эх… Помню ещё в школе настраивали сеть…
Вот про кратность вообще не помню. Может это был «толстый» эзернет?
А насчет километра, так это тогда всего две проблемы: сигнал/шум, и тайминги CSMA/CD.
Сейчас в кремнии и С/Ш получше, и модуляции поизысканее. А тайминги — чисто договоренность.
А в случае «один порт комутатора — одно устройство», вообще, проблемы были чисто договорится.
На реалтеках и д-линках мы реально гоняли пакеты на триста пять метров (бухту обжали :-). Но заказчику такое ставить нельзя — у любого другого админа будет истерика.
Возможно на кратность просто забивали, но да, что то мне тоже про толстый кажется, хотя у меня его и не было. А для тонкого до сих пор где-то линейка DIP микросхем трансиверов валяется — грозы :(
Где-то видел инструкцию, как перепаять кварцы на сетевых картах, поправить схему, чтобы работать по 1 витой паре и гнать где-то на километр на 2 -2,5 мегабитах

А ещё 1гбит и 10гбит по витой паре (1000BASE-T и 10GBASE-T) тоже работают в обе стороны по каждой из 4 используемых витых пар, причём не в режиме 'мультипоинт', а именно передавая 2 разных сигнала в каждую из сторон по линии передачи (aka витой паре).

А почему медь а не оптика?
Оптика ведь многим дальше сигнал передаст, да и интерференции нет.
А при такой низкой скорости ещё и проблема с модами не так критична.
Здесь и питание в одном флаконе.
IoT в вашу медь :-)
А «гетерогенную» оптику с питанием скоро придумают, лет через пять.
С медью проще работать. Дешевле инструменты, ниже квалификация требуется.
Но не везде медь годится. Проложите медью связь на электростанции :)
А ещё у оптики гальваническая развязка есть «из коробки».
Тут речь идет про локальные соединения все же. Там медь поудобнее. И не требует специнструмента для работы с оптоволокном.
Интерференция есть даже в оптоволокне. При отправке двух сигналов на недостаточно разделенных частотах и при высокой яркости света(да, яркость тоже влияет на эффект). Образуются гармоники там где их и не ждали, на соседних частотах. Таким образом свет одной частоты может влиять на свет других частот.
Интерференция есть. А разве 2 лазера будут когерентны друг с другом? А образование гармоник — это вообще нелинейный эффект, кто будет такую мощность давать в волокно?
недостаточно разделенных частотах

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

Заменить CAN (а тем более FlexRay) этим вот интерфейсом — сомнительная, хотя и нажористая идея. Вот победить RS-485+Modbus в КИПиА — запросто, протокольный уровень и правда ничем не сложнее, а за новую схемотехнику потребитель все равно заплатит, как уже платит за использование EtherCAT везде, где ни попадя. А вот с заменой I2C опять наркоманство какое-то… Зачем?


А Хартинг пусть сначала научится делать разъемы М12.

Вот победить RS-485+Modbus в КИПиА — запросто
Не в этой жизни, эта парочка ещё нас с вами переживёт.
Я прекрасно это понимаю, но уж коли мы рассуждаем в духе «ну может же», то да — может.
в духе «ну может же»
В этом духе — конечно, может. Вероятность 50% :)
Практически же, у них разная сложность реализации и тут Modbus на 485 явно выигрывает.
Это сравнение очень напоминает сравнение USB и UART (232). Несмотря на все прогнозы и перипетии UART жив и будет жить ещё долго.
Ну погодите, про различия в сложности схемоты Ethernet и RS-485 (причем скорее дело в традиционности второго) я уже упомянул, и за это есть кому заплатить. А в части протоколов там нет особых отличий.

Но, повторюсь, общая позиция очевидна — вряд ли.
и за это есть кому заплатить.
В кровавом энтерпрайзе — да. Но старикашка 485 (и UART, вообще) применяется не только в нём.

+1.


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

©пёрто в интернете, использовано в обсуждении "USB vs. UART-RS232".

для передачи питания нужны 2 пары проводов

Это когда вместе с данными?

Сомнительная затея. Имхо, на производстве не взлетит, там давно rs-485, который дешевле, поддерживается почти всем и вся, умеет в топологию типа кольцо и дружит с опторазвязками. В автомобильной электронике так же давно есть CAN. Скорости в 10 мбит/с там не нужны.


Единственное применение, которое приходит на ум — ip-телефония, скорости подходящие и некоторая экономия проводов.

Ну наконец-то решили основательно взяться за этот сегмент ) Для умного дома самое то, как и для кучи разных применений, где 100 мбит+ никак не нужны, ценой кучи проводов. Теперь полноценная TCP/IP сеть вместо 1wire, дальше дело времени, когда умные приблуды станут обыденностью в доме.
IP камеры подключать одной парой вообще будет сказка, еще и при 1 км расстояния. 2-3 камеры 720p на одной шине вполне поместятся. Проще и дешевле защищать от перенапряжений для уличного применения, т.к всего одна пара. Будем надеяться китайцы за несколько лет освоят :)
К тому времени, как массово внедрится этот стандарт, камеры меньше 4Мп будут смотреться как компьютеры pentium3 с 512мб оперативки в 2020 году. И со стороны беспроводки будет сильная конкуренция, либо wifi6, либо 5G с фемто-сотами. Если бы появился лет 5 назад, ещё мог составить конкуренцию, хотя бы против коаксиала в виде AHD/TVI/SDI
Камера 2Мп это 1920*1080*25 требует около 7 мбит в h264, по факту можно включить сжатие до 2 мбит без особых потерь. Но уже сейчас 5Мп камера стоит не намного дороже чем 2Мп.
Меньше 7 Мбит/с — это наверное так себе качество (среднее 0.15 бит/пиксель дает 7.416 Мбит/с).
Я в принципе смотрел фильмы с 0.11 бит/пиксель, но это было FullHD на мониторе 1280x800.
Хотя, я создал 0.016 бит/пиксель видео (1920x800), оригинал — такой же, 4:2:2 и 10 бит.
Авторские права и все такое
Частота кадров, используемая в системах видеонаблюдения (опрос установщиков систем видеонаблюдения)
image
(Последний столбик неправильно подписали. Должно быть ">25")
В подключении разницы нет обжать два или восемь проводов в коннекторе, да и никто не запрещает AHD использовать на коаксиале. Питание на километр не подашь, а защищать только выход видео не будешь. А две, три камеры можно и по оптике кинуть.
Интересно, а полярность внутри диф.пары нужно соблюдать или это дело разруливается как в USB3.0/PCIe/Ethernet?
Именно. Внутри диф.пары подключать проводники можно как угодно, но сами диф.пары (RX/TX) между собой путать нельзя. Инверсия делается на уровне PHY.
А для особо непонятливых как-то подробнее можно про этот момент? Я всё ваше изречение воспринял, как масло еонялсам. Какой RX/TX в USB, какие дифпары между собой?

В USB 3 SuperSpeed (5Гбит/с) есть две дифпары: StdA_SSRX ±, StdA_SSTX ±. Приемники SuperSpeed обязаны уметь принимать сигнал с обратной полярностью (USB 3.0 specification, section 6.4.2) — http://xillybus.com/tutorials/usb3.0-training-by-example


The USB 3.x spec requires the receiver to be tolertant to lane polarity reversal, i.e. that the P and N differential wires are swapped. If this happens, all K codes in use are received without change (the 8b/10b code makes them appear to be the same), but D10.2 (0x4a) arrives as D21.5 (0xb5), and D5.2 (0x45) arrives as D26.5 (0xba).

Подключение RX пары хоста на RX пару приемника приведет к неработоспособности SuperSpeed. Пару D+/D- стандарта usb 2 вроде переворачивать нельзя.
В USB 3.2 появляются режимы с несколькими наборами пар (lane): USB 3.2 Gen 1×2, USB 3.2 Gen 2×2; USB Type-C кабели: SSTXp1/SSTXn1, SSRXp1/SSRXn1, SSTXp2/SSTXn2, SSRXp2/SSRXn2; картинки Figure 1, Figure 3. Можно ли подключать пары в неправильном порядке (TX1-RX2) — неясно; возможно описано где-то в http://caxapa.ru/thumbs/945953/USB4_1.0_20190829.pdf

Очередной идиотизм из серии:
— У нас есть 14 несовместимых между собой стандартов, нужно изобрести один универсальный!
— У нас есть 15 несовместимых между собой стандартов…
Уж в автомобилях-то точно.

А почему так категорично? Чем он кардинально лучше текущего CAN для автомобильного применения?

У меня сложилось такое впечатление после просмотра презентаций автомобильных компаний. У них там как в фильме "Москва слезам не верит": "В будущем не будет никакого CAN и FlexRelay — одно сплошное телевидение Ethernet". Не могу сказать, чем оно кардинально лучше CAN, но кто я такой, чтобы указывать BMW, Daimler или Volkswagen.


Хотя они в основном рассказывают про скоростные сети — от 100 Мбит и выше. Но в конференциях по 10-мегабитному SPE тоже участвуют активно. Вообще, если смотреть список основных докладчиков на этих конференциях — практически всегда выступают Cisco, BMW, Rockwell Automation и Pepperl+Fuchs (производитель всяких датчиков и промавтоматики). Электронщиков тоже хватает — Microchip, Analog Devices, NXP, Broadcom, CanovaTech.

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