Фичи и баги OWEN Logic

[Сергей0308]

Формирование наличия Modbus соединения по аппаратной переменной, возможно, не корректно работает.

Проект содержит два ПР205 в двух шкафах на расстоянии до 10 м. Связь между ними по Modbus RTU RS-485.
Для Master обрыв соединения определяется с фиксацией по инверсии аппаратной переменной наличия соединения с задержкой 15 секунд.
Для Slave обрыв соединения определяется по прекращению изменения принимаемой целочисленной переменной с задержкой в 4 секунды.

И тем не менее, ошибка зафиксировалась в Master, а в Slave ошибки не случилось. Непонятно, ведь у Master задержка 15 секунд против 4 секунд у Slave.


Также, Slave управляет собственным ПЧВ, который почти всё время стоит в ожидании.
Вывел на дисплей ПР205 состояние обрыва связи с ПЧВ - получил на экране непрерывно мигающий индикатор.

Мне кажется, что или я не понимаю назначение привязанной переменной или её алгоритм некорректен.

Прикладываю скрины:
- Master - привязка переменной к аппаратной части
- Master - формирование сигнала текущего отсутствия связи со Slave
- Master - формирование изменяющегося числа для Slave, чтобы Slave мог следить за состоянием связи
- Slave - формирование сигнала текущего отсутствия соединения с Master
Не стал показывать фиксацию с задержкой, но поверьте, это один и тот же проверенный макрос.

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

Очень странно, в смысле, Вы сами придумали неправильную логигу и другим жалуетесь на это?
Впрочем не надо расстраиваться, этот вопрос много раз обсуждался, в смысле, надо было просто взять готовое типа такого:

Нет связи.png

[FPavel]

Очень странно, в смысле, Вы сами придумали неправильную логигу и другим жалуетесь на это?
Впрочем не надо расстраиваться, этот вопрос много раз обсуждался, в смысле, надо было просто взять готовое типа такого:

Нет связи.png

Если всё же прочитать мой вопрос - предложенное решение там уже реализовано в Slave.

А вот в Master контроль выполняется по переменной, привязанной к аппаратному контролю. И это единственный способ определить отсутствие связи с готовыми устройствами типа ПЧВ, ТРМ. Поэтому применить для контроля связи с другим ПР тоже считаю корректным.

Проблема состоит в том, что в Master с контролем по аппаратной привязке сработала ошибка при 15 секундах задержки, а при контроле через heartbeat в Slave - не сработала даже с 4 секундами.

Оба ПР205 куплены одновременно, аппаратно идентичны.

[Сергей0308]

Если всё же прочитать мой вопрос - предложенное решение там уже реализовано в Slave.

А вот в Master контроль выполняется по переменной, привязанной к аппаратному контролю. И это единственный способ определить отсутствие связи с готовыми устройствами типа ПЧВ, ТРМ. Поэтому применить для контроля связи с другим ПР тоже считаю корректным.

Проблема состоит в том, что в Master с контролем по аппаратной привязке сработала ошибка при 15 секундах задержки, а при контроле через heartbeat в Slave - не сработала даже с 4 секундами.

Оба ПР205 куплены одновременно, аппаратно идентичны.

Хорошо, верим Вам, в смысле, в мастере работает, а в слейве нет, так Овен здесь причём, в смысле, в слейве Вы сами формируете логику работы при потере связи?
Или объясните понятно, ясно и конкретно, что не так по-вашему, намёки здесь неуместны, мне так кажется!

[1exan]

Если всё же прочитать мой вопрос - предложенное решение там уже реализовано в Slave.

А вот в Master контроль выполняется по переменной, привязанной к аппаратному контролю. И это единственный способ определить отсутствие связи с готовыми устройствами типа ПЧВ, ТРМ. Поэтому применить для контроля связи с другим ПР тоже считаю корректным.

Проблема состоит в том, что в Master с контролем по аппаратной привязке сработала ошибка при 15 секундах задержки, а при контроле через heartbeat в Slave - не сработала даже с 4 секундами.

Оба ПР205 куплены одновременно, аппаратно идентичны.

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