Activity

Привет всем!

Запускаю на бета-тестирование новую версию GIGAMESH 2.

Функциональность новой версии:

• управления станком с ЧПУ классической схемы (системой трех ортогональных приводов);
• встроенная поддержка некоторых неклассических кинематик (систем неортогональных приводов, в т.ч. параллельных) - биангулярная машина, машина с LambdaZ, граффити-робот a’la Hector (не тестировано);
• 3D - линейная интерполяция G00, G01
• круговая интерполяция G02, G03 в заданной плоскости;
• выбор плоскости круговой интерполяции G17, G18, G19;
• ручное управление приводами с помощью колеса мыши;
• ускоренное движение приводов;
• поддержка LPT-моста
• автоматическое включение приоритета реального времени на время выполнения программы, для обеспечения стабильной работы двигателей;
• останов выполнения программы по внешнему сигналу E-Stop
• управление электроавтоматикой по конфигурируемым М-директивам;
• обработка G4 - пауза;
• контроль скорости обработки (F);
• 3D-визуализация рассчитанной траектории инструмента;
• поддержка платформы x64;

Подробности и архив здесь

“Дискретный - не дискретный” я взял для удобства

Конечно, я просто уточнил…

В частности от величины зазора, например

Конечно же, но это в частности.

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

Шаговый двигатель это не дискретная машина - это синхронных двигатель, но ее можно использовать как дискретную, подавая дискретно изменяющиеся токи в обмотки. Собственно, увеличение кратности микрошага, в пределе до бесконечности, сразу же возвратит мотору его аналоговость 😃
Исходя из принципа действия синхронной машины (идеальной конечно) ШД (идеальный) обязан хорошо и предсказуемо точно работать при идеальном синусе.

Кстати, Анатолий, а точность вашего ЦАП какова, а особенно на краях диапазона? быть может не только и не столько в моторе дело?

А как вы думаете ведет себя ШД на скорости? Ведь ротор имеет инерцию и он не будет притормаживаться там где микрошаги “короткие” (и тем более останавливаться). Это совершенно понятно что погрешности изготовления и темные силы электромагнетизма не дают точного синуса, но вот эти самые кривости и составляют потери в КПД моторов в динамике. Т.е. синус - это идеализированная форма кривой. А вот если ее (форму) менять в зависимости от скорости, то, вероятно это бы весьма было бы полезно для повышения КПД.

Это взято из мануала к ЧПУ Fanuc (перевод с японского |) ), не помню к какой серии.
Вообще-то разные системы ЧПУ понимают Ж-код по-разному, это может быть не нормально, но это факт, так что, видимо, нужно изменять постпроцессор, чтобы было как хочется.

Многие САМ программы делают проги в абсолютных и больше не как , вообще насчет рекомендаций ГОСТа нечего незнаю , но сам знаю что в абсолютных более правильно делать так как нет набегающей погрешности при отработке ЧПУ программы . Кстати не один постпрцессор не пишет 90.1 отдельно для IJK , я первый раз об этом слышу . Каким постом готовить такие проги ЧПУ ?

Насчет ГОСТа, по ссылке сходите - скачается, можно посмотреть. А постпроцессоры не пишут потому что так не рекомендуется, а, например, в фануковском мануале вообще, дословно, сказано так:

Расстояние от начальной точки до центра дуги
Центр дуги определяется адресами I, J, K для осей X, Y, Z. Числовые значения I, J, K представляют собой вектор из начальной точки до центра дуги и всегда указываются в относительных координатах независимо от G90 и G91.

Само собой я ставлю G90 , но всеравно EMC не видит круговую интерполяцию в абсолютных координатах . Вот попробуйте напишите у себя в EMC следующее , координаты сначало стоят по нулям :
G01G90X0Y10F1000
G02G17G90X0Y10I0J0F1000

G90 воздействует на XYZ, а на IJK воздействует G90.1:

G90.1 Absolute Distance Mode for I, J & K offsets

