Шаговый двигатель

[eugeneb]

Для наглядности отдельно построим начальную и среднюю части последнего графика:

СпойлерПоказать

1960702.png (9.52 КБ) 1577 просмотров

[/url]

СпойлерПоказать

9871327.png (10.49 КБ) 1577 просмотров

[/url]

Мы видим, что на самых ответственных местах - разгона и торможения -
требуемое задание для генератора совсем нелинейное.

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

И вас, коллега, не минула чаша сия.

Если внимательно посмотреть на ваше видео, можно видеть, что ШД
разгоняется и тормозит нелинейно.

Кстати, обратите внимание, график не предполагает никакой ступенчатости.
Ваш же алгоритм уже в себе содержит ступенчатость. Ещё не доходя
до "природы ступенчатости" ШД

Поэтому я и спрашивал вас, как вы получили свой график.
Дело в том, что ступеньки-то там должны быть (такой уж алгоритм),
а вот форма трендов на подъёме и спуске вызвала у меня сомнения.

Вернёмся. Ступенчатость в нашем задании появится на этапе, когда мы начнём
генерировать это задание для генератора ФЛПрог. И она будет связана
не с алгоритмом, а с небольшим быстродействием младших Ардуин. Чем тяжелее будет
вся управляющая программа, тем сильнее будет проявляться ступенчатость задания.
То есть ступенька (на самом деле, задержка в выдаче задания) будет появляться
при каждом цикле УП. А длительность цикла зависит от тяжести УП.
Надеюсь найти здесь какой-то баланс.

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

И вот мы подошли к получению текущего времени. Без него - никуда...
Ваше последнее предложение как раз об этом.
Я примерно также и вижу его получение.
Мне хотелось бы получить не 200-микросекундные интервалы, а хотя бы 50 мкс.
А лучше 10 мкс. А ещё лучше - получить доступ к системным часам. 
Интересно, это возможно в FLProg?

Я как раз ломаю голову над тем, что будет, если длительность цикла УП
превысит длительность периода генератора. Что будет у него на выходе?
Как вообще измерить длительность цикла УП?

Добавлено (20.12.2017, 14:31)
---------------------------------------------

На выходе мы получаем импульсы, следующие с частотой – 100 микросекунд.

Уж извините, коллега, меня это коробит. Вещи надо называть своими именами.
Мы же, типа, специалисты

[vacz]

Да, похоже , проблема существует. Есть над чем подумать.

Чем тяжелее будет
вся управляющая программа, тем сильнее будет проявляться ступенчатость задания.
То есть ступенька (на самом деле, задержка в выдаче задания) будет появляться
при каждом цикле УП. А длительность цикла зависит от тяжести УП.
Надеюсь найти здесь какой-то баланс.
что будет, если длительность цикла УП
превысит длительность периода генератора. Что будет у него на выходе?

В МК все операции выполняются последовательно в одном программном цикле. Чем больше операций, тем они медленнее, тем больше длительность программного цикла. Я как то, сталкивался с такой проблемой. Длительность цикла УП превышала длительность периода генератора, и ШД терял обороты. Чтобы обойти такие ситуации есть возможность выполнять некоторые операции параллельно основному программному циклу, выполнение функций по прерыванию по таймеру. В теме, Слимпер , здорово помог, создав блоки по прерыванию, работающие независимо от программного цикла. В одном блоке один генератор, во втором блоке четыре независимых друг от друга генератора. Надо будет пощупать их на предмет использования их в проекте. Получить доступ к системным часам, наверно вряд ли получится.
На счет моей ошибки, прошу извинить. Поторопился поделиться возникшей идеей, насчет получения времени, не проанализировав тщательно. Но, как говорят: «Не ошибается тот, кто ничего не делает».

[eugeneb]

Дорогой vacz!

Рад, что мы пришли к согласию!
Я подготовлю более подробное разъяснение этого вопроса 
уже для остальных форумчан.
Это может быть полезно людям.

[vacz]

В генераторах ФЛПрог нет такого параметра как частота. В качестве
задания на них надо подавать период (точнее полупериод) желаемой частоты.

Зависимость задания периода от времени выглядит так:


