ПОЛЕЗНО GRBL Commander - автономный контроллер на ESP32

[vvv1234]

Аппаратно - применением FRAM памяти, куда записывается смещение файла для текущей и предыдущей строки. Т.е. при выполнении УП пишется постоянно, потому и выбран такой тип памяти.
Программно - после простейшей проверки целостности данных, берём смещение, откатываемся немного назад и "прочёсываем" файл для получения параметров, которые нужны для продолжения - безопасную высоту, обороты, подачи, и т.д.

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

 

[OlegK]

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

Продолжение начинается немного раньше, т.е. часть пути проедем уже по пройденному. Но это аварийное восстановление, штука не регулярная, поэтому лучше продолжить работу хоть так, чем запороть всю работу и заготовку.
"Долговременная" пауза - там сначала вырабатываем буфер ГРБЛ, затем "собираем" все нужные данные в файл на карте памяти, поэтому продолжаем работу с той же точки, где и прервали работу.
Пока придумалось вот так, возможно, совершенством и не блещет, но пока работает, а там видно будет, насколько оно ущербно.

 

[vvv1234]

Продолжение начинается немного раньше, т.е. часть пути проедем уже по пройденному. Но это аварийное восстановление, штука не регулярная, поэтому лучше продолжить работу хоть так, чем запороть всю работу и заготовку.
"Долговременная" пауза - там сначала вырабатываем буфер ГРБЛ, затем "собираем" все нужные данные в файл на карте памяти, поэтому продолжаем работу с той же точки, где и прервали работу.
Пока придумалось вот так, возможно, совершенством и не блещет, но пока работает, а там видно будет, насколько оно ущербно.

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

 

[OlegK]

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

Изначально и была такая идея (в общей теме по DIY оффлайнику, где-то мелькало), т.е. совсем без FRAM-чипа, но с АКБ. По определённым причинам отказался от этого и попробовал текущий вариант - меня устроило.
Согласен, применение АКБ позволило бы "удлинить" время для того, что бы записать сразу необходимое, а не парсить это из файла, т.к. на это всё равно требуется какое-то время.

 

[vvv1234]

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

А что насчет реальных экспериментов, сколько раз проверяли?

 

[OlegK]

А что насчет реальных экспериментов, сколько раз проверяли?

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

 

[vvv1234]

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

Я тут поразмышлял на предмет оптимизации восстановления после аварийной остановки. Выводы следующие.

Есть два возможных алгоритма работы.

1. После остановки возвращаемся в нули, начинаем работу сначала. Надежно, но если работа долговременная, то нет гарантии, что снова остановится по аварии.
2. Останавливаемся, запоминаем положение, возвращаемся немного назад, продолжаем работу. Нет гарантии, что реальное положение шпинделя будет соответствовать с достаточной точностью запомненному (инерция, помехи при остановке, и т.д).

А вот если совместить два подхода, то будет более надежно. Останавливаемся. Запоминаем предпоследнюю строчку жкода. Возвращаемся в нули, но работу начинаем с запомненной строчки.

 

[OlegK]

Запоминаем предпоследнюю строчку жкода. Возвращаемся в нули, но работу начинаем с запомненной строчки.

Именно так сейчас оно и работает.
При "плановой" паузе, можно и без поиска дома - остановились, отогнали шпиндель в раб. 0 и отключили питание. Хотя тоже - при вкл. питания, ШД могут дёрнуться, что на сколько-нибудь собьёт нулевую позицию. Так что предпочтительнее всего продолжать с поиском дома, нашли дом, вернулись в раб.0 и вперёд.
С аварийной ситуацией - восстановление возможно только после поиска дома, без этого в раб 0 можно только на глаз выцеливаться, что, ПМСМ, бессмыссленно.

Насчёт предпоследней строки G-кода.
Внутренний буфер ГРБЛ может хранить около 16 линейных команд (если я не ошибаюсь) - это можно пронаблюдать, если остановить передачу в станок, но позволить ему выполнять работу дальше, пока он не остановится.
Команд, которые работают с дугами помещается поменьше, но один фиг, отследить, какая строка была предпоследней для станка, а не для оффлайника - как?

Да, вот про буфер планировщика -

Grbl essentially has two buffers between the execution of steps and the host PC interface. One of them is the serial receive buffer. This briefly stores up to 128 characters of data received from the host PC until Grbl has time to fetch and parse the line of G-code. The other buffer is the look-ahead planner buffer. This buffer stores up to 16 line motions that are acceleration-planned and optimized for step execution.

 

[ЮрийВ]

Именно так сейчас оно и работает.
При "плановой" паузе, можно и без поиска дома - остановились, отогнали шпиндель в раб. 0 и отключили питание. Хотя тоже - при вкл. питания, ШД могут дёрнуться, что на сколько-нибудь собьёт нулевую позицию. Так что предпочтительнее всего продолжать с поиском дома, нашли дом, вернулись в раб.0 и вперёд.
С аварийной ситуацией - восстановление возможно только после поиска дома, без этого в раб 0 можно только на глаз выцеливаться, что, ПМСМ, бессмыссленно.

Насчёт предпоследней строки G-кода.
Внутренний буфер ГРБЛ может хранить около 16 линейных команд (если я не ошибаюсь) - это можно пронаблюдать, если остановить передачу в станок, но позволить ему выполнять работу дальше, пока он не остановится.
Команд, которые работают с дугами помещается поменьше, но один фиг, отследить, какая строка была предпоследней для станка, а не для оффлайника - как?

Да, вот про буфер планировщика -

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

 

[vvv1234]

Команд, которые работают с дугами помещается поменьше, но один фиг, отследить, какая строка была предпоследней для станка, а не для оффлайника - как?

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

Ваши сообщения автоматически объединены: 14.01.2022

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

Я написал "предпоследнюю" в смысле одну из предыдущих.

 

[OlegK]

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

Тут штука в чём, Юра, улавливаешь разницу времени выполнения десятка простых линейных команд с подачей 50 мм/мин или с подачей 3000 мм/мин?
Я запоминаю смещение текущей строки, ещё не переданной в станок и смещение уже переданной. От этой точки, например, можно "откатиться" назад некоторую величину (настраиваемо), считать байты без передачи до начала след. строки и начать с этой точки. Насколько оно будет рано - зависит от G-кода.

 

[vvv1234]

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

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

 

[ЮрийВ]

улавливаешь разницу времени выполнения десятка простых линейных команд с подачей 50 мм/мин или с подачей 3000 мм/мин?

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

Ваши сообщения автоматически объединены: 14.01.2022

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

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

 

[vvv1234]

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

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

Или SolidWorks . Интереснее, но у него частенько гамильтонианы расходятся...

 

[OlegK]

программа может считать в начале работы скорость подачи

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

Потребуется много времени и терпения. Оно того стоит?

Я бы поставил вопрос чуть иначе - где это всё взять?