Я привёл варианты кода, которые решают задачи управления ШД.
Есть установка, у которой предельное ускорение 10'000Гц/10сек, предельное замедление предельное ускорение 10'000Гц/20сек
1) Сделать 300 импульсов, максимальная скорость 60 Гц
2) Сделать 400 импульсов, максимальная скорость 60 Гц
3) Сделать 10 импульсов, максимальная скорость 60 Гц
4) Раскрутиться до 60 имп/сек и продолжить вращение бесконечно
5) Раскрутиться до 5000 имп/сек и продолжить вращение бесконечно
5) Просто сделать 100 импульсов на частоте 60 имп/сек.
Покажите как хотя бы первые 1-2-3 задачи будут решаться, если у ФБ будут такие аргументы, как вы предлагаете:
enable, period, quantity, accel_time, decel_time
Я к тому, что "accel_time" и "decel_time" совершенно непонятно как вычислять.
Реально, приведите пару строк, как будет выглядеть использование блока, если аргументы такие, как вы предлагаете. По факту -- аргументов "enable, period, quantity, accel_time, decel_time" недостаточно. Как минимум, нужен аргумент "какая по факту скорость достигается в конце разгона".
Последний раз редактировалось Владимир Ситников; 25.09.2016 в 23:07.
Заново подбирать время разгона для каждого значения quantity? Реально так?
Вот реально не могу понять почему вы думаете, что подбирать "время разгона/торможения" для каждого конкретного quantity это легче и проще, чем подобрать это самое время разгона/торможения один раз и потом использовать его для вообще всех значений? Например, если оказалось, что до 1000Гц без проблем разгоняемся за 5 секунд, то так и пишем: accel_time:=1000/5.
Дальше это accel_time уже не трогаем, а ставим quantity/max_speed как нужно
Поймите вы, что время разгона зависит от quantity. И отлаживать систему, в которой куча взаимосвязанных переменных тяжелее, чем отлаживать систему, где каждый параметр независим.
"слишком быстро разгоняется" -- уменьшили accel_ramp
"надо ехать подальше" -- увеличили quantity
"слишком медленно тормозит" -- увеличили decel_ramp.
Вы же предлагаете, что "пусконаладчики" каким-то мифическим образом подбирают времена.
А, если quantity потом меняется? Что? Все времена переигрывать?
Это реально каменный век.
"ускорение" действительно проще выражать в виде дроби 10'000 Гц/10 сек (по крайней мере мне)
Но в этом и прелесть, что, подобрав один раз эту дробь, можно менять остальные параметры (количество импульсов, предельную скорость) и не возвращаться к подбору "времени разгона".
Эта дробь имеет понятный смысл: за такое-то время мы достигнем такой-то скорости (если понадобится).
Если надо сделать 300 шагов за определенное время, то я прикину какая частота импульсов должна быть чтобы уложиться в заданное время. Далее буду подбирать время разгона и торможения чтобы вал ШД повернулся на заданный угол без пропуска импульсов. И так для любого количества импульсов. Задача вашего ФБ просто, без всякого думоства, исполнить то, что задано на входе.
Последний раз редактировалось Newcomer; 25.09.2016 в 23:23.
О, наконец какой-то похожий на реальность пример. "сделать 300 шагов за 6 секунд и по возможности не насиловать установку".
Над такой задачей подумать можно.
Над временем ускорения/замедления -- нет.
Если хочется -- выбивайте из ОВЕН признания Hardella и делайте свой блок.
Я тов. Филоненко сказал "нет, невозможно пользоваться ОВЕНовским инструментарием", так и вам говорю: "нет, время разгона/торможения делать не буду, т.к. алгоритм делать неудобно и пользоваться тоже неудобно будет".
Невозможно реализовать то, что вы хотите.
Импульсы дискретные по своей сути.
Частота импульсов не может меняться "произвольно".
Импульс либо есть либо его нет.
Вот пример:
10 импульсов, accel_ramp = 10000/10, decel_ramp = 10000/20, max_speed=60
10pulses_1000_500_60.png
Вот реально, чему равно "время замедления" и "время ускорения" в этом случае?
Я "скорость" на графике строю как "1/интервал_между_импульсами". Можно долго обсуждать правильно ли это, но это лишь дополняет мутность самого вопроса "длительность разгона"