т.е. можно попробовать
G90
G90.1
G01X0Y10F1000
G02G17X0Y10I0J0F1000
а, вообще, даже советский ГОСТ не рекомендует программировать IJK в абсолютных координатах: см. п.4.3.3…

Верно ли я понял. Рассмотрим систему ШД – редуктор – рейка (или винт). Компенсация люфтов нужна в том случае, если в передаче «винт-гайка» или «рейка-шестерня» присутствуют зазоры. Эти зазоры можно устранить разными механическими способами, что соответственно и надежнее.

Верно 😃

Если редуктор допускает люфт, то может стоит использовать дополнительные входы контроллера для подключения энкодера к винту или приводной шестерни. Все равно контроллер работает с собственными сигналами dir и step и не привязывается к МАСН3.

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

ИМХО все равно на каком принципе работает Smoothstepper - то ли он step dir буфферит то ли обрабатывает полиномы. По идее если первоначальным источником выступает Mach3, то всегда можно написать макрос в котором при изменении направления по той или иной оси будуд добавляться н-ое кол-во шагов.
И уже с учетом этого макроса Mach будет выдавать теже полиномы на степпер.Т.е абсолютно не обязательно в полином траектории обработки добавлять выборку шагов , можно просто при изменении направления движения добавлять отдельный полином описывающий только выборку люфта а потом уже сама траектория обработки детали.

Представляем картину: есть три параметрических полинома, синхронизированные во времени, собственно, параметром. В одну из траекторий нужно вставить кусок выборки люфта. Вставляем, что делать с остальными? Окей, они просто стоят, тогда как быть с кривыми разгона-торможения, а c lookahead? С какой скоростью проходить smoothstepper`у участок выборки люфта? Это не конкретные проблемы реализации, а так сказать, концептуальные проблемы - чисто для размышлений.
Все эти проблемы, конечно решаемы, но повторюсь, они совсем не так просты как кажется. Эта проблема сама по себе не проблема - проблемой является совокупность проблем с этой проблемой связанных. О завернул… 😁
Подчеркну, я не знаю досконально как устроен обмен данными между мачем и степпером (но немного знаком с задачей выборки люфта в NC-программе), поэтому все что пишу про smoothstepper - мои предположения. С другой стороны, не думаю что разработчики где-то напишут почему их продукт не выполняет какую-то конкретную функцию.

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

Подозреваю, что народ просто жалуется на то, что в степпере нет встроеенной выборки люфта и ее надо описывать в Маке. ИМХО.

Народ не спроста жалуется. ИМХО )))

На сколько я представляю smoothstapper это так сказать интерпретатор сигналов step dir и т.д. для Mach3 . И самостоятельно он G коды не обрабатывает.

Smoothstepper не обрабатывает G-коды, но и не работает с step-dir. В него траектория передается в виде параметрических полиномов, т.е. мач преобразует траекторию G-кодов в траектории приводов. Видимо вставка выборки люфта в такое представление траектории не совсем тривиальная штука.
Ссылку на источник не даю - не нашел, пишу то что помню, а читал об этом давно.

Вышла стабильная версия программы GIGAMESH для управления 3-координатным картезианским станком (портальный, консольный).

Возможности:

• управление станком с ЧПУ классической схемы (системой трех ортогональных приводов) по протоколу step/dir;
• 3D - линейная интерполяция G00, G01;
• круговая интерполяция G02, G03 в заданной плоскости;
• выбор плоскости круговой интерполяции G17, G18, G19;
• ручное управление приводами с помощью колеса мыши;
• ускоренное движение приводов;
• поддержка LPT-моста;

Реализовано удобное автоматическое включение приоритета реального времени при исполнении управляющей программы для исключения (уменьшения) нестабильности работы двигателей.
Скачать можно здесь.

…Ну да это управляющая программа на трубу получиться

Теперь все понятно с подготовкой УП: существует специализированный CAD-CAM (CADWIND или CADFIL), который выдает G-код - программу на оболочку. PMAC - один из вариантов ЧПУ-контроллера.

В этом то и ограничения.

Дыкть это понятно, что УП могут быть разными, я просто образец такой программы спрашиваю - пошшупать…

Возможно, не совсем корректный вопрос: как описываются оболочки для их реализации на станке? Существует ли вообще такое понятие как управляющая программа для какой-то конкретной оболочки?

Какие то оболочки … найти можно где меняеться парамтеров по 7-8 Ну там диаметр, количество проходов, углы по проходу и тд. Но теряеться весь смысл ЧПУ тогда.

Я так понимаю это как раз про такую программу? Тогда не понятно почему смысл теряется?

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

Еще внимательнее посмотрел, точно - в исходной строке присутствует IJ и R одновременно. Вот именно на это ругается.

spike, а то что в Z такое (на мой взгляд) странное число - нормально? Или это просто глюк, мало того что Z не должно быть, а оно в добавок ещё и кривое?

Да не, нормальное оно, пробелы расставляем и вот:
G03 X6.201 Y26.989 Z-1.9 I7.535 J26.989 R1.334 F92.0

Z может и присутствовать он ведь не изменяется - стандарт не нарушается, но вот Мачу не нравится… А вообще смещение по Z образует спиральную интерполяцию.

Ему не нравится то, что присутствуют XYZ одновременно - круговая интерполяция G02(03) может быть описана только для одной из координатных плоскостей (XY, YZ или ZX). Т.к. присутствует смещение центра окружности I и J - по X и Y, соответственно, перемещение по Z вообще присутствовать в этой строке не должно.
Что делать? Надо разобраться откуда такая строка появилась. Или просто выкинуть Z.
А да, точно, Z не изменяется оносительно предыдущих строк - ее просто выкинуть, да и плоскость интерполяции выбрана XY (G17).

а у этих прог скважность равна 2.(предположение, сам эти проги не щупал)

Не скажу как в lpttest, но в GIGAMESH`е длительность таймаута регулируется - по умолчанию это 100мкс.

