DarkXimik

На подобных устройствах используется урезанная версия RS-232 интерфейса (RxD, TxD, GND). Так вот RxD преобразователя соединяют с TxD теплосчётчика, а TxD преобразователя с RxD теплосчётчика. GND с GND. Может у Вас кабель неправильно распаян/подключен? Проверьте.

Здравствуйте. А что за ПО используется на сервере?

Здравствуйте! Сталкивался с похожей проблемой. Разница только в том, что любые com-порты (например созданные Uport 1110 ) оказывались кем-то заняты. То есть какое-то стороннее ПО просто тупо занимает любые найденные com-порты. В моём случае этим ПО оказалось SoMachine от Schneider Electric. Снёс за ненадобностью SoMachine и всё заработало. Так, что ищите того кто занимает порты.

Ну походу с OPC тоже бяда? А что за метеостанция если не секрет?

Может даже производитель метеостанции снабдил её каким нибудь софтом. Например OPC-UA сервером.

Да и у симпл-скада есть поддержка. И форум есть. Там больше шансов решить вашу проблему. Симпл скада понимает OPC-UA. Возможно на форуме подскажут какой нибудь OPC-UA сервер умеющий работать с метеостанциями.

А разве симпл скада работает на линуксе? Вы чего то про линукс писали.

А Вам не кажется, что этот вопрос логичнее задать производителю "SCADA". Это ведь "SCADA" не может напрямую работать с метеостанцией, а не nport-5150. Вы нам даже название этой "SCADA" не сообщили. С таким набором исходных данных трудно оказывать помощь. Всё, что мы знаем про "SCADA", так это то, что она умеет работать через WEB API и умеет читать текстовые файлы.

Здравствуйте. Я не техподдержка поэтому выскажусь. Судя по всему Вы не очень понимаете каково назначение преобразователей RS-232/422/485 в ethernet. Так вот, данные устройства инкапсулируют любую информацию пришедшую в последовательный порт в пакеты TCP или UDP. И/или делают обратную операцию. Они не преобразуют протоколы! И режим TCP server не подразумевает никакого HTTP/HTTPS. Проще говоря, если Ваша метеостанция отправляет в порт asscii строку то asscii строку вы и получите из TCP-соккета. Причём в не изменённом виде. И искать там HTTP любой версии просто пустая трата времени. Его там нет. От слова ВООБЩЕ! Во всяком случае nport-5150 никакой HTTP не добавит.

Добрый день. Хочу добавить, что выбор режима зависит от возможностей того ПО которое вы применяете для организации ССПИ или что там у Вас. Проще говоря режим работы преобразователя TCP Server не означает, что МЭК 60870-5-101 преобразуется в МЭК 60870-5-104. Если исползуемое Вами ПО может работать в так называемом режиме МЭК 60870-5-101 поверх TCP то выбирайте TCP Server, иначе RealCOM.

Может быть тип данных всё-таки не boolean, а signed long? Ну не может целое быть true.

То-есть Вы уверены в том, что соединение с МЭ110-220.3М устанавливается? Так же уверены в том, что OPC сервер работает с МЭ110-220.3М в режиме modbus повех tcp, а не в режиме modbus tcp? Если так, тогда Вам однозначно в поддержку ОВЕН обратиться надо.

И еще, чуть не забыл, MODBUS поверх TCP в true переведите.

Порт в настройках "Node1" нужно так же поменять на 4001. Там где настройки TCP/IP, под IP адресом. Последовательный порт преобразователя так же должен быть переведён в режим RS-485. Ну и возможно провода местами поменять на МЭ110-220.3М. Или перевести преобразователь в режим RealCOM, создать виртуальный com port и работать с ним. COM порт можно создать, например NPort Administrator или Windows Driver Manager. Можно качнуть на сайте moxa.

Так вы форумом ошиблись. Вам скорее сюда https://owen.ru/forum/forum.php А вообще в каком режиме преобразователь работает? RealCOM? TCP server? Он modbus rtu в modbus tcp не преобразует. Порт не может быть 502. Скорее порт 4001, но только если преобразователь в режиме TCP server.

