Блок Device (Link)

[Arsie]

Сообщение от tvf

В любом случае вопрос о качестве связи делится на 3 вопроса (как минимум):

1. Приходят ли данные?
2. Все ли данные приходят хорошими?
3. Все ли данные приходят из отправленных?

Ответ об однозначно хорошей связи может быть только при положительных ответах на все три вопроса.

Вы предлагаете 3 вопрос решить с помощью дополнительной переменной с контрольной суммой. Положим мы решили этот вопрос, хотя здесь не все так просто и однозначно.

Но как быть с 1 и 2? Если данные не приходят, или приходят битыми, то ответ на 3 вопрос теряет смысл. Положительные ответы на 1 и 2 вопрос являются необходимыми, но недостаточными для ответа о качестве связи. Именно ответы на вопросы 1 и 2 и должен давать блок Device (Link) вне зависимости от интерфейса.

Device(link) не даст вам ответ ни на один из этих вопросов, да и не сможет, как его не модифицируй. А вот переменные с контрольной суммой + "сердцебиение" - дадут.

Ну, разве что он сможет показать, что часть пакетов побитая. Но это всё равно не равнозначно некорректным данным.

Я удивлён, что вы не понимаете этой очевидной вещи.

[tvf]

Сообщение от Arsie

Ну, разве что он сможет показать, что часть пакетов побитая. Но это всё равно не равнозначно некорректным данным.

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

Решение 3 вопроса - о приходе всех отправленных данных в общем случае много сложнее, чем формирование и отправка 2 дополнительных переменных.

[Arsie]

Сообщение от tvf

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

Собственно, именно это я и написал.

Сообщение от tvf

Решение 3 вопроса - о приходе всех отправленных данных в общем случае много сложнее, чем формирование и отправка 2 дополнительных переменных.

Придут не все - не совпадёт контрольная сумма.

Надеюсь вы понимаете, что "сердцебиение" должно быть включено внутрь контрольной суммы?

[tvf]

Сообщение от Arsie

Собственно, именно это я и написал.

А для этого необходима работа блока Device (Link) вне зависимости от протокола.

Сообщение от Arsie

Придут не все - не совпадёт контрольная сумма. Надеюсь вы понимаете, что "сердцебиение" должно быть включено внутрь контрольной суммы?

Надеюсь вы понимаете, что этих 2 переменных явно недостаточно для гарантии того, что данные идущее в обе стороны 100% доходят до адресатов? ModBus для этого не особо предназначен. А реализация на уровне алгоритма как минимум слишком трудозатратна и ресурсоемка.

[Arsie]

Сообщение от tvf

Надеюсь вы понимаете, что этих 2 переменных явно недостаточно для гарантии того, что данные идущее в обе стороны 100% доходят до адресатов?

Так. Стоп. Притормозите. Мы контролируем доходимость данных до слейва. Точка.

Вы точно ничего не перепутали, говоря о контроле обеих направлений в "модуле расширения" (с)?

Контроль сети за мастером. Точка.

А то вы так договоритесь до чертей восьминогих.

----------

Всё нормально делается на любом протоколе. Можете мне ничего не доказывать - так делал лично я и всё прекрасно работало. С двумя переменными.

[tvf]

Контроль сети за мастером. Точка.

Ни кто это и не отрицает. Речь шла об информировании слейва, что мастер считал из него все данные корректно. Обоюдный контроль связи, это не только контроль записи в слейв, но и контроль чтения из слейва. Мастер то определит, надо еще сообщить об этом слейву.

Контроль записи в слейв с 2 доп. переменными требут как минимум записывать все переменные одним запросом. А если запросов на запись 2 и более? Как вы это делали?

Ну и вопрос сконтрольной суммой. Простое суммирование не даст 100% гарантии. CRC16 на FBD реализовывать?

[Arsie]

Сообщение от tvf

Ни кто это и не отрицает. Речь шла об информировании слейва, что мастер считал из него все данные корректно. Обоюдный контроль связи, это не только контроль записи в слейв, но и контроль чтения из слейва. Мастер то определит, надо еще сообщить об этом слейву.

Зачем?

Сообщение от tvf

Ну и вопрос сконтрольной суммой. Простое суммирование не даст 100% гарантии. CRC16 на FBD реализовывать?

Вы критикуете какие-то решения, когда "дано" ещё даже неизвестно. Мало того, что критикуете, так ещё и в крайности впадаете.

Зачем?

[Nick]

Сообщение от tvf

Ни кто это и не отрицает. Речь шла об информировании слейва, что мастер считал из него все данные корректно. Обоюдный контроль связи, это не только контроль записи в слейв, но и контроль чтения из слейва. Мастер то определит, надо еще сообщить об этом слейву.

Контроль записи в слейв с 2 доп. переменными требут как минимум записывать все переменные одним запросом. А если запросов на запись 2 и более? Как вы это делали?

Ну и вопрос сконтрольной суммой. Простое суммирование не даст 100% гарантии. CRC16 на FBD реализовывать?

диагноз, паранойА!
а потом надо мастера уведомить, что он успешно сообщил слейву, что данные успешно записаны. А потом сообщить слейву что его уведомление дошло до мастера успешно...