…
тестил электронику при помощи двух прог
lpttest и GIGAMESH2 H v.2.2.8

но результаты не впечатлили… пропуски шагов…

Может быть будет интересно вот это: Не документированная фича…

После интерполяции, циферки бегут, моторчики слегка пищат, но все стоит.

А вас не затруднил бы один эксперимент: переименуйте файл inpout32.dll во что нибудь типа такого inpout32_.dll (чтобы его не затереть) и разархивируйте в папку программы вот этот файлик. Попробуйте выполнить какую нибудь маленькую программку (достаточно просто одной строки типа G00 X10 Y10). После этого должен появиться файл DlPort_log.txt - закиньте его мне. Заранее спасибо огромное!

Из пожеланий:
желательно бы добавить возможность ручного перемещения, только кнопками курсора, а то на моем блокноте скролл вообще не работал.
И еще: процесс “интерполяции” занимает время сравнимое с временем обработки. А если деталь обрабатывать часов на пять - то и “интерполировать” прийдется столько же?

Кнопки и ручное управление с помощью Ж-кода будет.
А вот насчет интерполяции - пока, наверное, так. - Работаем над этим… одновременно по трем направлениям: 1 - ускорение работы интерполятора; 2 - сохранение готовой для исполнения программы и 3 - освобождение РС от функции непосредственного управления драйверами (генерации step-dir).

Небольшая поправка в программе - теперь по умолчанию плоскость интерполяции задана XY. Обычно в стойках ЧПУ (и в turbocnc) так и сделано и некоторые постпроцессоры пропускают инициализацию G17.
Теперь принимает оба файла. Закачку обновил.

Мачевский съел. А вот с турбоцнцшным - косячокс… не нравится ему I и J - нужен R. Поправлю в ближайшее время.
Спасибо за помощь!

