ПЛК110-60 и Modbus (Master)

[rwg]

Добрый день! Недавно (http://www.owen.ru/forum/showthread.php?t=17031&p=134692#post134692) я жаловался на проблемы со связью с ПЛК. Вчера всплыла следующая проблема. ПЛК должен опрашивать 6 разных ТРМ по Modbus RTU с индивидуальными периодами опроса, от 1 до 10 секунд. Вчера программа изменила свой алгоритм работы. Подключение (кстати, связь с ПЛК заработала сразу, было очень приятно) показало, что согласно конфигурации ПЛК Modbus Master опрашивает все ТРМ и код последней ошибки всегда 81. Подключение вольтметра к линиям АВ RS485 показало, что опроса нет, напряжение не меняется ни на мВольт (при идущем опросе бывают уменьшения показаний вольтметра на несколько Вольт). Соответственно лампы RS на ТРМах не мигали. Сброс не помог, но после перепрограммирования всё заработало. Показания всех ТРМ в конфигураторе ПЛК были равны равны 0. Но наладчики вспомнили, что за 3 дня до этого на втором ПЛК был аналогичный сбой, но показания были равны последнему удачному измерению и не менялись. Сбой тогда самоустранился, возможно после отключения питания на длительное время.
Вопросы:
1. Есть ли возможность программного перезапуска Modbus Master без перезапуска основной программы. Если нет, почему, если есть, почему этого нет в конфигураторе ПЛК. Есть ли возможность у оператора перезапустить Modbus Master без использования отладочных средств и перезапуска основной программы или он должен отключать оборудование и ждать прибытия КИПовца.
2.(Больше из любопытства) Почему "Last Error" в конфигураторе ПЛК привязан к Modbus Master, хотя на самом деле это свойство Universal Modbus Device (по нему можно было бы быстро выделять неустойчиво работающие ТРМ, а сейчас об устойчивости работы можно только гадать). И почему у Universal Modbus Device нет метки времени последнего измерения? Без этих двух параметров честный OPC не сделаешь.

[rwg]

Пробежался по форуму. Понял, что с этой проблемой мучаются многие и выход один, переписать весь диалог по Modbus самому заново. Печально. А что ещё в CoDeSys написано столь же непрофессионально?

[lara197a]

У меня ТРМы и не только в больших количествах опрашиваются ПЛК100 и 110 уже много лет, без сбоев и выключений.
1. Связь нужно прокладывать кабелем для RS485, а не просто витой парой.
2. Экран заземляется с одной стороны.
3. При необходимости включайте оконечные резисторы.
4. Установите время минимального цикла ПЛК хотя бы 10мс.(если программа и перифирия большие, то можно больше.)
К примеру e S300-400 время цикла обычно 15-20мс. Все что нужно быстрее- на спец модули....

[rwg]

Суммарная длина RS485-проводников 1,5 метра, поэтому используется самодельная витая пара без экрана и оконечных резисторов. Время цикла 20мс, период опроса разных ТРМ 1 - 3 - 10 секунд. Сбои были при незаземлённых фильтрах БСФ, вчера я это исправил и надеюсь, что благодаря этому сбои прекратятся. Но готовлюсь к худшему варианту.

[Гарчев Евгений]

Вопросы:
1. Есть ли возможность программного перезапуска Modbus Master без перезапуска основной программы. Если нет, почему, если есть, почему этого нет в конфигураторе ПЛК. Есть ли возможность у оператора перезапустить Modbus Master без использования отладочных средств и перезапуска основной программы или он должен отключать оборудование и ждать прибытия КИПовца.
2.(Больше из любопытства) Почему "Last Error" в конфигураторе ПЛК привязан к Modbus Master, хотя на самом деле это свойство Universal Modbus Device (по нему можно было бы быстро выделять неустойчиво работающие ТРМ, а сейчас об устойчивости работы можно только гадать). И почему у Universal Modbus Device нет метки времени последнего измерения? Без этих двух параметров честный OPC не сделаешь.

1. Можно, режим опроса в UMD ставьте не по времени, а по команде и запускайте/останавливайте опрос по необходимым условиям.
2. Потому что в ModBus Master есть еще и LastAddress, в которой указывается адрес опрашиваемого устройства, по этой переменной и анализируйте наличие ошибки опроса (Last Error) для каждого устройства (удобно использовать оператор Case).
Метку времени последнего удачного измерения также можно сделать самостоятельно по указанным переменным.

[rwg]

1. Можно, режим опроса в UMD ставьте не по времени, а по команде и запускайте/останавливайте опрос по необходимым условиям.
2. Потому что в ModBus Master есть еще и LastAddress, в которой указывается адрес опрашиваемого устройства, по этой переменной и анализируйте наличие ошибки опроса (Last Error) для каждого устройства (удобно использовать оператор Case).
Метку времени последнего удачного измерения также можно сделать самостоятельно по указанным переменным.

Спасибо за ответ.
По 1. Вариант с опросом устройства по команде опробую, но боюсь, что зависание на уровне модуля Modbus Master и опрос всё равно закончится ошибкой 81.
По 2. LastAdress привязан к LastError в течение одного цикла, при нормальной реализации Модбуса опрос одного параметра может уложиться в 5мсек, а цикл работы контроллера может быть 20 - 50 мсек. При этом не гарантируется, что оба Last относятся к одному устройству. Но если опрос вести по команде, а цикл увеличить до 2-5 мсек, то, действительно, всё должно получиться. Жаль, что получается не автоматом, а после плясок с бубном.

[Гарчев Евгений]

1. Может и не поможет этот вариант в Вашем случае, но он есть. При работе с ТРМ-ами запись любых значений необходимо делать по изменению, либо по команде один раз, т.к. запись параметров осуществляется сразу в энергонезависимую память, которая имеет ограниченный ресурс перезаписей, обратите на это внимание. При работе по ModBus RTU в ТРМ-ах кол-во стоп-бит фиксированное и равно 2-ум, не забывайте про это тоже.
2. естественно тут будет привязка и к времени цикла работы ПЛК, но период опроса ставить 5 мс для 6-ти ТРМ-ов, к тому же при построении опроса через конфигурацию ПЛК - это через чур ... Да и время цикла работы ПЛК более 20-30 мс - это тоже многовато, в таком случае необходимо разбивать программу по циклам через тот же CASE.

[rwg]

1. При работе с ТРМ-ами запись любых значений необходимо делать по изменению, либо по команде один раз, т.к. запись параметров осуществляется сразу в энергонезависимую память, которая имеет ограниченный ресурс перезаписей. При работе по ModBus RTU в ТРМ-ах кол-во стоп-бит фиксированное и равно 2-ум, не забывайте про это тоже.
2. естественно тут будет привязка и к времени цикла работы ПЛК, но период опроса ставить 5 мс для 6-ти ТРМ-ов, к тому же при построении опроса через конфигурацию ПЛК - это через чур ... Да и время цикла работы ПЛК более 20-30 мс - это тоже многовато, в таком случае необходимо разбивать программу по циклам через тот же CASE.
1. В ТРМы я не пишу, только читаю. Про обязательные 2 стоп-бита у ТРМ202 я где то в конференции читал, поэтому протестировал сеть на работу с 1 и 2 битами. Изменение этой настройки на работу сети влияния не оказало, что удивило и порадовало.
2. Период опроса у меня ТРМов 0,5 - 10 секунд, 5мс - это минимальное полное время выполнения одного запроса Modbus (время передачи 16 байт + 3,5 мс на 2 таймаута). Уменьшить время цикла ПЛК я пока побоялся, потому, что раз в секунду у меня выполняется обработка дробных чисел, продолжительность цикла увеличивается, а на что это может повлиять, я пока не знаю. Сейчас средняя загрузка процессора 2%, но это в среднем.

[Гарчев Евгений]

1. В ТРМы я не пишу, только читаю. Про обязательные 2 стоп-бита у ТРМ202 я где то в конференции читал, поэтому протестировал сеть на работу с 1 и 2 битами. Изменение этой настройки на работу сети влияния не оказало, что удивило и порадовало.
2. Период опроса у меня ТРМов 0,5 - 10 секунд, 5мс - это минимальное полное время выполнения одного запроса Modbus (время передачи 16 байт + 3,5 мс на 2 таймаута). Уменьшить время цикла ПЛК я пока побоялся, потому, что раз в секунду у меня выполняется обработка дробных чисел, продолжительность цикла увеличивается, а на что это может повлиять, я пока не знаю. Сейчас средняя загрузка процессора 2%, но это в среднем.

1. Поначалу может и не повлиять 1 стоп-бит на качество опроса, тем более если кроме ТРМ-ов нет опрашиваемых устройств с одним стоп-битом, так что ставьте 2 стоп-бита, всегда там, где есть ТРМ-ы.
2. пускай минимальное время запроса/ответа 5 мс, если периодичность опроса 100 мс, то в last address и last error в течение этих 100 мс будут "висеть" значения с последнего запроса.
На работу с интерфейсами может повлиять, в первую очередь на Ethernet, на связь со средой ...

P.S.
Как Вы оценили загрузку процессора в процентах?

[rwg]

2. пускай минимальное время запроса/ответа 5 мс, если периодичность опроса 100 мс, то в last address и last error в течение этих 100 мс будут "висеть" значения с последнего запроса.
P.S.
Как Вы оценили загрузку процессора в процентах?

LastAddres и LastError, вероятнее всего, меняются после каждого запроса. Если 10 запросов занимают 50мс и выполняются раз в секунду, то эти 2 Lasta меняются 10 раз в течение 50мс, а потом 950мс не меняются. Чтобы разобраться из среды программирования, какой из ТРМ отвечает, а какой нет, я сделал всем ТРМам разные периоды опросов, иначе LastAddres почти всегда был равен наибольшему адресу. Потом начал смотреть на светодиоды RS на ТРМах и от этой методики ушёл.
Загрузка - 400мкс время выполнения цикла, делёная на период цикла 20мс, даёт 2%.

[Гарчев Евгений]

LastAddres и LastError, вероятнее всего, меняются после каждого запроса. Если 10 запросов занимают 50мс и выполняются раз в секунду, то эти 2 Lasta меняются 10 раз в течение 50мс, а потом 950мс не меняются.


Так и есть, только lastaddres меняется при опросе каждого из устройств, просто когда идет ожидание времени polling time lastadders принимает значение адреса последнего устройства, которому был направлен запрос. Чтобы не делать разные периоды опросов для разных устройств при подсчете кол-ва ошибок, сделайте проверку наличия ошибки по каждому устройству только по условию, если lastadrres в текущем цикле поменял свое значение по сравнению с предыдущим циклом.

[rwg]

сделайте проверку наличия ошибки по каждому устройству только по условию, если lastadrres в текущем цикле поменял свое значение по сравнению с предыдущим циклом.
Это я понял, и даже знаю, что при работе с ТРМ всё будет работать. Но при работе Modbus на максимальной скорости для безошибочного определения сбойного датчика время цикла ПЛК должно быть гарантированно не более 2-3 мс. При целочисленной арифметике этого обычно удаётся достичь, а вот каким будет реальное время цикла, в котором рассчитываютя сигналы 4 ПИД-регуляторов и ведётся архивация параметров, я не знаю. И боюсь, что при этом не ответившим будет считаться второй или третий после действительно отказавшего. Поэтому надо ещё как минимум озаботится о том, чтобы разные медленно выполняемые расчёты не попадали в один цикл ПЛК.