cnc-club.ru

Argon-11 писал(а):Так что советую, раз уж имеете достаточно мощный МК, используйте плавучку.

Обязательно приму к сведению. Спасибо! На этом камне есть кастрированная реализация "плавучки" одинарной точности, возможно что то и подойдет как нельзя кстати.

MX_Master писал(а):Я ж пару страниц назад давал пример трёхсекционной S-кривой на целочисленной логике. Вот здесь

Отлично! Уже есть желание на несколько дней уйти в отладку.)

MX_Master писал(а):пример трёхсекционной S-кривой на целочисленной логике

А что там целочисленного, кроме результата? Если писать алгоритм на C, то без навыка с целочисленным извлечением квадратного корня придется пом*дохаться на славу )
Стоит ли оно того?

P.S. А вот если нужны целочисленные алгоритмы, почему никому в голову не пришли табличные методы?

Argon-11 писал(а): почему никому в голову не пришли табличные методы?

Ну почему же. Я ещё на первой странице скромно намекал на табличное преобразование...

иногда к стати можно и такой магией пользоваться https://habrahabr.ru/company/infopulse/blog/336110/ при расчетах

5 минут в интернетах на предмет целочисленного SQRT и вариантов уже с пяток

MX_Master писал(а):Таблички нужны, когда есть место в ОЗУ для их хранения.

Почему в ОЗУ? Я их, обычно, создаю в ПЗУ (в смысле, в памяти программ). В нынешних МК её дофига...

Shkryab писал(а):

MX_Master писал(а):Таблички нужны, когда есть место в ОЗУ для их хранения.

Почему в ОЗУ? Я их, обычно, создаю в ПЗУ (в смысле, в памяти программ). В нынешних МК её дофига...

Я такого не говорил

Теоретически можно обойтись только таблицей, почти без вычислений, одними сравнениями.
Навскидку:
формируем самую подробную таблицу (для самого длинного интервала ускорения, назовем его 1x).
Принимаем ее длину за 100%
Все прочие интервалы ускорения (меньшие) получаем из нее, масштабируя шаг. Т.е. для 2x ускорения берем из таблицы каждый 2й эл-т.
Ну как-то так.
Конечно, памяти потребуется овердофига + помозговать таки придется насчет округлений при дроблении вида 3.43x. Но это уже детали. Зато почти без вычислений на лету.

А вот подумалось: похоже, табличный метод - единственный вариант для изменения скорости на лету. Требуется вводить поправку с интервалом, сопоставимым с интервалом вывода самих шагов, иначе увидим какую-то ступенчатость. При выводе шагов 10кгц это интервал порядка 100мкс. В некоторых случаях и целочисленный алгоритм на лету не спасет.

и ваще я начинаю понимать, почему всякие mesы да smoothstepper-ы сделаны на FPGA, а не МК!

Из платки за 1.7$ вполне можно выдавить перерасчёт скорости с частотой до 10 КГц. И вывод до 500 КГц. Не все шаговые дрова такое могут принять. Если учесть, что там будут S-кривые, то это станет лучшим результатом по цене во всей ЧПУ отрасли

Предлагаю не играть в снежки, а объединить умы на благо ЧПУ сообщества

MX_Master писал(а):а объединить умы на благо ЧПУ сообщества

А чем мы тут занимаемся? Истину ищем!
Я ваще сторонник вычисления таблицы заранее с хранением ее в ОЗУ.

Про степмастер - я предполагаю, что S-образность задается все ж не в нем, а в ЧПУ-софте. Сглаживание во времени - это другой алгоритм, как их сравнивать так сходу?

Argon-11 писал(а):Я ваще сторонник вычисления таблицы заранее с хранением ее в ОЗУ.

А я сторонник вычисления таблицы в экселе с сохранением её в ПЗУ...

Shkryab писал(а):А я сторонник вычисления таблицы в экселе с сохранением её в ПЗУ...

Ну или так, я не против!

Допустим, самый длинный 10-секундный разгон, апдейт скорости с частотой 10кгц, по 2байта на эл-т. 200кБ. По нынешным временам вполне подъемно как в ПЗУ, так и в ОЗУ.
Можно сократить, если всю S разбить на 3 участка: начало, середина и конец. Середина - линейный участок, начало и конец - зеркальные. Т.е. храним таблицу только начального участка. Итого от силы ~60кБ. Красота!

Argon-11 писал(а):Можно сократить, если всю S разбить на 3 участка: начало, середина и конец. Середина - линейный участок, начало и конец - зеркальные. Т.е. храним таблицу только начального участка. Итого от силы ~60кБ. Красота!

Или представить в виде отрезков. Храним десяток точек перелома и значения углов наклона. Итого -- сотня байт...

А как же дух истинного программирования?
Как насчёт продумать более быстрый способ перерасчёта скорости?

Shkryab писал(а):Или представить в виде отрезков. Храним десяток точек перелома и значения углов наклона. Итого -- сотня байт

ага, и приходим к тому же - придется на лету вычислять промежуточные значения!

MX_Master писал(а):Как насчёт продумать более быстрый способ перерасчёта скорости?

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

Была у меня когда-то задачка - цифровая фильтрация аудиосигнала на лету. Проц был из LPC21xx, т.е. ARM7, частота дискретизации 44кГц, частота процессора то ли 60МГц, то ли 72МГц. Сделать удалось, но ради этого пришлось пожертвовать некоторыми вещами. Например, кроме накопления сэмплов и цифровой фильтрации проц освобождался от всех других занятий, т.к. не успевал. Даже несмотря на то, что его пришлось слегка подразогнать процентов на 10. Цифровая фильтрация была, конечно, целочисленная и с применением спец.инструкций а-ля dsp.
Здесь задача очень похожая.

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

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

Разве что потестировать то, что получается...

MX_Master писал(а): Истинное программирование - в умелом расчёте воспроизводства этого апельсина, не выжимая из него максимум.

Да, скорее это верно, чем моя фраза. То, что я сказал, относится к стародавним временам типа 90х годов ) Выжимали каждый такт, каждый байт!

Так вот, если делать "в лоб", через вычисление "на лету", то с высокой вероятностью апельсин будет выжат гораздо более чем наполовину. А надо бы кроме как вычислять "S" еще и другими делами заниматься и иметь свободное время - вдруг потребуется несколько осей с независимыми ускорениями?