Ничего не понял из того, что вы написали.библиотекой на разные порты открыть два сокета, а брать данные из одного массива/структуры
Какой кошмар.
Почему овен такой овен.
Ничего не понял из того, что вы написали.библиотекой на разные порты открыть два сокета, а брать данные из одного массива/структуры
Какой кошмар.
Почему овен такой овен.
Ну здесь не ОВЕН такой ОВЕН, а изначально при проектировании системы не проработали. Говорить о системе на 30 контроллеров с дублированным доступом, и винить OPC сервер, который для таких целей не создавался... Ну вряд ли правильно
Без другого OPC - никак. OPC CODESYS (раз уж на то пошло, а не ОВЕН) работает по протоколу Gateway, который не поддерживает работу с несколькими опрашивающими. Что, к стати, логично.
Что бы я посоветовал:
1. Создаете в каждом контроллере ModBus TCP Slave.
2. На свои ПК устанавливаете ModBus TCP сервера (причем в Вашем случае я бы не гнался за халявкой).
Опрашиваете независимо друг от друга.
И еще 1 вопрос.
Если на первом сервере настроить кодесис опс --> клиент ---> скада.
Второй сервер настроить на подключение к кодесис опс первого сервера,
при этом альтернативное подключение (в клиенте имеется такая возможность)
настроить на собственный опс кодесис.
В теории все должно быть так:
запускаем 1й сервер, он начинает работать по протоколу, 2й при этом работает с опс первого.
Если первый сервер падает, то начнет ли собственный опс кодесис 2го сервера конектится к ПЛК?
клиентом по отношению к ОРС-серверу является как раз таки сама скада.
У ОРС-сервера кодесис нет таких возможностей. Да и это получается резервирование, которое должно выполняться на уровне SCADA-системы. Т.е. одна скада-система настраивается на другую (основную), которая работает через свой ОРС-сервер, если комп с основной скада-системой и ОРС-сервером "отваливается", то резервная скада-система запускает ОРС-сервер на своем компе.