Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Автономный Контроллер Чпу (stm32f103)
Все о станках с ЧПУ > Станки с ЧПУ, Hobby CNC > Электронные компоненты
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
dr_gachet
BosniaCNC,
Еnough thank and please :-). We want to know the parameters of your device!
som.andrew
Цитата(ATLab @ 10.4.2013, 15:27) *
А не соблаговолит ли, многоуважаемый BosniaCNC, выражаться по-русски?
Раз уж прочитал обсуждение на русском?


Цитата(BosniaCNC @ 11.4.2013, 0:55) *
Здесь на русском и насколько хорошо Google Translate не знает. Мой язык не русский, и я не учила в школе. Я сожалею, что вы должны использовать переводчик.
Я надеюсь, что вы счастливы сейчас?
BosniaCNC


Теперь понятно откуда радился анегдот про то что где руссикие отдыхают все бармены говорят по-русски (;
BosniaCNC
Цитата(dr_gachet @ 12.4.2013, 18:39) *
BosniaCNC,
Еnough thank and please :-). We want to know the parameters of your device!


There are no parameters. This project is dead
BosniaCNC
Цитата(som.andrew @ 13.4.2013, 11:03) *
Теперь понятно откуда радился анегдот про то что где руссикие отдыхают все бармены говорят по-русски (;


It does not have the whole world to speak English, even as the whole world does not speak Russian, and I think that it's not funny. I try to understand for all, to be a bad translation as google is not my fault. rolleyes.gif
I think we have a smart topic for discussion and not to deal with linguistics.
Oxford
Проект уже копирует китай
topor
Цитата(Oxford @ 13.4.2013, 14:12) *
Проект уже копирует китай

логи видели? smile.gif
ебэевской ссылкой поделитесь biggrin.gif
по идее уже должны быть wacko.gif
Oxford
Да нет ссылок нет, просто они за форумами следят. Вон босния интересуется сидит.
Вообще технологии копируют как копиры, поэтому осторожней надо выкладывать в общий доступ такие вещи.
mm.Mike
Цитата(Oxford @ 14.4.2013, 7:31) *
Вообще технологии копируют как копиры, поэтому осторожней надо выкладывать в общий доступ такие вещи.


Ну и пусть копируют. Я за opensource.
Деньги нужно получать за сопровождение и сервис.

Практически все корпоративные разработки WEB на GWT (google). Вместо Апач - переходят на glassfish (Sun-Oracle). Linux-ы.. опять же.
Так что это общая тенденция. А поскольку самостоятельно разобраться зачастую дороже чем платить за сопровождение, то платят почти все (я имею в виду серьезных корпоративных заказчиков, а не домашних энстузиастов). Ну потом, кто определяет на чем будут создаватся продуты.. те же программеры. И выберут они те бесплатные продукты, которые могли попробовать и знают, что в случае крайней необходимости найдут корни любой потенциальной проблемы в исходниках.

Долой глюкавые и дырявые черные ящики от Микрософт..
Они сволочи даже SOAP в .Net не по стандарту реализовали, что бы обратной совместимости не было. Явно специально. Терпеть не могу эту контору.
som.andrew
Цитата(mm.Mike @ 14.4.2013, 6:18) *
А поскольку самостоятельно разобраться зачастую дороже чем платить за сопровождение.

Можно это объяснить банальным отсутствием комментариев и описанием архитектуры?
В этом контексте возможно провести параллели с политикой MS?
BosniaCNC
Цитата(Oxford @ 14.4.2013, 2:31) *
Да нет ссылок нет, просто они за форумами следят. Вон босния интересуется сидит.
Вообще технологии копируют как копиры, поэтому осторожней надо выкладывать в общий доступ такие вещи.


Мальчик, ты оставил эти BosniaCNC и делать свою работу, если у вас это? Вы не устояли давать комментарии и делать анализ своих действий, ни я призвал вас сделать. Я являюсь членом этого форума, как вы вошли мои проекты не знаю, почему я не работать с заявлениями.
Спасибо за ваше внимание и я молился, и мои действия в будущем не комментируют.
Проект, который вы говорите, я уже скопировали земляка и вопрос о том, кто там, потому что от того, кто скопировал все претензии то же самое. Я там просто позвонил мне, чтобы это сделать, и проверить его, и я сказал, что это мой проект.

(Я надеюсь, что Google сделал хороший перевод, что я не писать по-английски)
mm.Mike
Цитата(som.andrew @ 14.4.2013, 12:39) *
Можно это объяснить банальным отсутствием комментариев и описанием архитектуры?


Напрасно. Все opensource решения от Google и Oracle хорошо документированы. Ничуть не хуже MS.
Ну только скажите мне, кто в последний раз серьезно копался в документации? Когда сроки стоят "вчера" времени на глубокое копания зачастую просто нет.

Цитата(som.andrew @ 14.4.2013, 12:39) *
В этом контексте возможно провести параллели с политикой MS?


Не надо о грустном. Если сравнивать скорость реакции Oracle (по БД и Solaris) на запросы по проблемам со скроростью реакции MS..
Офисный рещения.. да черт с ними если зависают/падают и пр.
Впрочем, серьезных решений от MS особо то и нет :) только класса "офисные" :)

