cnc-club.ru

aystarik писал(а):http://www.synthetos.com/wiki/index.php ... yG-Planner Ник, вот на это не смотрел? Ребята вроде как жерк на 6 осях на ордюне считают... И статейка даже есть какая-то...

Как-то странно у них получается

Jerk Equations

The jerk equations drive acceleration and deceleration planning. A good treatment can be found in Ed Red's course notes http://www.et.byu.edu/~ered/ME537/Notes/Ch5.pdf

There are two core calculations that drive everything else. This pair of functions returns the fourth thing knowing the other three.
_mp_get_target_length() is a convenient expression for determining the optimal_length (L) of a line given the inital velocity (Vi), target velocity (Vt) and maximum jerk (Jm). The length (position) equation is derived from:

a) L = (Vt-Vi) * T - (Ar*T^2)/2 ... which becomes b) with substitutions for Ar and T
b) L = (Vt-Vi) * 2*sqrt((Vt-Vi)/Jm) - (2*sqrt((Vt-Vi)/Jm) * (Vt-Vi))/2
c) L = (Vt-Vi)^(3/2) / sqrt(Jm) ...is an alternate form of b) (see Wolfram Alpha)
d) L = abs(Vt-Vi) * sqrt(abs(Vt-Vi)/Jm) ... is a second alternate form. Note: Vt is not always > Vi due to rounding, tolerances, and other factors.
where Ar = (Jm*T)/4 Ar is ramp acceleration
where T = 2*sqrt((Vt-Vi)/Jm) T is time
where Jm (maximum jerk) is the cartesian sum of the jerks for each axis in the move. The values in the unit vector are used to scale the resultant jerk for the move.
assumes Vt, Vi and L are positive or zero

Дистанция зависит не только от текущей скорости и требуемой, но и от текущего ускорения.

нам лижбы работало грамотно

Nick писал(а):Дистанция зависит не только от текущей скорости и требуемой, но и от текущего ускорения.

Скорее всего ускорение должно быть равно нулю на концах.

Дак они в формулах его вроде вообще не используют...

Nick писал(а):a) L = (Vt-Vi) * T - (Ar*T^2)/2 ... which becomes b) with substitutions for Ar and T

Nick писал(а):where Ar = (Jm*T)/4 Ar is ramp acceleration

лишняя переменная...

Ник, как дела в этой области?

Nick, просто подумал, треугольные ускорения получаются при [EMCMOT]TRAJ_PERIOD = const.

т.е. внутри периода приращение скорости постоянно. Если, например, менять величину периода по какой-либо функции на этапах разгона и торможения, то получится, что приращение скорости в реальном времени будет меняться по этой функции.

Т.е. потребуется обойти только граничные условия.

Lexxa писал(а):т.е. внутри периода приращение скорости постоянно.

Так оно и так вроде постоянно? График скорости получается такой _/''''''''\_ , при этом ускорение такое '''------_ , а нам надо ускорение _/''''''''\_

Nick, просто подумал, треугольные ускорения получаются при [EMCMOT]TRAJ_PERIOD = const.

А где про это почитать?

Нигде)
Я имел ввиду, что если на этапах разгона и торможения менять длину сервопериода,тодля внешних железках это будет равносильно изменению ускорения в момент ускорения оси.
Но начинается сложность с граничными условиями, когда a->0, т.е. t->бесконечности. Путь тупиковый.

Ник, почему нельзя ввести функцию для значения acc и не париться?
Ведь все вычисления мгновенные
Вот функция
trajInifile->Find(&axes, "AXES", "TRAJ");
в ней ищется значение MAX_ACCELERATION из INI файла:
trajInifile->Find(&acc, "MAX_ACCELERATION", "TRAJ");
Допустим надо разогнаться до скорости V со скорости Vo=0.
четыре участка -
1 - скорость меняется не линейно время t1 на участке скорости _/
2 - скорость меняется линейно время t2 на участке скорости /
3 - скорость меняется нелинейно время t3 на участке скорости ""\
4 - скорость не меняется.
в INI файл добавляем три параметра T1, T2, T3 соответствующие участкам 1, 2, 3.
Математически описываем acc функцию, возвращающую acc на разных временных периодах - T1, T2 и T3.
Так не получится?
Ведь значение этого ускорения используется в TRAJECTORY PLANER?
Или если так сделать, то он не сможет корректно рассчитать путь оси до точки останова?

Nick писал(а):А где про это почитать?

Чтобы все не читать стоит глянуть картинку на 20 странице. Будет понятно что откуда происходит.
Подобные характеристики скоростных траекторий важны в прямом приводе, допустим в позиционере камеры.
В станке, на мой взгляд, бесполезное увеличение сложности алгоритма планировщика.

Lexxa писал(а):Ник, почему нельзя ввести функцию для значения acc и не париться?

Потому, что ее должен знать планировщик. И исходя из нее рассчитывать траекторию. И еще по хорошему согласовывать траектории всех осей.
Планировщик считает дистанцию до остановки, чтобы понять когда надо начинать тормозить. При обычных условиях у нас есть скорость и ускорение v a. Дистанция до остановки S = v0*t + a*t^2/2. Время остановки t = v0/a.
К чему это приводит, когда просто добавляем jerk - максимальное изменение ускорения aka ускорение ускорения. То получаем дистанцию S = v0*t + a*t^2/2 + j*t^3/6, а время надо считать из уровнения v0 + a*t + j*t^2/2. Если подставить напрямую, то получается уравнение хрен знает какой степени. И приходится рассматривать 8 интервалов. В общем геморрой.

Господа, а у этой темы было какое то логическое продолжение?

Тут такое дело. Если нужно править планировщик, то и все stepgen'ы надо допиливать. Ибо скорость они меняют тоже линейно.

MX_Master писал(а):Тут такое дело. Если нужно править планировщик, то и все stepgen'ы надо допиливать. Ибо скорость они меняют тоже линейно.

Какие то наработки гуглятся, но вот пробовал ли кто что. Степгены пофиг, лично мне, аналог

Аналог пофиг, лично мне, EtherCAT (:

На мой взгляд ни степгены, ни пвмгены тут ни при чем. Расчет траетории должен быть на уровне планировщика. Как планировщик скажет так степген и поедет.

MX_Master писал(а):все stepgen'ы надо допиливать. Ибо скорость они меняют тоже линейно.

Генераторы держат ту частоту, которую прикажут (в меру своих способностей). А приказы поступают один раз за сервопериод. Скачок частоты за 1 мсек достаточно мал, чтобы механика что-то заметила.

Хорошо, уговорили. Осталось дело за малым, накатать другой планировщик
Добровольцы есть? -Нет. Так и знал

S-кривые - не самоцель. Тут во взрослых системах эвон что бывает Re: Обрабатывающий центр SV500 #569

Взрослые системы подразумевают взрослые деньги, потраченные на разработку и тесты с учётом взрослых задач. А просто так спрашивать по форумам запилил ли кто-то S-кривые в LinuxCNC - бессмысленно.