Так как нам для управления генератором нужно задавать
полупериод в милисекундах или в микросекундах, модифицируем
эту формулу так:

Можно ли выложить ссылку, откуда взяты эти формулы? Возникли некоторые вопросы, хочу посмотреть.

[Nikan]

.

[eugeneb]

Можно ли выложить ссылку, откуда взяты эти формулы?

Выведем эту формулу сами.
Скорость из школьного курса физики, раздел кинематики, второе уравнение движения
(6 класс по советскому летоисчислению, сейчас не знаю): 

Здесь А - ускорение.
В нашем случае начальная скорость равна нулю. 
В применении к шаговому двигателю скорость заменяем частотой
импульсов (имп/с). Соответственно ускорение будет в единицах (имп/с²). 

Наша формула приобретает вид: 

Частота со своим собственным периодом связана выражением: 

Заменяем частоту в нашей формуле: 

Выражаем Т: 

Вот, собственно.
Ссылки тоже можно найти. Сейчас поищу...

Добавлено (21.12.2017, 15:20)
---------------------------------------------
Вот зачётная статья по шаговым двигателям. Очень полная. Кто-то на форуме
уже давал на неё ссылку.

https://darxton.ru/wiki-article/kontrol ... vigatelya/

В ней, в разделе "Разогнать!" тоже приведена эта формула.
Только в нашем случае T₀=0

[vacz]

Вопросов к первой формуле у меня нет. Вопрос ко второй формуле:

Так как нам для управления генератором нужно задавать
полупериод в милисекундах или в микросекундах, модифицируем
эту формулу так:

Давайте проведем проверочные арифметические действия. Выразим t- константой (например-10); А - константой (например- 100). Произведем расчет по первой формуле.
Затем произведем проверочные арифметические действия со второй формулой в миписекундах. Затем в микросекундах. Сравним получившиеся три результата. Что получится у Вас? Возникнут ли вопросы?

[eugeneb]

Я что-то не вкурю в чём вопрос.
Все три формулы - это одна и та же формула,
только в разных масштабах. Допустим по вашему заданию:
t=10 (мс) = 10*10^-3 (с)
A=100 (имп/c²)

1. Первая формула исходная - вычисляет период требуемой частоты импульсов в единицах Си:

T=1/(At)= 1/(100(имп/с²)*10*10^-3(с)) = 1 (с)

То есть, через 10 мс от начала работы период импульсной последовательности должен быть 1 с.

2. Вторая формула (*1000/2) - это уже полупериод (потому
что разделили на два) в милисекундах (потому что умножили на 1000):

T=1000/(2At)=1000/(2*100(имп/с²)*10*10^-3(с)) = 500 (мс)

То есть, через 10 мс полупериод импульсной последовательности должен быть 500 мс = 0,5 с. Период,
стало быть - 1 с.

3. Третья формула не приводилась, но подразумевалась.
Результат - тоже полупериод, но в микросекундах:

T=1000000/(2At)=10⁶/(2*100(имп/с²)*10*10^-3(с)) = 5*10⁵(мкс)

То есть, через 10 мс полупериод импульсной последовательности должен быть 500000 мкс = 0,5 с. Период - 1 с.

Все три результата совпали.

Давайте возьмём время t=10 c.

По второй формуле:

T=1000/(2At)=1000/(2*100*10)=0.5 (мс)

То есть, через 10 секунд задание полупериода должно
быть 0,5 мс, что означает, что генератор выдаст импульсы с частотой 1 кГц.

А-а, я понял откуда путаница...
В первой и второй формулах буква Т означает разные
величины: в первой - период, а во второй - полупериод.

Строго говоря, вторую формулу надо записать так:

T/2=1000/(2At)

Но, это не отменяет приведённых мною вычислений.

[vacz]

Наверно, для модифицирования в милисекунды и микросекунды выглядеть формулы должны так: Тмс/2=10³(1/(2Аt)) и Tмкс/2=10⁶(1/(2Аt)) Не трогая константу 1 (время одного периода). Для проекта правильней будет использовать формулу в микросекундах :