som.andrew
Цитата(mm.Mike @ 14.4.2013, 14:04) *
Напрасно. Все opensource решения от Google и Oracle хорошо документированы. Ничуть не хуже MS.
Ну только скажите мне, кто в последний раз серьезно копался в документации? Когда сроки стоят "вчера" времени на глубокое копания зачастую просто нет.

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

Цитата(mm.Mike @ 14.4.2013, 14:04) *
Не надо о грустном. Если сравнивать скорость реакции Oracle (по БД и Solaris) на запросы по проблемам со скроростью реакции MS..
Офисный рещения.. да черт с ними если зависают/падают и пр.
Впрочем, серьезных решений от MS особо то и нет :) только класса "офисные" :)

А вот тут вы банально переключаете внимание от выше описанных мной паралелей, наверное у вас на это есть причины... причем вполне понятные - каждый зарабатывает как может.
topor
оффтоп
мужики прислали мне вот это а сидюк не прислали(ни схемы ни загрузчика)
у кого есть скиньте куда-нибудь
Зы заказывал не я а мой товарищ--а он в командировке--писать поставщику--увы.
Oxford
Цитата(topor @ 18.4.2013, 13:51) *
оффтоп
мужики прислали мне вот это а сидюк не прислали(ни схемы ни загрузчика)
у кого есть скиньте куда-нибудь
Зы заказывал не я а мой товарищ--а он в командировке--писать поставщику--увы.

А что хотите как прошить или что?
topor
Цитата(Oxford @ 18.4.2013, 10:49) *
А что хотите как прошить или что?

поизучать кортексы-а без схемы(выудил что драйвер LCd ili9320) и загрузчика как-то того. blink.gif
mm.Mike
Цитата(topor @ 18.4.2013, 18:12) *
поизучать кортексы-а без схемы(выудил что драйвер LCd ili9320) и загрузчика как-то того. blink.gif


загрузчик на сайте STM. ссылку я в форуме давал. поищите.

Схему стоит посмотреть у других продавцов такого же товара на e-bay. Часто выкладывают ссылку (сдесь не буду выкладывать. размер большой).


На точно такой плате я делал металлоискатель. Проект с библиотекой экрана - в том же архиве, где eclipse+gcc

Но вообще то плата не самя удачная по разводке. А процессор из младших
Impartial
Цитата(mm.Mike @ 2.4.2013, 17:38) *
STM32F103 - на данный момент единственный вариант (китайский на e-bay) c уже интегрированным/разведеным LCD
Никаких интерфейсных плат разводит/травит/паять не надо. Подключай шлейф и вперед.
Плюс весьма значительный.

M4 - даже не вариант. за эту же цену (так же без LCD) уже есть "правильные" варианты


Я, интереса ради, запустил ЕМС2 (LinuxCNC) на вот такой плате
http://www.st.com/web/catalog/tools/FM116/...SS1532/PF252419
Интересные получились результаты.
Тестировал на простом прогоне их стандартной программы AXIS.ngc.
Оказалось, что быстродействие сильно зависит от наличия сопрцессора с плавающей точкой и оптимизации вычисления синуса и косинуса.
Без сопроцессора программа на частоте проца 168 мгц выполнилась за 5 мин 37 сек. А с сопроцессором и синус-косинусным алгоритмом от STM - за 17 сек.
Это приличный результат, учитывая наличие богатой периферии в этом процессоре.

Попробуйте пересобрать Ваш проект с плавающей точкой. Результат по скорости значительный. Использовать фиксированную точку в мат. расчетах не лучший вариант (IMHO).
topor
Цитата(mm.Mike @ 18.4.2013, 13:19) *
загрузчик на сайте STM. ссылку я в форуме давал. поищите.

Схему стоит посмотреть у других продавцов такого же товара на e-bay.

перешерстил e-bay -такое впечптление что они или копипастят у друг друга или все продавцы живут в одной квартире а торгуют как в старом анекдоте ...
увы не нашел
ЗЫ на одном электронном форуме тоже попросил--вроде должны скинуть(и чего они в 150 метров напихали?)

biggrin.gif
mmMike CNC controller -- The best price --50$!!!
Made in China
rolleyes.gif
mm.Mike
Цитата(topor @ 19.4.2013, 14:56) *
перешерстил e-bay -такое впечптление что они или копипастят у друг друга или все продавцы живут в одной квартире а торгуют как в старом анекдоте ...
увы не нашел
ЗЫ на одном электронном форуме тоже попросил--вроде должны скинуть(и чего они в 150 метров напихали?)

biggrin.gif
mmMike CNC controller -- The best price --50$!!!
Made in China
rolleyes.gif


