Правя си тука една програмка (алгоритъм) за управление на стъпкови мотори.
Чат пат нещата се получават, но ме гложди следния въпрос:
Има ли смисъл за положително и отрицателно ускорение да могат да се задават различни стойности?

Зависи от конкретната система. Например в Мач3 се задава ускорение и забавяне на двигателите.
Не знам доколко е общовалидно, но от скромния ми опит, задаване на такива параметри И в серво-драйва носят единствено проблеми.
Та, ако управлението ще е директно - има смисъл. Ако в системата има моушън контролер, това е негова грижа.

Не става въпрос тези ускорения да се задават в драйвера.
Нека използвам твоя термин - моушън контролер.
Опитвам се да реализирам необходимата логика в моушън контролера.
В Mach-3 двете стойности (почти съм сигурен) са еднакви. Не се задават отделно.

Ами ако гороим за моушън контролери мога да си представя случаи в които има смисъл на теория, на практика може би няма. Смисъл може да има ако имаш движение синхронизирано със шпиндел примерно, ако имаш опция константна скорост на рязане и следваш сложен профил .. на практика това едва ли би повлияло на резултата.

В мач 3 стойностите са еднакви, но при други контролери не са.
А при серво драйверите акселерация и деселерация са отделни параметри. Не знам доколко е общовалидно, но е така при тия "серва" с които съм работил.

Всичко зависи от товара. Примерно за термопринтерите всеки производител дава една таблична с примерни стъпки. Тръгва се винаги от първата (тая с най-голямо време) и при ускорение може да скачаш да кажем с 3 реда в таблицата. А при спиране да кажем с 5 реда. Това е така защото двигателя тегли хартия и тя има триене. То ти дава възможност да спираш по-бързо, отколкото можеш да ускоряваш.
Сега при цнц дали има чак такова триене не знам. Ако е минимално и товарът е чисто инерционен няма смисъл може би. Но ако ще променяш обороти по време на фрезоване ще има смисъл.

Ако не правиш моушън контролер само за един конкретен стъпков мотор ( с определена тежест на ротора ),
който да движи един тип гиъртрейн на една конкретна машина, а да движи повечко (с различна тежест и инерция неща),
тогава трябва да може да се задава ускорение, с повечко стойности и да се променя динамично по време на движение.

Отново опираме до конкретното решение. Преди година или две смених двигателя на шпиндела на стругчето с AC-серво мотор и съответния драйвер.
Настройките по подразбиране бяха 50 ms за 1000 оборота за ускорение и забавяне.
При "гол двигател" е много ефектно - визуално двигателят е спрял и след едно мигване време се върти с 2000 оборота. Същото и при спиране.
Обаче в реалния свят той задвижва някакви колела, ремъци, шпиндел, универсал и детайл. И сумарната подвижна маса става доста. Тогава тая "зрелищна" настройка от 1000 rpm / 50 ms става неподходяща. Усилията стават големи, ремъците приплъзват и т.н.
И ако при ускорение лимитиращ фактор се явява лимитът на въртящия момент, то при забавяне се явява енергията генерирана от двигателя, която трябва да разсее от драйвера или товарния (спирачния) му резистор.
И т.н...

А при стъпковите двигатели всичко е значително по-зле.

Благодаря за мненията!
За сега реших да не си усложнявам живота и ще оставя за тръгване и спиране да се задават еднакви стойности.

Доста съм човъркал по темата за ускоренията и ето до какви изводи съм достигнал (ако на някой му е интересно).
Във формулата за изчисление на n-тия импулс участва корен квадратен, от където идват и основните трудности.
От тук има три начина за работа:

1. Директно изчисление на квадратния корен въпреки бавното изпълнение.
Аз се спрях на този вариант защото:
Вече има доста пъргави 32b MCU с хардуерно FPU на съвсем приемливи цени.
Аз например работя с STM32H7xx
Коренът се смята за 60-70nS. Общата дължина за обработка на прекъсването е окол 150nS.
Тук даже има и бонус, защото можем да метнем корена към FPU и докато чакаме, да изпълняваме други инструкции, които не за FPU.
Недостатък: Методът не е приложим за бавни контролери.

2. Апроксимация на формулата, така че да избегнем корена.
Този вариант работи напълно адекватно, но има един основен проблем.
При изчисляване на всеки следващ импулс, се натрупва минимална грешка, което не проблем при ускорение.
Натрупаната грешка, обаче сериозно затруднява преценката, кога точно да започне спирането, така че да спрем на точната позиция.
На практика това означава, че последните 2-3 импулса са или прекалено къси или прекалено дълги.

