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

[_Pavel_]

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

[SCADAMaster]

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

То есть данные с прошлой сессии приходят? Тогда про какую Антарктиду идут рассуждения?

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

Slave можно сделать с разными портами и одинаковыми тегами.

И противоречие со стандартом ModBus.

Просим вас указать где в Modbus TCP есть запрет двух и более коннектов:
http://www.modbus.org/docs/Modbus_Me...uide_V1_0b.pdf

Отключите мультимастерность OPC - если это возможно и наступит счастье.

Мы считаем что это ничего не даст. Но можно поэкспериментировать.
В комплекте с нашим OPC сервером есть ранее упомянутая утилита ModRSSim (c:\Program Files\InSAT\MasterOPC Universal Modbus Server\MODRSSIM\) - это эмулятор Modbus Slave устройства.
Г-н _Pavel_ просим вас выполнить следующее. Установите данную утилиту, и переключите ее на режим Modbus TCP, и установите у нее в настройках один коннект (см. приложение). Воспроизведите ошибку с этой программой (вместо ОРС сервера - сервер не запускайте). Поступление пакетов с прошлой сессии можно будет увидеть по логу - кнопка Comms в правом нижнем углу. В настройках лога включите отображение времени "Show Times" - так будет легче увидеть данные после разрыва. Посмотрите какие данные поступят от контроллера после восстановления соединения.

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

То есть данные с прошлой сессии приходят? Тогда про какую Антарктиду идут рассуждения?

А что мешает данным из прошлой сессии попасть в сеть при восстановлении физического линка?

Просим вас указать где в Modbus TCP есть запрет двух и более коннектов:
http://www.modbus.org/docs/Modbus_Me...uide_V1_0b.pdf

Пункт 1.2 Там даже рисунок есть. И перечисление из 4-х вариантов соединений. Везде 1 мастер - (1..N) slave. Обратных вариантов нет.

И в пункте 4.2.1:

A MODBUS request has to be sent on the righ
t TCP connection already opened. The IP
address of the remote is used to find the TC
P connection. In case of multiple TCP
connections opened with the same remote, one connection has to be chosen to send
the MODBUS message, different choice criteria can be used like the oldest one, the
first one.

[SCADAMaster]

А что мешает данным из прошлой сессии попасть в сеть при восстановлении физического линка?

Давайте вернемся немного назад. Вы писали:

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

Вот сейчас г-н _Pavel_ оставил как раз самую простую схему. И 30 хопов в Антарктиде мы исключили, остается только ваш контроллер и наш OPC сервер. Поэтому давайте оставим Антарктиду г-ну Сидякину, и разберемся почему у вас в контроллере не происходит очищение буфера?

И в пункте 4.2.1:
A MODBUS request has to be sent on the right TCP connection already opened. The IP address of the remote is used to find the TCP connection. In case of multiple TCP connections opened with the same remote, one connection has to be chosen to send the MODBUS message, different choice criteria can be used like the oldest one, the
first one.

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

Или:
A MODBUS request has to be sent on the right TCP connection already opened. The IP address of the remote is used to find the TCP connection. In case of multiple TCP
connections opened with the same remote, one connection has to be chosen to send the MODBUS message, different choice criteria can be used like the oldest one, the
first one. The connection has to maintain open during all the MODBUS communications. As described in the following sections a client can initiate several MODBUS
transactions with a server without waiting the ending of the previous one.
Как описано в следующих разделах клиент может инициировать несколько MODBUS операции с сервером, не дожидаясь окончание предыдущего.

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

Давайте вернемся немного назад. Вы писали:
Вот сейчас г-н _Pavel_ оставил как раз самую простую схему. И 30 хопов в Антарктиде мы исключили, остается только ваш контроллер и наш OPC сервер. Поэтому давайте оставим Антарктиду г-ну Сидякину, и разберемся почему у вас в контроллере не происходит очищение буфера?

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

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

Одним Modbus клиентом. А не 2-а на 1 сервер. а шина - это ethernet - там может быть всё что угодно - но 1 мастер - N slave.
При этом N коннектов 1 клиента к серверу - но внутри 1 мастер к slave. О чём чётко пишется в пункте 4.2.1.
Банальный здравый смысл, а учитывая что ModBus TCP это надстройка над обычным ModBus serial, где жёстко 1 мастер - то и транспортный уровень не должен менять логику. На рисунке как раз и показан пример со шлюзами из serial в serial через TCP.
Иначе получится абсурд - пишем письмо бабушке - а авиакомпания меняет язык в письме.

P.S. Вот когда ГОСТ рассматривают как "рекомендацию" - и возникают проблемы.

a client can initiate

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

[_Pavel_]

Г-н _Pavel_ просим вас выполнить следующее. .

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

[SCADAMaster]

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

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

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

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

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

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

[_Pavel_]

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

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

[_Pavel_]

Вот посмотрите, пожалуйста, видео эксперимента: тынц

[SCADAMaster]

Как мы поняли из вашего видео, старые запросы с контроллера все равно приходят (в контроллере 1000, а в программу поступило сначала 5400, а затем 4300). Поэтому вариант с ограничением коннектов в сервере ничего не даст.