В пинциепе, все 150 Мб не нужны. Там вякая хрень, надерганая китайцами для весу
Ловите схему. По моему, это Ваша плата.
topor
Цитата(mm.Mike @ 19.4.2013, 10:41) *
Ловите схему. По моему, это Ваша плата.

примного благодарен.
mm.Mike
Цитата(Impartial @ 19.4.2013, 14:55) *
Я, интереса ради, запустил ЕМС2 (LinuxCNC) на вот такой плате
http://www.st.com/web/catalog/tools/FM116/...SS1532/PF252419
Интересные получились результаты.
Тестировал на простом прогоне их стандартной программы AXIS.ngc.
Оказалось, что быстродействие сильно зависит от наличия сопрцессора с плавающей точкой и оптимизации вычисления синуса и косинуса.
Без сопроцессора программа на частоте проца 168 мгц выполнилась за 5 мин 37 сек. А с сопроцессором и синус-косинусным алгоритмом от STM - за 17 сек.
Это приличный результат, учитывая наличие богатой периферии в этом процессоре.


О! А можете проверить на прицепленном файле?
Это средней "вредности" рельеф. При заданных у меня ускорениях (координата не теряется и не ребуется коррекция по энкодеру) этот рельеф обрабатывается 4,5 часа. Время просчета траектории + вывод на экранчик траектории - 55 сек.
Сколько из этих 55 сек расчет, а сколько вывод на экран сказать не могу. Но фактически каждый пиксель отрисовывается (отключать сейчас рисование в контроллере лень.)

Цитата(Impartial @ 19.4.2013, 14:55) *
Попробуйте пересобрать Ваш проект с плавающей точкой. Результат по скорости значительный. Использовать фиксированную точку в мат. расчетах не лучший вариант (IMHO).


Разбалованы программисты отсутсвием проблем с производительностью.. Да. То что я писал, используя интегрирование и целочисленные вычисления с определнным уровнем приближения, можно было уместить в десяток строк с использованием плавающей запятой и пр. Но делалось под конкрентный проц и конкретные задачи.
EMC писался без учета оптимизации по скорость (с расчетом на современные компы). Это не в укор... просто не было задачи такой.

-----------
Меня "обвиняют" в двух совершенно противоположных вещах. biggrin.gif Одни говорят что взял слишком маломощьный проц и проще LinuxCNC + ARM. Другие - "да все можно на 8-битной меге сделать!" rolleyes.gif
Про 8-бит даже комментировать не хочу.. Хотя, если кому дырки сверлить на станке с масимальной подачей 200мм/мин.. то.. вперед.

Поясняю еще раз:
- Мне нужен был готовый, с экраном (ключевые слова) контроллер не слишком больших размеров и с полным контролем (либо RT OS, либо голый кристалл). Есть другой вариант под эти условия?

Ну лениво мне платы разводить и пр. если есть уже готовый кит точно под задачу!


Почему я не буду использовать LinuxCNC под, например, raspberry:
- Нет вариантов простым подключением маленького экрана.
- стартует Linux сек 30-40 (!) на нем.
- Linux даже с спец сборкой ядра - это не RTOS. Все одно требуется внешний формирователь step|dir на основе траектории, выданной EMC (это можно на быстрых компах ножками LPT дергать.. в надежде успеть).
- Все, что я пока видел на ютюбе для малины - это медленное и печальное исполнение AXIS.ngc на скорость 200мм/мин для станка с винтами. Как оно потянет ли нормальный рельеф - ?

------------------------------
Еще одна фраза: "не нужен никакой дисплей/экран. Нажал кнопку и поехало"...

Ну.. для любителей концептуального минимализма..
А мне нужно:
1. Список файлов на флешке с возможностью просмотра/выбора файлов как минимум. У меня уже десятка два файлов там. Что я каждый раз с ноутом+USB подходить должен? Тем более, что флешка в данной плате не вытаскивается легко. Стоит себе и стоит.
2. Ручное управление.. Вообще то координаты видеть хочется.

Ну а остальное, типа "время от начала работы" и вывод всякой вспомогательной информации - просто доп. удобства.



Impartial
Цитата(mm.Mike @ 19.4.2013, 14:33) *
О! А можете проверить на прицепленном файле?
Это средней "вредности" рельеф. При заданных у меня ускорениях (координата не теряется и не ребуется коррекция по энкодеру) этот рельеф обрабатывается 4,5 часа. Время просчета траектории + вывод на экранчик траектории - 55 сек.
Сколько из этих 55 сек расчет, а сколько вывод на экран сказать не могу. Но фактически каждый пиксель отрисовывается (отключать сейчас рисование в контроллере лень.)

Проверил. Полный расчет без вывода координат значительно медленнее - около 16 минут. Время сервоцикла 1 мс. Проц работает на частоте 168 мгц.
Сколько из этого времени сам расчет, а сколько работа с OTG FS и файловой системой сказать трудно, нужно с профайлером прогнать.
BosniaCNC
mmMike,
What does the letter "E"?

"#define CRD_E 3
SM_E_STEPS_PER_MM"


