Search in topic

Выставить ноль после смены инструмента.

а) Перехлеснулись две темы.

б) Об оптике: есть такой метод измерения - теневой. Используется как раз геометрическое расходдение тени. Точечный источнок ( не лазер! У него когерентный пучек. Он не расходится. ). Свет идет на объект, за объектом стоит мишень.
Дальше не сложно взяв расстояния от источника до объекта и от объекта до мишени посчитать масштаб полученного на
мишени изображения. Точнее, его контура. Сответственно с увеличением мсштаба растет точность замера.

в) Для примера скрин окна настройки двигателей из Mach3. Тут есть все, что надо для полного счастья.

а) да, я читал ту ветку. Вообще форум очень хороший, много полезной инфы, даже такой которая в данный момент не нужна - зато потом сразу вспоминаешь, где видел.

б) знаем, плавали. Тут есть один тонкий нюанс, на той неделе на него нарвался. Дело в том, что разница показаний ПЗС на некоторых теневых участках сильно искажается помехами (разной природы, в т.ч. тепловой нагрев сенсора, помехи по питанию и по шинам и т.д.). Я ведь освещенность компаратором отлавливаю, а у него хоть и есть гистерезис, но все-равно не со всеми проблемами справляется (провода-то довольно длинные). Может, когда будет натхнэння, сделаю отдельный контроллер только для сенсора, чтобы от него уже не аналоговый шнурок тянуть а уже цифирь гнать. А мудрить супер защищенную схему только для того, чтобы еще больше увеличить точность - зачэм, если я каралэва Грузии 😃. Если серьезно - то это уже выходит как за рамки того, чего нам нужно, так и за понятие “пара свободных вечеров”. Будет необходимость - задумаюсь. Я не зарекаюсь, конечно, вдруг после полной сборки окажется что там просчитались, тут не додумали и т.д. - всяко ведь бывает.

в) Клёво. надо себе такой-же сделать 😃

Хочу немного уточнить, с Вашего …

Спасибо, большое, за комментарии, и за науку 😃

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

А, с другой стороны, мне более интересно позицию инструмента найти, а не каретки.

Если знаете позицию каретки по X и Y, то значит и знаете позицию инструмента.

Будет необходимость - задумаюсь. Я не зарекаюсь, конечно, вдруг после полной сборки окажется что там просчитались, тут не додумали и т.д. - всяко ведь бывает.

Я думаю у Вас будет еще не один повод задуматься и переделать. Именно по этому я спрашивал про технолога.
😁
Так, что не отчаивайтесь! До окончания работы еще много времени!!! Будет об чем почесать репу!
😁 😁

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

Еще в 80 годы разрабатывалась система слежения за инструментом. При поломке его или чрезмерном затуплении аппарат ехал в магазин ( Свой, конечно, станочный! ) и менял его.
( Так вот… исподволь затравочка… 😁 😁 😁 )

Я теряюсь в догадках - или Вы с меня издеваетесь, или одно из двух 😕. В прицепе модель дивана. Сделана не знаю в чем, но файл - dxf. Этот файл прекрасно грузит наша программа.
Свои тестовые модели (простенькие) делали в Blender. За яшшерицу не скажу, но здаётся мине шо тоже проблем не должно быть.

Новости с полей - уже умеем парсить obj формат (Wavefrontовский).

Obj уже 3D формат. Скинь диван в dxf формате.

Эх,Джон Сильвер (JohnSilver, Esq.)был фантазер и обманщик.

Obj уже 3D формат. Скинь диван в dxf формате.

Баха, есть трехмерный dxf в природе, но это такое говно, что только уж очень просвещенные о нем знают 😃

Баха, есть трехмерный dxf в природе, но это такое говно, что только уж очень просвещенные о нем знают 😃

Не сильно просвещенный, но… в общем Rhino как раз в такое чудо и конвертирует при необходимости. В общем есть, конечно кое что… но не то. Я бы не стал им пользоваться.
😦

Эх,Джон Сильвер (JohnSilver, Esq.)был фантазер и обманщик.

Угу. Читать - одно удовольствие, даже я так врать придумывать не умею 😃. Читать - имеется ввиду как Валентину Леонтьеву слушать, на ночь 😃.