3. Изнасяне на корена в таблица.
Това е най-удачния вариант, ако работим с бавни контролери.
Таблицата обаче трябва да е логаритмична за да се постигне малка грешка в малка таблица.
При това условие таблицата се получава 4kB (1024 броя uint32_t).
Четенето обаче от логаритмична таблица не е много бъзо. За споменатия контролер печелим около 20nS спрямо вариант 1.

Горните изводи са лично мои и не претендирам за 100% достоверност!

Ами ти май вече си си го усложнил достатъчно

Не е ясно какъв точно проблем бориш, но принципно за да ускоряваш и спираш си има някаква причина. Но чисто механично ти няма как да спираш и тръгваш внезапно. Това е Ъпсурд. Демек за да управляваш моторетката ти трябва да имаш авансово информация каква трябва да ти е скоростта. Обикновено имаш информация за N стъпки напред. Ако N e нула моторетката трябва да е паркирана щото ти нямаш идея какво да правиш. Ако N e 1 то можеш да направиш само 1 стъпка и толкоз. Няма накъде да ускоряваш, щото не знаеш дали може или не може.
Изобщо за да има някакво смислено управление ти трябва да имаш задание за поне 10-100 стъпки напред. И вече така си смяташ ускоренията, че ако не се ъпдейтне заданието ти да може да спреш навреме.
Та независимо каква задачка бориш ти ТРЯБВА да имаш някаква авансова информация. И тъй като информацията е АВАНСОВА е редно ти да си я обработваш АВАНСОВО. Не да чакаш прекъсвания и да цепиш наносекунди!

Нека да ти пример как се прави термо печат. Имаш поток от данни с текст/графика на някакъв си там принтерски език. Това се рендва до пиксели и се пъха в буфер за печат. Докато се пъха се броят колко пиксела има във всеки ред. Налага се защото всеки пиксел е отделно реотанче в печката. Но ако има пуснати твърди много реотанчета токът става прекалено голямо. Затова при нужда реда се цепи на няколко части. Съответно за да не се разминат визуално отделните порции, скоростта на движение трябва да е по-ниска. Отделно се мери температура на печката, напрежение на захранването и т.н, за да се определи необходимото време за термо трансфера...
Всичко това е нещо като "задание" като то дава само тавана на времената. Ако се печата текст, между редовете където е бяло и не се ползва печка няма таван. Може да движиш колкото бързо искаш. Ако има текст имаш и ограничения.
В случая целта на управлението на двигателя е да движи колкото се може по-бързо, но без превишава скоростта. Но тъй като често има ту бели, ту плътни участъци двигателят постоянно е в ускорение или спиране. И ускоренията са важни, защото де-факто определят играта. В зависимост от конкретната механика може да са необходими от 10 до 20 стъпки за да се ускори от 0 до 100%. Не става за 1 или 2 стъпки. А при печат на текст както казах се редуват пълни и празни редове, демек може от 100% към 0% и обратно. Конкретните времена зависят модела на механизма, но да кажем най-бързите са до към 100uS на стъпка. Само че обикновено управлението е с микростъпки, щото е по-мазно така. Микростъпките обикновено се правят с DAC, отделно фазите на двигателя, отделно имаш стробове за печките, зареждане на данните по сериен към печката. Доста неща са и естествено всичко трябва да са в синхрон. Но с STM32 не е проблем, щото просто ползваш таймери и можеш да ги навързваш. Включително и DAC-а си се управлява от таймер. Та няма нужда да се цепят микро или нано секунди от процесора... Във всеки един момент от времето имаш подготвени данни за N стъпки напред с предварително сметнати времена.
Пак може да имаш "нещо като сметки" в прекъсвания (не че го препоръчвам), но то трябва да е супер елементарно. Примерно таблиците за които говорих - те са с времена или ако искаш данни за таймери, но реално като текуща скорост се ползва индекса в табличката. Индекс 1 ти е първа скорост, 2 ти 2-ра и т.н. И ако знаеш, че имаш данни за N=4 стъпки напред и знаеш, че при спиране може да скачаш по 5 скорости, то очевидно трябва да се погрижиш текущия индекс да е по-малък от 5*N т.е. трябва да си на 20-та скорост максимум. Няма нужда от квадратни корени

Разбирам идеята ти, но не мисля, че е приложима.
В принтера може би всичко е ясно предварително и могат да се изчислят (или прочетат от таблица) N стъпки напред.