по мне дык достаточно что мастер отправил запрос и получил ответ соответствующий, что все ОК. Слейв максимально должен быть автономен. ну можно секунды ему слать как тут говорилось выше чтоб знал, что он не одинок, и то это кажется и так уже перебор, говорящий о избыточном построении системы.

[ujin]

Сообщение от tvf

Ни кто это и не отрицает. Речь шла об информировании слейва, что мастер считал из него все данные корректно. Обоюдный контроль связи, это не только контроль записи в слейв, но и контроль чтения из слейва. Мастер то определит, надо еще сообщить об этом слейву.

В том и смысл heartbeat, что данные передаются постоянно с определенной периодичностью, например один раз в секунду или один раз в пять секунд. Это задание состояния управляемому объекту, задание регулируемого параметра, контроль состояния, контроль параметра, контроль аварийного регистра. Даже если проходит 10% пакетов, рано или поздно вся информация доходит. Соответственно время прихода информации удлинняется. При этом запросы портятся примерно одинаково, так что портится и heartbeat (в моем случае unix_time).
Если задание или уставка не меняется, она все равно передается вместе и с периодичностью heartbeat. Слейв уже сам решает, что делать с данными - они пришли но не изменились.

Сообщение от tvf

Контроль записи в слейв с 2 доп. переменными требут как минимум записывать все переменные одним запросом. А если запросов на запись 2 и более? Как вы это делали?

Все точно так же. Запросы портятся примерно одинаково.

Сообщение от tvf

Ну и вопрос сконтрольной суммой. Простое суммирование не даст 100% гарантии. CRC16 на FBD реализовывать?

CRC уже реализовано в протоколе модбас. Поэтому если данные приняты, соответственно они с очень большой долей вероятности правильные (неправильные данные отбрасываются). Т.е проверка правильности данных лежит на протоколе.
Определение, что какие то данные передаются либо за блоком Device(link) либо за heartbeat. В случае с heartbeat ввиде unix_time имеем дополнительную проверку в виде попадания времени в, допустим 6 часовое окно. Плюс есть источник синхронизации своего времени.

[tvf]

диагноз, паранойА!

Ну зачем уж так сразу. Если говорить о 100% контроле качества связи, то мастер узнает и так, из ответов слейва. Что бы то же самое узнал и слейв, то необходимо знать:

1. Идут ли запросы от мастера?
2. Все ли запросы приходят хорошими?
3. Дошли ли до мастера все данные на чтение?
4. Пришли ли от мастера все данные на запись?

Где тут избыточность? Как реализовывать, это второй вопрос. И надо ли, это третий вопрос.

Меня в данной теме прежде всего интересовали первые два вопроса, решаемые с помощью блока Device(Link). Ну не заработал у меня блок с первой попытки. Почему, не знаю. И справка говорит, что он и не должен работать. А оказалось, что все работает, просто наслоилась ошибка в справке, к которой так любит отправлять Arsie, и какая то моя ошибка. Вопрос яйца выеденного не стоил, просто надо было сказать что у вас все работает, что ошибка в справке. Но на это потребовалось неделя времени и 2 страницы препирательств.

[Arsie]

Сообщение от tvf

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

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

Оказалось, что требуемую вам функциональность блок Device(link) реализовать не может, т.к. не отвечает вашему же требованию "Контролировать целостность данных".

Всё остальное - моя попытка донести это до вас.

[Nick]

Сообщение от tvf

Где тут избыточность?

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

[tvf]

Сообщение от Arsie

Проследите переписку,

Переписка началпсь с

Попытался с помощью этого блока (Device (Link)) контролировать обмен через Ethernet на контоллере Pixel (2G). Ни чего не вышло. Перечитал справку еще раз. ... Есть ли штатные средства SMLogix для контроля обмена через Ethernet для контроллеров типа Pixel (2G)? Хотя бы на уровне успешно принятых запросов?

Вопрос шел о контроле обмена на уровне успешно принятых запросов. Эту функциональность блок Device (Link) обеспечить может? Только прямой ответ: Да/Нет. Вопрос о контроле целостности данных возник позже, но 100% обоюдный контроль целостности данных был признан избыточным.

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

Только до тех пор, пока слейы решает сугубо свои задачи, сам не от ково не зависит и от него никто не зависит. Если слейв часть технологического процесса, сам зависит от кого то и от него кто то зависит, то не все так однозначно. А если из практики, то ее у меня не так много, но приходилось делать локальную диспетрезацию вентиляции с возможностью управления из общей системы диспетчеризации объекта. Со SCADA заморачиваться не стал, поставил панель вайнтек слейвом и 6 мастеров ModBus TCP. Выход в диспетчеризацию объекта через панель. Так что вопрос с избытоностью зависит от конкретной задачи.

[Arsie]

Сообщение от tvf

Переписка началпсь

Да неважно уже, с чего она началась. Все всё поняли, я надеюсь.

Справка дополнена, мнения составлены.

[tvf]

Понятно. Ложечки нашлись. Насколько сложно в этот блок встроить фильтрацию по Modbus адресу? Ну что бы осадок не оставался.

[Arsie]

Сообщение от tvf

Понятно. Ложечки нашлись. Насколько сложно в этот блок встроить фильтрацию по Modbus адресу? Ну что бы осадок не оставался.

Фильтрации по адресу в нём не будет за ненужностью.

Информацию по ошибкам слейвов поставляют блоки Slave(link).