Modbus Universal MasterOPC Server новый OPC сервер от компании ИнСАТ

[_Pavel_]

Прокомментируйте, пожалуйста:

Итак, каждые 100 мс ПЛК уменьшает значение на 100.
В р-не значения 5300 кабель вынимают.
ПЛК ещё некоторое время продолжает посылать пакеты (с числами всё меньше и меньше, тем более у Вас стоит 3 попытки повтора.
Наконец Мастер рвет коннект, пробует новое соединение и когда кабель втыкают - соединяется.
Но некоторое время остатки предыдущих пакетов с разорванного коннекта гуляют по сети.
Непонятно по какой причине slave их воспринимает как ликвидные, хотя: номер порта-источника другой, последовательность посылок по TCP разрушена.
Но соединение в Slave всё еще воспринимает данные из "фантомного соединения".
Причины:
1. Таймаут на разрыв соединения в slave много больше чем у мастера. +
2. Slave поддерживает мультисоединение - несколько мастеров на 1 slave (это вообще невообразимо - 2(3, 4 ...100?) мастера на 1 slave ???)

[SCADAMaster]

ПЛК ещё некоторое время продолжает посылать пакеты (с числами всё меньше и меньше, тем более у Вас стоит 3 попытки повтора.

Это не совсем правильное поведение.
В качестве примера приведем наш ОРС сервер в режиме "Мастер". Если сервер чувствует обрыв соединения (приходит ошибка от системной функции ОС), то сервер прекращает попытки повтора (зачем если коннекта нет), закрывает соединение, и пытается снова соединиться.

Наконец Мастер рвет коннект, пробует новое соединение и когда кабель втыкают - соединяется.
Но некоторое время остатки предыдущих пакетов с разорванного коннекта гуляют по сети.

Давайте представим такую схему. У нас есть один ПЛК и компьютер, которые соединены напрямую кабелем (перекрестным). Разорвали соединение.
Какие остатки предыдущих пакетов будут гулять по сети? И где они будут гулять?
Они могут накопиться в буфере контроллера, и потом (если контроллер не очистил буфер) выйти в сеть. У нас в ОРС сервере (в режиме Мастер) это учитывается, и буфер при новом соединении очищается.

Непонятно по какой причине slave их воспринимает как ликвидные, хотя: номер порта-источника другой, последовательность посылок по TCP разрушена.
Но соединение в Slave всё еще воспринимает данные из "фантомного соединения".

Почему нарушена последовательность посылок? Почему стал другой номер порта и источника?
После реконнекта сменился IP и порт?

1. Таймаут на разрыв соединения в slave много больше чем у мастера. +

У нас в Slave нет таймаута ожидания разрыва. Разрыв детектируется операционной системой и передается в программу.

2. Slave поддерживает мультисоединение - несколько мастеров на 1 slave (это вообще невообразимо - 2(3, 4 ...100?) мастера на 1 slave ???)

Наш Slave действительно поддерживает мультисоединение. Несколько странно почему это так удивляет главного разработчика фирмы ОВЕН. Большинство контроллеров поддерживает несколько соединений на один порт (Wago, Modicon, Delta), не говоря уже про различное ПО для операционной системы Windows (например эмулятор ModRSSim поддерживает до 1000 коннектов). Но к данной проблеме это отношения не имеет.

[Филоненко Владислав]

Это не совсем правильное поведение.
В качестве примера приведем наш ОРС сервер в режиме "Мастер". Если сервер чувствует обрыв соединения (приходит ошибка от системной функции ОС), то сервер прекращает попытки повтора (зачем если коннекта нет), закрывает соединение, и пытается снова соединиться.

Ошибка приходит по таймауту коннекта, а пока его нет (а это секунды и более) - ПЛК успеет 10-к пакетов послать при описанных настройках мастера.

Давайте представим такую схему. У нас есть один ПЛК и компьютер, которые соединены напрямую кабелем (перекрестным). Разорвали соединение.
Какие остатки предыдущих пакетов будут гулять по сети? И где они будут гулять?
Они могут накопиться в буфере контроллера, и потом (если контроллер не очистил буфер) выйти в сеть. У нас в ОРС сервере (в режиме Мастер) это учитывается, и буфер при новом соединении очищается.

Буфер мастера очищается, а буфер стека TCP/IP? На логе ясно видны попытки ретрансмита.
И зачем представлять самую простую схему - использование TCP/IP предполагает что мастер находится, к примеру, в Антарктиде, 30 хопов до slave-а.

Почему нарушена последовательность посылок? Почему стал другой номер порта и источника?
После реконнекта сменился IP и порт?

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

У нас в Slave нет таймаута ожидания разрыва. Разрыв детектируется операционной системой и передается в программу.

Через сколько секунд разрыва? В протоколе TCP/IP нет нативных средств для определения разрыва от внешних причин (дядя Вася с топором) в момент разрыва, только по таймауту.

Наш Slave действительно поддерживает мультисоединение. Несколько странно почему это так удивляет главного разработчика фирмы ОВЕН. Большинство контроллеров поддерживает несколько соединений на один порт (Wago, Modicon, Delta), не говоря уже про различное ПО для операционной системы Windows (например эмулятор ModRSSim поддерживает до 1000 коннектов). Но к данной проблеме это отношения не имеет.

[/QUOTE]
О майн гот! Расскажите мне, что будет со SCADA если я в один порт с 2-х мастеров буду по очереди слать: то "температура реактора 100 градусов" то "500 градусов"? Вот что будет делать SCADA, будет ли там признак "Данные из разных источников"? Нельзя ли узнать на каких опасных производствах стоит Ваш OPC?
Много соединений на 1 порт нужно для Web-сервера, к примеру, где действия 1 пользователя не пересекаются с другими. А ModBus априори предполагает наличие только 1 мастера в сети.

Описанный выше апокалипсец как раз и происходит у Павла. Соединение закрыто, мастер открыл другое а OPC еще обслуживает старое соединение и получает негодные данные.

[SCADAMaster]

Буфер мастера очищается, а буфер стека TCP/IP?

Это зависит от реализации и настроек маршрутизатора. Маршрутизатор может сбрасывать буфер при отсутствии коннекта.

И зачем представлять самую простую схему - использование TCP/IP предполагает что мастер находится, к примеру, в Антарктиде, 30 хопов до slave-а.

А почему бы и не проверить?
Может быть г-н _Pavel_ проверит работу по такой схеме?

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

Не обязательно. Порт источника может остаться как и в предыдущей сессии.
Кроме того если будет установлен новый коннект, а в буфере маршрутизатора остались данные, то эти старые данные будут записаны уже в новой сессии с новыми параметрами соединения (новым портом-source).

О майн гот! Расскажите мне, что будет со SCADA если я в один порт с 2-х мастеров буду по очереди слать: то "температура реактора 100 градусов" то "500 градусов"? Вот что будет делать SCADA, будет ли там признак "Данные из разных источников"? Нельзя ли узнать на каких опасных производствах стоит Ваш OPC?

Вы занимаетесь демагогией.
Отвечая на вопрос что будет если послать разный запрос с двух мастеров ответ прост - сервер пример и запишет в теги сначала первый запрос, затем второй запрос.
Точно также поступит и ваш контроллер, если добавлю в него два TCP порта (502 и 503).
И это полностью является проблемой разработчика - он может на уровне исполняемых контролировать подобные изменения (в MasterSCADA для этого есть параметр "блокировка обратной связи"). В конце концов существуют информационные системы - которые только получают данные, и не производят запись данных.

А ModBus априори предполагает наличие только 1 мастера в сети.

В контроллерах вашей разработки ни что не мешает мне добавить в узел Modbus(Slave) два TCP порта (или больше) и обращаться к ним с разных мастеров. Поэтому режим 2 мастеров у вас, просто реализован не так удобно как у других производителей.

[_Pavel_]

А почему бы и не проверить?
Может быть г-н _Pavel_ проверит работу по такой схеме?
.

Уже. Крайний тест, который я выкладывал был произведён "на столе" , где ПЛК подключен непосредственно к сетевому адаптеру компьютера.

[Филоненко Владислав]

Это зависит от реализации и настроек маршрутизатора. Маршрутизатор может сбрасывать буфер при отсутствии коннекта.
Вы занимаетесь демагогией.
Отвечая на вопрос что будет если послать разный запрос с двух мастеров ответ прост - сервер пример и запишет в теги сначала первый запрос, затем второй запрос.
Точно также поступит и ваш контроллер, если добавлю в него два TCP порта (502 и 503).
И это полностью является проблемой разработчика - он может на уровне исполняемых контролировать подобные изменения (в MasterSCADA для этого есть параметр "блокировка обратной связи"). В конце концов существуют информационные системы - которые только получают данные, и не производят запись данных.


В контроллерах вашей разработки ни что не мешает мне добавить в узел Modbus(Slave) два TCP порта (или больше) и обращаться к ним с разных мастеров. Поэтому режим 2 мастеров у вас, просто реализован не так удобно как у других производителей.

Но вот в чём нюанс - у меня на ПЛК это будут 2 различных slave c разными тегами (в терминологии SCADA) или 1 slave с разными портами , т.е. это осознанный (не значит правильный, но осознанный) выбор. А если OPC поддерживает мультимастерность на одном порту - это будет скрытая особенность, дыра как для случайных (как у Павла) так и для намеренных действий. И противоречие со стандартом ModBus. Кстати, на ПЛК можно не включать мультимастерность, а как это сделать для OPC?

[lomtik]

Добрый день, подскажите,
как будут вести себя в плане стабильности работа двух универсальных ОПС-серверов разных версий при работе с одним ПЛК-100. В краткосрочном периоде я потестил - все гуд, хотелось узнать что будет в долгосрочном. Нужно ли приводить опс-серверы к одной версии? На плк открыты порты 501 и 502, плк настроены в режиме модбас слэйв по тcp/ip. Версии ОПС - 3.1.3 (только оплатили, еще не забирали, скорее всего версия будет такой) и 2.0.0.11 (2.0.0.9) (покупали в 2012-м). И еще - кому интересно, 2,5 года назад я перешел с кодесисного глючного опс-сервера на универсальный от модбас. Сейчас у меня в сети общее кол-во ПЛК - 275 штук и два опс-сервера. На 1-м сервере всего плк - 240 штук, на втором - пока 35 штук. Второй сервер запускается по Dcom. Все работает очень гуд, ни одного сбоя или зависания за 2,5 года, только добавляю новые ПЛК. И еще добавлять и добавлять))). Проект один. Сейчас встал вопрос об открытии 2-го проекта, будем использовать теже ПЛК, только разделим сигналы и выведим их на теперь уже третий ОПС, который будет работать параллельно либо с первым либо со вторым опс-сервером.

