Программирование ПЛК110 [М02] для задач реального времени

[Владимир Ситников]

Будут тупо подбирать время разгона/торможения.

Заново подбирать время разгона для каждого значения quantity? Реально так?

Никто на практике не будет вычислять предельное ускорение установки и время разгона/торможения. Пусконаладкой не профессора занимаются. Будут тупо подбирать время разгона/торможения.

Вот реально не могу понять почему вы думаете, что подбирать "время разгона/торможения" для каждого конкретного quantity это легче и проще, чем подобрать это самое время разгона/торможения один раз и потом использовать его для вообще всех значений? Например, если оказалось, что до 1000Гц без проблем разгоняемся за 5 секунд, то так и пишем: accel_time:=1000/5.
Дальше это accel_time уже не трогаем, а ставим quantity/max_speed как нужно

Поймите вы, что время разгона зависит от quantity. И отлаживать систему, в которой куча взаимосвязанных переменных тяжелее, чем отлаживать систему, где каждый параметр независим.
"слишком быстро разгоняется" -- уменьшили accel_ramp
"надо ехать подальше" -- увеличили quantity
"слишком медленно тормозит" -- увеличили decel_ramp.


Вы же предлагаете, что "пусконаладчики" каким-то мифическим образом подбирают времена.
А, если quantity потом меняется? Что? Все времена переигрывать?
Это реально каменный век.


"ускорение" действительно проще выражать в виде дроби 10'000 Гц/10 сек (по крайней мере мне)
Но в этом и прелесть, что, подобрав один раз эту дробь, можно менять остальные параметры (количество импульсов, предельную скорость) и не возвращаться к подбору "времени разгона".
Эта дробь имеет понятный смысл: за такое-то время мы достигнем такой-то скорости (если понадобится).

[Владимир Ситников]

Если надо сделать 300 шагов за определенное время

О, наконец какой-то похожий на реальность пример. "сделать 300 шагов за 6 секунд и по возможности не насиловать установку".
Над такой задачей подумать можно.
Над временем ускорения/замедления -- нет.

Если хочется -- выбивайте из ОВЕН признания Hardella и делайте свой блок.

Я тов. Филоненко сказал "нет, невозможно пользоваться ОВЕНовским инструментарием", так и вам говорю: "нет, время разгона/торможения делать не буду, т.к. алгоритм делать неудобно и пользоваться тоже неудобно будет".

Если надо сделать 300 шагов за определенное время, то я прикину какая частота импульсов должна быть чтобы уложиться в заданное время. Далее буду подбирать время разгона и торможения чтобы вал ШД повернулся на заданный угол без пропуска импульсов. И так для любого количества импульсов. Задача вашего ФБ просто исполнить то, что задано на входе.

Невозможно реализовать то, что вы хотите.
Импульсы дискретные по своей сути.
Частота импульсов не может меняться "произвольно".

Импульс либо есть либо его нет.


Вот пример:
10 импульсов, accel_ramp = 10000/10, decel_ramp = 10000/20, max_speed=60
10pulses_1000_500_60.png

Вот реально, чему равно "время замедления" и "время ускорения" в этом случае?
Я "скорость" на графике строю как "1/интервал_между_импульсами". Можно долго обсуждать правильно ли это, но это лишь дополняет мутность самого вопроса "длительность разгона"

[Newcomer]

Предельное (минимальное) время разгона ШД от quantity не зависит, а зависит от инерционности системы. После того, как я опытным путем определю предельное время разгона, то я везде и буду подставлять его в качестве формального параметра ФБ.

В который раз повторяю можно выполнить деление 10'000 Гц/10 сек на входе блока, а можно это сделать внутри блока, но результат на выходе блока от этого не изменится.

[Владимир Ситников]

Предельное (минимальное) время разгона ШД от quantity не зависит, а зависит от инерционности системы.

Зависит.
Вот картинка для случая "10 импульсов, 20 импульсов и 100 импульсов":
move_100_50_60.png

Видно, что фактическое время разгона и замедления зависит от quantity.

В который раз повторяю можно выполнить деление 10'000 Гц/10 сек на входе блока, а можно это сделать внутри блока, но результат на выходе блока от этого не изменится.

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

[rovki]

И почему в ПЧВ задают время разгона и торможения ,а не количество периодов меняющейся частоты интересно????

[Newcomer]

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

Очень просто все выглядит. Подаю на вход ФБ время разгона, предельную частоту и количество импульсов. Вы в ФБ делите предельную частоту на время разгона, получаете свое любимое ускорение и делаете с ним все что надо.

Предельное время разгона ШД для конкретной механической системы я однажды определяю опытным путем .

[Владимир Ситников]

Очень просто все выглядит. Подаю на вход ФБ время разгона, предельную частоту и количество импульсов. Вы в ФБ делите предельную частоту на время разгона, получаете свое любимое ускорение и делаете с ним все что надо.

А как понять "достигается ли эта самая предельная частота"?

Посмотрите на красные и зелёные точки на графике (10 и 20 импульсов). При малых quantity предельная частота не достигается

[Newcomer]

А как понять "достигается ли эта самая предельная частота"?

Посмотрите на красные и зелёные точки на графике (10 и 20 импульсов). При малых quantity предельная частота не достигается

Если при заданном предельном времени разгона заданную частоту достичь не возможно значит ШД для данной механической системы выбран не верно, либо сама механическая система спроектирована не верно.

[Newcomer]

Владимир, ответьте на простой вопрос. Измениться ли результат на выходе ФБ если в одном случае выполнить деление
10'000 Гц/10 сек на входе блока, а во втором случае сделать это деление внутри блока ?

[Владимир Ситников]

Владимир, ответьте на простой вопрос. Измениться ли результат на выходе ФБ если в одном случае выполнить деление
10'000 Гц/10 сек на входе блока, а во втором случае сделать это деление внутри блока ?

Скажите начала что значит period в вашем варианте параметров
В моём варианте у каждого параметра есть понятный смысл, и параметры accel_ramp, decel_ramp, max_speed являются параметрами конкретной установки.
Т.е. фактичеки, я предлагаю блок, у которого задавать нужно только quantity.

Вы же почему-то упорно хотите заниматься подбором параметров и передавать лишние/недостающие данные.
Зачем -- понять не могу.


Слова "ШД выбран неправильно", конечно, говорить можно, но юстировку и т.п. никто не отменял. Я не хочу добавлять в блок искусственные ограничения на диапазон допустимых quantity. Вариант "блок работает, но quantity меньше 100 не передавать" будет звучать крайне странно.