Не сильно просвещенный, но… в общем Rhino как раз в такое чудо и конвертирует при необходимости. В общем есть, конечно кое что… но не то. Я бы не стал им пользоваться.
😦

Ну да увидел, после сохранения 3D объекта в формате dxf, файл dxf снова можно открыть в Rhino, но он уже не 3D объект. Как будто скелет от 3D объекта. На таком формате вряд ли можно нормально построить рельеф. Все вопрос закрыт.

Obj уже 3D формат. Скинь диван в dxf формате.

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

Эх,Джон Сильвер (JohnSilver, Esq.)был фантазер и обманщик.

Помнится, он был не фантазер, хотя и обманщик.

Угу. Читать - одно удовольствие, даже я так врать придумывать не умею 😃. Читать - имеется ввиду как Валентину Леонтьеву слушать, на ночь 😃.

Обращайтесь, я могу и в мп3 выложить, чтобы на ночь глаза не напрягать 😃

Ну да увидел, после сохранения 3D объекта в формате dxf, файл dxf снова можно открыть в Rhino, но он уже не 3D объект. Как будто скелет от 3D объекта. На таком формате вряд ли можно нормально построить рельеф. Все вопрос закрыт.

Риной не пользовался, а в Cinema4d все и экспортируется, и потом открывается в dxf безпроблемно.
Хотелось бы и в автокаде увидеть, но у меня его нету.

DCLD.ZIP

Честно говоря немного перестал понимать суть темы! Начинали с нуля инструмента… Вопрос JohnSilver: что Вы создаете? Насколько я сначала понял программу для управления станком с ЧПУ. Так? Так зачем же Вам париться с dxf, 3D и т.д. Это забота САМ программ (ArtCAM, VisualMill, Powermill и подобным)!!! А Ваша прога должна хорошо переваривать G-коды и подавать импульсы на моторы. И поверьте, это будет не так просто зделать. Вы не те приоритеты выставили! Не гонитесь за всем сразу! Думаю про двох зайцев слышали…

Честно говоря немного перестал понимать суть темы! Начинали с нуля инструмента… Вопрос JohnSilver: что Вы создаете? Насколько я сначала понял программу для управления станком с ЧПУ. Так? Так зачем же Вам париться с dxf, 3D и т.д. Это забота САМ программ (ArtCAM, VisualMill, Powermill и подобным)!!! А Ваша прога должна хорошо переваривать G-коды и подавать импульсы на моторы. И поверьте, это будет не так просто зделать. Вы не те приоритеты выставили! Не гонитесь за всем сразу! Думаю про двох зайцев слышали…

Суть темы изменилась после вопросов со стороны 😃
По поводу что создаем, по пунктам:

1. Станок.
2. Контроллер станка.
3. Управляющую программу.

Всех чудесных CAM-программ у меня нету, и по ряду причин не будет.

Для того, чтобы программа не подавала импульсы на моторы, и создан контроллер. Ведь, по сути, он умеет всего две важные вещи: выполнить элеменарную команду на перемещение по заданному вектору (т.е. подавать импульсы), и отчитаться о происходящем. Расчет ускорений и калибровка нулей - это, конечно, приятные дополнения, но не более того.

Команда же на перемещение суть неделимая, и выполняется как транзакция в базе даннных, т.е. или выполнилась полностью, или аварийная ситуация.

Повторюсь - фишка команд (с нашей точки зрения) в разгрузке ПК.
Cравните - одна команда для линейного перемещения по вектору занимает 15 байт, даже для RS232 передача (на скорости 33 кбит) занимает меньше милисекунды. После передачи команды я жду раппорта от контроллера о завершении её выполнения. Секунду она будет выполняться, или три минуты - меня мало интересует, все это время ПК занимается чем угодно. Даже если после выполнения команды ПК будет занят - ничего страшного, контроллер вежливо подождет.
В варианте с мачем - та же песня, только все время перемещения ПК со всей дури шимит лпт-портом (в простейшем варианте). Т.е. процессор ЗАНЯТ. Т.е. любая задача, которая сдуру попросит процессорного времени может свести на нет потуги с контролем ускорений.

