Хороший тон написания программ на G коде

Автор предупреждает! Статья не дописана! Данная статья не дописана и требует до- или, даже, переработки. Примеры и данные в этой статье могут быть не проверены, тесты не отлажены, а информация не действительна. Я постараюсь, чтобы таких статей было по-меньше, но пока они есть. Смотрите: NikiWiki:Отказ от ответственности

Хороший тон есть в каждом языке программирования, это некий удобный и устоявшийся стандарт языка. Язык G код немного сложнее "тонировать". Ибо это плоский как лом язык в котором все программы делятся на Кадры G кода, на самом деле представляющие из себя лишь одну строку.

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

Паузы

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

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

Нумерация строк

Совсем не обязательно вставлять в каждой строке ее номер при помощи G кода N.

Однако, при таком раскладе Вы не сможете воспользоваться GOTO

N100 GOTO 120
N110 M02 (Остановка программы)
N120 (GOTO переходит непосредственно сюда)

Пример глупый, но демонстрирующий то, что если Вы не пронумеровали Ваши строки, то и попасть при помощи GOTO в нужное место кода Вы не сможете.

Еще одна особенность в том, что LinuxCNC сам расставляет свои номера строк. И, при ошибке или переходе, выводит окна с указанием именно им созданных номеров и кодов.

Учитывая все вышесказанное, я принял для себя решение нумеровать строки только если того требует алгоритм (помните, что использование GOTO это "не наш метод", т.е. его надо избегать).

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

Сброс установок

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

Для этого необходимо применить коды: G17 - выбор плоскости обработки, G49 - отмена коррекции на длину инструмента, G20 или G21 - выбор единиц измерения, G40 - отмена коррекции на режущий инструмент, G92.1 - сброс отступа координатной системы. Возможно, и наверняка, я еще что-то упустил. А может быть Вы со мной не согласитесь.

Но, для меня, первая строка программы должна быть таковой:

N0001 G17 G49 G21 G40 G92.1

Естественно, если в программе при этом есть измерения инструмента и его смена и Вы полностью контролируете процесс.

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

Запоминание положения

Если Вашему коду требуется изменить систему координат (G54) или указать смещение (G92) или ввести коррекцию на инструмент (G41 и G42) то перед вводом данных настроек - запомните текущее положение инструмента. Подразумевается, что это безопасная для оператора и инструмента позиция и Вы вернетесь в нее же по окончании части кода где нужно вводить ограничения.

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

Разбивайте код на блоки и/или подпрограммы

Лично я программирую много и уже очень давно. Но всегда, когда встречаю длинный и не читаемый текст - путаюсь. Я лично предпочитаю, чтобы код был разбит на блоки (функции/методы/что угодно) и каждый блок кода был понятен при визуальном его рассмотрении. И уж точно этот код должен быть виден на одном экране.

В языке G кода есть только два варианта достичь такого положения вещей:

• Написание одного, но понятного и разбитого на блоки файла;
• Разбиение всего алгоритма на функции, описываемые командой O;

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

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

Алгоритмический подход

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

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

Куда проще и понятнее выглядит функция, приведенная в статье про Жертвенный стол. В ней все наглядно и понятно. Для чего же еще нужен компьютер, если не для генерации кода по мере необходимости?

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

Пусть Ваша программа "разговаривает"

В LinuxCNC есть полезная функция - MSG, она выводит сообщения в окно программы. Будет здорово, если Ваша программа будет сообщать о своих действиях. Не уверен, что это именно "Хороший тон", но мне такой подход люб. Конечно, если у Вас программа отлажена годами и Вы перешли к изготовлению второго миллиона одинаковых деталей - смысла "разговаривать" у программы нет, но мне, как новичку, кажется, что сообщения будут полезны. Особенно, если они содержат, кроме простых "Hello World" еще и какие-либо данные программы. Параметры или состояние чего-либо.

Облёт заготовки

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

По-этой причине я разработал алгоритм "облёта" заготовки. Суть алгоритма такова:

1. Задаем безопасную высоту, общую переменную, которуб будет использовать весь код и никогда не менять. На этой высоте "летать" можно сколь угодно. Для моего станка и жертвенного стола, а также, учитывая текущие задачи и заготовки, эта высота составляет 35мм над уровнем. Ибо смый высокий крепеж у меня имеет именно такую высоту;
2. Перед выполнением любой обработки определяем границы заготовки "переезжаем" по периметру, останавливаясь на каждом шагу чтобы определить что границы в первом приближении ничего не ломают и станок ни обо что не ударится;
3. На последнем этапе опускаемся на высоту 1мм над уровнем заготовки и повторяем процедуру. Повторение - мать учения и так мы куда более точно определеяем что никто ничего не поломает и в самом конце, когда программа отработает и будет переведено в стружку тьма хорошего материала, не окажется, что существовавшее ранее отверстие или брак в заготовке попадает на самое видное место.

Начало обработки

Любой датчик высоты/длины инструмента имеет погрешность. По этой причине, если Вы подадите станку команду

G00 Z0 

(в случае, если заготовка на высоте 0 находится) или

G00 Z[#<matherial_width>]

(если переменная #<matherial_width> содержит предполагаемую толщину заготовки, то Вы можете услышать удар. Мало того, что это может сломать фрезу, это еще очень большой удар по шпинделю и заготовке. По этой причине старайтесь опускать инструмент на высоту, скажем 1мм (уж точно больше погрешности датчика) и уже оттуда опускать до требуемой высоты командой

G01 Z0 F[#<z_feed_rate>]

или

G01 Z[#<matherial_width>] F[#<z_feed_rate>]

К стати, я долго мучался на предмет подачи по оси Z и пришел к выводу, что подача в 10 раз меньшая чем подача по осям X и Y - вполне адекватна. И фрезу не насилует и достаточно ровно и эффективно прорезает любую заготовку любой фрезой (при условии что по осям X и Y подача установлена адекватная и не ломает фрезу или не двигает заготовку или не наматывает стружку.)