Показано с 1 по 7 из 7

Тема: ПР200, "управляемые" запросы Modbus на несколько устройств.

  1. #1

    По умолчанию ПР200, "управляемые" запросы Modbus на несколько устройств.

    Добрый день.
    Делали некую распределённую систему на ПР200, там был модбас - мастер ПР200 и ведомые такие же.
    Считать надо было с каждого по 1 регистру (стандартному, в 2 байта).

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

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

    Я думал, что поставив количество попыток при отсутствии ответа =1 можно это посчитать по той переменной, которая < настройка прибора - интерфейсы - 485 мастер - устройство - статус> , но она, как только первый ответ получен, сразу становится =1 и в ноль до пропадания связи не обращается. Сколько при этом запросов в сеть улетело, посчитать тоже нельзя.

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

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

    Поставил фронтовыделитель на выдачу запроса, переменная "запрос" теперь ставилась на один цикл контроллера, и запросы начали выходить для всех устройств, однако, не синхронно с выставлением переменной в 1, а по 1 на каждый перебор этой переменной с первого до последнего ведомого устройства. То есть, "запрос" приравнивался к 1 для первого устройства, в линию выходил пакет, потом ставился для 2, 3, 4 и тд, в линию ничего не выходило, затем сначала для 1-го, потом 2-го - и тут только выходил на линию пакет для второго устройства.

    Вопрос в том, можно ли как-то иметь информацию не о наличии связи "вообще", а в конкретно нужный момент послать пакет в линию, и узнать, получен ответ в этот раз на этот пакет, или нет? Может быть, следовало использовать не те переменные "запрос" и "статус", которые за всё устройство, а такие же за конкретную считываемую величину отвечают?

  2. #2

    По умолчанию

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

  3. #3

    По умолчанию

    А почему плк? Если бы вот тут была возможность обработку переменной как-то "объехать" - то есть, при каких-то условиях она сбрасывается, при каких-то - возводится в 1, а при каких-то с ней ничего не делается, и она остаётся без изменений, то я бы вполне сделал и здесь.

    Потому что венцов потуг явилась идея, что аппаратно возведённую в "1" переменную "статус" надо бы сбросить, а затем уже выставлять запуск "запрос" для другого ведомого, но копирование переменной саму в себя с промежутком НЕ-И для сброса не поехало в симуляторе, а все наличные устройства уже поставлены на ихние ПМЖ на объекте, и по факту всё работает, но без статистики. Есть некая ерунда типа "количество потерь связи и общее время потери обмена за всё время работы", но это хрень (

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

    И вообще, двухсотка - вполне ПЛК, ибо может целочисленное вычисление, а даже плавающую точку, не то, что Лога какая-нибудь или Зелия, которые только сравнивают, а с 2 портами просто зверь, на которой накрутить можно такое, что чертям тошно станет.
    Последний раз редактировалось chm; 23.12.2015 в 15:31.

  4. #4

    По умолчанию

    Цитата Сообщение от chm Посмотреть сообщение
    А почему плк?
    Потому, что статистика требует архив, иначе это средняя температура по больнице.
    Как пример: за 3 месяца январь-март - ни единого разрыва.
    за апрель - июнь -0925944335 разрывов. Что даёт информация? -НИЧЕГО.
    А с архивом: тут гроза была -34567 разрывов, а вот тут - в соседнем доме Уася трансформатор тесла ночью гонял - 2348979 разрывов.

  5. #5

    По умолчанию

    за 12 часов статистика - вполне, даже при трансформаторе тесла, а если за смену к нему пару раз наведаться - то вполне уже можно что-то получить и сопоставить с поведением окружающей среды.
    По крайней мере, вопрос в том, как при "триггерном" управлении запросами получить что-то дальше первого устройства, что почему-то не получается.

    А для архива можно самописец какой приспособить на выходные реле. тут уже и имеющиеся "статусы" как раз сгодятся - не износятся контакты.

  6. #6

    По умолчанию

    Цитата Сообщение от chm Посмотреть сообщение
    за 12 часов статистика - вполне, даже при трансформаторе тесла, а если за смену к нему пару раз наведаться - то вполне уже можно что-то получить и сопоставить с поведением окружающей среды.
    Чем дальше - тем хотелка заказчика будет больше расти.
    Если сегодня вы сделаете счётчик разрывов с ручным сбросом, то завтра попросят архив только потому, что влом 2 раза в день ходить.

    По крайней мере, вопрос в том, как при "триггерном" управлении запросами получить что-то дальше первого устройства, что почему-то не получается.
    Вводите в передаваемые данные переменную, в зависимости от величины которой в ответной переменной будут переданы изменённые данные. Меняйте её раз в секунду например.
    А для архива можно самописец какой приспособить на выходные реле. тут уже и имеющиеся "статусы" как раз сгодятся - не износятся контакты.
    И в результате общая стоимость выше чем стоимость решения на ПЛК.

  7. #7

    По умолчанию

    Цитата Сообщение от Алексей Геннадьевич Посмотреть сообщение
    Чем дальше - тем хотелка заказчика будет больше расти.
    Если сегодня вы сделаете счётчик разрывов с ручным сбросом, то завтра попросят архив только потому, что влом 2 раза в день ходить.
    Если заказчик представляет собой один организм, а хождение 2 раза в день осуществляет другой организм, то, по богатому опыту, трудности второго организма первый не беспокоят.

    Вводите в передаваемые данные переменную, в зависимости от величины которой в ответной переменной будут переданы изменённые данные. Меняйте её раз в секунду например.
    какой-то идентификатор пакетов не мешает в стандарт вообще по жизни ввести, да но тут это извращение, тк чем меньше всего идёт по общему каналу (радиоэфир), тем лучше. Опять же, сейчас - ведомые контроллеры, а потом будет чего-то, что данные передаваемые в зависимости от пришедших изменять не умеет, хоть тот же овеновский 4-значный индикатор под стандартную дырку...

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


    Это всё лирика. По факту не получается работать с передачей кадра по изменению триггера.

Похожие темы

  1. Ответов: 7
    Последнее сообщение: 27.02.2013, 19:08
  2. Ответов: 2
    Последнее сообщение: 25.03.2012, 19:24
  3. Ответов: 2
    Последнее сообщение: 07.03.2012, 13:17
  4. Ответов: 8
    Последнее сообщение: 29.03.2011, 14:07

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •