Российские ЧПУ-контроллеры Инектра (INECTRA)

[rstm]

Даже для ручных перемещений с клавиатуры им пришлось костыли дописывать. Потому что нет в G-коде таких команд.

О, да! Ручные перемещения там, это "боль и унижение"! (на влмил в разы лучше)

[michael-yurov]

а зачем больше? вроде linuxcnc тоже нормально штатно работает с 1Khz
тогда всего 2000 блоков )

Практика показывает, что 1 кГц маловато. Особенно, учитывая, что у LinuxCNC и Mach3 на выход Step Dir в течение сервоцикла выдается целочисленное количество импульсов. На частоте 1005 Гц получим 5 подергиваний в секунду при движении.
После обработки степмастером, у которого сервоцикл 10 кГц и нет целочисленного квантования, сильно возрастает стабильность работы (исчезают срывы моторов), при этом еще и ускорение можно поднять в разы.
Хотя, для большинства задач 1кГц хватает, но, например, для гравировки мелких деталей на маленьком станочке с высокооборотистым шпинделем может быть и недостаточно. Не столько из за срывов, сколько из за возникающих вибраций при движении по траектории.

[Igor Burtsev]

Итак. Ещё один установленный контроллер и довольный клиент. На этот раз наш подопытный обычный MSC-3U. В этот раз получилось немного поэкспериментировать и есть забавные наблюдения.

Устанавливал в замену "стоковому" RichAuto A11E который произвольно глючил и перепрошивка результата не дала. Сама установка прошла "как по маслу" так как все банально стандартно. Опять же шиворот на выворот управление драйверами. Но то мелочи. И немного пришлось повозиться с настройками концевиков, так как на станке стояли NPN NC.
По ПК. В качестве подопытного достался слабенький мини пк на целерончике с 4гб ОЗУ и со встройкой видеокартой. ОС win10 x64 pro обычной. Программа запускается и в общем траектории до 20-30Мб съедает без проблем. Что клиента вполне устроило. Предупредил об прожорливости и оптимизации. Из уже неоднократно замеченных минусов это трындец на экранах 4:3 с разрешением меньше SXGA. Окна не маштабируются, часть важной информации уходит за края экрана и приходится постоянно скролить. Это прям жирный минус. Для комфортной работы в идеале минимум нужен экран WSXGA+ в формате 16:10 или fullHD 16:9. На фото видно как выглядит программа в разрешении 1024*768 часть окна ПЕРЕМЕЩЕНИЯ "упало" не видно не шага не скорости. Визуализатор не работает. Из за отсутствия нормальных драйверов на этой встройке. Да и толку его на таком размере. Короче в этом направлении можно было бы и доработать программу.
Из плюсов: запущенную программу свернул в трей и запустил паралельно браузер с парой десятками вкладок и вишенкой на торте видео в "4к" с Ютуба. Чтобы выгрузить ПК в 100% по процессору и ~90% по ОЗУ. Никаких рывков запинаний или ещё каких проблем в работе станка при этом не случилось. Хотя ПК фактически слайд-шоу показывал вместо видео. Подобный эксперимент не mach3 не ncstudio не проходила к слову. Это говорит о том, что теоретически вполне можно свободно пользоваться ПК при работающей в фоне Инектрой. Следующим экспериментом попробую сразу 2-3 станка запустить с 1 ноутбука одновременно через свистки Bluetooth. Если заведется это прям будет круть. Ещё попробовал управление с Android планшета. В общем необычно, но вполне тоже работает. Если попривыкнуть то это можно использовать как замену ПК.

[Igor Burtsev]

По поводу linuxcnc почитал что писали выше. Я не утверждаю, что это плохая или не работающая система. И уверен, что у нее определенно есть свои сильные стороны. Но из всего прочитанного выше все равно выходит, что эту систему лучше использовать при нестандартных решениях типа извращения с дельта кинематикой и шпинделем)))) или каких то максимально нестандартных решениях в токарной магии. Но мы же тут рассматривает обычные станки с обычной "классической" кинематикой. Если бы мне нужен был я бы не звал бабушку. Так если мне нужно простое решение за минимальные деньги, на самую классическую кинематику и ещё чтобы оператор мог с привычной системы (nc, mach, dsp) быстро обучиться - та же простая Инектра это оптимальный вариант. Зачем усложнять себе жизнь? Сейчас пришел на тест контроллер WLM55E v3 от WLDEV. Буду его в воскресение ставить. Он по прочитанной документации посерьёзнее будет Инектры и я предварительно думаю его будет оптимально использовать с гибридами или даже в дальнейшем попробовать с серыми чтобы организовать полноценно обратную связь. Ну то будем пробовать.

[vtgmfg]

Ну то будем пробовать.

только аккуратнее - а то получишь не техподдержку, а бан.

[alex_sar]

Практика показывает, что 1 кГц маловато. Особенно, учитывая, что у LinuxCNC и Mach3 на выход Step Dir в течение сервоцикла выдается целочисленное количество импульсов. На частоте 1005 Гц получим 5 подергиваний в секунду при движении.
После обработки степмастером, у которого сервоцикл 10 кГц и нет целочисленного квантования, сильно возрастает стабильность работы (исчезают срывы моторов), при этом еще и ускорение можно поднять в разы.

можно ведь просто и банально увеличить дискретность (step/mm) на стороне linuxcnc, причем сильно увеличить? тогда все эти скачки будут сглажены. и не нужно лезть на большие частоты. или так не получается?

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

[michael-yurov]

можно ведь просто и банально увеличить дискретность (step/mm) на стороне linuxcnc, причем сильно увеличить? тогда все эти скачки будут сглажены. и не нужно лезть на большие частоты. или так не получается?

Я правильно понимаю, что ты предлагаешь подготавливать данные для генерации Step с избыточной точностью, а потом, делить ее, скажем, в 10 раз, чтобы со стороны ЧПУ сохранялась высокая точность и равномерность, а на драйверы уже выдавать тот сигнал, частоту которого он сможет переварить? Идея хорошая, но возникает проблема в момент смены направления. Т.е. ЧПУ думает, что сгенерировала 207 импульсов, а на драйвер после деления на 10 поступило только 20, потом смена направления и в обратную сторону ЧПУ выдает 33 импульса, а драйверу передается только 3. Получаем сползание координат. Все это проблемы, которые не так-то просто решить. Проще каждый сервоцикл выдавать целочисленное количество импульсов, как и делает большинство ЧПУ.
Да, есть числа с плавающей точкой, но тогда могут возникать накопительные ошибки.

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

Ну вот в большинстве ЧПУ не смогли. Не хватает производительности, памяти, и т.п. То, о чем я писал.
Если посмотреть NCStudio, казалось бы, аппаратная генерация, 47,1 кГц, производительность полноценного компа для математики, а сигнал на выходе - жуткая рванина. Скорее всего из за целочисленной математики и упрощенных алгоритмов.

Я в своем контроллере заморочился. Даже чрезмерно. Как видишь, возникают вопросы, а зачем сервоцикл 10 кГц, а зачем 20 МГц на выходе, зачем генерация с избыточной точностью, зачем вся математика в числах с плавающей точкой, и кому, вообще, нужно отсутствие квантования и дробления на сервоциклы? Сейчас вот думаю, что надо бы поудалять часть подобных хитростей, а то слишком сложно все получается, и трудно будет расширять функционал.

[michael-yurov]

Еще про известный костыль вспомнил, во многих ЧПУ используемый - склеивание мелких последовательных сегментов. Казалось бы, какая разница, ну есть мелкие сегменты, ну и чем они мешают то? Какая разница пройти через 10 сегментов, или через два? А проблема глубже. Многие ЧПУ привязывают деление на сегменты к сервоциклам для упрощения расчетов. Т.е. этот сегмент - 30 сервоциклов. Следующий - 15... И, получается, что если сегмент должен быть пройден за 1,2 мс, ЧПУ потратит на него 2 мс (2 сервоцикла), и потеряет 40% времени.
Но так проще математика. Можно все в целых числах посчитать, сколько сервоциклов займет каждый сегмент. Сколько импульсов выдать в каждом сервоцикле, и, соответственно, не возникнет никаких проблем со смещениями или сползаниями координат.

