WLMill (Windows/Linux (Qt) + WLMotion) - управление фрезерным ЧПУ

[vtgmfg]

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

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

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

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

MACHINE.runGCode("G53G90G0 Z-10")
while(MACHINE.isActiv()) SCRIPT.process()
MACHINE.runGCode("G53G90G0 X10 Y10")
while(MACHINE.isActiv()) SCRIPT.process()

MACHINE.stopMov()

while(!MACHINE.goDriveVerify("Z")) SCRIPT.process()
while(!MACHINE.goDriveVerify("X")) SCRIPT.process()
while(!MACHINE.goDriveVerify("Y")) SCRIPT.process()
while(MACHINE.isActiv()) SCRIPT.process()

SCRIPT.console("MACHINE.getCurPosition(X) ="+MACHINE.getCurPosition("X").toFixed(3))
SCRIPT.console("MACHINE.getCurPosition(Y) ="+MACHINE.getCurPosition("Y").toFixed(3))
SCRIPT.console("MACHINE.getCurPosition(Z) ="+MACHINE.getCurPosition("Z").toFixed(3))

попробуйте.
в консоли будут координаты около тех которые были до поиска? т.е. ~ 10,10,-10 . если ошибку не выдаст.
я не настолько продвинут чтобы понять эту машину времени.

вот эту хитровывернутую конструкцию не я сам придумал, а команда разработчиков WLMill. А если просто влоб
MACHINE.goDriveVerify("Z")) - то это не будет работать после
MACHINE.runGCode("G53G90G0 X10 Y10")
while(MACHINE.isActiv()) SCRIPT.process()

[shad]

while(!MACHINE.goDriveVerify("Z")) SCRIPT.process()
while(!MACHINE.goDriveVerify("X")) SCRIPT.process()
while(!MACHINE.goDriveVerify("Y")) SCRIPT.process()

Вот здесь Вы в цикле ожидания каждый раз запускаете заново функцию goDriveVerify не дав ей закончиться
Нужно так
MACHINE.goDriveVerify("Z")
while(MACHINE.isBusy())
{
SCRIPT.process()
}
MACHINE.goDriveVerify("X")
while(MACHINE.isBusy())
{
SCRIPT.process()
}
MACHINE.goDriveVerify("Y")
while(MACHINE.isBusy())
{
SCRIPT.process()
}

Функция MACHINE.goDriveVerify возвращает true если проверку удалось запустить и false если что то пошло не так.
А вот как получить результат процедуры проверки после ее окончания в виде значения ошибки из скрипта нужно уже Сергея спросить.

[shad]

По идее после окончания проверки эти значения должны храниться в регистрах защелках оси.
Попробуйте DRIVEX.getLatch2Pos() например для оси Х сразу после окончания процедуры проверки.
Пусть если что меня поправит Сергей.

[vtgmfg]

MACHINE.isBusy()

нет такой функции

А вот как получить результат процедуры проверки после ее окончания в виде значения ошибки из скрипта нужно уже Сергея спросить.

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

По идее после окончания проверки эти значения должны храниться в регистрах защелках оси.
Попробуйте DRIVEX.getLatch2Pos() например для оси Х сразу после окончания процедуры проверки.
Пусть если что меня поправит Сергей.

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

[shad]

MACHINE.isActiv() тоже подойдет.
Verify сама по себе возвращает запустился процесс или нет. Там идет проверка состояния машины и если все ок она запустит проверку и вернет true.
А вот что там в защелках будет getLatch2Pos() по окончании проверки - координата касания или уже значение ошибки завтра Сергей наверное ответит.
Как правило погрешность может возникать когда теряются шаги. Это может быть проблема электроники или механики а на плазмах это еще и высокочастотные помехи, высокие значения ускорения оси. Как правило, если все исправно ошибка на обычном механическом датчике очень мала, а на бесконтактном еще меньше.
Сама процедура проверки не отличается от поиска нулей по сути. Это тот же двух этапный поиск со съездом с датчика в конце которой определяется разница с предыдущей позицией найденного нуля.
А зачем Вам нужны координаты касания? Это какая то специальная задача?

[vtgmfg]

MACHINE.isActiv() тоже подойдет.