Функционал программы невелик, но все мне известные файлы ей понимаются. Ну т.е. коды G00, G01, G02, G03, G17, G18, G19 она понимает практически в любом виде. Единственно, дуга не должна быть >180°.
Для кадров, которые GIGAMESH при интерполяции заливается голубыи поле “Ж-код” - это означает что данную команду он понял и обработал и зеленым поле “Шагов”, также в нем показывается количество шагов в этом кадре.
ArtCAM`ом, к сожалению я не пользуюсь - у меня MasterCAM, поэтому конкретный постпроцессор я назвать не могу. Если не затруднит, сделайте файл в каком нибудь “дефолтном” (ну или стандартном) постпроцессоре и попробуйте или покажите его мне.

Хотел бы сказать Вам спасибо за то что Вы пытаетесь сделать эту программу .
Вопрос , почему то , когда запускаю G-код , скорость заложенная в G-коде не отрабатывается правильно , у меня заложенно 50 мм в мин а отрабатывается намного с большей скоростью ?

Спасибо Вам за поддержку. Пока поддержание скорости подачи не реализовано. Скорость ограничивается только установленной максимальной скоростью приводов (пока также лишь одной на все оси).

Вышла стабильная версия программы GIGAMESH для управления 3-координатным картезианским станком (портальный, консольный).

Возможности:

• управление станком с ЧПУ классической схемы (системой трех ортогональных приводов) по протоколу step/dir;
• 3D - линейная интерполяция G00, G01;
• круговая интерполяция G02, G03 в заданной плоскости;
• выбор плоскости круговой интерполяции G17, G18, G19;
• ручное управление приводами с помощью колеса мыши;
• ускоренное движение приводов;
• поддержка LPT-моста;

Здесь можно подробнее почитать о программе, а также скачать полную рабочую версию и краткую инструкцию к ней .

Программа GIGAMESH2 H бесплатна для любого применения.

С уважением, spike.

Э…, наверно будет правильнее сказать, что скорость перемещения задаётся для инструмента, а не для какой-то конкретной оси.

Совершенно верно, директивой F задается скорость инструмента вообще (тангенциальная или касательная скорость).

Я дико извиняюсь за неадекватность

В чем ваша “неадекватность”? 😉

Но это последовательность основных G кодов (причем - я не понял суть последовательности) - а если высота безопасности выше 0?

Эти коды задают последовательность отвода инструмента после обработки.
Тут, конечно же, предполагается что в координатах станка Z=0 абсолютно безопасная высота (выше поднять инструмент типа нельзя…).
если на пальцах:
G91 G0 G28 Z0. - поднимает инструмент до HOME по Z
G28 X0. Y0. A0. - перемещает инструмент в HOME по X, Y, A
эти строки в самом конце УП.

…по активации возврата координат в 0…

Если суть проблемы в последовательности отвода инструмента после обработки по G28, то попробуйте так:
G91 G0 G28 Z0.
G28 X0. Y0. A0.

А при чем тут мач то ? Тут надо постпроцессор какой то умный ну и прогу соответстывенно.

Возможно что это тоже вариант, но кто проверит?

Мало кто обратил внимание - но точность обработки профиля у данной штуки будет по центру куда выше чем с краев.

Почему же это? 😉

…не могу ни как найти пока ссылку - там вроде как и про программу что то было…

Cсылка…

ага, понял, тоже вариант, что плохо - сильно избыточен, 4 степени свободы = 6 приводов

…Это то что я предлагал.

Можно конечно расширить рамку, разнести консоли метров на 10, тогда эти искажения на некрупных деталях будут не сильно заметны…

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

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

Пусть лучше программа извращается… 😉

…добавить снизу еще два шд…

совсем не понял, куда добавить?

Вы что предлагаете? Програмно сближать вируальные полоскости? Или механически делать рамку шире во время работы станка?

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

Нипонял, никак не могу понять смысл вашего поста…

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

Хотя на эти искажения тоже можно внести программные поправки…

да можно, но при этом придется задающие контура делать приближенными к центру пролета, т.е. нужно сузить рабочее пространство (или расширить рамку).

техническая сторона идентична АБСОЛЮТНО

не аргумент.

Пиарить просто не хочу ни его ни нас…

ё-моё что так осторожничать? во всей “необъятной” людей,которые занимаются ЧПУ и тусуются на форумах от силы 10000. Что так друг друга боимся?

Мы не конкуренты ни кому…

А кто вы? чего стесняетесь? я так понимаю robozone.su ? 😃

…есть ньюансы, которые кроме нас ранее ни кем в открытый
доступ не выкладывались…

елки, так в чем же фишка? ответьте - сделайте себе рекламу!

…слово “концепция” пропустили… жаль… а это уже весч, на которую можно реально получить патент со всеми вытекающими, только в нашей “необъятной” пока это дело не в ходу…все поправимо …

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

а вообще:

В любом случае закрепление авторского права - удел именно того, кто мало на что способен.
Или учебного заведения - для престижу.
А так… Изобрёл - воплоти и двигайся дальше быстрыми темпами.
Изобретение не есть что-то иное, кроме открытого нового пути движения.

wis, а несколько подробнее (техническую сторону) можно? Ну типа конкретика: сравнение вашего решения и решения celladon`a. Хотелось бы понимать что к чему, а пока кроме “сперли” ничего не понятно.
А вообще на celladon`a наезд по всему рунету идет, неужели он действительно такой негодяй, или это недобросовестная конкуренция? 😃
P.S.: а деньги и силы лучше на дело пустить - конкурировать в нашей стране между собой - как в тундре не разойтись… ИМХО; кетайцам вы что предъявите, если они у вас идеи “сопрут”?

GOOD DAY, GOOD!
Вай, вай, вай! GOOD! как всегда! искрометная изобретательность! Как обычно - в сборники…

…если твоя прога будет поддерживать такую механику…

Что раньше, курица или яйцо? Как отлаживать программу? если нет машины? Говорю ведь - сам когда нибудь сделаю такую штуковину и не только такую, только когда это будет? А людям на какого-то spike`а надеяться и делать экзотику, ну как-то неправильно…

