Ok, могу поснимать USB, CAN, Audio, charger и т.д.
Будет тогда полегче?

Реально для корпоративных сетей с нормальным SNMP v1, v2 и соответствующим всем необходимым RFC (чтоб было совместимо с софтом на PC) большинство юзает линуксовые дивайсы, если их откроете то ахнете сколько там лишнего наворочено.
И цены у них приличные.
Что плохо, когда покупаете у крупного производителя, то практически не можете уже изменить структуру его MIB-ов и TRAP-ов (базы данных переменных и сигналов устройства) и WEB интерфейс также.
В моем устройстве необходимую структуру MIB-ов и TRAP-ов можно заказать.
Клиент может разработать полностью кастомизированный WEB интерфейс с использованием AJAX

касательно функционала и прочего: нужен аналог устройства http://lightcom.ru/production/netping/digiping.asp , но, от отличного от "lightcom" производителя

Вы, видимо, путаете низкоуровневые протоколы (Ethernet и RS485) и высокоуровневые (TCP/IP и верхняя часть ProfiBus).

Напомню, что Ваша реплика звучала так:


Сам по себе Ethernet (собственно оговоренный набором стандартов IEEE802.3) используется для передачи пакетов более высокого уровня (например, IP, а в них TCP), и вот именно TCP обеспечивает гарантированную доставку.

Аналогично, RS485, который может выступать как один из физических уровней для ProfiBus - это даже вообще физическая среда, но обычно, под термином RS485 подразумевается еще и использование UART-фреймов для передачи байтов. И, следовательно, как и в Ethernet, гарантированность доставки перекладывается на более высокий уровень.

Да нет не путаю. Можно ли использовать Windows для систем реального времени? Там где можно, там и Ethernet сойдет в качестве полевой шины. Т.е. если не нужна гарантия передачи информации в заданные интервалы времени, то пожалуйста. Разве протокол TCP или RS485 разруливает доступом устройств к сети Ethernet?

Поразительное логическое заключение



Простите, но Вы сами-то поняли, что спросили?

Это не логическое заключение, это аналогия.
Я понял, что спросил. Можно по другому.
Какое гарантированное время доступа одного устройства к другому обеспечивает TCP поверх Ethernet (не индустриал) при загрузке процентов (хотя бы) до 50?

Скажем так, если нагрузка сети такова, что свичи не блокируются, то это время на прохождение по линии связи (скорость света с учетом эпсилон) плюс задержка в свичах. Задержка в свичах, конечно, не нормируется, но ее можно принять как время, требуемое на прием пакета, плюс время, требуемое на передачу пакета, плюс время на возможное ожидание окончания уже передаваемого пакета. Время ожидания окончания передачи пакета надо брать с учетом InterFrame Gap. Внутренняя коммутация практически не вносит дополнительных задержек, например, RTL8324 имеет "Non-blocking wire-speed forwarding and filtering (4.8Gbps throughput)", это 24 порта по 100 мБит в обе стороны, при этом свич не блокируется.

Но, собственно говоря, в рамках этой темы - наш спор суть флуд

Пусть в сети несколько узлов (или десятков) с датчиками и датчики подключенны к контроллеру по эзернет и произошла авария. Все ломанутся докладывать контроллеру. Вы сможете спрогнозировать время реакции на самый нужный датчик?
А используя Profibus, я это легко прогнозирую.

Смогу. Не более стольких-то микросекунд.

Выдержка из статьи «Computerworld Россия»
http://www.comprog.ru/local6.html

Традиционным недостатком использования Ethernet в системах управления долгое время считался вероятностный характер доступа устройств к сети, не позволявший гарантировать передачу информации в заданные интервалы времени. Считалось, что при загрузке сети, превышающей 40%, задержка передачи данных возрастала экспоненциально. Однако исследования, проведенные в конце 80-х, показали, что при повышении уровня трафика задержки увеличиваются линейно и варьируются в пределах от 2 до 30 мс, что приемлемо для ряда промышленных применений. Однако для дополнительного уменьшения задержки потребовалось бы разбить сеть на сегменты и значительно снизить трафик в каждом из них.

http://ru.wikipedia.org/wiki/Industrial_Ethernet

Industrial Ethernet — стандартизованный (IEEE 802.3 и 802.11) вариант Ethernet для применения в промышленности. Сеть с процедурой доступа CSMA/CD. Industrial Ethernet обычно используется для обмена данными между программируемыми контроллерами и системами человеко-машинного интерфейса, реже для обмена данных между контроллерами и, незначительно, для подключения к контроллерам удаленного оборудования (датчиков и исполнительных устройств). Широкому применению Ethernet в последних задачах препятствует суть метода CSMA/CD, делающая невозможным гарантию обмена небольшим количеством информации (единицы байт) с высокой частотой (миллисекундные циклы обмена). Новый стандарт PROFINET, включающий в себя Ethernet как подмножество, устраняет эти недостатки, дополняя стек протоколов протоколами, обеспечивающими временную синхронизацию сети.
В последнее время является одной из самых распространённых промышленных сетей. Широко применяется при автоматизации зданий и в областях не требующих высокой надёжности.

АБАЛДЕТЬ!
У автора сухие контакты, а вы микросекунды подсчитываете.
Надо водку пить хоть иногда.

По теме: проблема решается модбасом через ethernet + пинговалка, снимающая управляющее воздействие по таймауту (потеря управляемости)

Насколько мне известно, метод CSMA/CD в режиме Full-Duplex не используется и, следовательно, препятствовать не может.

Не читайте перед обедом советских газет! (ЦЕ)

Давно уже фулл-дуплекс И свичи неблокирующие. А все приведенные данные - это для сетки на коаксиале.



Не я начал.

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

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

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