Выставить ноль после смены инструмента.
Честно говоря немного перестал понимать суть темы! Начинали с нуля инструмента… Вопрос JohnSilver: что Вы создаете? Насколько я сначала понял программу для управления станком с ЧПУ. Так? Так зачем же Вам париться с dxf, 3D и т.д. Это забота САМ программ (ArtCAM, VisualMill, Powermill и подобным)!!! А Ваша прога должна хорошо переваривать G-коды и подавать импульсы на моторы. И поверьте, это будет не так просто зделать. Вы не те приоритеты выставили! Не гонитесь за всем сразу! Думаю про двох зайцев слышали…
Честно говоря немного перестал понимать суть темы! Начинали с нуля инструмента… Вопрос JohnSilver: что Вы создаете? Насколько я сначала понял программу для управления станком с ЧПУ. Так? Так зачем же Вам париться с dxf, 3D и т.д. Это забота САМ программ (ArtCAM, VisualMill, Powermill и подобным)!!! А Ваша прога должна хорошо переваривать G-коды и подавать импульсы на моторы. И поверьте, это будет не так просто зделать. Вы не те приоритеты выставили! Не гонитесь за всем сразу! Думаю про двох зайцев слышали…
Суть темы изменилась после вопросов со стороны 😃
По поводу что создаем, по пунктам:
- Станок.
- Контроллер станка.
- Управляющую программу.
Всех чудесных CAM-программ у меня нету, и по ряду причин не будет.
Для того, чтобы программа не подавала импульсы на моторы, и создан контроллер. Ведь, по сути, он умеет всего две важные вещи: выполнить элеменарную команду на перемещение по заданному вектору (т.е. подавать импульсы), и отчитаться о происходящем. Расчет ускорений и калибровка нулей - это, конечно, приятные дополнения, но не более того.
Команда же на перемещение суть неделимая, и выполняется как транзакция в базе даннных, т.е. или выполнилась полностью, или аварийная ситуация.
Повторюсь - фишка команд (с нашей точки зрения) в разгрузке ПК.
Cравните - одна команда для линейного перемещения по вектору занимает 15 байт, даже для RS232 передача (на скорости 33 кбит) занимает меньше милисекунды. После передачи команды я жду раппорта от контроллера о завершении её выполнения. Секунду она будет выполняться, или три минуты - меня мало интересует, все это время ПК занимается чем угодно. Даже если после выполнения команды ПК будет занят - ничего страшного, контроллер вежливо подождет.
В варианте с мачем - та же песня, только все время перемещения ПК со всей дури шимит лпт-портом (в простейшем варианте). Т.е. процессор ЗАНЯТ. Т.е. любая задача, которая сдуру попросит процессорного времени может свести на нет потуги с контролем ускорений.
Возможно мы таки заставим контроллер переваривать G-коды, но это пока в отдаленных планах и, честно говоря, особой необходимости в этом не вижу.
Хотя уже сейчас есть возможность для контроллера обходиться без ПК - т.е. УП генерирует набор команд, заливаем всё это дело на SD или MMC карту, и втыкаем карту в контроллер. Все, после этого он выполняет последовательно все команды до тех пор пока не возникнет аварийная ситуация или пока все команды не выполнятся.
За двух зайцев слышали, конечно. Потому и разделили полномочия - товарищ больше занят УП, а я - контроллером, электроникой и железом. А если вдуматься - то за зайцами гонятся, а мы никуда не спешим.
По поводу dxf - ну так получилось, что два чайника от него оттолкнулись, ну и что? Проблемы нам это никакой не составило, посему и обсуждать нечего.
Да, где-то возможно мы наивны, спорить не буду - но ведь на опыте учатся.
2Zarko: а Вы чего в два часа ночи по форумам шастаете?😃
По поводу что создаем, по пунктам:
- Станок.
- Контроллер станка.
- Управляющую программу.
Всех чудесных CAM-программ у меня нету, и по ряду причин не будет.
Для того, чтобы программа не подавала импульсы на моторы, и создан контроллер. Ведь, по сути, он умеет всего две важные вещи: выполнить элеменарную команду на перемещение по заданному вектору (т.е. подавать импульсы), и отчитаться о происходящем. Расчет ускорений и калибровка нулей - это, конечно, приятные дополнения, но не более того.
Команда же на перемещение суть неделимая, и выполняется как транзакция в базе даннных, т.е. или выполнилась полностью, или аварийная ситуация.
Повторюсь - фишка команд (с нашей точки зрения) в разгрузке ПК.
Cравните - одна команда для линейного перемещения по вектору занимает 15 байт, даже для RS232 передача (на скорости 33 кбит) занимает меньше милисекунды. После передачи команды я жду раппорта от контроллера о завершении её выполнения. Секунду она будет выполняться, или три минуты - меня мало интересует, все это время ПК занимается чем угодно. Даже если после выполнения команды ПК будет занят - ничего страшного, контроллер вежливо подождет.
В варианте с мачем - та же песня, только все время перемещения ПК со всей дури шимит лпт-портом (в простейшем варианте). Т.е. процессор ЗАНЯТ. Т.е. любая задача, которая сдуру попросит процессорного времени может свести на нет потуги с контролем ускорений.Возможно мы таки заставим контроллер переваривать G-коды, но это пока в отдаленных планах и, честно говоря, особой необходимости в этом не вижу.
Хотя уже сейчас есть возможность для контроллера обходиться без ПК - т.е. УП генерирует набор команд, заливаем всё это дело на SD или MMC карту, и втыкаем карту в контроллер. Все, после этого он выполняет последовательно все команды до тех пор пока не возникнет аварийная ситуация или пока все команды не выполнятся.За двух зайцев слышали, конечно. Потому и разделили полномочия - товарищ больше занят УП, а я - контроллером, электроникой и железом. А если вдуматься - то за зайцами гонятся, а мы никуда не спешим.
Да, где-то возможно мы наивны, спорить не буду - но ведь на опыте учатся.2Zarko: а Вы чего в два часа ночи по форумам шастаете?😃
Да. Планы как у всех грандиозные.Боюсь,что все ими и кончится…
К сожалению народ не понимает величия идеи заставить один компьютер
расчитывать путь и одновременно гнать пургу в контроллер.
Есть CAD(проектирование) как правило это в офисе, и есть CAM(изготовление) как правило это в цеху.
Для изготовления просто покупается за 30$ простенький второй и его уже догнохивают у станка.Быстродействия хватает даже у 386-го.И програм никто не пишет,а используют халявные TurboCNC,KCam и др.Которые чудно разбираются с концевиками,скоростями,глубинами,подачами и проходами.
Контроллер конечно можно городить самому.Но вряд-ли ВЫ удивите мир.Скорее всего угрохаете год и явите миру очередной клон 297-298.
Предвидя Ваши возражения,что нет ни офиса ни цеха,а есть только кухня юзают вариант
всеми обожаемого Mach 2-который 2 в одном флаконе.Правда он халявен до 1000 строк.
Основная засада будет с железяками и моторами.Выяснится,что их надо расчитывать, искать и покупать.
Нигде они уже бесплатно не валяются.
Когда через год-1,5 Вы явите миру чудо,выяснится,что производством в стране никто и не собирался заниматься,а в ВПК и своих горе-инженеров валом…
Вот такая выставка нулей…
Да. Планы как у всех грандиозные.Боюсь,что все ими и кончится…
К сожалению народ не понимает величия идеи
Отвлекусь в сторону мемуаров… Все одно про установку нулей, кажется. выяснили…
😁
Некогда собираясь в курилке развлекались фантазиями на тему " а надо сделать… " Ну, скажем утюг с программным управлением, рогатку с самонаведением по звуку, блок управления магнитофоном с заложенными 30 рецептами варки кофе и, соответственно прибамбасами для этого. И что интересно - из кучи идей необузданной фантазии некоторые решения прошли в железо. По скольку фантазировали не только о том, что сделать, но и как сделать. Не все конечно, и не целиком, но достаточно много для того ято бы сказть - фантазии вещь полезная.
😁
Суть темы изменилась после вопросов со стороны 😃
Такой плавающей темы уже давно не видел… 😛
По поводу что создаем, по пунктам:
- Станок.
- Контроллер станка.
- Управляющую программу.
Вот именно, управляющую программу!!! 😃
Всех чудесных CAM-программ у меня нету, и по ряду причин не будет.
Могу поделиться, только в личку… 😉
Для того, чтобы программа не подавала импульсы на моторы, и создан контроллер. Ведь, по сути, он умеет всего две важные вещи: выполнить элеменарную команду на перемещение по заданному вектору (т.е. подавать импульсы), и отчитаться о происходящем. Расчет ускорений и калибровка нулей - это, конечно, приятные дополнения, но не более того.
Команда же на перемещение суть неделимая, и выполняется как транзакция в базе даннных, т.е. или выполнилась полностью, или аварийная ситуация.
Повторюсь - фишка команд (с нашей точки зрения) в разгрузке ПК.
Cравните - одна команда для линейного перемещения по вектору занимает 15 байт, даже для RS232 передача (на скорости 33 кбит) занимает меньше милисекунды. После передачи команды я жду раппорта от контроллера о завершении её выполнения. Секунду она будет выполняться, или три минуты - меня мало интересует, все это время ПК занимается чем угодно. Даже если после выполнения команды ПК будет занят - ничего страшного, контроллер вежливо подождет.
В варианте с мачем - та же песня, только все время перемещения ПК со всей дури шимит лпт-портом (в простейшем варианте). Т.е. процессор ЗАНЯТ. Т.е. любая задача, которая сдуру попросит процессорного времени может свести на нет потуги с контролем ускорений.
Ну это понятно. Как контроллер на который надо равняться посмотрите на DeskCNC (www.deskcnc.com).
Возможно мы таки заставим контроллер переваривать G-коды, но это пока в отдаленных планах и, честно говоря, особой необходимости в этом не вижу.
Хотя уже сейчас есть возможность для контроллера обходиться без ПК - т.е. УП генерирует набор команд, заливаем всё это дело на SD или MMC карту, и втыкаем карту в контроллер. Все, после этого он выполняет последовательно все команды до тех пор пока не возникнет аварийная ситуация или пока все команды не выполнятся.
Возможно, но сначала сделайте рабочий контролер и софт для него…
За двух зайцев слышали, конечно. Потому и разделили полномочия - товарищ больше занят УП, а я - контроллером, электроникой и железом. А если вдуматься - то за зайцами гонятся, а мы никуда не спешим.
По поводу dxf - ну так получилось, что два чайника от него оттолкнулись, ну и что? Проблемы нам это никакой не составило, посему и обсуждать нечего.
Да, где-то возможно мы наивны, спорить не буду - но ведь на опыте учатся.
Пусть не занимаеться товарищ УП! Это ненужно! Лучше разбирайтесь в G-кодах, ускорениях и т.д.
2Zarko: а Вы чего в два часа ночи по форумам шастаете?😃
😒
а) Такой плавающей темы уже давно не видел… 😛
б) Могу поделиться, только в личку… 😉
в) Возможно, но сначала сделайте рабочий контролер и софт для него…
г) Пусть не занимаеться товарищ УП! Это ненужно! Лучше разбирайтесь в G-кодах, ускорениях и т.д.
а) Народу нравится (С) Кин-дза-дза!!!
б) я ж говорил - причин целый ряд (или Вы думаете, шо я гуглить не умею 😃 ?)
в) дык это… контроллер готов. Осталось проверить на собранной системе (читай - пляски с бубном).
г) а нааам хооооочется (с интонацией Матроскина)
😃
2Zarko: а Вы чего в два часа ночи по форумам шастаете?😃
А Вы что там в четыре ищете?
😁 😁 😁
а) Народу нравится (С) Кин-дза-дза!!!
б) я ж говорил - причин целый ряд (или Вы думаете, шо я гуглить не умею 😃 ?)
в) дык это… контроллер готов. Осталось проверить на собранной системе (читай - пляски с бубном).
г) а нааам хооооочется (с интонацией Матроскина)😃
а) Без коментариев…
в) А как он работает? Почитайте форум! Есть огромное количество схем (которые тоже работают), но вопрос КАК? На макете ничего не увидите. Нужно запускать на станке и смотреть не делает ли пропусков шагов и прочих неприятностей… В Вашем примере пока рано утверждать о полной работоспособности контроллера.
б,г) Я так понял дело принцыпиальное! Сотни людей годами сидят над разработкой софта, стратегий УП и т.д. Вы думаете что сделаете лучше? Вы хоть знаете сколько их есть (стратегий УП)? Правильно здесь писали, Вам надо пообщаться с технологом. Без знания основ механообработки даже не суньтесь в разработку софта. Дело Ваше, не мое время будет потеряно… 😃
А Вы что там в четыре ищете?
😁 😁 😁
😃
- Станок.
- Контроллер станка.
- Управляющую программу.
Всех чудесных 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 ?
Насколько знаю никаких приемуществ не дает. Тотже степ-дир, только надо электронику городить. Реализованого никогда не видел.
Насколько знаю никаких приемуществ не дает. Тотже степ-дир, только надо электронику городить. Реализованого никогда не видел.
Совершенно справедливо. Преимущество только в большей длинне кабеля связи и в количестве жил и большей защищенностью от помех. Так же как и с СОМ портом. Но расплачиваться приходится преобразованием их сигналов в паралельный. Впрочем, это не только Мачевское. Остальные проги управления работают с этими портами точно так же.
Реализаций с USB не видел. А вот СОМ портом пользуются, кому надо отнести станок на приличное расстояние от компа.
Совершенно справедливо. Преимущество только в большей длинне кабеля связи и в количестве жил и большей защищенностью от помех. Так же как и с СОМ портом. Но расплачиваться приходится преобразованием их сигналов в паралельный. Впрочем, это не только Мачевское. Остальные проги управления работают с этими портами точно так же.
Реализаций с USB не видел. А вот СОМ портом пользуются, кому надо отнести станок на приличное расстояние от компа.
Все совсем не так.
USB - версия должна в десятки раз быть более скоростной (по частотам STEP). И только из-за этого городят все эти расширения в виде отличных от LPT, типа самостоятельных карт.
USB - версия должна в десятки раз быть более скоростной (по частотам STEP).
И каков физический смысл гонки???
Совсем ушли от темы 😉 . Мненя интересует как устроить замер инструмента в KCam4.
Совсем ушли от темы 😉 . Мненя интересует как устроить замер инструмента в KCam4.
Ну вот! Пришел лесник и всех разогнал!
😵
😁 😁
А разве мы это забыли обсудить? Вроде где то в начале все расписали.
И каков физический смысл гонки???
Да гонки то и нет, собственно. Просто достаточно взять калькулятор и посчитать возможности LPT-порта. И потом совместить их с например микрошаговым приводом с 16-ю микрошагами и передачей 2/1. Или с серво-приводом, управляемым классическим STEP-DIR - а ведь серво легко крутится на 3000 об/мин - вот и посчитайте, сколько ему нужно импульсов при енкодере например 1000cpr… Или с енкодером на 5000cpr - вот сейчас ставлю на 4-ю координату…
Вообще вся эта гонка за скоростями совсем неактуальна, потому что реальная обработка ведется довольно медленно. Глобально высокие (50мм/сек и выше) скорости нужны для чистовой обработке с малым съёмом, ну и для быстрых перемещений.
То есть скорости крайне актуальны на производстве. С чем сам столкнулся - станки работают без перерыва, и очередь еще к ним…
Да гонки то и нет, собственно. Просто достаточно взять калькулятор и посчитать возможности LPT-порта.
Простите, конечно, но на сколько мне известно управлять непосредственно последовательным кодом никто, пока не придумал. Стало быть предлагается для повышения быстродействия вклинить дополнительные поеобразователи и…
придти опять же к паралельнму выходу. Мне кажется несколько замысловато такое ускорение.
😃
Вот по поводу скоростных приводов, полностью согласен. Между ним и материалом вклинился инструмент, который, по несознательности своей, никак не хочет резать быстрее, чем может.
😁 😁
а что скорость? насколько скорость usb больше, чем lpt? 😃 к тому же, usb живет своей жизнью, в отличие от lpt, и там возможны всякие плохо контролируемые задержки. если уж использовать usb, то по самому кабелю надо гнать не импульсы, а команды типа g-кода. тогда нужен умный контроллер, соответственно.
если уж использовать usb, то по самому кабелю надо гнать не импульсы, а команды типа g-кода. тогда нужен умный контроллер, соответственно.
С переферией так и происходит. USB, фактически логическое продолжение тенденции. По мере совершенствования базы
переферийные устройства становятся умными. Имея свои мозги они требуют теперь минимума каналов для обмена.
Когда то ведь все усторойства управлялись ЦП.
Но, тут вопрос в назначении каналов. LPT всегда был плохо защищен. Отсюда и появление COM портов. Они построены по принципу токовой петли и значительно, в десятки раз устойчивее к помехам. USB тоже хорошо защищен. Но вот с удобством использования у них явный провал перед LPT.
С удобством как раз все нормально. Просто это последовательные шины. Для реализации управления несколькими двигателями нужно городить некий протокол поверх. С учетом критичности ко времени (не скорости!, а именно точности временных интервалов) это нетривиальная задача.
А lpt - параллельный интерфейс. Там все проще некуда.