Минимальное время цикла работы ПЛК

[Валенок]

Где там в Т2.2 про 2.1мс ? Можно, конечно, тешить себя что не более 25 это и 0 (ноль) тоже. Как и -1.

Сам процесс считывания данных массы на входе и статуса прибора занимает 3,75 мс.

Вы серъезно так считаете ? Это случай связи устройств с временем цикла обоих стремящихся к нулю. А учли квантование времени в ПЛК, квантование времени в слейве ? Даже не выходя из цикла ПЛК - в лучшем случае 6-7мс. Причем все равно 115.2 или 38.4. Время тут ест не обмен, а квантование и временные маркеры конца пакетов.
Минимальное время цикла и контроль изменений. Изменения и есть - опа.

[Титаренко Михаил]

Больше 10 мс - будет затык. Самое неприятное, когда на действующем оборудовании CodeSys с ошибкой "вылетит". Связь рвётся и приходится к шкаПчику бежать - проверять: не повис ли и ПЛК заодно.

[sea]

Где там в Т2.2 про 2.1мс ? Можно, конечно, тешить себя что не более 25 это и 0 (ноль) тоже. Как и -1.

Да, на сайте открыл РЭ (re_mv110-224.td_1404.pdf), в нем как Вы указали.
У меня на HDD другая версия РЭ (rie_mv110-224.td_1118.pdf) и с прибором тоже она была:
http://www.owen.ru/uploads/rie_mv110-224.td_1118.pdf
И частоту дискретизации можно изменить в приборе.

[sea]

Вы серъезно так считаете ? Это случай связи устройств с временем цикла обоих стремящихся к нулю. А учли квантование времени в ПЛК, квантование времени в слейве ? Даже не выходя из цикла ПЛК - в лучшем случае 6-7мс. Причем все равно 115.2 или 38.4. Время тут ест не обмен, а квантование и временные маркеры конца пакетов.

Рассчитал минимальное время передачи бит в канале без задержек (от чего-то нужно было отталкиваться), "запрос - ответ".
REAL - 226 бит, 1,96 мс;
WORD - 206 бит, 1,79 мс.
Начало и конец пакета для RTU приняты по 14 бит.

[Валенок]

REAL - 226 бит, 1,96 мс ..WORD - 206 бит, 1,79 мс

Стартовый бит может не идти сразу за стоповым

Начало и конец пакета для RTU приняты по 14 бит.

Читаем например википедию

Слейв имеет цикл. Нужно быть уверенным что отправив в порт из мастера :
1.Данные пошли сию мксекунду
2.Прям в момент прихода последнего бита от мастера стартовал цикл слейва чтоб в очередной раз включить таймер для отслеживания маркера -ведь уже может быть задержка.
Но:
3.Цикл слейва не будет кратен маркеру - придется выдержать округленное вверх время маркера
4.Слейву нужно тупо время для подготовки данных расчета crc
5.Слейв может тупо позаниматся другой задачей
6.Слейв стал посылать данные в ответ
7-8. см. 2-3, но квантуется цикл мастера
9.Проверка данных с выкладыванием в область обмена займет время
10. Вот они - данные

Набегает в общем в отличие от теории

[sea]

Стартовый бит может не идти сразу за стоповым

Читаем например википедию

Слейв имеет цикл. Нужно быть уверенным что отправив в порт из мастера :
1.Данные пошли сию мксекунду
2.Прям в момент прихода последнего бита от мастера стартовал цикл слейва чтоб в очередной раз включить таймер для отслеживания маркера -ведь уже может быть задержка.
Но:
3.Цикл слейва не будет кратен маркеру - придется выдержать округленное вверх время маркера
4.Слейву нужно тупо время для подготовки данных расчета crc
5.Слейв может тупо позаниматся другой задачей
6.Слейв стал посылать данные в ответ
7-8. см. 2-3, но квантуется цикл мастера
9.Проверка данных с выкладыванием в область обмена займет время
10. Вот они - данные

Набегает в общем в отличие от теории

Это понятно. Конечно, еще есть задержки по времени передачи данных. Я рассчитал минимальное время обмена данными, чтобы хоть ориентировочно можно было от него отталкиваться...
Да и смотря какой слейв.

