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

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

Добрый день!

Дано:
ПЛК110-30[M02]
OPC-сервер Lectus OPC
Множество разнесенных территориально объектов связанных с диспетчерским пунктом (ДП) по радиоканалу, .

Задачи:
1) Организовать маршрутную ретрансляцию пакетов данных Modbus RTU с "верхнего" rs232 порта на "нижний" rs485.

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

При маршрутной ретрансляции из «верхней» сети в «нижнюю» пакеты данных имеют структуру, приведенную в таблице 1.
Маршрутный ретранслятор отбрасывает от исходного пакета (П1) свой маршрутный адрес и «верхнюю» контрольную сумму CRCВ (при ее наличии), и получившийся новый пакет (П2) передает в «нижнюю» сеть.
При получении корректного ответа из «нижней» сети (пакет П3) маршрутный ретранслятор добавляет в начале пакета свой маршрутный адрес, а в конце – новую («верхнюю») CRC пакета, и отправляет получившийся пакет (П4) в «верхнюю» сеть.
Маршрутная ретрансляция может иметь несколько уровней вложенности, по количеству маршрутных ретрансляторов на пути данных от ДП до оконечного устройства.
Пример того, как должно быть в приложении. (маршрутный адрес ПЛК ретранслятора 227, адрес оконечного устройства 23)

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

[imaex]

Вы хотите из ПЛК110 некое подобие гейта Modbus TCP/RTU сделать? А он умеет? И зачем? не проще на нём все данные собирать, раз уж всё равно оконечные устройства к нему подключены?

И какой смысл Вы вкладываете в определение "маршрутный"? Что-то я в Вашем описании даже намёка на маршрутизацию не увидел.

Ничего у Вас не получится, ПМСМ. Тем более что

Маршрутная ретрансляция может иметь несколько уровней вложенности, по количеству маршрутных ретрансляторов на пути данных от ДП до оконечного устройства.

Во всяком случае средствами MODBUS, где даже намёка на маршрутизацию нет.

Может для начала задачу стоит сформулировать?

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

Вы хотите из ПЛК110 некое подобие гейта Modbus TCP/RTU сделать? А он умеет? И зачем? не проще на нём все данные собирать, раз уж всё равно оконечные устройства к нему подключены?

И какой смысл Вы вкладываете в определение "маршрутный"? Что-то я в Вашем описании даже намёка на маршрутизацию не увидел.

Ничего у Вас не получится, ПМСМ. Тем более что


Во всяком случае средствами MODBUS, где даже намёка на маршрутизацию нет.

Может для начала задачу стоит сформулировать?

Исправляюсь:
Система действующая и в ней более 3000 ПЛК подключены к АРМ с помощью радиоканалов 160 МГц.
Радиоканал не всегда про,ивает от базы до абонента, поэтому используются ПЛК, которые ретранслируют пакеты данных на промежуточных узлах... На сегодня такой функционал работает на ScadaPACK, ICPDAS,B&R.
Есть 100500+ нефтегазодобывающих скважин со своими станциями управления, которые технологи постоянно меняют, т.к. меняют режимы работы сважин.
У каждой станции управления различаются адреса целевых регистров и типы данных.
На уровне АРМ разработаны шаблоны для каждого типа станции управления, и при замене станции просто меняется шаблон на верхнем уровне и указывается маршрут связи.

Данная тема возникла на фоне отсутствия возможности закупки ПЛК ScadaPACK и желания перейти на работу с отечественным производителем. Сейчас определяется техническая возможность для решения данных задач оборудованием ОВЕН.

[imaex]

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

Вот в таком изложении понятней. Ретрансляция пакетов для ПЛК не является основной задачей? Чисто побочно, поскольку умеет (ScadaPACK) штатно, если я правильно понимаю? А вариант снять с ПЛК функцию ретранслятора и переложить на более специализированное устройство рассматривали? Насколько я понимаю, репитеры для радиоканалов 160 МГц существуют.

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

Вот в таком изложении понятней. Ретрансляция пакетов для ПЛК не является основной задачей? Чисто побочно, поскольку умеет (ScadaPACK) штатно, если я правильно понимаю? А вариант снять с ПЛК функцию ретранслятора и переложить на более специализированное устройство рассматривали? Насколько я понимаю, репитеры для радиоканалов 160 МГц существуют.

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

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

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

[zaychenko]

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

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

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

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

[keysansa]

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

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

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

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

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

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

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

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

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

[Spawn]

какую сторону ковырять.

"Здрасьте" SysLibCom и SysLibSockets...

[Spawn]

Василий Соловьев, оборудование ОВЕН достаточно "гибкое", с возможностью реализации очень большого количества хотелок. И Ваша задача вполне реализуема, я думаю. Но готовых примеров, схожих с Вашим (я, по крайней мере) не встречал на форуме. И если их все таки нет, то придется всю реализацию делать самостоятельно (так же, как когда-то, кто-то делал реализацию Вашей системы на базе оборудования иностранного производителя). Библиотеки для работы с RS и Ethernet (не все, конечно, есть и другие) указаны выше.

[keysansa]

Нафига нагружать контроллер не свойственными ему задачами, если можно это решить существующими сетевыми протоколами, поддерживаемыми всеми более-менее толковыми маршрутизаторами...
ЗЫ. RTU<->TCP - так же решается, либо переделкой программы и конфигурации, либо шлюзами RTU<->TCP