E = Precision feedrate for threading on lathes and you must have with letter G76 (Threading cycle for turning, multiple repetitive cycle)!
rolleyes.gif
mm.Mike
Цитата(Impartial @ 19.4.2013, 21:01) *
Проверил.

Спасибо!
Цитата(Impartial @ 19.4.2013, 21:01) *
Полный расчет без вывода координат значительно медленнее - около 16 минут. Время сервоцикла 1 мс. Проц работает на частоте 168 мгц.
Сколько из этого времени сам расчет, а сколько работа с OTG FS и файловой системой сказать трудно, нужно с профайлером прогнать.


Кстати, в мои 55 сек включено все. И чтение из файла то же.. От нажатия на кнопку "2" - симуляция с показом траектории на экране, до конца расчета/показа и вывода времени прохода по расчетной траектории.

Какая версия LinuxCNC? Глянуть какой там алгоритм обсчета в этой версии.
LinuxCNC модульная система и написана совсем без учета оптимизации по скорости. Куча взаимодействий меду модулями. И, скорее всего задержки не сколько на вычислениях, сколько на всяких обменах и пр.
mm.Mike
Цитата(BosniaCNC @ 19.4.2013, 21:38) *
mmMike,
What does the letter "E"?

"#define CRD_E 3
SM_E_STEPS_PER_MM"


E = Precision feedrate for threading on lathes and you must have with letter G76 (Threading cycle for turning, multiple repetitive cycle)!
rolleyes.gif


It's atavism :) 4-th axis or extruder.
But it dos not in use at now. I had a plan to try 4-th axis and|or 3d-printer.. but now I have no such plan :)
Because I have got no idea of what can I will do with ones.
X,Y,Z axis only are support.

_Off_
Цитата
И, скорее всего задержки не сколько на вычислениях, сколько на всяких обменах и пр
..а если попробовать запустить G-код с частыми сменами G02,03- скорость вычислений изменится?
Impartial
Цитата(mm.Mike @ 19.4.2013, 18:04) *
Спасибо!
Кстати, в мои 55 сек включено все. И чтение из файла то же.. От нажатия на кнопку "2" - симуляция с показом траектории на экране, до конца расчета/показа и вывода времени прохода по расчетной траектории.
Какая версия LinuxCNC? Глянуть какой там алгоритм обсчета в этой версии.
LinuxCNC модульная система и написана совсем без учета оптимизации по скорости. Куча взаимодействий меду модулями. И, скорее всего задержки не сколько на вычислениях, сколько на всяких обменах и пр.

Версию точно не помню, по моему 2.20
Безусловно, времени много уходит на пересылки. Расчет - кубический интерполятор. Но судя по отчету профайлера на него ушло около 7%.
Пока детально с отчетом не разбирался он пишется в неудобном для чтения формате. Много времени уходит на взаимодействие с фифо по подсистеме движения и на выдачу в ХАЛ. Всего просчитано и выдано около 20 миллионов сервоциклов (1мс) это около 5.5 часов работы реального станка.
Наверное начальные максимальные ускорения и скорости разные.
Если кому интересно отчет профайлера посмотреть вот.
Нажмите для просмотра прикрепленного файла
mm.Mike
Цитата(_Off_ @ 19.4.2013, 22:27) *
..а если попробовать запустить G-код с частыми сменами G02,03- скорость вычислений изменится?


G02, G03 - это обработка материала (дырки пр.). Нет у меня примеров г-кода выполняемого более 30 минут и с расчетом более 2 сек (субъективно "раз", "два" biggrin.gif - расчет закончен)

Это я к тому, что статистику не на чем собирать.. Ну разве что профилер добавить в код, что бы посмотреть время расчета в ms. А так (раз возник интерес сравнить) я по секундомеру засекал время расчета.
BosniaCNC
Цитата(mm.Mike @ 19.4.2013, 17:11) *
It's atavism :) 4-th axis or extruder.
But it dos not in use at now. I had a plan to try 4-th axis and|or 3d-printer.. but now I have no such plan :)
Because I have got no idea of what can I will do with ones.
X,Y,Z axis only are support.