Но эта формула применительна к периоду колебаний (Т) - время одного полного колебания. Ее еще придется дорабатывать с учетом зависимости длительности шага от времени разгона: начальной скоростью, скоростью в конце некоторого промежутка времени и разность между ними.

[eugeneb]

Да, вы привели правильные формулы. Но должен кое-что пояснить.
10³ и 10³*1 - это одно и тоже математически. А физического смысла тут нет. И 10³ и 1 - величины безразмерные. Это просто множители.

Умножая результат (Т) в секундах на множитель 1000, мы получаем тоже время, но в милисекундах. Умножая
на 10⁶ - соответственно в микросекундах. Это просто вопрос масштаба и удобства. Действительно, на моих скоростях удобнее оперировать микросекундами.

Не трогая константу 1 (время одного периода)

Это не константа и не время. Это просто числовой множитель. Время одного периода (или полупериода) мы как раз вычисляем. Оно слева. Это Т (или Т/2). Оно меняется непрерывно с течением времени t. (кроме, конечно времени t=0  . Это запрещённая точка). Меняется  по закону гиперболы, чтобы получившаяся частота импульсов менялась линейно.

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

Нет, это конечная формула. В любой момент времени t вы  получаете текущее мгновенное значение полупериода Т/2, которое сразу можно подавать на вход генератора. Если программа лёгкая, вы будете делать это чаще. Если программа тяжёлая - реже. Но каждый раз это будет точная текущая мгновенная величина полупериода.

Генератор работает на одном задании, пока не получит следущее. На интервале между заданиями скорость (частота генерируемых импульсов) не меняется. Вот так и появляется ступенчатость трапеции. Бороться с этим можно только увеличивая частоту смены заданий генератора, то есть облегчая программу.

А скорость роста скорости ( тавтология, однако) задаётся константой А. Это ускорение. Оно постоянно на интервале времени от нуля до точки перехода графика скорости (трапеции) на горизонтальный участок. Геометрически, А - это тангенс угла наклонного участка к оси t.

А вот если есть начальная скорость в начале трапеции, то да, формула заметно усложнится. Но это не мой случай.

[vacz]

А вот если есть начальная скорость в начале трапеции, то да, формула заметно усложнится. Но это не мой случай.

Из Ваших сообщений:

варианта блока, который строит "трапецию" скорости?
То есть учитывается ещё один параметр - ускорение/замедление(имп/с^2),
а параметр Speed является ограничением сверху.

нарисовалась задача линейно разогнать и линейно
остановить ШД за одну секунду при общем количестве импульсов от 1500 до 3000 .

Я почему то понял так, что Вы хотите начать разгон с начальной скоростью - 1500 и линейно разогнать до 3000. Затем , с начальной скоростью -3000, начать линейно останавливать. В таком варианте потребуется ни одна, а даже две начальные величины. Одна -1500(начальная величина), при начале разгона. Вторая -3000(начальная величина), при начале торможения.
Но, наверно я не правильно Вас понял.

[eugeneb]

А, да, я тут только запутал всех. Если интересно, могу чуть подробнее рассказать.

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

Во-первых, нужно это делать быстро, в идеале за одну секунду. 

Во-вторых, из-за большого момента инерции на валу мне чуть-чуть не хватает крутящего момента на старте/останове.
Ошибка проектирования  

ШД пропускает шаги, теряет синхронизацию и механизм безнадёжно опаздывает.

Ставить доп редуктор заказчик не хочет - это опять деньги, переделка, время. Да и я боюсь, что безнадёжно увеличится число шагов, которое надо будет дать за одну секунду. 

Вот я и заморочился с плавным разгоном/торможением. А из-за этого требуемая максимальная частота импульсов (высота трапеции) ещё увеличивается. 

Драйвер у меня Leadshine M542
Опытным путём установил, что лучше всего мотор тянет на микрошаге 8 или 16, а это как раз 1600 или 3200 имп/оборот. И я ещё не выбрал, на каком микрошаге буду работать.

Программа управления сама по себе довольно тяжёлая и я сижу на границе быстродействия Меги.

Добавлено (23.12.2017, 21:18)
---------------------------------------------

в аурдине используется для подсчета времени - функция микрос и миллис,

