Бюджетный usb-контроллер для mach3 - кому интересно присоединяйтесь.
Да кстати , а что за фирма производитель такой PCB KIT
Это я 😃
Все проблему с базами решил. Проблема была в мотор-тюнинге. При слишком большом допустимом ускорении мач решает что ЧПУ имеет право остановится мгновенно, т.к. допустимое ускорение запредельное. По этому он и не делал реверс - типа и так стал точно. Привел ускорение к реалистичному виду - появился реверс.
Ну будем ждать выхода девайса в свет)))))). Попутного ветра.
Leg, тут вопрос такого плана. Вывода на движки осей не будут меняться? На этой(отладочной) плате? Кристал один, хочу всё-таки забуферировать, мало ли…
Leg, тут вопрос такого плана. Вывода на движки осей не будут меняться? На этой(отладочной) плате? Кристал один, хочу всё-таки забуферировать, мало ли…
Нет не будут,в варианте с этим камнем просто не могут, они подключены к аппаратным выводам сигнал-генераторов(таймеров) МК. Смело буферизируйте.
Вообщем правильное поведение при перемещении в Домашнюю позицию следующее - на скоросте заданой для домашней позиции - обычно в процентах от максимальной происходит перемещение до срабатывания датчика, далее происходит отъезд то размыкания датчика. Эта позиция считается домашней, машиная координата станка для данной оси обнуляется.
Отъезд нужен для того чтобы корректно обработать ситуацию когда все датчики висят на одной линии - стандартная типовая ситуация для ЛПТ. т.е. каждая ось двигается поочереди и отъезд с датчика нужен для того чтобы освободить линию с датчиками для следующей оси.
Мач на ЛПТ при правильных настройках работает именно так. Могу отснять видео.
Скорость перемещения в Home должна быть меньше и должна быть возможность ее корректировки - у меня портал 2х метровый на рейках скорость перемещения до 20 метров и минуту - если я его на такой скорости отправлю домой он просто не успеет остановится когда сработают датчики и хода самих датчиков тоже не хватит он просто их снесет и его заклинит.
Мач на ЛПТ при правильных настройках работает именно так.
Спасибо, примерно такого ответа и ожидал.
Отъезд нужен для того чтобы корректно обработать ситуацию когда все датчики висят на одной линии - стандартная типовая ситуация для ЛПТ. т.е. каждая ось двигается поочереди и отъезд с датчика нужен для того чтобы освободить линию с датчиками для следующей оси.
Если датчики отдельно, функция отъезда никак не отключаема? Т.к. вроде лишняя выходит.
Еще вопрос: в 45 посте я писал про решение проблемы которая у меня возникла. Но, я считал что это связано с интерпретированием мачем точности останова. Может ли кто проверить - на околопредельном ускорении у всех мач не делает съезд с датчиков? Правда на движках с таким ускорением лучше наверно не проверять, можно отключить один движок и нажать концевик руками - станет ли мач идти назад или перейдет на другую ось?
Это ближе, вот кто бы рассказал какие, перевертел уже все.
Мне как кодеру проще понять реализацию смотря на код а не настройки - к сожалению это одна из функций полностью скрытых внутри драйвера и увидеть ее реализацию нет возможности.
Насколько я понял вопрос - это устанавливается здесь (на картинке выделено чёрным- правда мач немецкий)
Насколько я понял вопрос - это устанавливается здесь (на картинке выделено чёрным- правда мач немецкий)
Не, это выход из лимитов, это уже работает.
Ну я если чесно пробовать не буду но помоему на сколько я помню - когда ставил макс. скорость на перемещение домой то мач просто моментально останавливал станок а поскольку портал тяжелый то моторы тупо клинило и ни о каком отъезде там уже речи быть не могло оно шаги безбожно пропускало.
Кстати такая же последовательность принятия базы работает и в Линукс ЕМС2 - думаю это своего рода стандарт.
Когда датчики на разных пинах -теоретически это наверно и не надо - но я где то читал что если этот отъезд делать на совсем медленной скорости то вроде как повышается повторяемость принятия базы - что в принципе логично.
Я бы кстати поучаствовал в тестировании проекта и может быть даже в ковырянии плагина (есть опыт написания плагина под мач.) но пока совсем некогда этим заняться. 😦 Если дело дойдет до группового заказа плат и т.п. то я бы с удовольствием присоединился. Ну а пока буду внимательно следить за проектом.
Ну я если чесно пробовать не буду но помоему на сколько я помню - когда ставил макс. скорость на перемещение домой то мач просто моментально останавливал станок а поскольку портал тяжелый то моторы тупо клинило и ни о каком отъезде там уже речи быть не могло оно шаги безбожно пропускало.
У меня проблема проявляется не на макс скорости, а при настройке в маче макс ускорения. Скорость при этом минимальна, 1% от максимума.
но я где то читал что если этот отъезд делать на совсем медленной скорости то вроде как повышается повторяемость принятия базы
Вполне логично, я в начале именно так и представлял работу баз, но в маче ничего подобного не отрыл, хотя реализовать могу.
Если датчики отдельно, функция отъезда никак не отключаема? Т.к. вроде лишняя выходит.
Олег, нужно еще помнить, что в станках под управлением Mach функции Limit switch и Home switch как правило вешают на одни и те же переключатели. Поэтому съезжать с них нужно обязательно.
Олег, нужно еще помнить, что в станках под управлением Mach функции Limit switch и Home switch как правило вешают на одни и те же переключатели. Поэтому съезжать с них нужно обязательно.
Это естественно, я имел ввиду в варианте с полностью отдельными датчиками, т.к. у контроллера входов хватит. Ну не суть, не отключаема - мне проще с софтом.
Тут с лимитами тоже вопрос:
Не нашел в маче “умного” съезда. При оверрайде лимитов как авто так и ручном - чешет куда пошлют, а если случайно старт нажать - несется по концевику. Я считал что логично открывать все направления кроме сработавшего, а при съезде открывать и его и снимать оверрайд.
Это так или есть решение? (В варианте с отдельными лимитами на оси и направления)
Это так или есть решение?
Даже на пром станках приходится, выключать и вручную выталкивать из лимитов. Видал несколько десятков пром станков, везде только один датчик на конце, что для лимита, то и для хоума.
Даже на пром станках приходится, выключать и вручную выталкивать из лимитов.
Вручную - в прямом смысле? Вращать винт руками?
Но сам мач позволяет разблоктровать лимиты и вывести ось джоггингом. После выхода с датчика лимиты переактивируются автоматически. Неудобно только что после разблокировки лимитов - ось может двигаться во все направления даже в сторону сработки.
К стати кнопку разблокировки лимитов и ручной переезд - можно вынести на сам станок(панель оператора), в моем контроллере работает.
Где штурвалы стоят, а станки с большим полем на рейках и серво, там толчка хватает.
Для тех, кто макетирует.
Схема ложится на всякие макетки для 128-й меги с миниумом проводов.
2Leg имеет смысл на аналоговые входы вывести “крутилки” для скорости подачи и шпинделя - сильно помогает во время подбора режимов реза.
На какую частоту кварца расчитан бутлоадер?
Вопрос возник т.к. в USBKEY кварц 8, а тут 16.
На какую частоту кварца расчитан бутлоадер? Вопрос возник т.к. в USBKEY кварц 8, а тут 16.
Бутлоадер стандартный, он прошит в чипе производителем, работает и на 8 и на 16. Но моя прошивка только на 16.
2Leg имеет смысл на аналоговые входы вывести “крутилки” для скорости подачи и шпинделя - сильно помогает во время подбора режимов реза.
Подумаю на будущее, но у меня жесткие ограничения по времени выполнения кода - шаговый генератор требует высоких скоростей и жесткого реалтайма.
По этой причине осей не 6 а 4, и скорость 50КГц - зато импульсы, такт в такт, даже если по всем осям в один момент.
Считаем: 1/(4*2*50000) = 2,5 мкс - на обработку одного шага, а еще надо ЮСБ поддерживать.
Еще для всех: Длительность импульса степ (вкладка мотор-тюнинг) не настраивается , равна 10мкс. Проверьте работают ли Ваши драйвера на этом импульсе.
Теперь по софту.
Решил так:
Т.к. тестирующих может оказаться много и ошибки могут быть как с моей стороны так и пользователей, функционал будет добавляться последовательно, все версии будут лежать отдельно. Что бы минимизировать влияние неотлаженного функционала на рабочий (особенно в прошивке МК) и повысить достоверность баг-репортов от тестирующих.Как-то так.
В общем прилизал минимальный функционал в котором я более-менее уверен, типа демоверсия_1:
-
4 оси, 50 КГЦ, длительность импульса 10мкс, активный уровень - низкий.( Все статично, не настраивается, состояние настроек не имеет значения, кроме скорости и ускорения(мотор-тюнинг))
-
Движение по УП (Само движение должно быть ОК, управляющие G-кода требуют тестирования)
-
Ручное перемещение (Должно быть ОК во всех вариациях, все настраивается, ускорение - замедление тоже работает)
-
Линии ввода вывода. Пока все линии на ввод (После тестирования всей версии в целом добавлю вывод)
Назначать на линии ввода можно любые функции, но не все реализованы : -
Нет возврата на базу (уже вроде продумал, но после тестирования)
-
Нет индекса, зонда, управления дугой.
Все остальное по входам вроде есть, ОЕМ- кода для ввода/вывода здесь
Завтра подшлифую драйвер USB и подошью архив, и можно выкладывать, потом займусь второй версией, но тестировать начинайте с первой даже если на момент сборки будет вторая.
Т.к. тестирующих может оказаться много и ошибки могут быть как с моей стороны так и пользователей, функционал будет добавляться последовательно, все версии будут лежать отдельно. Что бы минимизировать влияние неотлаженного функционала на рабочий (особенно в прошивке МК) и повысить достоверность баг-репортов от тестирующих.Как-то так.
Только сегодня нашел тему. Присоединяюсь!
Переделал… для таких динозавров как я
Юрий, разьем юсб с какой стороны будет? Снизу я так понимаю цельная земля? Просто в таком варианте логичнее перевернуть его на нижнею сторону чтоб не возится с пропайкой металлизации под разъемом. Но по разводке вижу что оставили разъем сверху. Обратите внимание что бы корпус разъема не коснулся плюсовой дорожки.