От темы мы отошли. А решение по установки МинВЦ ПЛК уже указано постами выше:
- МинВЦ ПЛК устанавливаем 0 мс;
- через Конфигуратор задач запускаем программу с требуемым интервалом (если требуется). Данный интервал принимает больше среднего времени цикла ПЛК.
В этом случае и сетевой обмен не тормозит и программа выполняется через заданный интервал.

[Валенок]

Работает ? Вот и славненько

[Дмитрий Артюховский]

"От темы мы отошли. А решение по установки МинВЦ ПЛК уже указано постами выше:
- МинВЦ ПЛК устанавливаем 0 мс;
- через Конфигуратор задач запускаем программу с требуемым интервалом (если требуется). Данный интервал принимает больше среднего времени цикла ПЛК.
В этом случае и сетевой обмен не тормозит и программа выполняется через заданный интервал."

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

нормальное состояние это когда ритмично выполняется цикл ПЛК в котором прогоняется программа пользователя, затем служебные задания (обмены), затем временная пауза для выравнивания времени. В этом случае основной код выполняется со стабильной частотой дискретизации, происходят регулярные, стабильные во времени, вызовы фоновых процедур. Предлагаемая вами схема подразумевает довольно значительное время выполнения цикла основного кода, в это время не будет обработки фоновых обменов, и возможны потери из-за переполнения буферов и из-за превышения таймингов запросов - ответов протокола обмена. Зато, во время нулевых циклов, когда основной код не выполняется, будут только суматошные вызовы фоновых процедур по контролю пустых буферов обмена ))) Кроме того, на фоновые обмены отводится время между окончанием цикла пользователя и очередным таймерным отсчетом.... а если этот таймер не настроен будет??? (нулевое время цикла) то сколько времени будет отведено на фоновые процедуры???

[sea]

"От темы мы отошли. А решение по установки МинВЦ ПЛК уже указано постами выше:
- МинВЦ ПЛК устанавливаем 0 мс;
- через Конфигуратор задач запускаем программу с требуемым интервалом (если требуется). Данный интервал принимает больше среднего времени цикла ПЛК.
В этом случае и сетевой обмен не тормозит и программа выполняется через заданный интервал."

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

нормальное состояние это когда ритмично выполняется цикл ПЛК в котором прогоняется программа пользователя, затем служебные задания (обмены), затем временная пауза для выравнивания времени. В этом случае основной код выполняется со стабильной частотой дискретизации, происходят регулярные, стабильные во времени, вызовы фоновых процедур. Предлагаемая вами схема подразумевает довольно значительное время выполнения цикла основного кода, в это время не будет обработки фоновых обменов, и возможны потери из-за переполнения буферов и из-за превышения таймингов запросов - ответов протокола обмена. Зато, во время нулевых циклов, когда основной код не выполняется, будут только суматошные вызовы фоновых процедур по контролю пустых буферов обмена ))) Кроме того, на фоновые обмены отводится время между окончанием цикла пользователя и очередным таймерным отсчетом.... а если этот таймер не настроен будет??? (нулевое время цикла) то сколько времени будет отведено на фоновые процедуры???

А что Вы предложите?

Эту тему:
http://www.owen.ru/forum/showthread.php?t=14379
просматривали?

[Дмитрий Артюховский]

Все эти темы поднимаются в основном "продвинутыми" электриками, которым нужно датчик по порту подключить ))) Нет понимания главного... ПЛК придуманы не три лампочки включать - для этого есть реле, а для создания автоматизированных систем управления. А в них основная мысль в применении законов управления, есть наука такая - ТАУ, пропорциональные, интегральные, дифференциальные звенья, законы управления и пр. На контроллерах реализуется ее дискретное изложение. А для его реализации абсолютно необходима стабильная частота дискретизации взятия отсчетов и воздействий. При не выдерживании времени, и в частном случае при установки нулевого времени, цикла, закон управления, со всей своей мудреной математикой летит к чертям собачьим и система запросто сваливается, например в автоколебания ))))

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