ВОПРОС Вопросы по оптимизации G-кода

[Sany-sch]

Уменьшите число микрошагов и сравните результаты.

На этой электронике микрошаг не регулируется. Здесь 80 шагов/мм

 

[САМОУДАЛЕННЫЙ 3729]

Модальные G-коды сохраняются в памяти системы ЧПУ и действуют до их прямой отмены в течении всего времени исполнения управляющей программы системы ЧПУ, немодальные G-коды действуют лишь в пределах одного кадра управляющей программы, в котором они находятся.

Модальные и немодальные G-коды

Модальные и немодальные G-коды.

www.intuwiz.ru

спасибо , отличный и доступный ответ.

 

[vvv1234]

На этой электронике микрошаг не регулируется. Здесь 80 шагов/мм

Для экспериментов не очень подходит .

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

P.S. Можно сравнить время обработки оптимизированной (без G и пробелов) и неоптимизированной строчек. Поговорите с OlegK , он у нас главный специалист по RegEx.

 

[OlegK]

Поговорите

оффтоп

 

[Vlad-I-Mir]

Тонкий намёк...

оффтоп

 

[Sany-sch]

Поговорите с OlegK

Да, он мне уже неоднократно помогал, за что ему огромное спасибо.

Для экспериментов не очень подходит .

Увы, станок не мой, домашний, а обзорный. Вчера поступили новые вводные. У человека станок Atomstack s20 pro Так он гравирует на холсте на скорости 7000 кодом сделанным в выжигалке и артефактов почти нет. Точнее так, он их не заметил, а я искал и нашел.

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

 

[SnakeKVC]

Да, он мне уже неоднократно помогал, за что ему огромное спасибо.

Увы, станок не мой, домашний, а обзорный. Вчера поступили новые вводные. У человека станок Atomstack s20 pro Так он гравирует на холсте на скорости 7000 кодом сделанным в выжигалке и артефактов почти нет. Точнее так, он их не заметил, а я искал и нашел.

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

И что Вы тут нашли? У Вас материал не однородный, и прожиг тоже будет плавать.
Начинаю обдумывать вариант что баги связаны с браком конкретных "камней" - это вообще с чего такое решение?
Вот реально, если конечно времени не жалко дело Ваше. Но тем чем Вы занялись, это проблема высосанная из пальца. ИМХО

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

Вы в курсе что лазер сучки в дереве не прорезает?
Так вот, Вы взяли примерно такое же место(косячное) на холсте и одеваете сову на глобус.
К оптимизации кода эта проблема не имеет никакого отношения.

 

[Robinson1957]

Можно сравнить время обработки оптимизированной (без G и пробелов) и неоптимизированной строчек. Поговорите с OlegK , он у нас главный специалист по RegEx.

Об оптимизации кода можно говорить в случае если в CAM, в котором создается УП, есть опция оптимизации, чтобы делались холостые переходы на минимальные расстояния, в остальных случаях, то бишь уменьшения перевариваемого объёма за счет исключения пробелов и повторов модальных команд несущественно, т.к. скорость обмена порта и скорость обработки микроконтроллера, даже 328, существенно выше требуемого, если, конечно не задирать разрядность после запятой до 6 - 8 знаков. Единственным ограничением для 328 является ограниченная скорость тактирования шагов, но это с успехом решается контроллером на STM32.

 

[OlegK]

Единственным ограничением для 328 является ограниченная скорость тактирования шагов

Ещё довольно сильно может повлиять метод передачи G-кода в станок, что прямо указано автором.
При простой передаче "отправка-ответ" и УП, состоящей из множества из коротких отрезков с перемещением на высоких скоростях, буфер сериал-порта и буфер внутреннего планировщика GRBL будет часто опустошаться, вызывая "затыки" в работе станка.

Спойлер

Although this communication lag may take only a fraction of a second, there is a cumulative effect, because there is a lag with every G-code block sent to Grbl. In certain scenarios, like a G-code program containing lots of sequential, very short, line segments with high feed rates, the cumulative lag can be large enough to empty and starve the look-ahead planner buffer within this time. This could lead to start-stop motion when the streaming can't keep up with G-code program execution. Also, since Grbl can only plan and optimize what's in the look-ahead planner buffer, the performance through these types of motions will never be full-speed, because the look-ahead buffer will always be partially full when using this streaming method.

 

[SnakeKVC]

Ещё довольно сильно может повлиять метод передачи G-кода в станок, что прямо указано автором.
При простой передаче "отправка-ответ" и УП, состоящей из множества из коротких отрезков с перемещением на высоких скоростях, буфер сериал-порта и буфер внутреннего планировщика GRBL будет часто опустошаться, вызывая "затыки" в работе станка.

Всё правильно. Но опять же, это не связанно с производительностью МК. А автор всё время подозревает что МК хилый.

 

[demyuri]

Всё правильно. Но опять же, это не связанно с производительностью МК. А автор всё время подозревает что МК хилый.

Была мысля, предложить пентиум 4. Только с ОС проблема.

 

[OlegK]

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

 

[Sany-sch]

Об оптимизации кода можно говорить в случае если в CAM, в котором создается УП, есть опция оптимизации,

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

Была мысля, предложить пентиум 4. Только с ОС проблема.

Спасибо, улыбнулся.

 

[demyuri]

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

Ура, всем богам! На 5й странице открылась истина (ну, хоть не на 15й)!
С этого и надо было начинать. 5 страниц ниочем, а можно было по делу.

 

[Sany-sch]

И что Вы тут нашли? У Вас материал не однородный, и прожиг тоже будет плавать.
Начинаю обдумывать вариант что баги связаны с браком конкретных "камней" - это вообще с чего такое решение?
Вот реально, если конечно времени не жалко дело Ваше. Но тем чем Вы занялись, это проблема высосанная из пальца. ИМХО

Спасибо что добавили ИМХО. Я оценил.
То есть, Вы утверждаете, Что полотно не однородно, так мы его не прожигаем. Или краска из баллончика легла неоднородно???
Ладно это я могу допустить что краска и полотно не однородно. Но знаете во что я не поверю, так это в то, что неоднородность получилась строго по оси Х, да ещё и совпала с размером пикселя по ширине.

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

Ура, всем богам! На 5й странице открылась истина (ну, хоть не на 15й)!
С этого и надо было начинать. 5 страниц ниочем, а можно было по делу.

Это чтото меняет?