МАРШРУТНАЯ РЕТРАНСЛЯЦИЯ MODBUS

[EFrol]

Добрый день, Василий.
Давайте определимся, что Вам надо?

Если Вам нужно готовое устройство от ОВЕН - такого устройства нет.
Если Вам нужен пример кода для ПЛК110-30 - Вам бы его уже предложили.
Если Вам нужен ответ на вопрос "можно ли реализовать на базе этого ПЛК ретранслятор" - можно. (ссылки на библиотеки Вам дали)
Если Вам нужна помощь в реализации ПО по вашим задачам - предложите форму сотрудничества.

Примечание:
Ретранслятором в данном случае имеется в виду только ПЛК реализующий инкапсуляцию пакетов "верхний-нижний" и капсуляцию "нижний-верхний".
Запрос капсулируется на верхнем уровне Lectus'ом.
Последний ретранслятор в цепочке на выходе выдает ModbusRTU-запрос для контроллера обслуживающий скважину.
Ответ передается обратно с капсуляцией на каждом ретрансляторе.
Инкапсуляцию ответа производит Lectus.

Если я ТЗ описал верно, то готов взяться за решение.

[melky]

Без схемы не совсем понятно. Подозреваю, какие бы там ПЛК ни были, это реализация программная, а не заложенная сразу в ПЛК. Так как предусматривать такие вещи производителям ПЛК слишком дорого...

[imaex]

Подозреваю, какие бы там ПЛК ни были, это реализация программная, а не заложенная сразу в ПЛК.

Предположу, что всё же "искаропки". Беглое чтение первого попавшегося документа по ScadaPACK 32 показало, что там в настройках Modbus TCP есть режим Store and Forward и ссылка на некую таблицу маршрутизации, завязанную на этот режим. Возможно, это как раз про то самое. Но, не уверен

[zaychenko]

ПЛК выполняет функции удаленного ввода-вывода для сбора состояний датчиков и пересылку пакетов из "верхней сети" (мощный модем 160 МГц, связь с ДП) в "нижнюю" (маломощный модем 433 МГц, связь со станциями управления).
Основная задача, в этом случае, это реализовать "вложенную", если так можно выразиться, ретрансляцию пакетов Modbus RTU (и я понимаю что это не возможно cделать стандартными функциями Modbus) из одного порта в другой .

Но не на всех объектах "верхняя" сеть это модемы 160 МГц, где-то используется ШПД (WLAN). Вот для этих случаев уже необходимо сначало преобразование из TCP в RTU, затем отправка пакета RTU в "нижний" порт, а после ответа оконечного устройства обратно преобразование в TCP и отсылка в "верхний" порт.

Изменить конфигурацию оборудования невозможно... проекты реализуются годами. Использовать другую схему передачи данных тоже невозможно.
И да... никто не знает когда и кем эта ретрансляция вообще была придумана... возможно из-за того что ScadaPACK в нефтянке были практически монополистами и там этот базовый функционал из коробки.

Мб подойдет под решение задачи вот это видео: https://www.youtube.com/watch?v=0w8hZK6yLW4&t=1s

[EFrol]

Добрый день!
2) Организовать маршрутную ретрансляцию пакетов данных Modbus TCP с "верхнего" Ethernet порта на "нижний" rs485.

Кстати 2-ю задачу может выполнить https://owen.ru/product/mkon/specifications
Он только покеты со Slave ID равным 1 оставляет себе, а все остальное отправляет в RS485, добавляя CRC в конец пакета.

Т.е. Ваш ModbusTCP пакет: 64 97 00 00 00 09 E3 17 03 00 01 00 01 D7 3C
он выдаст в RS485: E3 17 03 00 01 00 01 D7 3C 97 CF
соответственно ретранслятор (0xЕ3) 227 отбросит Е3 и 97 СF
передаст дальше только: 17 03 00 01 00 01 D7 3C - уже корректный ModbusRTU запрос устройству (0x17) 23

[keysansa]

Не делайте скоропалительных выводов. Это может быть удобно по неочевидным причинам, которые на поверхности не лежат. А может просто так исторически сложилось. ТС же всей картины не раскрывает.

Согласен. Но данный коментарий мне напоминает противостояние Linux и Windows. В первой - каждая утилита заточена под свою задачу, но выполняет ее идеально. Вторая - сумасшедший комбайн, где все перемешано (говорю с точки зрения автоматизации а не пользователя).

[keysansa]

ПЛК выполняет функции удаленного ввода-вывода для сбора состояний датчиков и пересылку пакетов из "верхней сети" (мощный модем 160 МГц, связь с ДП) в "нижнюю" (маломощный модем 433 МГц, связь со станциями управления).

Контроллер выступает мастером на 160МГц, и по другому порту выступает слейвом (или мастером) на 433 МГц. Тут проблем не видно.

Основная задача, в этом случае, это реализовать "вложенную", если так можно выразиться, ретрансляцию пакетов Modbus RTU (и я понимаю что это не возможно cделать стандартными функциями Modbus) из одного порта в другой .

Зачем ретранслировать пакеты, что сложнее, если можно передавать состояния переменных, что проще? Памяти хватает, скорости тоже. Да, будет лаг во времени на одну посылку. Но с учетом канала связи, данные там не realtime.

Но не на всех объектах "верхняя" сеть это модемы 160 МГц, где-то используется ШПД (WLAN). Вот для этих случаев уже необходимо сначало преобразование из TCP в RTU, затем отправка пакета RTU в "нижний" порт, а после ответа оконечного устройства обратно преобразование в TCP и отсылка в "верхний" порт.

То же самое, опрос - по одному интерфейсу, хранение значения внутри контроллера, отдача - по любому другому. Почитайте про OPC. Они похожую задачу уже реализовали, пройдете большинство "камней".

Изменить конфигурацию оборудования невозможно... проекты реализуются годами. Использовать другую схему передачи данных тоже невозможно.

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

ЗЫ. Посмотрите еще на устройства Anybus, например. Их логика такая:
* Есть общая память, которая конфигурируется следующим образом...
* Интерфейс 1 записывает все полученные данные в область памяти А и отправляет данные из области Б
* Интерфейс 2 отправляет данные из области А и записывает все полученные данные в область Б.

[imaex]

Это не модбас-tcp

?


Part of Data Package Description Value
64 97 Transaction identifier 0x6497 (25751)
00 00 Protocol identifier 0 = MODBUS protocol
00 09 Length 0x0009 (9)
E3 Unit identifier 0xE3 (227)
17 Function code 0x17 (23)
03 00 01 00 01 D7 3C Data

[Василий Соловьев]

?


Part of Data Package Description Value
64 97 Transaction identifier 0x6497 (25751)
00 00 Protocol identifier 0 = MODBUS protocol
00 09 Length 0x0009 (9)
E3 0xE3 (227) / Адрес порта ретрансляции в данном случае
17 Unit identifier (23) / Адрес устройства назначения
03 Function code 0x03 (04)
00 01 00 01 (D7 3C - CRC запроса modbus RTU) Data

Это не стандартный запрос, но именно в таком виде реализовано передача данных на объектах.... меняют местами "ретрансляторы"(точнее целиком шкафы)... меняют местами конечные устройства, иногда "вложенность такой вот матрЁшечной ретрансляции" достигает 4 уровней!
Изначально делалось это для ускорения замены шаблонов на АРМ оператора... вообщем, так исторички сложилось))

[melky]

Абсолютно стандартный Modbus, только не Modicon