OwenCloud. Что это и с чем его едят?

[Pavel5698]

Доброго времени суток, коллеги! Есть проект на плк210-02 и панель weintek. Связь между ними настроена с помощью opc ua. Заказчик узнав, что используется оборудование Овен попросил сделать owen cloud. Но возникла проблема с тем, что в символьной конфигурации около 4 тысяч переменных, а в облако можно передавать не более тысячи. Простыми способами решить эту проблему получится?
Я вижу два решения - 1) Отказаться от овен клауд. 2) Переделать связь между плк и панелью на библиотеку OCL.
Но первое не устраивает заказчика, а второе - нас.
Есть ли возможности обойти это ограничение или сделать передачу в облако иначе?

А можно просто поинтересоваться, что вы автоматизировали? Какой объект? 4 тыс. переменных для одного ПЛК210 это сильно

[Андрей Чернов]

А можно просто поинтересоваться, что вы автоматизировали? Какой объект? 4 тыс. переменных для одного ПЛК210 это сильно

Если бы Вы знали какие объекты у нас бывают, то не удивлялись бы 4 тысячам. Выжимаем все соки из ПЛК210. Так уж повелось.

Вот пример одного из среднестатистических проектов.

Снимок экрана 2024-06-06 145907.png

[Pavel5698]

Вот пример одного из среднестатистических проектов.

Мощно конечно) А что это за объекты в основном поделитесь?

[Андрей Чернов]

Мощно конечно) А что это за объекты в основном поделитесь?

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

[Pavel5698]

По поводу Вашего вопроса про OwenCloud.
Через символьную конфигурацию точно вы 4000 тегов не сможете передать.
Если свободен 1 порт RS485, то можно попробовать докупить шлюз типа ПМ210 или ПЕ210 и опрашивать ПЛК через него, предварительно настроив ПЛК как Modbus RTU Slave через ту же библиотеку OwenCommunication. В Облаке, когда вы создаете прибор, можно в него добавить максимум 1000 параметров. Можно опрашивать только самые необходимые теги из ПЛК.
Если нужно больше 1000 тегов, то можно попробовать через ту же OwenCommunication сделать так, чтобы ПЛК отвечал на запросы по разным адресам (SlaveID), к примеру 1, 2 и 3. В облаке соответственно добавить несколько приборов с разными адресами. Получается, что сервер облака будет опрашивать несколько приборов, но по факту это все будет 1 ПЛК.
Но я вижу сразу некоторые неудобства, с которыми придется столкнуться:
1. Замучаетесь добавлять эти параметры в Облаке. Даже если вы будете создавать json файл, а потом импортировать его в сервис - это будет долго.
2. При таком количестве параметров будет все подлагивать постоянно, это неприятно
3. Вам 100% необходимо делать групповой опрос параметров, значит они должны лежать вместе по регистрам. НО насколько я помню у Облака нет валидации на количество параметров в запросе. Т.е. если будут регистры с 0 по 999, то облако одним запросом сразу спросит с ПЛК все 1000 регистров. ПЛК на такое не ответит. Вроде максимально 125 регистров можно передать за 1 запрос. И соответственно в карте регистров ПЛК нужно будет делать пробелы через каждый 125 регистров, чтобы облако по этим пробелам делило свои запросы.

В общем тяжеловато это все и возможно только если есть свободный порт RS, чего, вероятно, у Вас нет при таком количестве параметров

[МихаилГл]

Если бы Вы знали какие объекты у нас бывают, то не удивлялись бы 4 тысячам. Выжимаем все соки из ПЛК210. Так уж повелось.

Вот пример одного из среднестатистических проектов.

Снимок экрана 2024-06-06 145907.png

Интересный вопрос появился... А в ветке модбас ТСР мастер модули последовательно опрашиваются? А если добавить вторую такую и перенести туда часть модулей...
Кто нибудь в курсе? Повлияет это на скорость обмена с модулями?

[Pavel5698]

А если добавить вторую такую и перенести туда часть модулей

Мне кажется ничего не изменится. Вероятно сначала также последовательно опросит приборы в одном компоненте Modbus TCP Master потом в другом и по новой.