Обновленный ПЛК110?

[_Pavel_]

Вот лог с константой. Значение = 1075.
20:13:50 разрыв
20:14:05 подключил кабель
эффект не наблюдаю

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

Что и ожидалось. При обрыве какие-то данные меняются и передаются в SCADA при восстановлении питания.
Нужна логика поведения при обрыве канала. Т.к. есть и мастер и slave - можно организовать пинг-понг значения и определять обрыв.

[_Pavel_]

Коротко расскажу что происходит у меня в ПЛК во время обрыва:
Есть некая переменная Х, которая рассчитывается на борту и отражает положение (координату) движущегося объекта. Объект умеет плавно разгоняться и плавно тормозить, т.е. Х резко меняться не может. Так как объект подвижный, связь со скадой осуществляется через WiFi. Беспроводная связь не гарантирована и поэтому я тестирую всю систему в условиях, когда связь кратковременно пропадает в различных ситуациях. Вышеописанная ситуация возникает при следующих условиях: объект движется, Х равномерно меняется, я имитирую разрыв соединения путём отключения кабеля ethernet от контроллера, объект при этом продолжает двигаться, соотвтетсвенно Х продолжает меняться. Затем объект останавливается и Х соответственно становится постоянной. Далее я подключаю кабель ethernet, соединение успешно восстанавливается скада видит правильное текущее значение Х, которое уже не меняется. Затем через несколько секунд Х в скаде начинает резко прыгать несколько раз и если параллельно смотреть это значение на борту ПЛК через CDS то оно, как и должно быть, никак не меняется. Потом, через некоторое время, всё становится хорошо.
Кроме того на борту ПЛК контролируется переменная ошибок модуля модбас мастер и если она не равна нулю (+ определённый таймаут), то код, присваивающий расчётную Х соотв. переменной в конфигурации мастера не выполняется. Но в любом случае переменная, объявленная в конфигурации может меняться не зависимо от того есть связь или нет.

В общем и целом проблема не является критичной ибо на борту ПЛК всё хорошо, но визуализация страдает. Я чувствую, что здесь есть косяк, только не пойму у кого: в реализации модбас TCP в конфигураторе ПЛК или всё-таки дело в OPC-сервере. Поэтому:
1. Попробую применить другой OPC-сервер
2. Напишу простенькую программку для ПЛК, имитирующую поведение ПЛК в этой ситуации без остального кода. И таки докажу проблему
3. Пойму, что сам дурак и чего-то не вижу или неправильно понимаю...

[_Pavel_]

Итак, мне удалось получить проблему на простенькой программке, которая имитирует вышеописанный алгоритм. Во вложении к данному посту проект CDS, конфигурация OPC-сервера MasterOPC, а также лог сниффера, в котором зафиксировано появление ошибки при работе этого теста.
Кабель выдёргивал при значении MB_X примерно 5000. После стабилизации значения подключал кабель примерно через 2-3 секунды. Зафиксированы ложные значения: 5300 и 4200.
Владислав, посмотрите, пожалуйста. Алгоритм работы теста описывать не буду, там всё тривиально.

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

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

[_Pavel_]

Настройки слэйва во вложении.

Всё таки виноват OPC-сервер?

[_Pavel_]

Владислав, поучавствуйте, пожалуйста в этой теме.

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

Настройки слэйва во вложении.

Всё таки виноват OPC-сервер?

Это, вероятно, настройки мастера - а где настройки slave? P.S. Настройки таймаутов соединений, возможно, не в самом OPC, а в операционке, но я тут не совсем Копенгаген.

[_Pavel_]

Владислав, позвольте Вас снова побеспокоить.
Коллеги утверждают (тынц), что неактуальные данные передаёт-таки контроллер после восстановления соединения. Подскажите, пожалуйста, это можно как-то исправить или это нормальное поведение? (и соответственно нужно понять и простить )

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

Владислав, позвольте Вас снова побеспокоить.
Коллеги утверждают (тынц), что неактуальные данные передаёт-таки контроллер после восстановления соединения. Подскажите, пожалуйста, это можно как-то исправить или это нормальное поведение? (и соответственно нужно понять и простить )

Я считаю, что это правильное поведение. Данные, которые передаёт контроллер, это не переданные, но попавшие в очередь на передачу данные предыдущей сессии (в реальной сети такие "фантомы" встречаются регулярно). Эти данные slave-ом должны игнорироваться, т.к. уже установлена новая сессия.
Утверждение, что все так делают и можно иметь мультимастерный ModBus противоречит самой концепции Мастер-slave. И тем более, такое поведение slave-а должно быть не "по умолчанию", а специально настраиваться. Тем более на 1 порту.