ПЛК110-60 + МВ110-8АС + МК110-4К.4Р

К ПЛК 110-60 по RS485 подключено 2 модуля МВ110-8АС и 3 модуля МК110-4К.4Р, опрос производится с помощью библиотеки ОВЕН ModBus. Настройки соединения 115200, 8, N, 1.

Принцип опроса, взят из раздела "Примеры и полезности".

А теперь, собственно, к сути проблемы. Стоит задача ,МАКСИМАЛЬНО БЫСТРО, опросить вышеперечисленные модули УСО. Модули МВ110-8АС опрашиваются групповым запросом ,начиная с 264 регистра колличеством 24 регистра. Оба аналоговых модуля ,по части связи, работают хорошо, из тестовых 40000 запросов, ни одной ошибки :cool: .

А вот с МК110-4К.4Р происходит какаято ерунда :confused: , первый , в очереди опроса, из трех модулей практически никогда не отвечает, второй работает почти хорошо, а третий отвечает примерно в два раза чаще чем первый.
При это если опрашивать каждый модуль по отдельности, то все три модуля прекрасно отвечают на все посланные запросы.

В результате множественных эксперементов и набюдений, было установленно, что если где-то за 50мс перед опросом ,любого модуля МВ110-4К.4Р, в сети происходила какаято передача данны не адресованная ему, то он некоторое время игнорирует адресованные ему запросы. Причем дело не в таймауте а именно в игнорировании запроса.

Вобщем последовательность действий такова:

1. ПЛК посылает запрос первому МВ110-8АС, сразу получает ответ, радуется :) .

2. Порадовался ответу от первого, посылает запрос второму, сразу получает ответ от второго, радуется :) .

3. Порадовался ответу от второго, посылает запрос первому МК110-4К.4Р, и тут начинаются проблемы. Так как непосредственно перед его опросом без задержки в 50мс, происходила передача данных между ПЛК и вторым модулем МВ110-8АС, то он игнорирует запрос адресованый ему.
Следует заметить, какой таймаут не устанавливай, ответа все равно уже не будет. А вот если после опроса второго модуля МВ110-8АС подождать 50мс, то он отвечает мгновенно.

4. Так как первый модуль МК110-4К.4Р проигнорировал запрос ПЛК, функциональный блок "MB_RD_HOLD_REGS" начинает ожидание ответа и отсчет времени ТаймАута. Таким образом в сети получается "Тишина" на время ТаймАута.

5. ПЛК подождал таймаут, огорчился :mad: , и перешол к опросу второго МК110-4К.4Р, и так как перед его опросом, в сети получилась столь необходимая пауза, то он почти всегда отвечает.

Вот такая неприятность.
Какие будут советы?

Спасибо!

или попробуйте воспользоваться modbusASCII, в RTU чтоб получить корректный запрос и адекватный ответ пауза между запросами должна быть из моих наблюдений примерно 15-20мс

Цитата:

---

Вот такая неприятность.

---

и это не неприятность, а так работает этот протокол http://ru.wikipedia.org/wiki/Modbus
раздел RTU фрейм

Цитата:

---

Сообщение от Валенок

Не. Это так реализуют. Если б авторы читали ссылку - проблем не было бы

---

авторы ссылку читали, просто аппаратная реализация (а не программная) подразумевает работу на совсем низких скоростях, плюс от себя пару мс вот и получается примерно то время, которое лично у меня получилось. По ссылке на 9600 большая пауза ~4мс вот устройство отправило ответ выждало две паузы и стало готовым к приему следующего запроса, если исходить из расчета, что кому то захочется поработать на 4800 это как раз 16мс выйдет

Цитата:

---

паузы вообще необязательны

---

как не обязательны, именно из этого описания и следует что они должны быть, в modbus ASCII, там да ценная информация находится между начальным и конечным символом и можно слать запросы без пауз, сложности возникнут при чтениях, а при записи вообще проблем нет, на ответы обычно и так ни кто не смотрит

Цитата:

---

Сообщение от Валенок

Задержки ответа в конфигураторе на 4K.4R ?

---

Может я плохо описал ситуацию, но больше печатать небыло сил.
В конфигураторе задержка ответа "0", да и дело не в этом.
Я ведь описывал, что сколько не ставлю таймаут, вплоть до 2с, ответ все равно не приходит. Мне кажется что дело именно в игнорировании запроса.

Цитата:

---

Сообщение от Валенок

Попробуйте сделать только 1 запрос и отбить реальную задержку ответа

---

Если спрашивать только один модуль, то задержки ,можно считать,вобще нет, все работает идеально!

P.S.
Считаю что спорить о стандартах протокола не имеет смысла, так как в этом же алгоритме опроса работает два МВ110-8АС, но у них и намека нет на такую проблему, ВСЕ РАБОТАЕТ ИДЕАЛЬНО.

Попробуйте еще раз,внимательнее, перечитать мое сообщение, а лучше попробовать опытным путем, по возможности.

Пришлось переключить один МВ110-8АС на RS485-1, а второй МВ110-8АС и три МК110-4К.4Р на RS485-2. На RS485-2 каждый второй запрос сделал на МВ110-8АС, так как аналоги приоритетнее, а между ними с задержкой 50мс , ставлю 40мс начинают проскакивать ошибки. После ответа от МВ110-8АС, по очереди запросы на 1, 2, 3 МК110-4К.4Р.

