PDA

Просмотреть полную версию : Блок Device (Link)


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

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

Номер порта указываете верный? Вам нужна статистика как для слейва?

tvf
29.01.2014, 07:07
Номер порта указываете верный? Вам нужна статистика как для слейва? Все указываю как написано в справке. Статистика нужна вне зависимости от того, кем является контроллер (мастер или слейв). Для мастера желательно еще и разделение по адресу слейва. Но это так, пожелание.

Видимо "неработа" блока Device (Link) в контроллерах Pixel (2G) связана с тем, где разбираются пакеты ModBus. Для RS485 это процессор контроллера вне зависимости от марки (Pixel, 2G, 2Gi). Для Ethernet это процессор контроллера (2Gi) или процессор модуля связи (Pixel, 2G). А модуль связи передает только голую информацию, без статистики. Хотя это тоже домыслы. Так что повторяю свой вопрос:Есть ли штатные средства SMLogix для контроля обмена через Ethernet для контроллеров типа Pixel (2G)? Хотя бы на уровне успешно принятых запросов?Если нет, то будет ли это сделано? Если да, то каким образом?

Arsie
29.01.2014, 10:48
Для мастера желательно еще и разделение по адресу слейва. Но это так, пожелание.

Чем вас не устраивает Slave(link)?


Так что повторяю свой вопрос:Если нет, то будет ли это сделано? Если да, то каким образом?

1) Slave(link)

2) Переменная типа "Echo"

3) "Одноразовые запросы"

4) Контроль постоянно изменяющейся переменной

tvf
29.01.2014, 11:24
Чем вас не устраивает Slave(link)? Согласно справке на блок Slave(link) имеем:

Querys - для мастера: количество полученных ответов от слейвов
TrmPacket - для мастера: количество посланных слейвам запросов
NoRespons - для мастера: количество неответов от слейвов

То есть для мастера блок Slave(link) определяет "средную температуру по больнице". А хочется определять температуру для каждого пациента (слейва). Если вы можете определить, какой из слейвов дает наибольший процент ошибок, то поделитесь этой сакральной информацией.
1) Slave(link)
2) Переменная типа "Echo"
3) "Одноразовые запросы"
4) Контроль постоянно изменяющейся переменной
1)Slave(link) без проблем работает только по RS485. По Ethernet работает только на 2Gi.
2-4)Эти способы требуют соответствующей подготовки мастера. Слейв только отвечает на запросы мастера. А вот к мастеру привязываться не хотелось бы. Да и к интерфейсу обмена тоже.
Уточню вопросы:
1. Когда и как контроллеры Pixel (2G) смогут контролировать обмен и качество обмена по Ethernet находясь а режиме слейва?
2. Когда и как контроллеры Pixel (2G, 2Gi) смогут контролировать обмен и качество обмена с каждым конкретным слейвом, в объеме предусмотренным блоком Slave(link)?

Arsie
29.01.2014, 12:25
Согласно справке на блок Slave(link) имеем:

Быть может всё же Device(link)?



1)Slave(link) без проблем работает только по RS485. По Ethernet работает только на 2Gi.
2-4)Эти способы требуют соответствующей подготовки мастера. Слейв только отвечает на запросы мастера. А вот к мастеру привязываться не хотелось бы. Да и к интерфейсу обмена тоже.
Уточню вопросы:
1. Когда и как контроллеры Pixel (2G) смогут контролировать обмен и качество обмена по Ethernet находясь а режиме слейва?
2. Когда и как контроллеры Pixel (2G, 2Gi) смогут контролировать обмен и качество обмена с каждым конкретным слейвом, в объеме предусмотренным блоком Slave(link)?

1) Слейвы в modbus вообще не контролируют обмен, это задача мастера

2) Блок Slave(link) в них работал всегда

Если же говорить о блоке Device(link), то это специальный отладочный блок, который и знать не знает, сколько и чего подключено к порту. Его дело - считать пакеты, пришедшие на порт и ушедшие с него.

