По всей видимости, о магическом минимальном времени цикла не знает никто).По всей видимости этот параметр, кроме того что можно делать таймеры k:=k+1; if k>10 then ... , оно влияет на сетевой обмен(замедляет его)))). Т.е как я понял если я ставлю минимально время цикла 50мс, время цикла программы 30ми(допустим а не 20%...) остается 20мс для сетевого обмена. А вот если задачей вызывать программу раз в 50мс то сетевой обмен будет идти раз в 1мс если минимальное время цикла стоит 1мс. Если я не прав поправьте. Или это какой то особый вид работы плк). Кстати если поставить мин. время 50мс то можно ждать пока программа загрузится в плк вечно.Лучше уж тогда задачами вызывать раз в 50мс и мин время задать 0, хоть плк не тупит во время наладки(долгой загрузкой). Вот не знаю как правильно, может кто нибудь подскажет.
да разве в измерениях не борются за точность, чем меньше деление тем выше точность и меньше погрешность. Так же и здесь, манипулятор перекладывающий яйца, во первых может промахнутся беря предмет, во вторых во время не остановившись может сломать захваченый объект это при условии что задали большое время цикла
Уважаемый, я подчеркиваю, что использование столь грубого инструмента, как МинВЦ, для формирования каких-либо задержек, управляющих поведением ПЛК, - считаю плохим тоном.
Тем более, что инструмент этот работает непонятно как, документирован куцо, поясняется немногословно.
Если бы я делал манипулятор, работающий с яйцами (о, ужос!), то все временнЫе промежутки формировал бы с использованием системного времени и всяких там TON-ов и TOF-ов.
Поэтому подвожу итог на сегодня: не вижу смысла в каких-либо значениях МинВЦ, кроме нулевого. Был бы рад ошибаться.
ненулевое время нужно, чтоб выполнилась сама программа, после окончания минимального выполнение будет идти в перемежку с прерываниями на коммутации связи, как то так
"Не верю"
Раньше об этом как-то и не думал, поэтому сейчас лишь догадки, не подтвержденные никакими экспериментами. Но я все более склоняюсь к мысли, что МинВЦ придумано именно для вот таких незамысловатых способов организации "размеренной поступи Командора": поставил 100 мс, знаешь наверное, что РеалВЦ составляет единицы миллисекунд, а потом проц просто стоит, насвистывая. И тогда да, удобно знать, что через 100 мс выполнится следующий цикл, в котором ПЛК оживет.
То есть, это для систем, в которых ПЛК, даже со своим МинВЦ в сотню миллисекунд, является самым шустрым в системе. Все остальные процессы относительно вялотекущие. Тогда барабанная дробь по 100 мс является хорошим метрономом.
Резюме для меня: МинВЦ = 0. Это мой случай. Баста.
слишком уверены. А предположим когда наступает форс-мажорное событие и включается обработчик который по времени выйдет за рамки ста миллисекунд, Ваша стройная система будет нарушена
Ха. И еще раз "ха"
Да я просто олицетворяю скромность, неужто не видно?
Возражу двукратно:
1) Моя система не будет нарушена, ибо я решил, до реабилитации МинВЦ его забить на ноль. Так что речь может идти лишь о некоей условной системе, для которой я тщусь придумать использзование столь нашумевшего МинВЦ.
2) Если бы я реализовывал вот эту самую систему с метрономом из МинВЦ, то я бы, конечно же, поставил такое время, которое заведомо больше любого РеалВЦ. Что такое отработчик события? Всего лишь кусок кода. Он не может длиться вечность
Кроме того, какое-то "форс-мажорное" событие наверное заставит нас забыть о спокойной и размеренной жизни под звуки метронома. Тут уж пролет одного-двух циклов и не заметит никто.
Так что система стройная и логичная, по-своему. Дайте же, наконец, МинВЦ шанс остаться в деле!
ОВЕН же не скажет, мол, да, ребята, заложили на всяк случ. Видели где-то у кого-то, толком сами не знаем, что с ним делать, но выглядит солидно: МинВЦ, МаксВЦ, все дела...