[MX_Master]

никакая платная система такого не позволит сделать

Я, как раз, такую систему пилю, где юзер может управлять контроллером на любом утюге с любым интерфейсом. В контроллере есть всё необходимое, чтобы ни в чём не огранивать внешние устройства управления. Главное, чтобы связь по сети была. Наверное, многим такой свободный подход будет не по душе. Михаилу Юрову, точно, не понравится Но я за разнообразие, чем больше будет разных систем, тем удобнее будет всем. Каждый (включая бизнесменов) найдёт себе что-то по душе.

А у меня, например, 10 кГц, и уже получается нужно 20000 блоков данных, например по 48 байт (навскидку, для 6 осей + служебная информация). Т.е. мегабайт! А если еще второй такой же буфер держать для подмены, если данные обновились, уже два мегабайта получается. Такими объемами оперативки у STM32 даже не пахло.

Тут, наверное, семейство STM32H7 подойдёт. Но в большинстве других случаев, народ ставит внешнюю ОЗУ.

Практика показывает, что 1 кГц маловато.

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

[hmnijp]

Т.е. до 100 000 сегментов в секунду! Понятно, что у пользователей Инектры числа намного скромнее, но все же.
Даже у mach3 для нормальной работы нужен буфер в пару секунд, при чем там не сегменты, а данные для каждого сервоцикла. Т.е. в буфер должно поместиться хотя бы 2000 блоков данных.

на практике проверял, что планировщик лцнц спокойно обрабатывает несколько тысяч строк кода в секунду -типичная 3д обработка.
https://www.youtube.com/shorts/FqobL6rUDgg

а зачем больше? вроде linuxcnc тоже нормально штатно работает с 1Khz
тогда всего 2000 блоков )

можно ведь просто и банально увеличить дискретность (step/mm) на стороне linuxcnc, причем сильно увеличить? тогда все эти скачки будут сглажены. и не нужно лезть на большие частоты. или так не получается?

Я правильно понимаю, что ты предлагаешь подготавливать данные для генерации Step с избыточной точностью, а потом, делить ее, скажем, в 10 раз, чтобы со стороны ЧПУ сохранялась высокая точность и равномерность, а на драйверы уже выдавать тот сигнал, частоту которого он сможет переварить? Идея хорошая, но возникает проблема в момент смены направления. Т.е. ЧПУ думает, что сгенерировала 207 импульсов, а на драйвер после деления на 10 поступило только 20, потом смена направления и в обратную сторону ЧПУ выдает 33 импульса, а драйверу передается только 3. Получаем сползание координат. Все это проблемы, которые не так-то просто решить. Проще каждый сервоцикл выдавать целочисленное количество импульсов, как и делает большинство ЧПУ.
Да, есть числа с плавающей точкой, но тогда могут возникать накопительные ошибки.

что то немного перемемешали всё... на примере linuxcnc:
там никакие импульсы не передаются - в платы каждый сервоцикл

(по дефолту ±1кгц + коррекция времени с помощью dpll. хотя на современном компе нормально работает сервоцикл 2-8кгц - есть примеры такого использования для работы с драйверами Delta по ethercat, у которых он на 8кгц как раз, но это не каждый комп нормально тянет, надо немного повозиться с настройкой выделенного rt ядра. А например openCN, имеющий некоторое сходство с linuxcnc, делает планировние/вычисления не в реалтайме, но использует rt ядро xenomai для связи по езеркат c сервоциклом 10кгц. Да, езеркат и другие сетевые привода сейчас стремительно дешевеют и набирают популярность linuxcnc-ethercat devices. )