[_Pavel_]

А где оно отключается?

[SCADAMaster]

А с чего оно должно происходить? Линк потерян, в буфере пакеты, пакеты не потеряли ещё актуальности. Линк возобновился - выдаём в сеть.

Ну мы уже писали ранее - это не совсем корректное поведение. Нужно закрыть соединение, тогда пакеты будут удалены. А после восстановления связи уже посылать новые.
А если рассуждать как вы (данные не потеряли актуальности) - то что мы тогда вообще обсуждаем, получается что у _Pavel_ проблем никаких нет - данные то поступили актуальные.

1 клиент, один, а не 2. Если 1 мастер создаёт несколько параллельных запросов к разным данным - это можно.

Это не играет роли. Slave поддерживает несколько коннектов, от одного мастера или от нескольких зависит от конфигурации пользователя, т.е. от реализации конечного проекта.

Успел отметить факт: произвёл дисконнект, значение в утилите замерло, проходит секунд 7-10, значение изменяется (в правильном направлении), потом ещё несколько секунд - ещё раз изменяется как будто пакет доходят. При этом ПЛК уже отключен, а соединение занял кто-то другой...

Вам лучше смотреть по логу - по данным вы можете и не увидеть, так как они могут изменится быстро. Посмотрите какие запросы поступают после восстановления соединения, и спустя какое то время (раз вы говорите что пакеты доходят спустя какое-то время).

[_Pavel_]

У меня на компьютере сразу кто-то подключается к этой утилите и занимает единственное соединение, пока не могу понять кто... вроде бы всё подозрительное убил диспетчером задач...

Пардон, это ПЛК в сброшенном состоянии подключается...