Не делайте скоропалительных выводов. Это может быть удобно по неочевидным причинам, которые на поверхности не лежат. А может просто так исторически сложилось. ТС же всей картины не раскрывает.Сообщение от keysansa
Не делайте скоропалительных выводов. Это может быть удобно по неочевидным причинам, которые на поверхности не лежат. А может просто так исторически сложилось. ТС же всей картины не раскрывает.
Согласен. Но данный коментарий мне напоминает противостояние Linux и Windows. В первой - каждая утилита заточена под свою задачу, но выполняет ее идеально. Вторая - сумасшедший комбайн, где все перемешано (говорю с точки зрения автоматизации а не пользователя).
В трансформаторной будке живет трансформаторная собака (с) Прозрачный гонщик
Очень похожую задачу решал лет 7 назад на ПЛК304
Сейчас, наверно, и не найду. Да и писалось на CDSv3.
Однако, думаю, что и на CDSv2 тоже можно сваять!
Если я не ошибаюсь то в инструкции на Ваш ПЛК110-30, есть такой пункт
UNM.jpg
Впрочем здесь есть Доска Услуг
Последний раз редактировалось EFrol; 29.08.2022 в 18:10.
Добрый день, Василий.
Давайте определимся, что Вам надо?
Если Вам нужно готовое устройство от ОВЕН - такого устройства нет.
Если Вам нужен пример кода для ПЛК110-30 - Вам бы его уже предложили.
Если Вам нужен ответ на вопрос "можно ли реализовать на базе этого ПЛК ретранслятор" - можно. (ссылки на библиотеки Вам дали)
Если Вам нужна помощь в реализации ПО по вашим задачам - предложите форму сотрудничества.
Примечание:
Ретранслятором в данном случае имеется в виду только ПЛК реализующий инкапсуляцию пакетов "верхний-нижний" и капсуляцию "нижний-верхний".
Запрос капсулируется на верхнем уровне Lectus'ом.
Последний ретранслятор в цепочке на выходе выдает ModbusRTU-запрос для контроллера обслуживающий скважину.
Ответ передается обратно с капсуляцией на каждом ретрансляторе.
Инкапсуляцию ответа производит Lectus.
Если я ТЗ описал верно, то готов взяться за решение.
Без схемы не совсем понятно. Подозреваю, какие бы там ПЛК ни были, это реализация программная, а не заложенная сразу в ПЛК. Так как предусматривать такие вещи производителям ПЛК слишком дорого...
Предположу, что всё же "искаропки". Беглое чтение первого попавшегося документа по ScadaPACK 32 показало, что там в настройках Modbus TCP есть режим Store and Forward и ссылка на некую таблицу маршрутизации, завязанную на этот режим. Возможно, это как раз про то самое. Но, не уверен
Кстати 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
Последний раз редактировалось EFrol; 31.08.2022 в 17:00.
?
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
Это не стандартный запрос, но именно в таком виде реализовано передача данных на объектах.... меняют местами "ретрансляторы"(точнее целиком шкафы)... меняют местами конечные устройства, иногда "вложенность такой вот матрЁшечной ретрансляции" достигает 4 уровней!
Изначально делалось это для ускорения замены шаблонов на АРМ оператора... вообщем, так исторички сложилось))
Абсолютно стандартный Modbus, только не Modicon
Ваши права
Ответить с цитированием