Возможно мы таки заставим контроллер переваривать G-коды, но это пока в отдаленных планах и, честно говоря, особой необходимости в этом не вижу.
Хотя уже сейчас есть возможность для контроллера обходиться без ПК - т.е. УП генерирует набор команд, заливаем всё это дело на SD или MMC карту, и втыкаем карту в контроллер. Все, после этого он выполняет последовательно все команды до тех пор пока не возникнет аварийная ситуация или пока все команды не выполнятся.

За двух зайцев слышали, конечно. Потому и разделили полномочия - товарищ больше занят УП, а я - контроллером, электроникой и железом. А если вдуматься - то за зайцами гонятся, а мы никуда не спешим.
По поводу dxf - ну так получилось, что два чайника от него оттолкнулись, ну и что? Проблемы нам это никакой не составило, посему и обсуждать нечего.
Да, где-то возможно мы наивны, спорить не буду - но ведь на опыте учатся.

2Zarko: а Вы чего в два часа ночи по форумам шастаете?😃

По поводу что создаем, по пунктам:

1. Станок.
2. Контроллер станка.
3. Управляющую программу.

Всех чудесных CAM-программ у меня нету, и по ряду причин не будет.

Для того, чтобы программа не подавала импульсы на моторы, и создан контроллер. Ведь, по сути, он умеет всего две важные вещи: выполнить элеменарную команду на перемещение по заданному вектору (т.е. подавать импульсы), и отчитаться о происходящем. Расчет ускорений и калибровка нулей - это, конечно, приятные дополнения, но не более того.

Команда же на перемещение суть неделимая, и выполняется как транзакция в базе даннных, т.е. или выполнилась полностью, или аварийная ситуация.

Повторюсь - фишка команд (с нашей точки зрения) в разгрузке ПК.
Cравните - одна команда для линейного перемещения по вектору занимает 15 байт, даже для RS232 передача (на скорости 33 кбит) занимает меньше милисекунды. После передачи команды я жду раппорта от контроллера о завершении её выполнения. Секунду она будет выполняться, или три минуты - меня мало интересует, все это время ПК занимается чем угодно. Даже если после выполнения команды ПК будет занят - ничего страшного, контроллер вежливо подождет.
В варианте с мачем - та же песня, только все время перемещения ПК со всей дури шимит лпт-портом (в простейшем варианте). Т.е. процессор ЗАНЯТ. Т.е. любая задача, которая сдуру попросит процессорного времени может свести на нет потуги с контролем ускорений.

Возможно мы таки заставим контроллер переваривать G-коды, но это пока в отдаленных планах и, честно говоря, особой необходимости в этом не вижу.
Хотя уже сейчас есть возможность для контроллера обходиться без ПК - т.е. УП генерирует набор команд, заливаем всё это дело на SD или MMC карту, и втыкаем карту в контроллер. Все, после этого он выполняет последовательно все команды до тех пор пока не возникнет аварийная ситуация или пока все команды не выполнятся.

За двух зайцев слышали, конечно. Потому и разделили полномочия - товарищ больше занят УП, а я - контроллером, электроникой и железом. А если вдуматься - то за зайцами гонятся, а мы никуда не спешим.
Да, где-то возможно мы наивны, спорить не буду - но ведь на опыте учатся.

2Zarko: а Вы чего в два часа ночи по форумам шастаете?😃

Да. Планы как у всех грандиозные.Боюсь,что все ими и кончится…

К сожалению народ не понимает величия идеи заставить один компьютер
расчитывать путь и одновременно гнать пургу в контроллер.
Есть CAD(проектирование) как правило это в офисе, и есть CAM(изготовление) как правило это в цеху.

Для изготовления просто покупается за 30$ простенький второй и его уже догнохивают у станка.Быстродействия хватает даже у 386-го.И програм никто не пишет,а используют халявные TurboCNC,KCam и др.Которые чудно разбираются с концевиками,скоростями,глубинами,подачами и проходами.
Контроллер конечно можно городить самому.Но вряд-ли ВЫ удивите мир.Скорее всего угрохаете год и явите миру очередной клон 297-298.
Предвидя Ваши возражения,что нет ни офиса ни цеха,а есть только кухня юзают вариант
всеми обожаемого Mach 2-который 2 в одном флаконе.Правда он халявен до 1000 строк.
Основная засада будет с железяками и моторами.Выяснится,что их надо расчитывать, искать и покупать.
Нигде они уже бесплатно не валяются.
Когда через год-1,5 Вы явите миру чудо,выяснится,что производством в стране никто и не собирался заниматься,а в ВПК и своих горе-инженеров валом…
Вот такая выставка нулей…