4-axis must be A, B or C. "E" can't be a tag extruder.
RS274D no "E" as the axis, and this can cause confusion.
You must adhere to ISO 6983 and RS274D (http://en.wikipedia.org/wiki/G-code#List_of_G-codes_commonly_found_on_FANUC_and_similarly_designed_controls).
You can alter the syntax in the editor, but it is not standard, and it can cause an error.
For the extruder is better to take a minor syntax as M10 and M11 or M98 subprogram.
Regards
_Off_
Цитата("mm.Mike")
Это я к тому, что статистику не на чем собирать.. Ну разве что профилер добавить в код, что бы посмотреть время расчета в ms
..статистика собственно и интересна (процент загрузки от парсинга, математика с тригонометрией и т.д.). Вариантов оптимизаций много - знать-бы "куда копать" smile.gif
mm.Mike
Цитата(Impartial @ 19.4.2013, 22:39) *
Версию точно не помню, по моему 2.20
Безусловно, времени много уходит на пересылки. Расчет - кубический интерполятор. Но судя по отчету профайлера на него ушло около 7%.
Пока детально с отчетом не разбирался он пишется в неудобном для чтения формате. Много времени уходит на взаимодействие с фифо по подсистеме движения и на выдачу в ХАЛ.


Расчет с обратным проходом по г-коду от найденой точки с 0-й скоростью или простой вариант с анализом предыдущей, текущей и следующей строки г-кода?

Впрочем, завтра сам гляну на алгоритм.. а сегодня уже спать пора rolleyes.gif

Цитата(Impartial @ 19.4.2013, 22:39) *
Всего просчитано и выдано около 20 миллионов сервоциклов (1мс) это около 5.5 часов работы реального станка.
Наверное начальные максимальные ускорения и скорости разные.


Наверное. Я ускорения долго подбирал пока не нашел максимум, при которых у меня возврат в 0 после фрезеровке рельефа в пределах сотых..
Муторное это дело.. подбирать. И все равно с запасом у меня взято. явно...

Придет наконец то еще один энкодер на X - доделаю помесь ШД с серво и для оси X:)
на Z - энкодер уже стоит и, при ускорение +30% и включенной коррекции, по Z потерь нет! (время для этого рельефа 3:45)
Тогда этот рельеф будет у меня за 3 часа пилиться!
Он у меня как эталон.. ибо много резких переходов, размер средний и дарить можно кому угодно (нейтральный по теме). Удобно.. biggrin.gif

Гляжу на ютюбе, как на некоторых станках шпиндель мечется - и аж завидно :)
Impartial
Цитата(mm.Mike @ 19.4.2013, 19:15) *
Расчет с обратным проходом по г-коду от найденой точки с 0-й скоростью или простой вариант с анализом предыдущей, текущей и следующей строки г-кода?

Не понял, как это с нулевой скоростью? По всем координатам? По идее такой точки нет на траектории.
Цитата
Придет наконец то еще один энкодер на X - доделаю помесь ШД с серво и для оси X:)

А не проще сервопривод поставить?:)
mm.Mike
Цитата(BosniaCNC @ 19.4.2013, 22:54) *
4-axis must be A, B or C. "E" can't be a tag extruder.
RS274D no "E" as the axis, and this can cause confusion.
You must adhere to ISO 6983 and RS274D (http://en.wikipedia.org/wiki/G-code#List_of_G-codes_commonly_found_on_FANUC_and_similarly_designed_controls).
You can alter the syntax in the editor, but it is not standard, and it can cause an error.
For the extruder is better to take a minor syntax as M10 and M11 or M98 subprogram.
Regards


There are so many non standart g-code using in 3d-printer like reprap...
In any way, I already remove ones from source code.

After I receive encoders from e-bay (midle of May..) I am going to share next version with encoders support
and without source code artefacts biggrin.gif like:
- 3d-printer exptruder.
- 3d mechanical scaner
Using a CNC as 3d printer is not a good idea. 3d printer should have own disign..
3d-scaner with mechanical sensor has two BIG problems. 1: One is scratching scaned object. 2: One is terrybly slow! (I used.. I know)

But this artifact do not interfere on main proccess in current version.. really! :)
mm.Mike
Цитата(Impartial @ 19.4.2013, 23:22) *
Не понял, как это с нулевой скоростью? По всем координатам? По идее такой точки нет на траектории.

Да ну rolleyes.gif
Любая точка, в которой, например, происходит смена направления движения по любой оси - это точка с 0-й скоростью.

А на практике, таких условий больше (мест в которых нужно тормозить в практический 0), если использовать режим "точной траектории", а не "сплайн траектории".

Цитата(Impartial @ 19.4.2013, 23:22) *
А не проще сервопривод поставить?:)


Мне - не проще.
Энкодер существнно дешевле. Да и станок у меня уже собран на ШД. И экодер на вал ШД удачно ставится...
И если это никто никогда не делал, то не значит, что это сделать нельзя biggrin.gif

Я сделал. У меня работает. Не до скорости сервопривода, конечно. Но на 30% подымается ускорение без проблем (и практически на столькоже в % уменьшается время обработки).
-30% времени на обработку с гарантированной коррекцией любых накоплений ошибок, и отклонением от "точной траектории" в пределах сотых - это знаете ли приятный бонус за 1.6 тысячи руб (800 руб энкодер)
Impartial
Цитата(mm.Mike @ 19.4.2013, 19:50) *
если использовать режим "точной траектории", а не "сплайн траектории".

А можно более развернуто, что значит эта формулировка?
mm.Mike
Цитата(Impartial @ 20.4.2013, 1:25) *
А можно более развернуто, что значит эта формулировка?


режимы G61 и G64 (формулировка была условной. Как помнил по смыслу - так и написал rolleyes.gif )

G64 - я не делал. Теоретически, в общем случае, проход по траектории должен быть быстрее, но математика сложнее.
На целых числах с ходу не придумаешь как сделать...
И, как мне кажется, для маленьких допусков разница в скорости прохождения траектории должна быть мизерная.