Так что

Цитата:

---

Для скоростей более 19200 бод допускается использовать интервалы 1,75 и 0,75 мс соответственно.

---

Спасибо!

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

Цитата:

---

Время 1-2 и 5-6 вычисляется, 4 - известно

---

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

Но тогда в данной ситуации, при опросе подряд двух МВ110-8АС, второй должен был регулярно страдать, а этого не происходило. Из 40000 запросов на двоих, ни одной ошибки.

Я уж и не помню точно, очень много было разных экспериментов, но поначалу подозрения у меня были тоже на МВ110-8АС. Поэтому я пробовал опрашивать только 3 модуля МК110-4К.4Р., результат, тот же!
Пробовал менять последовательность опроса, и как только дело доходило до МК110-4К.4Р, ситуация сново повторялась.

Цитата:

---

Сообщение от Валенок

По поводу задержки. Сам всегда ставлю 0. Но у отдельных девайсов надо зачем-то (:confused: ) ставить не меньше 1. (Например 8D-4R) Это - кривой релиз.

---

А что происходит если поставить 0 ?

Цитата:

---

Сообщение от Валенок

Я несовсем понял - только 3х 4К4R - "тот же" - нормуль ?

---

Нет, таже проблема.

Во-о оно как :)
Есть возможность сделать следующее ?

var
et : time;

case step of
1:
ton(in:=false);
ton(in:=true, pt:=T#1d);
..(enable:=true);
step:=2;
2:
..(enable:=false, complete=> complete);
if complete then
t(et=> et);
step:=3;
end_if
end_case

скока et ?

Оборудование уехало на монтаж, проверить нет возможности!
Куда пропали представители техподдержки?

НЕТ, Ну где я не прав ?

А время цикла ПЛК, у Вас не маловато?.
Попробуйте в следующий раз посмотреть в модуле статистике.
Очень часто увеличение минимального времени цикла помогает снять проблемы со связью.

Минимальное время цикла 0, что значит столько сколько нужно для выполнения программы.

Если добавить модуль *статистик* в ПЛК конфигураторе, то там есть флаг.
Если этот флаг фключен, то ресурсов мало. Нужно в ручную увеличить время цикла.
http://s19.postimage.org/4x5oatzkv/image.jpg

Работа с syslibcom почти не требует временных ресурсов. Почти - 0.2..0.4мс с кучей проверок/перепроверок.
Этот флаг - для всего остального кода

Как бы вот все же лично мною замечено улучшение обмена.
да и вообще к примеру на S400 сколько раз смотрел время цикла в среднем 14-17мс и ничего всех устраивает. я обычно смотрю время в статистике и увеличиваю мин цикл. обычно 4-5мс .

Никакого вляния на порт время цикла не имеет
У Вас - искусственно введеные постоянные дополнительные,не требуемые стандартом модбас, задержки до/после запросов. Но они нужны только иногда из-за кривого релиза

даже при обмене с панелью при малом времени цикла может вылетать ошибка потери связи... ДА ДЕЛАЙТЕ КАК СЧИТАЕТЕ НУЖНЫМ .я просто рекомендую увеличить и проверить может и поможет.

У меня мастер - всегда ПЛК. Именно гимор с потерями связи и тп. заставил это делать. Видимо мы пошли разными путями :)
Я своим - доволен.

Цитата:

---

Сообщение от Валенок

У меня мастер - всегда ПЛК. Именно гимор с потерями связи и тп. заставил это делать. Видимо мы пошли разными путями :)
Я своим - доволен.

---

Это точно. У меня мастер всегда панель, проблем нет. Пробовал делать её слейвом. Не понравилось.

Цитата:

---

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

Если добавить модуль *статистик* в ПЛК конфигураторе, то там есть флаг.
Если этот флаг фключен, то ресурсов мало. Нужно в ручную увеличить время цикла.
http://s19.postimage.org/4x5oatzkv/image.jpg

---

"Кто в лес, кто за дровами"!

Так вот. Обратите внимание, на Вашем скрине видно, что минимальное допустимое время цикла может быть задано от "0" до "50"
Так вот я ставлю "0"? а РЭ написано:

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

Так что этот флаг у меня никогда не срабатывает.
Я ведь писал что с модулями МВ110-8АС проблем нет.

Так какая реальная задержка ответа ?

Так вот и оставьте ему время на простой.

У ИП, например, 50мс. Делать такой цикл ?

Цитата:

---

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

А время цикла ПЛК, у Вас не маловато?.
Попробуйте в следующий раз посмотреть в модуле статистике.
Очень часто увеличение минимального времени цикла помогает снять проблемы со связью.

---

Тоже так думал, да и в руководстве по программированию так написано, но сегодня обнаружил интересную вещь. Минимальное время цикла у меня было установлено 50мс, программа заливалась в контроллер очень долго, КДС в онлайне тоже еле шевелился, поставил 5мс, всё стало летать, для эксперимента установил 1мс (программа у меня выполняется за 2мс), поднялся флаг перегрузки процессора, однако "тормоза" ещё уменьшились, пинг по ethernet также уменьшился. В чем тут загвоздка?
http://www.owen.ru/forum/showthread.php?t=8791&page=3