передается 32битные числа - координаты по всем осям, либо значение скорости, если степгены работают с сигналом скорости из pid регуляторов обратной связи. В плате уже позиция или скорость пересчитываются(компонентом stepgen) в частоту генераторов, которые в свою очередь уже работают на частоте до десятка мгц, и так же в каждом сервоцикле счетчики степгенов возвращают обратно фидбек - сколько импульсов степген сгенерил по факту, по этому сползания координат не существует. этот же фидбек используется для коррекции скорости/позиции если сервоцикл не идеально равномерный (хотя в последних реализациях dpll этим может заниматься).

Еще про известный костыль вспомнил, во многих ЧПУ используемый - склеивание мелких последовательных сегментов. Казалось бы, какая разница, ну есть мелкие сегменты, ну и чем они мешают то? Какая разница пройти через 10 сегментов, или через два? А проблема глубже. Многие ЧПУ привязывают деление на сегменты к сервоциклам для упрощения расчетов. Т.е. этот сегмент - 30 сервоциклов. Следующий - 15... И, получается, что если сегмент должен быть пройден за 1,2 мс, ЧПУ потратит на него 2 мс (2 сервоцикла), и потеряет 40% времени.
Но так проще математика.

Это уже проблемы алгоритмов планировщиков.
НО во ВСЕХ современных чпу никто не двигается точно по коду, в этом абсолютно нет никакой необходимости - везде давно используют nurbs интерполяция. код интерпретируется, геометрически преобразовывается: если это длинные прямолинейные сегменты или дуги - на их стыках строятся кубические сплайны, если это куча мелких линий - апроксимируется одним гладким nurbs c заданной точностью(параметры сглаживания/точности следования), сплайны/полиномы соединяются с контролем кривизны - и это обязательно делать для g2 непрерывности пути(геометрическая кривизна/непрерывность пути прямопропорциональна рывку), чтобы потом возможно было строить профиль скорости с контролем рывка (s кривые).
И да, полученный сплайн потом дробится на частоту сервоцикла - каждый цикл чпу отправляет сразу команду приводам (по сети, либо плате управления которая будет генерить степген, ну либо наполняет буфер планировщика, если не может с такой частотой слать, это уже нюансы).

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

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

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

в том же лцнц в меса сделали сброс счетчиков степгена внутри самой платы (точно так же как происходит сброс счетчиков энкодеров по индексному сигналу Z метки, добавили обнуление ещё и степгенов). то есть это выборка на частоте опроса энкодеров, а не с частотой сервоцикла. ну а далее уже в чпу возвращается фидбек обнуленный+накопившийся за длительность цикла и сигнал о том что счетчики степгена были сброшены (произошел хоминг).

[vtgmfg]

а они, вот эти 10кГц и тысячи элементов предпросмотр сейчас рядом с нами в этой комнате?

Вот реально когда случается затык с 1мс сервроциклом и нехватка памяти изза большого количества мелких сегментов в очереди?
машиностроительные детали обычно "векторную" геометрию имеют.

гравировка/панно что ли? или зубные протезы? или чтото экстремально мелкое типа деталей механических часов?

[alex_sar]

машиностроительные детали обычно "векторную" геометрию имеют.

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

[vtgmfg]

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

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

[hmnijp]

машиностроительные детали обычно "векторную" геометрию имеют.

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

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

так это и для окружностей/сфер и любых других элементов - абсолютно тот же путь. кам генерит сетку, а потом уже полученные полилинии апроксимируют и получают дуги в коде, либо просто выводят линии g1.
(да в некоторых случаях можно сразу 2д вектор преобразовать в код, и у nx там есть какая-то сплайн интерполяция, но она на столько "часто" используется, что можно пока про неё не говорить ничего, и тем более о поддержке сплайнов в g-коде. Хотя в том же linuxcnc частичная поддержка такого есть G5.2-G5.3 NURBS block)


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

гравировка/панно что ли? или зубные протезы? или чтото экстремально мелкое типа деталей механических часов?

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

а они, вот эти 10кГц и тысячи элементов предпросмотр сейчас рядом с нами в этой комнате?