Ну вобщем всё логично. А вот на последнем скриншоте есть кнопка Auto Detection. Вы её нажимали. Ответ от устройства был? Просто есть подозрение, что кабель распаян неправильно. Вы пробовали в кабеле TX-/+ местами поменять с RX-/+?

А ещё вопрос. Вы ПИ-2 как подключаете к устройству TX+/- на устройстве к TX+/- на преобразователе(для RX+/- аналогично) или TX+/- на устройстве к RX+/- на преобразователе (ну и RX+/- устройство TX+/- преобразователь)?

Я в курсе, EKB installer тут не приделах. FB108 давно декомпилировали. http://plc4good.org.ua/view_post.php?id=246 Так для справки.

Ну если хорошо погуглить то 1000 евро нафиг не надо. Ну Вы поняли к чему я? А так вообще непонятно почему не заработала передача через CP для ET200S напрямую.

Ну так надо смотреть в сторону MODBUS RTU -> BROFIBUS/PROFINET. Что то вроде MGate 5103 . WinCC может и с MODBUS RTU через OPC DA/UA. Если в контролере нет никакого алгоритма работы с камерами (контроллер в роли ретранслятора) то в скаду проще напрямую заводить. А вообще последовательность устройство -> скада -> PLC -> скада не есть хорошо. Надо устройство -> PLC -> скада. А Вы смотрели чего от камеры приходит? В теории со стандартным MODBUS RTU вроде проблем не должно быть.

Здравствуйте. Не очень понял для чего Вы себе трудности придумали преобразуя MODBUS RTU -> MODBUS TCP? Не проще ли взять просто преобразователь com-портов в Ethernet? Например Nport-5150a. Вы бы имели всё тот же Ethernet, но не имели бы проблем в виде преобразователя протоколов. Я так понимаю софт от Binder может работать и с MODBUS RTU через com-порт?

Крутяк! Как минимум два раза у меня на данном кабеле какая то рабочая пара повреждена была, а вот на отрезке совершенно другого кабеля (от другого производителя) всё заработало с первого раза? Да и повреждение одной жилы как правило приводит к полной неработоспособности, и не какое автосогласование не помогает. Это кстати из опыта эксплуатации сетей. Как то связь с цехом пропала, проверил кабель одна жила в обрыве. Прекладывать кабель геморно. Переобжал концы и заменил повреждённую пару свободной. И всё заработало.

На другой стороне коммутатор. В цеху стоит HP Procurve модель не помню. В кабинете, где эксперименты проводил D-Link модель тоже не помню. Да и неважно точное название коммутаторов. На ноутбуке 100Base-T. Старенький он. Да и на NPort 5150A индикатор link горел зелёным. Типо всё ОК. Несущая на месте.

На коробке написано Cat 5e FTP. Мерят мне не чем. Собственно я согласен кабель как кабель. Вполне себе нормальный. Другие же устройства нормально работают с ним/через него. Доказано как минимум на двух отрезках данного кабеля. С NPort 5150A тогда, что? Может продукция MOXA некачественная? Я таки потерял кучу времени на эксперименты с кабелем и перекладку кабеля. Кстати года два назад у меня аналогичная проблема с NPort 5150A была. Решили проблему тогда путём укорачивания сегмента. В середине сегмента коммутатор поставили. Хорошо, что было где ставить. Мне не особо нравится такое поведение преобразователей NPort серии 5000A, а возможно и других серий. По мне, так преобразователь должен нормально работать на линиях длинной 100 метров не менее, без танцев с бубном. И тем более на линиях 50-60 метров. На любом кабеле на котором написано Cat.5e UTP/FTP/... Таков стандарт Fast Ethernet 10/100 Base T(X). И вроде как данному стандарту соответствует NPort 5150A. Во всяком случае так в документации к преобразователю написано.