tvf
29.01.2014, 13:22
Быть может всё же Device(link)?Да действительно Device(link). Не заметил подмены. И все в предыдущем сообщении относилось именно к нему.
1) Слейвы в modbus вообще не контролируют обмен, это задача мастераТем не менее ПЧ типа ATV212 при управлении по интерфейсу встают по ошибке при отсуствии обмена. А сеть именно modbus и ПЧ там стоят слейвами. Так что все реализуемо. Было бы желание. И в существующей ситуации, при обмене по RS485 все уже работает, остался Ethernet.
Если же говорить о блоке Device(link), то это специальный отладочный блок, который и знать не знает, сколько и чего подключено к порту. Его дело - считать пакеты, пришедшие на порт и ушедшие с него.Ну так добавить вход с названием "Адрес". Стоит на входе 0 - считаем все подряд, стоит n - считаем пакеты только с адреса n. Изменение значения - сброс всех счетчиков.

Arsie
29.01.2014, 14:00
Да действительно Device(link). Не заметил подмены. И все в предыдущем сообщении относилось именно к нему.

Никакой подмены нет, это два разных блока, выполняющие две разные задачи.


Тем не менее ПЧ типа ATV212 при управлении по интерфейсу встают по ошибке при отсуствии обмена. А сеть именно modbus и ПЧ там стоят слейвами. Так что все реализуемо. Было бы желание. И в существующей ситуации, при обмене по RS485 все уже работает, остался Ethernet.

У ATV212 какой порт?


Ну так добавить вход с названием "Адрес". Стоит на входе 0 - считаем все подряд, стоит n - считаем пакеты только с адреса n. Изменение значения - сброс всех счетчиков.

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

tvf
29.01.2014, 14:27
Никакой подмены нет, это два разных блока, выполняющие две разные задачи.С этим не спорю. Только Slave(link) работает только на мастере, а Device(link) и на мастере и на слейве. Разницу в названиях просто проглядел.
У ATV212 какой порт? RS485 ModBus. Если вы на именно на порт намекаете, то в 2Gi Device(link) как то контролирует обмен и по Ethernet. Значит варианты есть.
Если вы будете продолжать невнимательно читать мои ответы, мы с вами так ни до чего и не договоримся.
Ну так добавить вход с названием "Адрес". Стоит на входе 0 - считаем все подряд, стоит n - считаем пакеты только с адреса n. Изменение значения - сброс всех счетчиков. Сказанное относится именно к блоку Device(link). И является пожеланием, улучшающем информативность этого блока. Насколько это реализуемо, вам лучше знать. К слову говоря, некоторое удивление вызывает следующая фраза из справки:
PNum - номер порта уровня протокола (обязательно должен совпадать с CNum)Зачем 2 разноименных входа, значения на которых должны обязательно совпадать? 1 обойтись недьзя было?

Arsie
29.01.2014, 16:56
Сказанное относится именно к блоку Device(link). И является пожеланием, улучшающем информативность этого блока. Насколько это реализуемо, вам лучше знать.

Device(link) оценивает работу порта, а не протокола на нём. Это первое.

Device(link) оценивает связь между сетевым модулем и контроллером. Это второе.

Device(link) - это средство контроля работы локальных портов.

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

Некрасиво и неизящно и так можно сделать - я вам привёл список способов. Зачем вы предлагаете удлиннить этот список?



К слову говоря, некоторое удивление вызывает следующая фраза из справки:
Зачем 2 разноименных входа, значения на которых должны обязательно совпадать? 1 обойтись недьзя было?

Исторически сложилось (с)

tvf
30.01.2014, 08:20
Device(link) оценивает работу порта, а не протокола на нём. Как то вы вольно трактуете работу блока Device (Link). Или выдаете желательное за действительное. Справка по блоку Device (Link) прямо говорит:CRst - сброс собранной статистики о физическом уровне.
PRst - сброс собранной статистики о работе протокола (CRC, TrmPacket, NoRespons, IFunc, Size).
Или по вашему параметры CRC, TrmPacket, NoRespons, IFunc, Size относятся к работе порта?
Device(link) оценивает связь между сетевым модулем и контроллером.У меня на Pixel стоит сетевая плата. На каких выходах блока Device (Link) должны меняться показания при наличии обмена по Ethernet?
Device(link) - это средство контроля работы локальных портов.Тогда давайте определимся, что считать локальным портом. Сетевая плата, установленная в контроллер Pixel, является локальным или удаленным портом?
Вы пытаетесь скрестить ужа с ежом вместо того, чтобы предложить красивое и изящное решение. Это не моя, а ваша задача предложить мне красивое и изящное решение. Отсуствие такого решения (для Pixel с сетевой платой) и заставляет решать задачу Некрасиво и неизящно

