Ищу Ethernet to RS485 конвертер.
Необходимо надёжное устройство, так как работать будет с важными данными.
В поиске оптимального решения по соотношению цена/качество, наткнулся на китайского производителя USR IOT, в частности на этот продукт.
Кто-нибудь работал с их оборудованием? Есть отзывы?
Или может посоветуете конвертер?

Moxa NPort

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

С2000-Ethernet в прозрачном режиме. По цене точно выигрывает у моксы.

Moxa NPort 5130 стоит около 10 500 рублей
Есть конвертер ATC-1000 компании ATC-converters, он стоит порядка 4 500 рублей.
Работал с 4х-портовым конвертером ATC, вроде бы нареканий не было.
Что скажите по поводу этой фирмы?


По цене существенно выигрывает. В 5 раз примерно, судя по их прайсу.
Как в работе этот конвертер? Надёжный?

Если Вам нужна одна штука, то выбор очевиден. А если много... Сможете купить дешевую и испытывать ее для убеждения себя в ее надежности? Месяц, год...?

Выбор очевиден? Это вы на NPort намекаете? Нужно несколько, но и в перспективе могут ещё понадобиться. Может у форумчан есть позитивный опыт работы с конвертерами, хотелось бы узнать. Не хочется переплачивать.

Moxa NPort. Ее тоже нужно настраивать, чтоб все было хорошо (буфера, разделители, таймауты).
Можете подробнее описать задачу? Что именно вам нужно?
Виртуальный COM-порт на ПК, который транслируется через TCP/IP в железный RS485?
Или RS485 с двух сторон, а посередине TCP/IP?
Есть ли требования к задержкам? Пропускной способности?

Нужен виртуальный COM-порт на ПК, который транслируется через TCP/IP в железный RS485. Работать с устройством "Эскорт КУСС", особых требований к устройству нет. Опрашиваем раз в пару секунд и пишем ответ.

Не очень понятно. А почему не нормальный COM-порт, который преобразуется в RS485? Зачем между ними что-то еще?

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




Зато дешево

В C2000-Ethernet есть прозрачный режим работы, т.е. UDP <-> RS232/485. RS конфигурируется по скорости и стоп-битам. Подробнее можно посмотреть в разделе характеристики.
Если характеристики удовлетворяют задаче, то это хороший и дешевый вариант. В плане эксплуатации куча форумов и приличная тех.поддержка.
Если требуется широкий диапазон конфигурации (большое число сетевых клиентов, супер-выскоая скорость и пр.), то стоит смотреть в сторону моксы.
Главное разобраться к требованиям. ИМХО, не стоит переплачивать за сложное решение, если задача решается просто и не имеет потенциала к сильному усложнению.

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

Если протокол обмена завязан с тайм-аутами, могут быть проблемы.

Да ну! А как же тогда интеренет работает? Или думаете его не Камчатке нет?



Пакетный в байтовый и наоборот "прозрачно" и ОДНОЗНАЧНО не конвертируется в принципе. Посему если не пофиг что типа текстовой консоли, то тогда начинаются ПРАВИЛА конвертации одного в другого, для чего, увы, нужны наличие правил и их настройки.

Бывает, что и не работает... И не только на Камчатке.

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

Мы в свое время были вынуждены расширять протокол, т.к. предыдущий ну никак не мог "разрулить" ситуацию:
1. Запрос от Мастера.
2. Ожидание ответа.
3. Слейв отправляет ответ, но Мастер уже решил, что случился таймаут.
4. Мастер отправляет новый запрос уже следующему Слейву.
5. Приходит ответ от первого Слейва, но расценивается как ответ от второго.
6. Приходит ответ от второго Слейва - детектируется ошибка, мол, никто ничего не запрашивал.

Это хорошо, если есть исходники, у ТСа их нет, похоже..

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

1. Протокол разрабатывал не я.
2. Без адреса слейва все прекрасно работает, пока не появляется буферизация.

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



Исходников устройства у меня нет. Поэтому протокол менять я не могу.

Это понятно, но время "молчания" все-таки кто-то регламентирует, или оно может молчать вечно и программа будет ждать?? Если нет, то вот это время и может стать слабым звеном..