Если у Вас есть такой удобный "стенд" с профайлингом выполнения - может сможете сделать сравнительные анализы для одной таектории с разными режимами?
время обсчета и время прохода по траектории для одного файла с разными режимами. Желатель именно по g-code файлу типа owl_1_5. На нем, в теории, эффект G64 должен быть наибольшим.

Я думаю, это всем будет интересно!

На "большом" компе это сложно проверять. Там слишком "размытая" статистика получится (% на вычисления еще меньше, чем все прочие накладные расходы)

mm.Mike
Цитата(Impartial @ 19.4.2013, 22:39) *
Если кому интересно отчет профайлера посмотреть вот.
Нажмите для просмотра прикрепленного файла


Мда.. перенасыщененый лог.
Кстати, сборка с профаллером то же свою лепту вносит в общее время выполнения. Трудно правда с ходу сказать какую. Редко пользуюсь стандартным.
Обычно проще свой код для оценки вставит. Проще разбиратся в резултатах потом biggrin.gif
Impartial
Цитата(mm.Mike @ 20.4.2013, 4:11) *
Да ну
Любая точка, в которой, например, происходит смена направления движения по любой оси - это точка с 0-й скоростью.

Ну да! smile.gif
Под точкой в тривиальной кинематике подразумевается точка обработки. И нулевая скорость этой точки на траектории бессмысленна.
Я не смотрел Ваши исходники. Как Вы считаете кинематику? Именно она должна следить за чрезмерными ускорениями точки обработки.

Никаких премудростей с профайлером нет. Это штатная аппаратная функция отладчика платы дискавери и проца STM32F4XX.
Вы с таким же успехом можете ее включить.
mm.Mike
Цитата(Impartial @ 20.4.2013, 9:29) *
Ну да! smile.gif
Под точкой в тривиальной кинематике подразумевается точка обработки. И нулевая скорость этой точки на траектории бессмысленна.
Я не смотрел Ваши исходники. Как Вы считаете кинематику? Именно она должна следить за чрезмерными ускорениями точки обработки.


Путем разбиения исходной траектории из g-code на отрезки с фиксированным временем прохождения каждого отрезка (dt=50ms). Скорость на отрезке вычисляется так, что разница скоростей проекций (VX, VY, VZ) на ось между двумя соседними отрезками/на время прохождения отрезка не превышала заданного максимально ускорения для данной оси (AXmax, AYmax, AZmax).
T.е. высчитывается V(n) для V(n-1) и V(n+1), так что бы соблюдалось условие для проекций на каждую ось (пример для X):
|VX(n-1) - VX(n)|/dt < AXmax, если направления у VX(n-1) - VX(n) совпадают, или V(n)/dt < AXmax, если VX(n1)

Соотвественно 0- для меня это смена направления (знака) проекции вектора скорости по g-code или когда одна из проекций вектора = 0.

Подход не канонический, но работает за счет "инертности".
При этом подходе, накладные расходы на расчеты и на генерацию шагов минимальны (таймер и фиксированные шаги на отрезке).

Но не используется просмотр вперед.. и это иногда приводит к неприятностям. Впрочем я уже это писал (сильно раньше) и повторятся не буду.
Для идеального расчета нужно выбирать участки g-code для просчета скорости. Не всю же траекторию с конца анализировать..

Цитата(Impartial @ 20.4.2013, 9:29) *
Никаких премудростей с профайлером нет. Это штатная аппаратная функция отладчика платы дискавери и проца STM32F4XX.
Вы с таким же успехом можете ее включить.

Я не про премудрости.
Любая трассировка программы любыми средствами - в общем случае увеличивает суммарное время выполнения этой программы. Хотя и не влияет на время выполнения функций, время выполнения которых нужно измерить..
Во загнул... biggrin.gif
Закрыли тему профилирования. И Вы и я ее знаем..
Impartial
Цитата(mm.Mike @ 20.4.2013, 5:12) *
Путем разбиения исходной траектории из g-code на отрезки с фиксированным временем прохождения каждого отрезка (dt=50ms). Скорость на отрезке вычисляется так, что разница скоростей проекций (VX, VY, VZ) на ось между двумя соседними отрезками/на время прохождения отрезка не превышала заданного максимально ускорения для данной оси (AXmax, AYmax, AZmax).
T.е. высчитывается V(n) для V(n-1) и V(n+1), так что бы соблюдалось условие для проекций на каждую ось (пример для X):
|VX(n-1) - VX(n)|/dt < AXmax, если направления у VX(n-1) - VX(n) совпадают, или V(n)/dt < AXmax, если VX(n1)

