Суть проблемы - есть устройство регистрации сухих контактов, подключенное к ПК. До него нужно довести состояние сигнализаторов уровня жидкости. Сигнализаторы удалены. По ТЗ необходимо преобразовать состояние сигнализаторов (сухой контакт) в Ethernet. Затем передать на обратный преобразователь Ethernet сухой контакт. И подать на устройство регистрации.
Кто нибудь делал подобное?
У Моха есть контроллеры 4000 серии. Позволяют преобразовать Сухой контакт -> Modbus/TCP. Затем с компа можно посмотреть состояние. Но задача стоит именно в выводе на сухой контакт на приемной стороне. То есть если с прямым преобразованием более менее понятно. То с обратным не очень ясно. Как вариант использовать одноплатный комп (типа промышленный ПК с соответсвующим программным обеспечением). Но хотелось бы что нить стандартное.

Дык возьмите у той же Moxa конвертор Ethernet<->RS232 и добавьте к нему МК с UARTом. Этот МК будет считывать состояния и управлять вашими "сухими" контактами в требуемом количестве.

В промышленных системах управления Ethernet, обычно, не используется непосредственно в системах управления (датчики-контроллер) по тому, что не обеспечивается гарантированная доставка сообщения. По этой причине, я так думаю, нет модулей удаленной периферии с интерфейсом Ethernet. Разрабатывался, так называемый, промышленный Ethernet, но текущее состояние я не знаю. Учтите это при включение датчиков в систему управления по Ethernet. И еще. Возможно, причина использования Ethernet в качестве полевой шины в наличии проложенного сетевого кабеля. Если удаление небольшое, возможно, будет дешевле пробросить новый кабель. Известите об этом заказчика с примерной раскладкой стоимости, может передумает.

А что, RS485 обеспечивает??? Гарантированная доставка сообщений обеспечивается протоколами более высокого уровня, и кстати, тот же Modbus этой гарантии не дает.

Я бы вообще не использовал стандартные конвертеры по причине дороговизны и избыточности. Вам надо 2 совершенно идентичных устройства. Ethernet контроллер+управляющий микроконтроллер. Для обеспечения гарантированной доставки использовать TCP. И будет счастье. Комплетктующие для вашего случая стоят копейки. Используюутся стандартные схемы включения. Ничего изобретать не надо, Конечно придется заплатить человеку который будет контроллер программировать. И не надо городить огород...

А вот такая штука тебе не подойдет? Стоимость модуля 18 баксов, стоимость платы под нее ... ну мне вышло рублей в 50. На выходе УАРТ, может быть хоть клиентом ,хоть сервером. Настроек тьма, хоть ТСП, хоть УДП. По моему самый вертолет. Нэ?

Есть такой. Как раз для сухих контактов проектировался.
http://aly.ogmis.lt/OpenProjects/ARMDominator4/ARMD4.htm

По Ethernet инфа о контактах передается по протоколу SNMP, HTTP, Telnet и т.д.
SNMP совместим со многими SCADA и бесплатными пакетами типа Open NMS.

Есть Add-On плата которая может превратить дивайс в резервный шлюз Ethernet-GPRS для всей внешней сети Ethernet в случае в случае если основной канал обрывается.

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

Народ, присоветуйте пожалуйста. Задача, мониторить через транспортную сеть на основе IP состояние сухих контактов на удаленных объектах. Готовые типовые решения есть?

Сеть ПЛК, например. Задавайте вопросы конкретнее (бюджет и т.д.)

Крайне желательно забирать информацию о контактах по протоколу SNMP

На Ваш "ответ" отвечаю: сеть Линукс-машин в пром. исполнении поможет. Сухие контакты можно повесить на пар. порт.

ЗЫ: Телепаты в отпуске, а вариантов много. От дешевых до дорогих.

Не понял, при чем RS485. Profibus, например, обеспечивает гарантированную доставку за заранее известное время.



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

А чем вам мой дивай не нравиться?

http://electronix.ru/forum/index.php?showt...mp;#entry403171

AlexandrY
Мне Ваш девайс очень понравился, но на вид он достаточно "тяжел", вернее громоздок для такой простой задачи. Кроме того, думаю, что и по цене будет "не легок". Если ошибаюсь, поправьте

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 штук (это не предел, понятное дело, просто в стойку вменяемой высоты больше оборудования не сунешь). В эти розетки тыкались сервера, свичи и прочее барахло в стойке и через веб-страничку можно было удаленно передернуть питание с рабочего места одмина, а не идти к стойке.