Arsie
30.01.2014, 10:02
Это не моя, а ваша задача предложить мне красивое и изящное решение.

Всё, что я вам мог предложить, я уже предложил.

ujin
30.01.2014, 21:13
Я ввел переменную unix_time. Меняется каждую секунду. Для мастера - это показатель что слейв online. Для слейва - что мастер online. Соответственно используется и как heartbeat и как источник периодической синхронизации времени. Запаковка распаковка в long действует до 2038 г. и широко описана. Потом 8 байт понадобится.

tvf
31.01.2014, 07:47
Я ввел переменную unix_time...На данный момент я примерно так и делаю. Одна переменная - связь, вторая - дата/время. Суть дискусси не в том, что контроль обмена нельзя сделать в принципе. А в том, что его нельзя сделать штатными средствами лоджика. По крайней мере в полном объеме, вне зависимости от интерфейса, роли в сети и типа контроллера. Под штатными средствами подразумевается красивое и изящное решение не требующее взамной увязки алгоритмов на мастере/слейве и роли контроллера в сети.

Arsie
31.01.2014, 10:58
Под штатными средствами подразумевается не требующее взамной увязки алгоритмов на мастере/слейве и роли контроллера в сети.

Проблема в том, что в протоколах типа "запрос-ответ" принципиально не существует "красивых" решений контроля связи со стороны слейва.

Возьмём упомянутый вами частотник. Вы предложили один костыль заменить на другой костыль. И я объясню, почему.

Объективно, команды на частотник нужно отправлять только при смене режимов работы. Т.е. отправили с утра команду "пуск", а команду "стоп" отправили вечером. Состояние самого частотника считываем раз в час. Этого для работы некоторых объектов достаточно.

Но что сделает частотник? Он через 10 секунд (такое у большинства частотников время предустановленное) разорётся, что связь пропала.

А она не пропала. Просто харатер обмена такой.

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

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

Другими словами: два костыля - пара (c)

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

ujin
31.01.2014, 13:39
А в том, что его нельзя сделать штатными средствами лоджика. По крайней мере в полном объеме, вне зависимости от интерфейса, роли в сети и типа контроллера.
У Вас есть пример, где это сделано на Модбасе? ПЛК где я встречал сигнал online на слейве использовал периодическое к нему обращение.
В модбасе нет проводов DTR, DSR. Поэтому любой способ детектирования связи возможен только через периодическое обращение к этому слейву и ответу от него. Блок Device(link) на пикселе разве не увеличивает значение Querys при запросе от мастера по ethernet?

tvf
31.01.2014, 14:19
Возьмём упомянутый вами частотник. Вы предложили один костыль заменить на другой костыль. И я объясню, почему.
Объективно, команды на частотник нужно отправлять только при смене режимов работы. Т.е. отправили с утра команду "пуск", а команду "стоп" отправили вечером. Состояние самого частотника считываем раз в час. Этого для работы некоторых объектов достаточно. Не все так примитивно. Из документации на ПЧ ATV212:[Не активна]: выполняется последняя команда управления
[Ост. с темпом]: ПЧ тормозится с заданным темпом. Контроль сети сохраняется
[Выбег]: ПЧ прекращает питание двигателя и он останавливается. Контроль сети сохраняется
[Err5 или Err8]: ПЧ блокируется по неисправности связи Err5 или по неисправности сети Err8.Выбор реакции на потерю связи достаточно широк. И я волен выбирать любую реакцию на потерю связи без вмешательства во внутренее ПО ПЧ. И без использования дополнительного костыля в виде гоняния туда/сюда дополнительной переменной. В ПЧ просто нет такой переменной. Теперь представим, что это не ПЧ, а Пиксель, упраляющий несколькими ПЧ. Если связь идет через RS485, то все можно сделать. А если по Ethernet - нет. Причем моя задача - только Пиксель и его ПЧ. Кто дает Пикселю команду на включение я понятия не имею, да и не интересует меня это. Это проблемы мастера. Моя задача - дать предсказуемую и вариабельную реакцию Пикселя на потерю связи и правила определения факта потери связи. А дальше пусть решает Мастер, ибо только мастер всегда знает, что происходит со связью и что при этом делать.
Если Пиксель выступает мастером, то все чуть лучше. Slave(link) определит превышение лимита ошибок, но причину вряд ли. В этом деле помог бы Device(link), но он показывает "средную температуру по больнице" да и то при связи через RS485, при связи через Ethernet он и этого не покажет.
Вот и получается, что в Лоджике вроде есть блоки для анализа качества связи, но толку от них немного. Вот и приходится пользоваться "некрасивыми и неизящными" решениями.