т.е. На 50 мс скорость считаем постоянной. В ЕМС это называется сервоциклом, по умолчанию 1мс. Если задать 50мс, то просчет будет в 50 раз быстрее smile.gif
Но и менее точным. Наверное нужно было постараться, чтобы вложиться в допуск. Снимаю шляпу перед Вашей настойчивостью.
Теперь понял откуда такая разница во временах.
Еше осталось непонятным такой момент. Если включена круговая интерполяция (G2.G3) как Вы отслеживаете скорость на участке типа "угол-дуга"?
В ЕМС применен специальный режим интерполяции сплайном с вычислением арксинуса и далее кубический пифагор.
mm.Mike
Цитата(Impartial @ 20.4.2013, 11:50) *
т.е. На 50 мс скорость считаем постоянной. В ЕМС это называется сервоциклом, по умолчанию 1мс. Если задать 50мс, то просчет будет в 50 раз быстрее smile.gif
Но и менее точным. Наверное нужно было постараться, чтобы вложиться в допуск. Снимаю шляпу перед Вашей настойчивостью.
Теперь понял откуда такая разница во временах.


1 ms - это наверное еще в пределах способностей STM32F103. Хотя.. меньше 10ms. не пробовал.
50 ms были подобранны методом тыка, как компромис между прозводительностью и способностью моих ШД (NEMA23) и станка справлятся с этим. На самом деле, взято с запасом. И на 100ms работало нормально и на 10ms.
Но чем то меня 50ms привлекли.. цифра красивая.. biggrin.gif

Кстати, зависимость не линейная в расчете от длинны сервоцикла. Я забыл упомянуть, что "сервоциклы" (в этой терминологии) у меня использую только там где нужно ускорение/торможение.
Если отрезок (G0,G1) длинный, и в середине будет большой участок с установившейся скоростью, то этом участке разбиения не будет. Пойдет как "большой сервоцикл" :)


Цитата(Impartial @ 20.4.2013, 11:50) *
Еше осталось непонятным такой момент. Если включена круговая интерполяция (G2.G3) как Вы отслеживаете скорость на участке типа "угол-дуга"?
В ЕМС применен специальный режим интерполяции сплайном с вычислением арксинуса и далее кубический пифагор.


Я решил проблему проще, в лоб. Точнее взял решение из grbl проекта. G03,02 превращается в последовательность отрезков с фиксированной точностью.
Для себя я установил: #define DEFAULT_MM_PER_ARC_SEGMENT 0.2

Потом эти отрезки скармливаваются основному алгоритму расчета траектории.
Алгоритм расчета отрезков довольно эффективен и использует тригонометрически функции по минимуму.

Возможно не очень эффективно с точки зрения производительности, поскольку отрезков на дугу получается очень много. Но дырки на скорости более 700 мм/мин ни разу не резал, а на такой скорости производительности хватает с запасом.
А STM32F103 все одно бы с приемлимой скоростью не сделал бы полноценные вычисления как в EMC.

Насчет фрезеровки дуги по отрезкам..

По крайней мере посадочное место в текстолите, под подшипник, фрезеруется с хорошей точностью. Подшипник встает с небольшим натягом, как и было задумано..
Текстолит, правда - это не сталь. допускает погрешности. Так что кто его там знает как по стали/бронзе/алюминию было бы.
Но у меня станок/шпиндель на метал не расчитаны. Так что не проверял.

Но для хобийных нужд меня более чем устраивает точность фрезеровки отверстий. Как вспомню какой было проблемой сделать "гнездо" под пошипник на маленьком токарнике.. так аж кайф :)


Impartial
Цитата(mm.Mike @ 20.4.2013, 12:14) *
Я забыл упомянуть, что "сервоциклы" (в этой терминологии) у меня использую только там где нужно ускорение/торможение.
Если отрезок (G0,G1) длинный, и в середине будет большой участок с установившейся скоростью, то этом участке разбиения не будет. Пойдет как "большой сервоцикл" :)

На мой взгляд надо чтобы сервоцикл был постоянным. Хотя, конечно, втиснуть это в 103 наверное не получится.
Дело в том, что такой подход пройдет для генератора шагов, хотя у Вас шаговый привод с обратной связью.
Для сервопривода как раз в сервоцикле нужно считать ПИД.
Я хочу сделать модель станка на останках струйных принтеров. Там интересный сервопривод с обратной связью по линейкам.
Могу предложить Вам использовать эти линейки с их же датчиками и не покупать задорого энкодеры.
Датчики, кстати, выдают квадратурный сигнал и питаются 3.3в. Я их пробовал прямо с таймерами STM32 в режиме энкодера. Работают отлично.
Так же в библиотеке DSP от STM есть очень интересный алгоритм ПИД.
Попробуйте, рекомендую.
mm.Mike
Цитата(Impartial @ 21.4.2013, 1:08) *
Я хочу сделать модель станка на останках струйных принтеров. Там интересный сервопривод с обратной связью по линейкам.
Могу предложить Вам использовать эти линейки с их же датчиками и не покупать задорого энкодеры.
Датчики, кстати, выдают квадратурный сигнал и питаются 3.3в. Я их пробовал прямо с таймерами STM32 в режиме энкодера. Работают отлично.