Тук обаче заданието е следното.
Задава се допустимото ускорение (закъснение). Това се прави веднъж и не е задължително да се променя.
Задава се скоростта, която трябва да се достигне.
Задава се броя на импулсите, които трябва да се отработят.
Ако е само това, да речем, че всичко може да се изчисли предварително НО:

Когато моторът тръгне, зададената скорост може да се промени (например с врътката за % от номиналната скорост). Това не го знаем предварително кога ще се случи.
По време на движение е възможно да се наложи спиране преди да е отработено пълното движение (например натискаме СТОП). Това също е случайно събитие.
Не виждам как може да се реализира това, освен на всеки текущ импулс да се изчислява дължината му в зависимост от моментната ситуация.
А прекъсвания така или иначе трябва да има за да се записват новите стойности за дължина на импулса в регистъра на таймера. Или поне докато е в режим на ускорение (закъснение).
(В същност, ако всичко е изчислено предварително може да се работи и с DMA, но при мен случая не такъв.)
Едно прекъсване от 150nS при максимална честота 100kHz е 1.5% от времето на процесора. За 4 мотора около 6% в най-лошия случай.

А корени трябват. Може да са сметнати предварително, ако това е възможно, или апроксимирани, но в основата на ускорението лежи квадратния корен.

Минаха 15+ години и малко съм ги позабравил нещата, но мисля че ползвах инвертиране на каналите и с едно пускане на таймер ставаха 4 стъпки. Трябва да проверя...
Но и прекъсване на всяка стъпка да е не виждам какво те притеснява. Проца ще се справи. Не виждам причина да смяташ времена. Предварително всичко може да ти е сметнато в табличка. И всеки ред ти е една скорост. Имаш текуща скорост и зададена скорост. В прекъсването ако се разминавят вдигаш или сваляш, но не повече от еди-колко си скорости наведнъж. Ти друго и да искаш - не става, щото ще почне да изпуска стъпки.
Номерът е таблицата да е добре съставена. При принтерите производителя знае въртящия момент при всяка скорост, знае инерцията, знае триенето и съответно разпределя равномерно времената.
При теб ти ще трябва да ги съобразяваш тия неща. Не знам дали става въпрос за класическо цнц и за какво са 4-те моторетки. А и да знаех не ги разбирам цнц-та. Аз съм дърводелец и когато сложа фрезер с голям диаметър намалям оборотите по разбираеми причини. Но това е само при смяна на инструмента, тъй че ускоренията нямат значение. Това може да повлияе и на скоростта на подаване, а що не и ускорения. Предполагам част от тия неща идват от разни софтуери. Но ако не идват може би не е зле да се автоматизира. Може отделна настройка, а може да е според скоростта на шпиндела. Но пак казвам, че не съм в час и идеята ми може да е глупава.

Във веригата HMI стотина милисекунди време за реакция ми се струва съвсем приемливо. Което е доста време.
Време за реакция от порядъка на 200 - 300 милисекунди при промяна на фидрейта също е приемливо.
И най-общо - гонене на време за реакция от порядъка на някакви наносекунди е безсмислено. Хората функционират значително по-бавно.

По микроконтролерките аршини: ...и докато го хвана, охлювът се шмугна в храстите...

Реакцията не е наносекунди. По задание максималната честота е 100kHz. Което е 10uS.
Наносекунди е времето за вземане на решение колко да е дълъг следващия импулс.



Да, така е. Но така или иначе реакция трябва да има.
Защо да чакам стотина милисекунди, като мога да реагирам на момента?

А ако мотора трябва да се движи синхронно, например командван от инкрементален енкодер?
Там не е ли важен всеки импулс?

Явно не ме разбра. Имаш поне стотина милисекунди време за реакция от момента на промяна на фидрейта или друго "непредсказуемо" събитие за да сметнеш какво то имаш за смятане, без да се усети осезаемо забавяне на системата. 50 ms да са, пак е много време.


Това са различни вериги и лупове.
Ако имаш предвид режим "мастер - слейв", тогава ускорението и забавянето е грижа на мастера. Там няма полезен ход откъм слейва.
Ако имаш предвид команда от MPG, при него управлението отново не е съвсем в реално време и не се отработва 1:1. Един клик не е един импулс, а минава през допълнителна аритметика за да се докара до микрон, стотна или десета ход за клик.

Ако правиш това което ми се струва че правиш, поглеждал ли си как е реализирано при GRBL и дерижатите му?