Про язык управления промышленными CNC-станками и всевозможными любительскими устройствами вроде 3D-принтеров написано очень много статей, но почитать о том, какова идеология этого языка и как она связана с аппаратной реализацией — почти негде. Поскольку моя работа связана непосредственно с программированием станков и автоматизацией производства, я попробую заполнить этот пробел, а также объяснить, почему выбрал такой странный заголовок.

Пару слов о себе, и почему я вообще решил написать об этом. Мои рабочие обязанности заключаются, в том числе, в том, чтобы заставить любой имеющийся в компании станок с ЧПУ делать всё, что он вообще может физически. Компания — небольшая (единицы сотен сотрудников), но в арсенале — вертикальные фрезерные автоматы Haas трех разных поколений, горизонтальные фрезерные автоматы DMG Mori нескольких типов, лазерный резак Mitsubishi, токарные автоматы Citizen Cincom и куча всего еще. И весь этот зоопарк управляется программами на G-code. Изучая разные реализации этого языка, я понял, что то, что пишут в учебниках и книгах по нему — не всегда является правдой. В то же время, мне стали понятны многие аналогии между этим языком и Assembler-ом, который я изучал когда-то в институте, и на котором практически ничего серьезного никогда не написал.

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

Для человека, привыкшего писать на языках высокого уровня, G-code, на первый взгляд, кажется ущербным. Он выглядит, как древний Basic с его goto, отсутствием явного определения переменных и прочими архаизмами. Но стоит посмотреть на него внимательнее, и становится понятно, что эта «ущербность» и «архаизм» — результат нескольких практических факторов: это язык довольно старый, он придуман для выполнения в строгих рамках доступных ресурсов, он решает одну и довольно простую задачу. Так что это вовсе не «ущербность», а рациональный минимализм, роднящий его с Assembler-ом.

Базовый синтаксис