Поздно. Уже один энкодер поставил и для 2-го место крепеж вырезал. Остальные (той же серии) едут. Так что..
А задорого ли.. Зашел вчера в магазин. Купил пару шоколадок, чуть мяса копченого, еще фигни по мелочи. Маленький пакет на одном пальце висел - цена энкодера :)
Что в Париже в супермаркете на вечер пожрать в гостинице - 20Euro.. что в Новосибе.. те же 20 за то же (хотя сыра такого у на не продают :((). Глобализация чтоб ее..
Будем считать 2 раза не поужинал - два энкодера biggrin.gif (для сдоровья полезнее)
--------
Реализация обратной связи для ШД все же существенно проще, чем для серводвигателя. Так что и алгоритм там прост.

Разгоняю (парамер ускорения в расчете сервоциклов) так, что теряет максимум 1-3 шага за сервоцикл (причем неважно длинный сервоцикл или нет). И то далеко не на каждом сервоцикле (а в редких местах, где сочетания ускорения, механического сопротивления,звезды сложились..) возникает потеря шагов. В одном из 500..1000 циклов (не больше).
Но это, однако, +30% к ускорению при котором потерь нет! и -30% к общему времени прохода г-кода!

А, поскольку разрешение энкодера (512 имп/об), у меня меньше чем у ШД (1600шаг/об), то дельта (потерянные шаги) высчитывается в начале следующего сервоцикла и шаги просто добавляются в следующем сервоцикле.
Вот и весь алгоритм rolleyes.gif
Там где потеря точности в 5мм/512 = 0.0097мм не принципиальна - работает хорошо..

Это же не двигатель в серво, количество оборотов функция от тока, нагрузки + порочие неопределенности и требуется полноценный быстрый PID.

Крутить ШД в режиме (обороты, ускорения), когда у него придется корректировать в пределах сервоцикла шаги - это значит выводить его слишком далеко за пределы его возможностей. Это конечно уже будет перебор...
Графики момента от скорости у ШД и двигателя в серво принципиально разные. Разные и подходы к реализации обратной связи.

Цитата(Impartial @ 21.4.2013, 1:08) *
Так же в библиотеке DSP от STM есть очень интересный алгоритм ПИД.
Попробуйте, рекомендую.

Знаю. Так же как и Фурье. Пробовал для других задач. Алгоритмы стандартные, просто адаптированнве под целочисленные операции.
Хотя.. в библиотеках для ST32F4xx возможно другие. Не смотрел.
BosniaCNC
Отключение для обсуждения здесь, будь то отсутствие энтузиазма или ожидают отправки из Китая?
Привет всем!

(Переводчик: Google.com)
Alexsvc
Давно слежу за веткой, даже поднял проэкт на HYMINI STM32.
И вот я чего не пойму, почему анализ ускорений нужно делать средствами стма ?
Почему нельзя сделать все оффлайн на ББ и кинуть на флеху тупой Step/Dir ?
Вобщем я и двинулся в этом направлении.
Сейчас думаю на чем писать на ББ бо кейл тока для стм rolleyes.gif .
Oxford
Была тема записывать на флешку сигналы STEP DIR. а потом проигрывать как mp3. ))
mura
китайцы так делают, но не просчитывают все на компе, а тупо пишут последовательность в память.
Т.е. певый раз МАЧ пропилил, а потом можно без компа все повторить.
Alexsvc
Цитата(Oxford @ 26.4.2013, 1:42) *
Была тема записывать на флешку сигналы STEP DIR. а потом проигрывать как mp3. ))

А где интересно ? Я б почитал...
И чем все кончилось ?
Oxford
Цитата(mura @ 26.4.2013, 14:48) *
китайцы так делают, но не просчитывают все на компе, а тупо пишут последовательность в память.
Т.е. певый раз МАЧ пропилил, а потом можно без компа все повторить.

Ага тема. При чем повторять N раз одну и ту же программу или менять проги уже записанные, или даже обмениваться ими. biggrin.gif Короче надо в этом направлении мутиться.
Oxford
Цитата(Alexsvc @ 26.4.2013, 19:05) *
А где интересно ? Я б почитал...
И чем все кончилось ?

Вот тема прошедших времен, ушедших имен http://www.cnczone.ru/forums/index.php?sho...ic=2154&hl=
последнее сообщение в 2011, заглохло что-то все там, если капнуть там разговоры еще с 2007 идут... ТЫНЦ ag.gif
Где я сразу сказал что нужен ARM камень для NC платы. ТЫНЦ

В 61 посте я давал прогноз. Пока лучше чем Moonglow ниче не сделали. Мое мнение.
Да и вообще тут уже кто чего только не пытался biggrin.gif одна теория была.


По мне так лучше алгоритм запись-воспроизведение замутить, проще, дешевле, надежнее. rolleyes.gif
http://www.cnczone.ru/forums/index.php?s=&...ost&p=25088
У меня пока с драйверами работы хватает )


Попробуй те двигаться в этом направлении. Можете мне писать в личку.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Форум IP.Board © 2001-2024 IPS, Inc.