Если не планируется изменения в работе блока Device(link), то дальнейшая переписка не имеет смысла. Я свою потребность до вас донес, как мог аргументировал. Ваша реакция тоже ясна - все и так хорошо. Какой смысл переливать из пустого в поржнее?

Arsie
31.01.2014, 14:59
Не все так примитивно. Из документации на ПЧ ATV212:Выбор реакции на потерю связи достаточно широк. И я волен

Отключение контроля это именно его отключение. Вы вольны либо копать, либо не копать. Без вариантов.


Теперь представим

Не хочу я представлять. Нафантазировать в отрыве от реальности можно что угодно.

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

На всякий случай я уточню, что такое PLC. PLC не частотник. PLC сам управляет объектом, а частотник создан быть управляемым кем-то, это его предназначение в жизни. Что такое автономная работа ПЧ я знаю, не нужно тратить своё и моё время на очевидные вещи.

Другими словами, вентустановка или котельная или ИТП от отключения диспетчеризации не умрёт. Она в нормальном режиме будет работать дальше. И информация о наличии диспетчеризации, откровенно говоря, не очень-то и нужна.



Если не планируется изменения в работе блока Device(link), то дальнейшая переписка не имеет смысла. Я свою потребность до вас донес, как мог аргументировал. Ваша реакция тоже ясна - все и так хорошо. Какой смысл переливать из пустого в поржнее?

Вы можете и не продолжать диалог, но тогда ничего и не изменится. Под лежачий камень вода не течёт.

Arsie
31.01.2014, 15:05
Если Пиксель выступает мастером, то все чуть лучше. Slave(link) определит превышение лимита ошибок, но причину вряд ли. В этом деле помог бы Device(link), но он показывает "средную температуру по больнице" да и то при связи через RS485, при связи через Ethernet он и этого не покажет.
Вот и получается, что в Лоджике вроде есть блоки для анализа качества связи, но толку от них немного.

Кстати, зачем вам знать причину потери связи во время работы объекта? Хотя бы один объективный аргумент.

Повторю второй раз: ПНР - это НПР. ПНР не являются типичной рабочей ситуацией на объекте.

Nick
31.01.2014, 15:58
Если Пиксель выступает мастером, то все чуть лучше. Slave(link) определит превышение лимита ошибок, но причину вряд ли. В этом деле помог бы Device(link), но он показывает "средную температуру по больнице" да и то при связи через RS485, при связи через Ethernet он и этого не покажет.


блок Дивайс-линк должен работать и по 485 и по Ethernet в любом контроллере.
опишите подробнее с показанным примером, как у вас законфигурен этот блок, с фоткой куска проекта или примером проекта. Может чтото не так. посмотрим.

ujin
31.01.2014, 16:05
Кстати, зачем вам знать причину потери связи во время работы объекта? Хотя бы один объективный аргумент.
Во первых извиняюсь не разобрался, что с ethernet работает только Device(link) на 2Gi. Хотя вроде при отладке пикселя видел, что связь определяется (проверю).
Необходимость контроля возникнет если использовать пиксель как модуль расширения для другого контроллера. Связь с которым организована по ethernet.
Были у нас такие объекты где мастер пром компьютер слейвы блоки расширения. Связь по дублированной ethernet.
Просто как вариант применения.

Arsie
31.01.2014, 16:25
Необходимость контроля возникнет

Что контроль иногда нужен - с этим я никогда не спорил :)


если использовать пиксель как модуль расширения для другого контроллера. Связь с которым организована по ethernet.
Были у нас такие объекты где мастер пром компьютер слейвы блоки расширения. Связь по дублированной ethernet.
Просто как вариант применения.

