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

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

если ПЛК генерит число 5 а в скаде 7067 - это одно.
Если же ПЛК генерил число 7067 - то это другое.
И таки да, снифер нужен

[_Pavel_]

Итак, прикладываю лог сниффера.
20:25:38 - разрыв, через несколько секунд соединение.
нормальное значение - 1077
плохое значение - 3151, зафиксировано 20:25:53..54
адрес тэга - 6
(значение константой пока не делал, но после восстановления связи значение уже не меняется, до и частично во время разрыва - меняется раз в 100 ms.)

[capzap]

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

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

Что видно по логу - сначала идёт транзакция по 6 unit, к-я обрывается. и она передаёт число близкое к 3190.
Далее идёт пауза, возобновление транзакции и 1 раз значение 1077, а затем опять близкое к 3190.

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

P.S. Как я понял у Вас одновременно на ПЛК и на ПК и мастер и slave?

[_Pavel_]

Хорошо, я проведу эксперимент с константой. Хотя мне кажется, что в этом случае эффект не проявится...
да, ПЛК и OPC и мастер и слэйв одновременно. Для организации событийного обмена.

[_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 ???)