Если вы хоть раз видели программу на G-code, то знаете, что это последовательность строк, которые состоят из буквенных кодов, за которыми следуют некие числа. Эти буквенные коды называются «адрес». Причина такого термина очень проста: в первых контроллерах станков программа выполнялась путем записи значений в ячейки памяти, которым были даны буквенные имена. Исполнительные устройства, в свою очередь, читали значения по этим адресам и делали то, что от них требуется. Когда мне приходится обучать операторов, я объясняю им, что контроллер, на самом деле, можно условно поделить на две части: ту, что отвечает за интерфейс с пользователем, и ту, что отвечает за работу механизмов. Они часто и физически разнесены по разным платам. А общение между ними происходит все еще через ограниченный набор этих самых ячеек памяти. Другой вопрос, что со временем, к именованным адресам, которые обозначаются буквами латинского алфавита, добавились еще численные адреса (начинающиеся с символа #), через которые осуществляется доступ к портам ввода-вывода, настройкам, специальным возможностям, и так далее.

Традиционно, когда описывают синтаксис G-code, говорят, что любая команда в программе начинается с буквы G для «подготовительных» кодов и M — для дополнительных, что номер строки начинается с буквы N, а номер программы или подпрограммы — с буквы O. Это, в принципе, правда, но не вся и не всегда.

Во-первых, деление на G- и M-коды — условно. Раньше, во времена первых станков с ЧПУ, это имело практическое значение, потому что связь синтаксиса с аппаратной реализацией была жестче. Сейчас же, это деление практически потеряло свое значение. Однако, правило о том, что M-код может быть только один на строке, все же стоит выполнять, как в старые времена, потому что никогда не знаешь точно, на сколько вольно производитель контроллера станка обошелся с реализацией языка. Например, на станках DMG Mori, автоматическое измерение длины инструмента, установленного в шпинделе, выполняется кодом G324, но если вы просто хотите активировать измерительный сенсор для того, чтобы почистить его (при этом крышка, под которой он скрыт во время обычной работы, открывается, и он выдвигается, но измерение не происходит), вам нужно выполнить код M44. По классической логике языка, использование G-кода для измерения длины — нестандартное решение, потому что вы явно не хотите, чтобы одновременно с этим (одной строкой кода) выполнялись какие-то еще действия. Но в современных реалиях это не имеет значения. На станках Haas та же операция измерения делается вообще запуском специальной подпрограммы с параметрами (тип и номер инструмента), а не одним кодом. Плюс, практически любой контроллер позволяет определять пользовательские G- или M-коды, полностью стирая различие между ними.

Ветвление и циклы

В G-code есть условный и безусловный переход по команде GOTO. Синтаксис адреса (аргумента) этой команды может различаться. Чаще всего, это число, соответствующее номеру строки, заданному на самой строке, как Nчисло. Но некоторые реализации языка, например — синтаксис контроллеров Okuma, позволяют давать строкам буквенные метки. С одной стороны, это хорошо, а с другой — нетипично, что смущает некоторых программистов и операторов.

Условный переход выполняется традиционным IF [выражение] THEN команда. Конструкция ELSE в языке не нужна, потому что если условие — ложно, команда на этой строке не будет выполнена, а будет выполнен переход на следующую строку. Это важно понимать, потому что ошибка с тем, чтобы поместить команду, которая должна быть выполнена только если условие истинно, на следующую строку — одна из самых распространенных в «ручном» программировании. Вероятно, это случается с неопытными программистами, которые до этого привыкли к синтаксису языков высокого уровня. В некоторых реализациях не обязательно и THEN, что добавляет краткости, но не добавляет читаемости. Сравните (даже не имея представления о смысле):

IF [#1 NE 10] THEN #2=20

и

IF [#1 NE 10] #2=20

Циклы в явном виде реализованы конструкцией WHILE [выражение] DOметка ... ENDметка, но, конечно, могут быть реализованы и через условный переход. Синтаксис позволяет также «выпрыгивать» изнутри цикла, используя GOTO. Но «запрыгнуть» внутрь цикла, используя размещенную внутри него метку — нельзя. Возможно, в каких-то контроллерах это и разрешено, но в тех, на которых я это проверял, это вызывает ошибку.

Подпрограммы

История использования подпрограмм в G-code тянется еще со времен перфолент. Существует несколько способов их вызывать, и это достаточно избыточно. Каждая программа или подпрограмма на G-code имеет свой идентификатор — цифровой код. Положение (под)программы определяет, должен ли этот идентификатор начинаться с латинской O или латинской N. По этому коду их можно вызывать разными способами. Эти способы (используемые для этого коды) различаются, например, тем, где контроллер будет искать эту подпрограмму — внутри файла (на станках Haas это код M97) программы или во всех файлах (а это уже M98). Если подпрограмма содержится в файле программы и имеет идентификатор номера строки (N), ее следует вызывать, как «внутреннюю подпрограмму». В этом случае, совершенно не нужно беспокоиться об уникальности идентификатора. Если же подпрограмма имеет идентификатор, начинающийся с буквы O, она может содержаться и внутри файла основной программы, и в отдельном файле. В этом случае, следует заботиться о том, чтобы номер был уникален среди всех программ в памяти контроллера, потому что иначе, контроллер либо выдаст ошибку при попытке записать такую подпрограмму в его память, либо, что хуже, может выполнить первую попавшуюся подпрограмму из нескольких с одинаковыми номерами. На большинстве контроллеров это, к счастью, невозможно. В общем, любую программу можно вызвать, как подпрограмму, только из-за отсутствия кода возврата M99, аналога return, и присутствия кода остановки M30, аналога halt, контроллер просто остановит выполнение. Но в некоторых случаях (когда это действительно конец процесса обработки детали) это может быть совершенно нормальным решением, пусть оно и выглядит некрасиво с точки зрения классического программирования. Это различие, на самом деле, восходит к временам, когда носителем для программ были перфокарты и перфолента, которые нужно было менять вручную, если подпрограмма находилась на другой ленте или в другой пачке перфокарт.

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

Указатели, переменные, регистры

Хотя G- и M-коды контроллеров — довольно большая тема, переменные — еще более обширная и сложная история. Дело в том, что «железо» станков управляется огромным количеством переменных, напоминающих по принципу их работы регистры процессоров. Доступ к этим регистрам в каких-то случаях возможен по предопределенным буквенным именам, в каких-то — по номерам, в каких-то — по назначенным буквенно-цифровым именам. При этом, свойства, назначение и поведение этих переменных могут быть совершенно разными.

Если вы хоть раз видели программу на G-code для промышленного станка, вы, возможно, заметили, что в начале самой программы, а иногда — в начале каждого фрагмента или подпрограммы, отвечающей за один инструмент или один элемент детали, есть длинная строка кодов, которые вроде бы ничего не делают. Это так называемая safe line. Она нужна, потому что станок помнит свое состояние. Например, содержимое какого-то регистра может сохраняться даже после выключения и включения станка, потому абсолютно всегда имеет смысл в явном виде устанавливать желаемое состояние перед совершением каких-то операций. Это напоминает то, как в web-разработке используются Reset.css и Normalize.css. Иначе, это правило для программистов звучит как «никогда не предполагай, что станок находится в определенном состоянии, если ты его в это состояние не привел». Пренебрежение этим может стоить дорого, включая капитальный ремонт станка. При этом, наиболее надежной практикой считается именно приведение станка в искомое состояние, а не проверка, находится ли он в нем. Почему? Потому что приведение, как правило, делается одной безусловной командой, а проверка требует условного ветвления.

Практический пример. При использовании контроллера Haas, некоторые адреса доступны для чтения только по номеру ячейки памяти, тогда как для записи — по буквенному псевдониму и по номеру. Скажем, чтобы установить скорость вращения шпинделя, достаточно выполнить код S<целое число>, запись IF [S EQ 200] (проверка если скорость шпинделя равна 200) работать не будет, нужно писать IF [#цифровой номер ячейки EQ 200]. Очевидно, что установить нужную скорость — куда проще, чем проверить ее. Более того, я с большим трудом могу себе представить ситуацию, когда проверка была бы действительно нужна, за исключением всего одного случая, с которым мне пришлось столкнуться. Некоторые станки имеют в своем наборе инструментов вентилятор, который устанавливается в шпиндель, как обычный держатель фрез. Это нужно, чтобы сдувать охлаждающую жидкость и стружку с детали после окончания ее обработки. Работа вентилятора зависит от скорости вращения — он складной, ему нужна определенная скорость, чтобы раскрыться от центробежной силы. Но станок имеет функцию изменения скорости вращения шпинделя, чтобы при отладке программы оператор мог на ходу переопределить скорость, заданную программой. Однако, если забыть отключить это изменение, вентилятор может или не раскрыться, или разлететься от слишком быстрого вращения. До того, как я начал работать в компании, этот вопрос никак не решался, считалось, что это ответственность оператора. Я же обратил на это внимание после первого происшествия и написал дополнение к программе для вентилятора, которое запускает вентилятор сразу после его установки в шпиндель, затем читает по нумерованному адресу (на счастье, документированному) значение реальной скорости вращения, делит его на устанавливаемую программой скорость и определяет, не различаются ли они больше чем на 1% (легкие вариации допускаются, хотя 1% — это порог с запасом), и если различаются — останавливает программу, включая индикатор ошибки и выдавая сообщение о том, что переопределение скорости следует отключить. Иронично, что тот же самый контроллер позволяет запретить переопределение некоторых параметров из программы (скорости движения стола, например), но не скорости вращения шпинделя. Почему? Так решил производитель. А моя задача — сделать так, как нужно производству, несмотря на то, что думает производитель, не нарушая гарантию. Для типичного производственного программиста, который не связан с автоматизацией, подобное решение выходит за рамки его деятельности.

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

Приведение типов

Это одна из неприятных особенностей многих реализаций G-code и контроллеров. Глядя на параметр X10, логично предположить, что это целое число. Но, в зависимости от того, как контроллер работает и как настроен, машина может интерпретировать и как X10.0 и как X0.0010 — в втором случае, это будет «десять минимальных единиц инкремента для данного контроллера». (Что, в свою очередь, может быть и десять микрон и десять десятитысячных долей дюйма.) Чудовищно, правда? Студенты и начинающие операторы постоянно делают эту ошибку. При этом, это можно настроить в контроллере. Потому, для полной переносимости и независимости от настроек, десятичная точка должна быть в цифровых значениях координат абсолютно всегда.

Хуже становится, когда речь о параметрах, передаваемых вызываемой подпрограмме. Практический пример. Автоматический измеритель длины инструмента Renishaw, установленный на станке Haas, требует для запуска измерения одного инструмента код G65 P9023 A12. T1, где T1 — номер инструмента (1, в данном случае). Но если вы хотите измерить сразу несколько инструментов, код будет G65 P9023 A22. I1. J2. K3. Тут уже параметры должны быть с точкой. Почему? Потому что когда вы пишете в T, этот адрес предназначен для хранения номера инструмента, потому на станке Haas он автоматически интерпретируется как целое число (мне неизвестны реализации, где это может быть дробное число, но я не могу этого исключить, например — у одного инструмента могут быть разные режущие кромки, нумеруемые, как дробная часть его номера). А вот когда параметры передаются через регистры, хранящие локальный стек переменных общего назначения, точка нужа, потому что там может храниться что угодно. При этом, у тех же станков Haas есть две настройки, которые отвечают за изменение этого поведения. Одна касается ввода параметров в контроллер, а другая — интерпретации некоторых именованных регистров использующихся для хранения координат.

Об обучении

Программированию станков с ЧПУ учат очень разными путями и с разными задачами. В одном случае, речь просто о том, чтобы научить пользоваться CAD/CAM, чтобы программист был в состоянии превратить модель (чертёж) в код, исполняемый на том или ином станке, изготавливающий деталь по модели. Это напоминает процесс обучения программированию «общего назначения» в ВУЗе, где вопросы исполнения кода, аппаратной архитектуры и написания кода на Ассемблере рассматриваются очень поверхностно. В других, заметно более редких случаях, процесс более всего напоминает обучение системному программированию, а примеры исполнения кода на конкретной архитектуре входят в него, как неотъемлемая часть. Поскольку я когда-то учился цифровой электронике, и программирование железа на низком уровне было частью этого, пусть и в довольно скромном объеме, второй вариант лично мне как-то ближе, и именно так я старался преподавать это сам, когда у меня была такая возможность.

Я вполне допускаю, что некоторые аналогии в статье могут показаться кому-то натянутыми, но я и не претендую на их точность. Речь, скорее, о сходстве «духа» упомянутых выше языков, о том, что опыт «ассемблерного мышления» может довольно сильно способствовать глубокому пониманию G-code, тогда как опыт программирования только на языках высокого уровня, отделенных от аппаратной реализации, может вызвать недоумение и даже некоторую неприязнь у того, у кого вдруг возникнет необходимость писать вручную для станков с ЧПУ.