Выставить ноль после смены инструмента.
Можно ищё такую вещь приобрести
spanntechnik-shop.de/…/Nulleinsteller-ohne-Magneth…
Чтоб стол не поржавел от плевков на бомашку… 😁
А про сканер розкажите поподробней, интересно же людям!
Как это всё устроено и работает(насчёт сканерных деталей)?
Я раскажу принцип, а если возникнут вопросы - уточняйте что именно интересует более детально.
Сенсор от сканера имеет 3 набора (красный+синий+зеленый) по 5400 ячеек по 5.25 мкм.
Установлен вертикально, напротив - источник света из 3-х светодиодов в световоде из матированого пластика прикрытый щелевой маской.
Все это прикручено в углу рамы.
Затем все просто - после смены инструмента ведем инструмент в зону калибровки, где после каждого шага проводим опрос ячеек сенсора и передаем управляющей программе, которая уже вычисляет форму и размеры инструмента.
Естественно горизонтальное разрешение не будет больше, чем шаг подачи, а вертикальное - родное сенсора + можно интерполировать значение освещенности ячеек в зоне края инструмента.
Использую только один набор ячеек (синий, потому как светодиоды бело-синего цвета), думаю что если заюзать все три - то можно еще больше повысить точность горизонтального сканирования (расстояние между наборами - 42 мкм).
Оптики никакой (ну, кроме щелевой насадки на источник света).
В качестве контроллера станка использую PIC18F4550.
Вдогонку - эта идея родилась из более простой - на тот же просвет между двумя щелями (фото- и светодиод). Но после тестов она была отброшена, т.к. не обеспечивала приемлемую точность (до половины десятой мм я добился с трудом), хотя тоже позволяло определить форму (с другим алгоритмом).
Я раскажу принцип, а если возникнут вопросы - уточняйте что именно интересует более детально.
Сенсор от сканера имеет 3 набора (красный+синий+зеленый) по 5400 ячеек по 5.25 мкм.
Установлен вертикально, напротив - источник света из 3-х светодиодов в световоде из матированого пластика прикрытый щелевой маской.Все это прикручено в углу рамы.
Затем все просто - после смены инструмента ведем инструмент в зону калибровки, где после каждого шага проводим опрос ячеек сенсора и передаем управляющей программе, которая уже вычисляет форму и размеры инструмента.
Естественно горизонтальное разрешение не будет больше, чем шаг подачи, а вертикальное - родное сенсора + можно интерполировать значение освещенности ячеек в зоне края инструмента.
Использую только один набор ячеек (синий, потому как светодиоды бело-синего цвета), думаю что если заюзать все три - то можно еще больше повысить точность горизонтального сканирования (расстояние между наборами - 42 мкм).Оптики никакой (ну, кроме щелевой насадки на источник света).
В качестве контроллера станка использую PIC18F4550.
Очень интересная идея! Один вопрос (так как я несильно разбираюсь в сенсорах сканера). По вертикали понятно как попадает фреза на сенсор, а по горизонтали? Тоисть если фрезу (конусную) сместить на 0.5 мм в сторону, данные замера изменяться?
Ещё лучше фото даного девайса!
Тоисть если фрезу (конусную) сместить на 0.5 мм в сторону, данные замера изменяться?
Конечно изменятся - форму же инструмента именно так и определяем.
После выходных я выложу фотки и самого датчика, и картинку как это видит контроллер.
Конечно изменятся - форму же инструмента именно так и определяем.
После выходных я выложу фотки и самого датчика, и картинку как это видит контроллер.
Вот в этом и вся проблемма! Форма фрезы нам не нужна, нам нужна её нижняя кромка… Ждём на фотки!
Вот в этом и вся проблемма! Форма фрезы нам не нужна, нам нужна её нижняя кромка… Ждём на фотки!
Е ні, дядьку, російською мовою буде “ждем фотки”. А те, що Ви написали - то є калька з української “чекаємо на світлину” 😃
Е ні, дядьку, російською мовою буде “ждем фотки”. А те, що Ви написали - то є калька з української “чекаємо на світлину” 😃
😃
Вдогонку - эта идея родилась из более простой
По логике следующим шагом должно стать слежение за состоянием инструмента. Такие системы есть. Правда используют
матрицы типа фотоуамер.
Для простого же определения длинны инструмента или нуля обработки, на мой взгляд, ну уж очень все наворочено.
К примеру - инфа о форме инструмента абсолютно избыточна. При создании УП я закладываю параметры инструмента. И УП просчитывается с учетом их. Так чего ради мне уточнять форму фрезы? Разве что подстраховаться от невнимательности при набивке магазина?
Точность же установки нуля ограничена дискретностью привода и никакие ухищрения с датчиками ее не улучшат. Совершенно достаточа точность примитивного сенсора. Пояснения по нему есть по ссылке, что дал выше.
Если он стационарный - точнсть установки огратничена только дискретом. Если переносной, то вмешивается еще погрешность установки на место измерения, ( стружка, неровность стола, и т.д. )
Афигеть…
Не, я по-другому наловчился.
Взял сенсор от старого планшетного сканнера, напротив него - источник света, и провожу инструмент между ними. Таким образом узнаю, где инструмент заканчивается (с точностью около 0.009 мм), и заодно передаю в управляющую программу форму инструмента.
А про “бомашку” я не додумался 😦
А что за программа, и как он переваривает форму инструмента?
К примеру - инфа о форме инструмента абсолютно избыточна.
Обьяснюсь. Я программист, что означает я ленивый. В переводе на обычный язык - хай машина думает, ей всё-равно заняться нечем.
Меня ломает пол-часа (а то и более) каждую фрезу/сверло/другие струменты рисовать в каде, да и необходимости такой не вижу.
Посему вставляю инструмент - и хай оно себе его обнюхивает. Тем более что долотом пока работа не предполагается а, значит, у нас тело вращения, которое я смогу с приемлемой [для меня] точностью отсканировать.
И, опять же, это прекрасная зарядка для ума 😃
А что за программа, и как он переваривает форму инструмента?
Программа - самопал, пишем (мы станок с другом сооружаем) на дельфине, ничего выдающегося.
Но принцип прост: получаем со сканера отсчеты, поскольку вертикальное разрешение известно, горизонтальное тоже, то строим набор кругов, по ним строим мэш и - вуаля!
А там и в dxf экспорт не проблема.
Правда, есть одно (на самом деле несколько 😒 ) западло.
Приходится на каждом шаге делать не один проход сканирования, а около десяти и потом усреднять - ведь инструмент вращается (если его останавливать - то тогда можно только нижнюю границу правильно определить, а форму уже дудки), и иногда сканер успевает отсканировать пустые места. К примеру, тело сверла получается волнистой формы (вроде как смотреть на неподвижное), а после нескольких сканов уже улучшается.
Обьяснюсь. Я программист, что означает “я ленивый”.
Вы просто не достаточно ленивы!!!
Нет никакой необходимости рисовать фрезы в кадах! Они создаются в CAM ах по мере необходимости и кладутся в библиотеки инструментов. Даже при сильной затормржености процесс занимает не больше двух - трех минут.
Даже при использовании нестандартных фрез, используюихся в столярке, например, нужно просто подобрать ее фиктивный диаметр. Но такое бывает нужно до исчезающего редко.
Стандартный лист фрезы в САМе содержит всю нужную инфу. Диаметр фрезы, длинну режущей части, общую длинну, диаметр хвостовика, цанги, скорость резки, кол - во перьев, форму, номер в обойме, название… что еще надо?
Без всяких Кадов прога на основании этих данных просчитает пути, проверит столкновения, скорректирует путь по форме фрезы и даже вычислит шаг по заданной шероховатости.
И ничего чертить не надо. Просто вводите цифры и жмете кнопки.
😃 😃 😃
Программа - самопал, пишем (мы станок с другом сооружаем) на дельфине, ничего выдающегося.
А что она уметь, G коды переваривает, или работает только с DFX?
И ничего чертить не надо. Просто вводите цифры и жмете кнопки.
‘Оно мине нада?’ © Фроим Грач 😃
Я Вам вот что скажу. Есть такой анекдот, где три кота выбирали самого из них ленивого. Так вот я, конечно, яйца не ленюсь из кипятка достать, но поскольку меня и моего друга угораздило родиться под знаком Девы, то у нас жизненный принцип как в известном мультике - ‘лучше день потерять, зато потом за пять минут долететь’ 😃.
у нас жизненный принцип как в известном мультике - ‘лучше день потерять, зато потом за пять минут долететь’ 😃.
Нет, ежели жизненный принцип… тоды конечно!
Хотя напрашивается: эту бы энергию, да в мирных целях…
😁
Для иллюстрации:
Лист из VM.
Респект!
Не перевелись еще гении на земле нашей!
Почитал, офигел, страшно подумать что за станок вы конструируете если у вас такое для определения “0” инструмента.
Молодцы, Удачи!
‘Оно мине нада?’ © Фроим Грач 😃
Я Вам вот что скажу. Есть такой анекдот, где три кота выбирали самого из них ленивого. Так вот я, конечно, яйца не ленюсь из кипятка достать, но поскольку меня и моего друга угораздило родиться под знаком Девы, то у нас жизненный принцип как в известном мультике - ‘лучше день потерять, зато потом за пять минут долететь’ 😃.
А что она уметь, G коды переваривает, или работает только с DFX?
А что она уметь, G коды переваривает, или работает только с DFX?
G-коды [еще] не умеет.
Песня такая (прошу не забывать, что мы оба программисты, в ЧПУ разбираемся на банальном уровне, потому не смейтесь над терминологией):
Станок предполагается использовать для небольших 3d изделий (пока рабочее поле 400х400х300), в основном биоформы.
Грузим dxf с изделием, грузим dxf (или задаем уже в программе) с болванкой. Говорим программе, кто из них кто - где изделие, а где болванка, попутно выбираем собственно расположение изделия в болванке (к примеру, болванка - куб с ребром 300, а изделие будет размером не более 20х100х40, логично разместить изделие поближе к краю заготовки). В принципе, программа сама старается подобрать расположение изделия внутри заготовки поближе к краю, но можно и корректировать.
Программа просчитывает путь для инструмента, после каждого прохода обновляя модель болванки - это для того чтобы по уже выбранным местам струмент перемещать быстро.
Каждое элементарное перемещение задается вектором, этот вектор пересчитывается в количество шагов и скоростей по осям и передается по USB (на наших ноутбуках нету ни LPT, ни COM портов) контроллеру, который отрабатывает эту команду. У контроллера есть небольшой буфер на 6 команд. По мере выполнения команд из буфера программа добавляет новые. Естественно контроллер умеет отчитываться что происходит (какая команда выполняется и на каком именно шаге) по запросу программы.
Если есть необходимость обработать изделие с разных сторон - скажем, нужно выбрать Г- или Зю-образный тоннель, - болванку разворачиваем, программе говорим ‘поворот болванки’ , в ручном режиме сопоставляем контрольные точки, а потом продолжаем обработку другой стороны.
Задумок много - скажем, хочу на Z-стойку добавить еще две степени свободы, опять-таки хочу заставить шоб контроллер полюбил G-коды, хочу энкодеры (чисто для контроля аварийных ситуаций) присобачить (элементарные, вообще-то, уже стоят - на вал двигателя нанесена маркером метка + оптопара на отражение, т.о. можно сопоставлять реальное положение вала с предполагаемым), вчера вот задумались - а фигли вручную вводить размеры болванки, хай веб-камера ее снимает и формирует модель (точность по болванке не особо важна, ну возьму вычисленные размеры и добавлю по паре мм на сторону), хочу чтобы после поворота болванки контрольные точки сами сопоставлялись (уже наработки есть, все предполагается в одном процессе с определением формы болванки)
В общем, делать еще его и делать 😃
Обьяснюсь. Я программист, что означает я ленивый. В переводе на обычный язык - хай машина думает, ей всё-равно заняться нечем.
короче, пока мечты 😦
Респект!
Не перевелись еще гении на земле нашей!Почитал, офигел, страшно подумать что за станок вы конструируете если у вас такое для определения “0” инструмента.
Молодцы, Удачи!
Спасибо 😒
короче, пока мечты 😦
Мечты о чем?
Каждое элементарное перемещение задается вектором, этот вектор пересчитывается в количество шагов и скоростей по осям и передается по USB (на наших ноутбуках нету ни LPT, ни COM портов) контроллеру, который отрабатывает эту команду. У контроллера есть небольшой буфер на 6 команд. По мере выполнения команд из буфера программа добавляет новые. Естественно контроллер умеет отчитываться что происходит (какая команда выполняется и на каком именно шаге) по запросу программы.
Программа, откуда берет вектора перемещения по Z? А ускорение учитывается?