Чуть поподробнее, будьте добры. У вас был какой-то неизвестный контроллер с неизвестной вам программой и вы подсунули ему Pixel, сымитировав сгоревший оригинальный модуль расширения?

Arsie
31.01.2014, 17:56
Во первых извиняюсь не разобрался, что с ethernet работает только Device(link) на 2Gi. Хотя вроде при отладке пикселя видел, что связь определяется (проверю).

В Пикселе работает, порт №5 :)

ujin
31.01.2014, 19:43
Чуть поподробнее, будьте добры. У вас был какой-то неизвестный контроллер с неизвестной вам программой и вы подсунули ему Pixel, сымитировав сгоревший оригинальный модуль расширения?
Мысль у Вас летит слишком быстро вперед. Это сложно. Хотя если есть описание и образец для экспериментов, то можно.
У нас был ПТК Торнадо. Пром компьютер ADVANTECH. Модули расширения торнадо с дублированным езернет. Два кольца езернет. Два свича moxa. Программа тоже торнадо. При отключении Advantech модули расширения определяют, что нет связи и переходят в безопасный режим. Поймал себя на мысли что все можно сделать точно так же и на пикселях только с одним езернетом. Где-то ранее я вам этот вариант расписывал в виде верхняя сеть RS-458 нижняя сеть RS-458 сеть диспетчеризации езернет. У них (торнадо) все дублированный езернет. У Вас Езернет на борту есть блоки диагностики есть, хотя мне юникс время больше нравится. Сразу и heartbeat и сразу синхронизация времени. Этот вариант я Вам ранее так же расписывал. И не надо мне говорить что это другая аппаратура. Народ делает в безнес центрах связь на оптоволокне между ПЛК на аналогичной вашей аппаратуре.
И в Вашей аппаратуре я препятствий для этого не вижу даже в сегодняшнем виде.

Arsie
02.02.2014, 14:19
Мысль у Вас летит слишком быстро вперед.

Модули расширения торнадо с дублированным езернет. Два кольца езернет. Два свича moxa. Программа тоже торнадо. При отключении Advantech модули расширения определяют, что нет связи и переходят в безопасный режим.

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

Абсолютно все приведённые в этой теме примеры основаны на том, что Пиксель является именно модулем расширения, а не самостоятельным устройством. Модули расширения - это MR и MC, они нормально падают в безопасное состояние по правилам, принятым в их протоколе обмена.

Если использовать Пиксель в роли модуля расширения, то придётся программно реализовывать безопасное состояние и задавать критерии входа в него и выхода из него. Использование блока Device(link) для этого - опасное заблуждение. Блок покажет наличие обмена даже в том случае, когда всего один единственный запрос из десяти будет удачен. Безопасный режим отключится, а 9 значимых запросов пропадут и работа автоматики будет нарушена. Для полноценной работы нужно считать хотя бы контрольную сумму всех данных, а это означает введение дополнительных переменных. Ещё одна в роли "сердцебиения" никак не усложнит программирование системы.

tvf
03.02.2014, 08:16
блок Дивайс-линк должен работать и по 485 и по Ethernet в любом контроллере.Согласно справке по блоку Device (Link)CNum - номер порта физического уровня:
3 - Ethernet в SMH2Gi

PNum - номер порта уровня протокола:
3 - Ethernet в SMH2GiТак что или ошибка в справке на блок, или у вас ошибочное представление о работе блока. Возможно дело в том, что "неработа" блока Device (Link) в контроллерах Pixel (2G) связана с тем, где разбираются пакеты ModBus. Для RS485 это процессор контроллера вне зависимости от марки (Pixel, 2G, 2Gi). Для Ethernet это процессор контроллера (2Gi) или процессор модуля связи (Pixel, 2G). А модуль связи передает только голую информацию, без статистики. Надо ли приводить пример?
Если использовать Пиксель в роли модуля расширения, то придётся программно реализовывать безопасное состояние и задавать критерии входа в него и выхода из него. Использование блока Device(link) для этого - опасное заблуждение. Блок покажет наличие обмена даже в том случае, когда всего один единственный запрос из десяти будет удачен. Безопасный режим отключится, а 9 значимых запросов пропадут и работа автоматики будет нарушена. Для полноценной работы нужно считать хотя бы контрольную сумму всех данных, а это означает введение дополнительных переменных. Ещё одна в роли "сердцебиения" никак не усложнит программирование системы.То есть принимая запрос с переменной "сердцебиения" и не принимая остальных 9 значимых запросов буде все ОК? Отличия между переменной "сердцебиения" и блоком Device (Link) в количестве информации о состоянии связи. Переменная "сердцебиения" выдает 1 параметр, блок Device (Link) выдает 10 параметров. А из 10 параметров можно получить куда больше информации. Как ее использовать, это уже дело каждого конкретного случая. Главное иметь такую возможность.