любой современный фанук, сименс, митсу, дельта, китайцы чуть выше среднего - везде десяток кгц. У тех что попроще - порядка кгц сервоцикл. Траектории с таким количеством точек - обычные 3д обработки в 3х осях. И вся инфа про надобность такого планирования выше это не какой-то хай-енд - все это инфа 15-20 летней давности, давно отлаженные технологии. И даже те вопросы что решают сейчас производители чпу второго-третьего эшелона(что по ценам доступны хоббистам) - намного сложнее по математике. Так что тут нет ничего сверхординарного.

[vtgmfg]

ты много видел камов которые генерят вектор

я вообще только SC и пробовал. и то что я вижу в Г-коде это может быть кусочнолинейная апроксимация или G2/G3.

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

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

И вся инфа про надобность такого планирования выше это не какой-то хай-енд - все это инфа 20летней давности, давно отлаженные технологии.

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

[hmnijp]

нафига мне G64PQ если я скруглениями в модели могу управлять как хочу.

при чем тут скругления в модели, это не имеет отношенияк к g64. ты понимаешь что для планирования скорости без остановок чпу дорисовывает на траектории тангенциальные скругления на все стыки и отрезков, и дуг в том числе? без этого была бы остановка до V=0 на каждом стыке. А если тебе надо не просто движение без остановок, но и с контролем рывка(s-кривые) - в этом случае уже и тангенциальных скруглений не достаточно, и чпу рисует кубические сплайны. да и дуги в коде - мало когда имеют 100% сходимость, тк описываются обычно всего 3мя знаками после запятой.

но мне вот это все не нужно.

если у тебя чпу не дергается останавливаясь до F0 на каждом сегменте - значит это уже используется(абсолютно в любой чпу, даже в грбл, может ты про это просто не в курсе). а этот код - просто настройка величины этого сглаживания. чем больше сглаживание - тем больше и равномернее скорость. Почитай литературу о path planning/jerk-limited trajectory generation.

[vtgmfg]

при чем тут скругления в модели, это не имеет отношенияк к g64. ты понимаешь что для планирования скорости без остановок чпу дорисовывает на траектории тангенциальные скругления на все стыки и отрезков, и дуг в том числе? без этого была бы остановка до V=0 на каждом стыке.

это я как раз понимаю.
если я рисую в кад квадрат со скруглениями R1 - то какого еще надо рожна чпу чтобы идеально пройти c G61?
то же вроде самое для квадрата без скруглений но с G64 P1.4 должно быть?
но вот этот 2й вариант чпу дается легче, экспериментально проходит быстрее

[hmnijp]

то какого еще надо рожна чпу чтобы идеально пройти c G61? то же вроде самое для квадрата без скруглений но с G64 P1.4 должно быть?

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

[wldev]

это я как раз понимаю.
если я рисую в кад квадрат со скруглениями R1 - то какого еще надо рожна чпу чтобы идеально пройти c G61?
то же вроде самое для квадрата без скруглений но с G64 P1.4 должно быть?
но вот этот 2й вариант чпу дается легче, экспериментально проходит быстрее

Если это про WLMill.
То разница конечно будет.

Если по простому, то у квадрата (вдоль осей XY) при переходе вершин
При G61 сначала полностью остановится одна первая ось, а затем поедет вторая.
При G64 не будет вторая ось дожидаться полной остановки первой, а поедет в момент когда первая начнёт тормозить.

[vtgmfg]

разница конечно будет.

Если по простому, то у квадрата (вдоль осей XY) при переходе вершин

я про вариант когда угол скруглен уже в модели. Вроде это логично - зачем отдавать CAM+ЧПУ то что они должны угадывать скругляя на основании допусков. Вот вам готовое скругление - его можно пройти без остановок и схода с траектории.
по достижении начала скругления одна ось начинает тормозить пока не остановится, а другая разгоняется от нуля до той же скорости.
и вроде как раз получается то же самое что при нескругленом угле и G64P.
Визуально вроде одно и то же. но G64P проходила поворот быстрее.

дуги не удовлетворяют условию движения с ограниченным рывком.

Как это будет при включенной S кривой не размышлял