А если по делу - можт у кого есть четыре свободных привода? попробуем такую машинку замутить наскоряк?

…приму посильное участие…

Подробней можно… Предыстория такая: когда-то мой неокрепший мозх был вынесен идеей гексапода (впрочем это не прошло:)), вот тогда и возник вопрос о том как управлять им - чтобы как-то решить его я начал разработку программы.
Основной задачей было обеспечение возможности расчета траектории для станка (робота, манипулятора) с любой кинематической схемой, при этом описание траектории обычное, для картезианской (оси координат совпадают с векторами подач или осями вращения) машины. Эту задачу я решил, есть некоторые проблемы, но они устраняются по мере обнаружения.
Сам по себе интерполятор не интересен - нужна программа для управления станком. Подумал что народу будет интересно принять участие в разработке и тестировании - на основе этого интерполятора была написана программа GIGAMESH 1H для управления обычным станком. Но народу видимо некогда или интереса нет… понятно почему… ☕ Короче, сам потихоньку работаю над проектом, сделал вот фрезер себе - сразу несколько проблем выявилось.
Работа программы с нетрадиционной кинематикой проверилась на биангулярной машинке (см. ссылку выше).
Вот зазываю народ попробовать что нибудь сделать, можт кто отзовется… Я-то конечно и сам сделаю, но сообща-то и веселей и быстрей… 😃

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

Товарищи! еще раз говорю, программа GIGAMESH изначально разрабатывалась для управления кинематическими схемами отличными от обычных ортогональных, в том числе и такой схемой. Поддерживается обычный Ж-код и обычные step/dir-контроллеры, работает под обычной виндой.
Но! Для того чтобы такой механикой управлять нужна эта механика, кто ее сделает? Будьте уверены, на первых этапах работы над такой механикой программа уже будет готова. Для того чтобы адаптировать ее под конкретную кинематическую схему необходимо написать (даже не написать а изменить) всего лишь один программный модуль. Именно так это было сделано для вот этой нетрадиционной машинки.
Еще раз подчеркну, я не считаю свою программу совершенной, и, однозначно в процессе работы вылезут какие-то проблемы и ньюансы.
Если кто-то все-таки решится сделать такую пенорезку велкам.

Спор не очем.

А никто и не спорит, особо про пускатели… 😃 просто мысли об идентификации КЗ…