Да. Планы как у всех грандиозные.Боюсь,что все ими и кончится…

К сожалению народ не понимает величия идеи

Отвлекусь в сторону мемуаров… Все одно про установку нулей, кажется. выяснили…
😁
Некогда собираясь в курилке развлекались фантазиями на тему " а надо сделать… " Ну, скажем утюг с программным управлением, рогатку с самонаведением по звуку, блок управления магнитофоном с заложенными 30 рецептами варки кофе и, соответственно прибамбасами для этого. И что интересно - из кучи идей необузданной фантазии некоторые решения прошли в железо. По скольку фантазировали не только о том, что сделать, но и как сделать. Не все конечно, и не целиком, но достаточно много для того ято бы сказть - фантазии вещь полезная.
😁

Суть темы изменилась после вопросов со стороны 😃

Такой плавающей темы уже давно не видел… 😛

По поводу что создаем, по пунктам:

1. Станок.
2. Контроллер станка.
3. Управляющую программу.

Вот именно, управляющую программу!!! 😃

Всех чудесных CAM-программ у меня нету, и по ряду причин не будет.

Могу поделиться, только в личку… 😉

Для того, чтобы программа не подавала импульсы на моторы, и создан контроллер. Ведь, по сути, он умеет всего две важные вещи: выполнить элеменарную команду на перемещение по заданному вектору (т.е. подавать импульсы), и отчитаться о происходящем. Расчет ускорений и калибровка нулей - это, конечно, приятные дополнения, но не более того.

Команда же на перемещение суть неделимая, и выполняется как транзакция в базе даннных, т.е. или выполнилась полностью, или аварийная ситуация.

Повторюсь - фишка команд (с нашей точки зрения) в разгрузке ПК.
Cравните - одна команда для линейного перемещения по вектору занимает 15 байт, даже для RS232 передача (на скорости 33 кбит) занимает меньше милисекунды. После передачи команды я жду раппорта от контроллера о завершении её выполнения. Секунду она будет выполняться, или три минуты - меня мало интересует, все это время ПК занимается чем угодно. Даже если после выполнения команды ПК будет занят - ничего страшного, контроллер вежливо подождет.
В варианте с мачем - та же песня, только все время перемещения ПК со всей дури шимит лпт-портом (в простейшем варианте). Т.е. процессор ЗАНЯТ. Т.е. любая задача, которая сдуру попросит процессорного времени может свести на нет потуги с контролем ускорений.

Ну это понятно. Как контроллер на который надо равняться посмотрите на DeskCNC (www.deskcnc.com).

Возможно мы таки заставим контроллер переваривать G-коды, но это пока в отдаленных планах и, честно говоря, особой необходимости в этом не вижу.
Хотя уже сейчас есть возможность для контроллера обходиться без ПК - т.е. УП генерирует набор команд, заливаем всё это дело на SD или MMC карту, и втыкаем карту в контроллер. Все, после этого он выполняет последовательно все команды до тех пор пока не возникнет аварийная ситуация или пока все команды не выполнятся.

Возможно, но сначала сделайте рабочий контролер и софт для него…

За двух зайцев слышали, конечно. Потому и разделили полномочия - товарищ больше занят УП, а я - контроллером, электроникой и железом. А если вдуматься - то за зайцами гонятся, а мы никуда не спешим.
По поводу dxf - ну так получилось, что два чайника от него оттолкнулись, ну и что? Проблемы нам это никакой не составило, посему и обсуждать нечего.
Да, где-то возможно мы наивны, спорить не буду - но ведь на опыте учатся.

Пусть не занимаеться товарищ УП! Это ненужно! Лучше разбирайтесь в G-кодах, ускорениях и т.д.

2Zarko: а Вы чего в два часа ночи по форумам шастаете?😃

😒

