Расскажите пожалуйста подробнее про энкодер и обработку данных с него на stm32.
Довольно сложно рассказать программный код и аппаратную часть текстом. В файле encoder.c инициализация (всего 60 строк). В документации на STM32F103 — очень понятно изложен принцип работы на счетчиках при работе с экодером.
У вас еще не было проблем с помехами от силовой части и стабильностью работы?
Серия STM32 очень толерантна к питанию. К тому же запитан через DC-DC stepdown преобразователь.
Проблем не было ни разу. Работает стабильно. Это не Raspberry pi, который от громкого чиха в reset уходит.
Сам не экспериментировал, но читал, что с «правильными» драйверами меньше греются шаговики и в общем случае на 10-20% на большей скорости работают без потери шагов.
Но цена у них… Если бы у меня станок работал не для хобби, а для заработка и увеличение производительности было бы принципиально (это важно на резке рельефов), то тогда бы задумался.
Хотя высокая скорость нужна только для частных случаев. Например вырезания рельефов на дереве.
Нагрев поборол радиаторами. С ними больше 60С не греются. В общем… смирился. Меня вполне устраивают.
В ATMega нет ничего плохого. Я их тоже использую. Но там где им место (что то простое..).
В расчете траектории для 3D принтера или простой гравировке и т.п. 8-и разрядный контроллер на 16Мгц справится.
Хотя даже если справится, то ни на что большей ресурсов толком не останется.
Но вот в фрезеровке 3D рельефа на высокой скорости… не верю.
Да и зачем ужиматься в скудном объеме памяти и скудной периферии? Линейка STM32 не принципиально дороже стоит.
Энкодеры «no name», найденые на e-bay. Оптические, разрешение 512.
На фотке их видно. На валу шаговика стоят перед муфтой. Очень удобно. Как раз, похоже, под шаговики и сделаны.
Доберусь до дома — включу в текст ссылки. На работе youtube закрыт. Когда дома статью писал — забыл скопировать.
Свою конструкция станка не рекламирую и не рекомендую. Поскольку он собран из того что было под рукой.
Все равно все делают по своему.
Конструкция станка — в этом, на мой взгляд, ничего сложного нет и целиком определяется доступными материалами (для домашней сборки).
Акцентировал внимание только на то, что лучше делать с подвижным столом, а не с подвижным порталом и какой нужен шпиндель.
Шпиндель (судя по виду, у меня такой же) не предназначен для силовой фрезеровки.
Обороты от 5000 до 24000. Причем 5000 это очень оптимистично. Не очень он любит меньше 7000-10000.
Он конструктивно (обмотки/подшипники) предназначен для высоких оборотов и небольшой осевой нагрузке.
Силовая обработка металов до 3000. А будете на малых оборотах с большим усилием резать — умрут подшипники в нем за пару часов работы.
Алюминий этим шпинделем можно только гравировать… да и то максимум на 0.2мм за проход.
Фрезеровку сколько не пробовал — фреза забивается/перегревается и ломается. И вода в качестве ОЖ не очень.
А фрезеровать по 0.2 на 200мм/мин (что бы не портить фрезы) — мазохизм.
А так можно из дерева барельефы, из пластика, фторопласта, текстолита. Алюминий не пробовали еще, ну думаю потянет.
Фторопласт и алюминий — не потянет. И шпиндель слишком высокооборотистый. А для силовой фрезировки с другим шпинделем конструкция станка, мягко говоря, хлипкая.
На моем станке, усилие на фрезе при обработке дерева без черновой обработки (бук, фреза 1.5мм, скорость
1200мм/мин, глубина 5 мм) порядка 130-250 грамм.
В ньютоны не перевожу, поскольку мерил самодельными пружинными весами и результат довольно грубый.
При этом даже на нагрузке 500 грамм, отклонение в статике не превышает 0.05 мм (микрометром с часовым циферблатом).
Предположу, глядя на конструкцию, что у вас вылезет за 1мм при прикладывании 0.5 кг усилия к кончику фрезы.
А уж как это все будет болтаться с тяжелым шпинделем с водяным охлаждением (трубки то же тянуть будут)…
Купить дорогой шпиндель и пр. и собрать из чего попало такую слабую конструкцию. Просто не понимаю.
Полно форумов по самодельным ЧПУ станкам. Зачем наступать на известные грабли.
Бутылочка с магнитным порошком — обязательный атрибут инженера по обслуживанию и наладки эмбоссеров.
Помогает точно подобрать ток записи (в тех моделях где это можно точно указывать) и определить проблемы с позиционированием в пишущем железе.
Но вот вручную декодировать — это жесть…
Который подозрительно напоминает наскрайбированные на карте цифры и буквы.
Следующая дорожка уже зашифрована, но об этом уже в другой раз.
А это жесть в квадрате! Можно подумать, что стандарт IS07813 это большой секрет…
Ну не смешите людей.
Трудолюбию я могу только аплодировать.
Но вот такой «хакерский» подход к получению информации, описанной в стандартах, меня удивляет.
Вот это правильный вариант. В моем банке раньше то же так было и я этим пользовался. USB карт ридер для карт SIM формактора. Не совсем дешево (~50Eur), за то надежно.
Более того — я карточное приложение для ЭЦП и разрабатывал, после того как в Gemalto (тогда еще Gemalto) из линейки продуктов GPK карты убрали.
А потом пошел тренд «массовый продукт для тупого пользователя».
И видимо подсчитали, что не выгодно больше это поддерживать/спрос маленький.
А нет банков (рядом с домом/работой), которые для сервиса Клиент-банка физ.лиц. предлагают подпись операций ключом, с аппаратного токена. И не факт что они вообще остались.
Для юр.лиц. — это стандарт (ЭЦП), а для физ.лиц. у всех одинаково дыряво (как в Сбербанке).
Попал на страницу Банк-клиента (хорошо если есть хоть какая двуфакторная аутентификация) и делай что хочешь.
Как минимум, практически у всех есть оплата мобильного на произвольный номер. А как максимум — перевод на чужой расчетный счет, а то и карт.счет. по PAN карты.
Почему этими дырками не пользуются массово — не понимаю.
Перехват SMS, а точнее «замена» карты в офисе мобильного оператора уже была. Предъявляли паспорт при замене или без паспорта… Концов не найти. Что взять с мальчика в торговом зале офиса абстрактного «мобильного оператора» с их зарплатами и текучкой кадров.
В результате у нескольких человек через сервис Банк-Клиент похитили по несколько миллионов (а не надо гранты на личном счете хранить).
Понятно, что атака была персональная и продуманная.
Банк, мобильного оператора, город и подробности — не называю специально. Но было такое и будет. Просто не слишком афишируется.
Двуфакторная авторизация в Банк-клиенте через SMS — зло.
Операции в Банк-клиенте без цифровой подписи для физ.лиц. — зло…
Поскольку работаю в сфере разработки ПО для платежных кар — храню на них только минимум.
И свой банк-клиент отключил (банк, где держу счета, начал экономить на аппаратных токенах физ.лиц. для подписи операций).
начал писать длинный комментарий (в фоне… на работе я). Случайно закрыл страницу и снова набивать его не буду.
Вы меня поняли не так. Вопрос не в сравнении производительности проца. Суть моего комментария — пихать всюду малину можно только из соображений «попробовать» и «поиграться».
Задача: Обработка 1200x800 кадров с выделением красной и зеленой линии лазера + управление шаговым двигателем 4096 шагов на 360 градусов. Запись сырой информации (координаты точек на кадр в int16_t) на SD.
Raspberry PI. USB камера, запись в файл на SD. библиотека ffmpg. Код на C++.
Время обработки кадра + запись на SD — от 100 до 800ms. В среднем 300ms.
STM407 (168Мгц, кстати). OEM камеры MT9D111. запись на SD в DMA режиме с фиксированной таблицей FAT (ну один файл большого размера на всю карту как бы). Код на C++ без OS.
Время обработки кадра + запись на SD всегда 200ms. Правда ни на что больше производительности бы не хватило.
Про потребление в автономе даже сравнивать нет смысла.
Конечно же, если бы надо было делать промышленный вариант, то выбрал бы что ни будь побыстрее чем специализированный STM контроллер. А может быть и нет. Вопрос стоимости и достаточности.
Прожорливость Raspberry Pi, на мой взгляд и исходя из моего опыта, делает ее игрушкой во всех автономных системах.
Поиграться для собственного удовольствия и развития — да. Использовать в тиражируемых решения — нет.
Для простых задач, как езда по линии и прочее, малина сильна избыточна. Для более менее сложных, как обработка видео в реальном времени — слишком слабая.
Например, мои эксперименты с выделением линии лазера (для 3D сканера) и предварительной обработкой с формированием множества точек и запись их в файл на SD + управление шаговыми двигателями, показали, что производительности Raspberry Pi со стандартным Linux и USB камерой нужного разрешения для этого недостаточно.
STM32F4… справляется с этой задачей гарантированно и контролируемо (без использования OS вообще и OEM модулем камеры с прямым управлением), пусть это занимает 80% ресурсов.
Потребление и сравнивать смешно.
Что касается обработки в реальном времени…
Попытка сделать управление ЧПУ станка на Raspberry Pi то же провалилась. И, насколько я знаю, никто до живого варианта для Raspberry ее не довел. (формирование Step/dir последовательности из g-code файла, попытками адаптации LinuxCNC)
А дохленький STM32F103 с этим справляется без проблем и с большим запасом. Работает успешно у меня на станке.
Впрочем это даже на ATMega некоторые энтузиасты делают (хотя я этого извращения не понимаю).
Сходу возникают две соображения против:
1. Ось отнюдь не из пермаллоя.
2. Токи Фуко в сплошном сердечнике (оси).
Возможно это будет работать, но КПД навскидку будет очень маленьким (10-20% в лучшем случае), особенно при использование меандра.
Впрочем, без расчетов и экспериментов, мои выводы основаны на моем личном опыте в электротехнике.
Заниматься теоретическим обоснованием с формулами и расчетами и, тем более проверками на практики, уж извините — лень.
Не «греет/не торкает» меня эта именно эта задача, поскольку опыт подсказывает, что она не решаемая в таком подходе.
Когда я выбирал варианты передачи 10Вт через «воздух» на подвижную платформу, я пытался найти примеры реализаций с использованием трансформаторного принципа на звуковых частотах. Не нашел (передача милливатт с мизерным КПД — это не то).
HCE приложение по «Visa Cloud-Based Payments Contactless Specification V1.3» написать не проблема. Это MasterCard извратная спецификация на HCE.
Открытого ПО для CAM можно пересчитать по пальцам одной руки…
(а не встал ли станок… и не случилось ли чего..).
В 2-х метрах от работающего станка вполне нормально смотрится телевизор на обычной громкости.
Довольно сложно рассказать программный код и аппаратную часть текстом. В файле encoder.c инициализация (всего 60 строк). В документации на STM32F103 — очень понятно изложен принцип работы на счетчиках при работе с экодером.
Серия STM32 очень толерантна к питанию. К тому же запитан через DC-DC stepdown преобразователь.
Проблем не было ни разу. Работает стабильно. Это не Raspberry pi, который от громкого чиха в reset уходит.
Но цена у них… Если бы у меня станок работал не для хобби, а для заработка и увеличение производительности было бы принципиально (это важно на резке рельефов), то тогда бы задумался.
Хотя высокая скорость нужна только для частных случаев. Например вырезания рельефов на дереве.
Нагрев поборол радиаторами. С ними больше 60С не греются. В общем… смирился. Меня вполне устраивают.
В ATMega нет ничего плохого. Я их тоже использую. Но там где им место (что то простое..).
В расчете траектории для 3D принтера или простой гравировке и т.п. 8-и разрядный контроллер на 16Мгц справится.
Хотя даже если справится, то ни на что большей ресурсов толком не останется.
Но вот в фрезеровке 3D рельефа на высокой скорости… не верю.
Да и зачем ужиматься в скудном объеме памяти и скудной периферии? Линейка STM32 не принципиально дороже стоит.
На фотке их видно. На валу шаговика стоят перед муфтой. Очень удобно. Как раз, похоже, под шаговики и сделаны.
Из того, что валялось под рукой прямо сейчас.
Поделки из дерева практически все розданы на подарки.
Что то на форуме показывал… www.cnczone.ru/forums/index.php?showtopic=100&st=500
Не поленюсь напишу про эксперименты по созданию 3D принтера на «рейка/шестерня» полностью сделанного на этом станке.
Свою конструкция станка не рекламирую и не рекомендую. Поскольку он собран из того что было под рукой.
Все равно все делают по своему.
Конструкция станка — в этом, на мой взгляд, ничего сложного нет и целиком определяется доступными материалами (для домашней сборки).
Акцентировал внимание только на то, что лучше делать с подвижным столом, а не с подвижным порталом и какой нужен шпиндель.
Более подробно по контроллеру — там есть ссылка на www.cnczone.ru/forums/index.php?showtopic=3334
где все подробно обсуждалось.
У меня уже давно работает на ней.
Не на ATMega. Но использовать 8-разрдный дохлый контроллер для такой задачи в 2015 году — это странно.
Обороты от 5000 до 24000. Причем 5000 это очень оптимистично. Не очень он любит меньше 7000-10000.
Он конструктивно (обмотки/подшипники) предназначен для высоких оборотов и небольшой осевой нагрузке.
Силовая обработка металов до 3000. А будете на малых оборотах с большим усилием резать — умрут подшипники в нем за пару часов работы.
Алюминий этим шпинделем можно только гравировать… да и то максимум на 0.2мм за проход.
Фрезеровку сколько не пробовал — фреза забивается/перегревается и ломается. И вода в качестве ОЖ не очень.
А фрезеровать по 0.2 на 200мм/мин (что бы не портить фрезы) — мазохизм.
Фторопласт и алюминий — не потянет. И шпиндель слишком высокооборотистый. А для силовой фрезировки с другим шпинделем конструкция станка, мягко говоря, хлипкая.
На моем станке, усилие на фрезе при обработке дерева без черновой обработки (бук, фреза 1.5мм, скорость
1200мм/мин, глубина 5 мм) порядка 130-250 грамм.
В ньютоны не перевожу, поскольку мерил самодельными пружинными весами и результат довольно грубый.
При этом даже на нагрузке 500 грамм, отклонение в статике не превышает 0.05 мм (микрометром с часовым циферблатом).
Предположу, глядя на конструкцию, что у вас вылезет за 1мм при прикладывании 0.5 кг усилия к кончику фрезы.
А уж как это все будет болтаться с тяжелым шпинделем с водяным охлаждением (трубки то же тянуть будут)…
Купить дорогой шпиндель и пр. и собрать из чего попало такую слабую конструкцию. Просто не понимаю.
Полно форумов по самодельным ЧПУ станкам. Зачем наступать на известные грабли.
Помогает точно подобрать ток записи (в тех моделях где это можно точно указывать) и определить проблемы с позиционированием в пишущем железе.
Но вот вручную декодировать — это жесть…
А это жесть в квадрате! Можно подумать, что стандарт IS07813 это большой секрет…
Ну не смешите людей.
Трудолюбию я могу только аплодировать.
Но вот такой «хакерский» подход к получению информации, описанной в стандартах, меня удивляет.
Более того — я карточное приложение для ЭЦП и разрабатывал, после того как в Gemalto (тогда еще Gemalto) из линейки продуктов GPK карты убрали.
А потом пошел тренд «массовый продукт для тупого пользователя».
И видимо подсчитали, что не выгодно больше это поддерживать/спрос маленький.
Для юр.лиц. — это стандарт (ЭЦП), а для физ.лиц. у всех одинаково дыряво (как в Сбербанке).
Попал на страницу Банк-клиента (хорошо если есть хоть какая двуфакторная аутентификация) и делай что хочешь.
Как минимум, практически у всех есть оплата мобильного на произвольный номер. А как максимум — перевод на чужой расчетный счет, а то и карт.счет. по PAN карты.
Почему этими дырками не пользуются массово — не понимаю.
В результате у нескольких человек через сервис Банк-Клиент похитили по несколько миллионов (а не надо гранты на личном счете хранить).
Понятно, что атака была персональная и продуманная.
Банк, мобильного оператора, город и подробности — не называю специально. Но было такое и будет. Просто не слишком афишируется.
Двуфакторная авторизация в Банк-клиенте через SMS — зло.
Операции в Банк-клиенте без цифровой подписи для физ.лиц. — зло…
Поскольку работаю в сфере разработки ПО для платежных кар — храню на них только минимум.
И свой банк-клиент отключил (банк, где держу счета, начал экономить на аппаратных токенах физ.лиц. для подписи операций).
Вы меня поняли не так. Вопрос не в сравнении производительности проца.
Суть моего комментария — пихать всюду малину можно только из соображений «попробовать» и «поиграться».
Задача: Обработка 1200x800 кадров с выделением красной и зеленой линии лазера + управление шаговым двигателем 4096 шагов на 360 градусов. Запись сырой информации (координаты точек на кадр в int16_t) на SD.
Raspberry PI. USB камера, запись в файл на SD. библиотека ffmpg. Код на C++.
Время обработки кадра + запись на SD — от 100 до 800ms. В среднем 300ms.
STM407 (168Мгц, кстати). OEM камеры MT9D111. запись на SD в DMA режиме с фиксированной таблицей FAT (ну один файл большого размера на всю карту как бы). Код на C++ без OS.
Время обработки кадра + запись на SD всегда 200ms. Правда ни на что больше производительности бы не хватило.
Про потребление в автономе даже сравнивать нет смысла.
Конечно же, если бы надо было делать промышленный вариант, то выбрал бы что ни будь побыстрее чем специализированный STM контроллер. А может быть и нет. Вопрос стоимости и достаточности.
А роботами я много экспериментировал.
Да и с малиной то же.
Поиграться для собственного удовольствия и развития — да. Использовать в тиражируемых решения — нет.
Для простых задач, как езда по линии и прочее, малина сильна избыточна. Для более менее сложных, как обработка видео в реальном времени — слишком слабая.
Например, мои эксперименты с выделением линии лазера (для 3D сканера) и предварительной обработкой с формированием множества точек и запись их в файл на SD + управление шаговыми двигателями, показали, что производительности Raspberry Pi со стандартным Linux и USB камерой нужного разрешения для этого недостаточно.
STM32F4… справляется с этой задачей гарантированно и контролируемо (без использования OS вообще и OEM модулем камеры с прямым управлением), пусть это занимает 80% ресурсов.
Потребление и сравнивать смешно.
Что касается обработки в реальном времени…
Попытка сделать управление ЧПУ станка на Raspberry Pi то же провалилась. И, насколько я знаю, никто до живого варианта для Raspberry ее не довел. (формирование Step/dir последовательности из g-code файла, попытками адаптации LinuxCNC)
А дохленький STM32F103 с этим справляется без проблем и с большим запасом. Работает успешно у меня на станке.
Впрочем это даже на ATMega некоторые энтузиасты делают (хотя я этого извращения не понимаю).
1. Ось отнюдь не из пермаллоя.
2. Токи Фуко в сплошном сердечнике (оси).
Возможно это будет работать, но КПД навскидку будет очень маленьким (10-20% в лучшем случае), особенно при использование меандра.
Впрочем, без расчетов и экспериментов, мои выводы основаны на моем личном опыте в электротехнике.
Заниматься теоретическим обоснованием с формулами и расчетами и, тем более проверками на практики, уж извините — лень.
Не «греет/не торкает» меня эта именно эта задача, поскольку опыт подсказывает, что она не решаемая в таком подходе.
Когда я выбирал варианты передачи 10Вт через «воздух» на подвижную платформу, я пытался найти примеры реализаций с использованием трансформаторного принципа на звуковых частотах. Не нашел (передача милливатт с мизерным КПД — это не то).