Эти функции вполне подошли бы мне в качестве системного времени.

что собственно и сделал Слимпер в блоках для шагового двигателя.

Обязательно посмотрю, как он до них добрался.

[Nikan]

.

[vacz]

Программа управления сама по себе довольно тяжёлая

Мне, в своем станочке, пришлось вынести генераторы ШД на отдельную Nano328. Соединив их через UART. Хоть как то минимизировать зависимость от программного цикла общей программы.

[eugeneb]

Разглядел устройство блока Generator2 Слимпера. Он там не пользуется функциями millis() и micros(). 

надо использовать системные таймеры -

Вот он примерно так и делает. Он заводит системный таймер на некую частоту (по умолчанию 5 кГц), а потом, через прерывания от этого таймера, программными делителями получает нужные частоты меньшей величины.

Не совсем то что я хотел. Не хотелось связываться с аппаратными таймерами и прерываниями. 

Но разглядывание блока Слимпера навело меня на нехорошие мысли. В том смысле, что я где-то лажанулся в своих рассуждениях. Сказывается недостаток практики.

В общем, мой пост №50 в части конечности формулы считать ошибочным. Ушёл в раздумья и эксперименты. До следующего года. 

Мне, в своем станочке, пришлось вынести генераторы ШД на отдельную Nano328. Соединив их через UART. Хоть как то минимизировать зависимость от программного цикла общей программы.

Удивительно, как одинаково мы мыслим!

Этот вариант я держу на крайняк, если не получится по простому. Я возьму отдельную Нанку, загружу на неё проект GRBL и буду через UART подавать на неё команды в G-коде. GRBL может выдавать частоты STEP до 30 кГц. При этом с любым разгоном и торможением.

[Fix]

Может кому интересно, очень познавательное видео по настройке драйверов шаговых двигателей A4988   
_uVideoPlayer({'url':'');

[eugeneb]

В общем, мой пост №50 в части конечности формулы считать ошибочным. Ушёл в раздумья и эксперименты. До следующего года. 
vacz писал(а):
Мне, в своем станочке, пришлось вынести генераторы ШД на отдельную Nano328. Соединив их через UART. Хоть как то минимизировать зависимость от программного цикла общей программы.
Удивительно, как одинаково мы мыслим!

Этот вариант я держу на крайняк, если не получится по простому. Я возьму отдельную Нанку, загружу на неё проект GRBL и буду через UART подавать на неё команды в G-коде. GRBL может выдавать частоты STEP до 30 кГц. При этом с любым разгоном и торможением.

В общем, уважаемый vacz, так оно и вышло. В новогодние каникулы запускал этот двигатель в реале.
Вся наша теория разгона ШД к FLProg не применима. Математически она правильная. Но контроллер с моей программой на FLProg не может программно сгенерировать импульсы с частотой более 400 Гц. И при этом уже даже скважность искажается - с 50% становится 80%.
А мне надо 3000 Гц.
А на 400 Гц и разгон не нужен - можно сразу их подавать, со старта.

Так что только внешним генератором. Сделал на GRBL. Отлично получилось.

[magpit]

Создал для Вас блок управления ШД. С возможностью установки  количества шагов и скорости. После запуска ШД выполнит заданное количество шагов и отключится. С установленной скоростью. Блок не подходит для совместной работы ШД с блоком "Дисплея" (экран). Для этого нужен блок на прерываниях блок с прерываниемна1 и на 4 ШД на 4 двигателя
Вложения
HD-step-dir-FBD.ubi
(131.27 КБ) 72 скачивания

Блок создаёт сбой в программе и программа вылетает. Не могли бы вы обновить блок?

СпойлерПоказать

error.log

(15.16 КБ) 65 скачиваний

Заменил обратные связи на переменные всё равно вылетает

[vacz]

Проблема в том, что автором был изменен блок счетчика CTU. Заменил на новый счетчик. Пробуйте.

HD-step-dir-p_(FBD).ubi

(147.25 КБ) 134 скачивания

[magpit]

Проблема в том, что автором был изменен блок счетчика CTU. Заменил на новый счетчик. Пробуйте.

Что то не работает...