а) Такой плавающей темы уже давно не видел… 😛
б) Могу поделиться, только в личку… 😉
в) Возможно, но сначала сделайте рабочий контролер и софт для него…
г) Пусть не занимаеться товарищ УП! Это ненужно! Лучше разбирайтесь в G-кодах, ускорениях и т.д.

а) Народу нравится (С) Кин-дза-дза!!!
б) я ж говорил - причин целый ряд (или Вы думаете, шо я гуглить не умею 😃 ?)
в) дык это… контроллер готов. Осталось проверить на собранной системе (читай - пляски с бубном).
г) а нааам хооооочется (с интонацией Матроскина)

😃

2Zarko: а Вы чего в два часа ночи по форумам шастаете?😃

А Вы что там в четыре ищете?
😁 😁 😁

а) Народу нравится (С) Кин-дза-дза!!!
б) я ж говорил - причин целый ряд (или Вы думаете, шо я гуглить не умею 😃 ?)
в) дык это… контроллер готов. Осталось проверить на собранной системе (читай - пляски с бубном).
г) а нааам хооооочется (с интонацией Матроскина)

😃

а) Без коментариев…
в) А как он работает? Почитайте форум! Есть огромное количество схем (которые тоже работают), но вопрос КАК? На макете ничего не увидите. Нужно запускать на станке и смотреть не делает ли пропусков шагов и прочих неприятностей… В Вашем примере пока рано утверждать о полной работоспособности контроллера.
б,г) Я так понял дело принцыпиальное! Сотни людей годами сидят над разработкой софта, стратегий УП и т.д. Вы думаете что сделаете лучше? Вы хоть знаете сколько их есть (стратегий УП)? Правильно здесь писали, Вам надо пообщаться с технологом. Без знания основ механообработки даже не суньтесь в разработку софта. Дело Ваше, не мое время будет потеряно… 😃

А Вы что там в четыре ищете?
😁 😁 😁

😃

1. Станок.
2. Контроллер станка.
3. Управляющую программу.

Всех чудесных CAM-программ у меня нету, и по ряду причин не будет.

По этому поводу мысли такие:
1 - 2 понятно. А вот с третьим пунктом у Вас пока не четкое представление о задаче. Судя по тому, что Вы забираете
в прогу 3D форматы, планируется построитель УП - управляющая программа. Делать этого не стоит. Построение УП в нормальном виде подразумевает их просчет, визуализацию, и с приемлимым касеством прорисовки. Кроме того, неплохо
иметь редактор этих УП. Хоть и редко, но возникает необходимость их коррекции. Мало того, что все это комфортнее делать не за стойкой станка а на нормальном компе, все это потребует и нехилого железа. Для примера - VM обсчитывает 3D деталь средней сложности минуты 2 - 3. Это на 3Ггц компе. Сама задача обработки G кодов с приемлимым качеством,
просчетом ускорений, дуг и т д. тоже не самя простая. В итоге придется на стойку монтировать приличный комп, который мог бы заниматься более полезным делом.
Возьмите на
www.artsoftcontrols.com/artsoft/index/index.htm
демку Мача. Я считаю эту прогу оптимальной для станков подобного применения. Посмотрите как он скомпанован и какие задачи решает. На практике эта прога обеспечивает полный контроль над станком. При этом удобно сделан и
не засорен лишней инфой, поскольку имеет редактор экранов, позволяющий выводить в окна только нужное оператору.
А создание УП - отдельная и весьма емкая задача. Как образец - Visual Mill. Он достаточно гибок в отношении стратегий, но и не так профессионально наворочен как Power Mill.
Есть еще отдельная примочка - Meta Cut. Это редактор - просмотрщик путей. Позволяет комфортно корректировать
готовые УП и выяснять неудобные и непонятные места еще до фактической обработки детали.

Не стоит сливать эти задачи в одну посуду. Будет неудобно.

Теперь о Маче.
Кроме того, Мач поддерживает USB, если оно так нужно. Да и по остальным возможностям вполне соответствует. Надо только разобраться в нем, что далеко не все делают, как показала практика.

Кто-то использует Мач с USB ?

Кто-то использует Мач с USB ?

Насколько знаю никаких приемуществ не дает. Тотже степ-дир, только надо электронику городить. Реализованого никогда не видел.