Arsie
03.02.2014, 10:13
То есть

Попробуйте прочесть, что я написал, ещё раз.

Nick
03.02.2014, 10:29
Согласно справке по блоку Device (Link)Так что или ошибка в справке на блок, или у вас ошибочное представление о работе блока.


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

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

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

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

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

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

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

tvf
03.02.2014, 11:22
Иначе... нафик он такой интересный нужен, с конфигурированеием портов и протоколов. Именно этот вопрос и у меня возник. Но прочитав справку, дальше эксперементировать не стал. Попробую еще раз.

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

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

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

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

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

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

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

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

tvf
03.02.2014, 12:04
Ну, разве что он сможет показать, что часть пакетов побитая. Но это всё равно не равнозначно некорректным данным.
Приход нормальных пакетов и отсуствие битых пакетов это и есть необходимое, но недостаточное условие для качественной связи.

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

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

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


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

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

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

tvf
03.02.2014, 12:37
Собственно, именно это я и написал. А для этого необходима работа блока Device (Link) вне зависимости от протокола.Придут не все - не совпадёт контрольная сумма. Надеюсь вы понимаете, что "сердцебиение" должно быть включено внутрь контрольной суммы? Надеюсь вы понимаете, что этих 2 переменных явно недостаточно для гарантии того, что данные идущее в обе стороны 100% доходят до адресатов? ModBus для этого не особо предназначен. А реализация на уровне алгоритма как минимум слишком трудозатратна и ресурсоемка.

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

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

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

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

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

----------

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

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

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

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

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

Зачем?



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

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

Зачем?

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

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

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

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

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

ujin
04.02.2014, 08:30
Ни кто это и не отрицает. Речь шла об информировании слейва, что мастер считал из него все данные корректно. Обоюдный контроль связи, это не только контроль записи в слейв, но и контроль чтения из слейва. Мастер то определит, надо еще сообщить об этом слейву.
В том и смысл heartbeat, что данные передаются постоянно с определенной периодичностью, например один раз в секунду или один раз в пять секунд. Это задание состояния управляемому объекту, задание регулируемого параметра, контроль состояния, контроль параметра, контроль аварийного регистра. Даже если проходит 10% пакетов, рано или поздно вся информация доходит. Соответственно время прихода информации удлинняется. При этом запросы портятся примерно одинаково, так что портится и heartbeat (в моем случае unix_time).
Если задание или уставка не меняется, она все равно передается вместе и с периодичностью heartbeat. Слейв уже сам решает, что делать с данными - они пришли но не изменились.
Контроль записи в слейв с 2 доп. переменными требут как минимум записывать все переменные одним запросом. А если запросов на запись 2 и более? Как вы это делали?
Все точно так же. Запросы портятся примерно одинаково.

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

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

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

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

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

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

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

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

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

Nick
04.02.2014, 10:16
Где тут избыточность?


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

tvf
04.02.2014, 11:00
Проследите переписку, Переписка началпсь сПопытался с помощью этого блока (Device (Link)) контролировать обмен через Ethernet на контоллере Pixel (2G). Ни чего не вышло. Перечитал справку еще раз. ... Есть ли штатные средства SMLogix для контроля обмена через Ethernet для контроллеров типа Pixel (2G)? Хотя бы на уровне успешно принятых запросов? Вопрос шел о контроле обмена на уровне успешно принятых запросов. Эту функциональность блок Device (Link) обеспечить может? Только прямой ответ: Да/Нет. Вопрос о контроле целостности данных возник позже, но 100% обоюдный контроль целостности данных был признан избыточным.

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

Arsie
04.02.2014, 11:07
Переписка началпсь

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

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

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

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

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

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