нет. так это не работает. само по себе работает. а после MACHINE.runGCode("G53G90G0 - нет

Как правило погрешность может возникать когда теряются шаги

нет. не тот случай

Как правило, если все исправно ошибка на обычном механическом датчике очень мала, а на бесконтактном еще меньше.

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

А зачем Вам нужны координаты касания? Это какая то специальная задача?

во первых понимать какова повторяемость хоумления по датчикам. по-моему это всем абсолютно интересно должно быть. кроме тех у кого датчиков нет
во вторых - безгеморройная проверка если есть подозрение на потерю шагов. если повторяемость датчиков укладывается в шаг конечно.. так то я могу 3д-щупом точно отхоумиться или проверить не сохраняя, там goProbe и он все что нужно предоставляет, в том числе и симуляцию - но это нужно щуп поставить в цангу.. а это уже целое дело
а обычное хоумление всуе - это добавка погрешности своими руками.
МACHINE.runGCode("G53G90G0 для того чтобы не ехать хоумиться на скорости в 5 раз меньшей чем возможно. то есть когда начальное положение примерно правильное, а не любое

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

[wldev]

Я функцию хоуминга(проверку) уже год жду, чтобы скриптом сделать функционал который мне нужен.

Добрый день. А почему бы не воспользоваться функцией для начала поиска нулей, которая предоставляется в макросе?
Или необходимый функционал требует дополнительно еще что то?

Можно сделать цикл

for(i=0;i<=10;i++) //i будет меняться от 0 до 10 включительно
MACHINE.setOutput(i,1)

[wldev]

Добавлю сохранение данных проверки положения... Чтобы их можно было использовать

[vtgmfg]

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

[shad]

Добавлю сохранение данных проверки положения... Чтобы их можно было использовать

Добрый день! А какой смысл ее использовать кроме как для понимания, что в машине что то не так и происходит потеря шагов.
Ну вот мы узнали ошибку и что? Обрабатываемая деталь уже в этом случае не в размерах и подлежит утилизации.
Даже зная эту ошибку использовать ее как поправку нет смысла в цикле обработки детали.
Или я не прав?

[shad]

Ну разве что для этапа пусконаладки или техобслуживания станка.

[vtgmfg]

Добавлю сохранение данных проверки положения... Чтобы их можно было использовать

Добрый день! А какой смысл ее использовать кроме как для понимания, что в машине что то не так и происходит потеря шагов.
Ну вот мы узнали ошибку и что? Обрабатываемая деталь уже в этом случае не в размерах и подлежит утилизации.
Даже зная эту ошибку использовать ее как поправку нет смысла в цикле обработки детали.
Или я не прав?

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

[shad]

а обычное хоумление всуе - это добавка погрешности своими руками.

Тут я позволю себе не согласиться. Это все зависит от точности используемых датчиков, количества импульсов на один миллиметр и решаемых задач.
Например, для плазмы одна десятка это даже очень хорошая точность.
Думаю для фрезера одна сотка тоже неплохо, но могу ошибаться.
В принципе задача поиска нулей заключается в возможности продолжить или восстановить работу станка после сбоя или например выключения электропитания. Включили станок, нашли нули и вперед.
Если же имеется проблема потери или лишних шагов, то это все не поможет. Ну разве что для диагностики и поиска причины.

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

[shad]

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

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

[vtgmfg]

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

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

поскольку эти датчики вообще не предназначены для такой задачи - то скорее всего там указан только разброс от дистанции типа +-20% - т.е. у большинства тут это будет +-0,5..1мм, а какая повторяемость и насколько ей можно доверять - это надо опытным путем устанавливать. вполне может и 0,01 если температурный режим установился.

[vtgmfg]

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

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

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

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

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

да хоть бы и сотка - все равно не хочется ее добавлять, а может и несколько раз.

Пробинг это уже немного другой процесс для обнаружения заготовки, ее размеров и так далее.

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

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

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

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

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

[vtgmfg]

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

то есть повторяемость хоуминга не выходила за 3мкм, что как бы даже абсурдно - но вот так. А вот выключение контроллера и включение уже отклонение до 40мкм. причем это больше чем 1 шаг ШД. 1 шаг =25мкм (если шагов 200 на оборот) в моем случае. и при желании можно и его не потерять.. но 40мкм это уже не один шаг.. еще понаблюдаю за системой.. и вот тут тоже желательно голую функцию..

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

[vtgmfg]

интересный феномен. проделал 5 циклов с выключением контроллера вместе с драйверами шд и перезапуском WLMill.
Verify сразу после, без хоумления показывает считай стабильно уход Х = -42..-49мкм , Y =19, Z=+46..51, потом хоум обычный и снова Verify - теперь уже отклонения не выходят за 1..3мкм.

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

вопрос - откуда берется такая система в отклонениях.. если шаг швп 5мм и ШД 200 шагов то один шаг 25мкм..
ось Х уходит на ~2шага в минус , Y ~один шаг в плюс, Z ~2 шага в плюс.
Какое может быть этому объяснение? как бы можно ожидать что оси должны показывать отклонение в диапазоне ~-25..25мкм. или таки -50..+50 ? но тогда шагов у ШД должно быть 100 на оборот. или их и есть 100 в смысле стабильных положений..

[michael-yurov]

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

[vtgmfg]

Стабильных положений 50.

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

когда я делаю verify(хоум без обновления) сразу после включения то получаю красивые цифры 3мкм, хотя на самом деле оси при включении съехали на свои -46,19,48мкм.
А какое максимальное смещение оси? +-100 что ли? если швп 5мм и 50 стабильных положений на оборот..

Как отследить, сколько микрошагов драйвер сделал с момента включения?

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

вообще то микрошаги выдает контроллер и вполне может вести у себя реверсивные счетчики микрошагов от включения питания.. если у меня 1600step на оборот то это 4 или 5разрядов нужно. и соответственно перед выключением парковать шд на ближайший XYZ где эти счетчики станут=0 и запоминать эту координату.. ну или запомнить эти счетчики и сразу после включения сдвинуть оси на эти микрошаги, но координаты машинные не менять.
какая в этом практическая польза хз. ну разве что не делать хоуминг при включении, если знаешь что на момент выключения никаких сбоев не было. то есть исключить ошибку хоуминга если вынужденный перерыв в работе.