На мой взгляд, первичная фаза обработки G кода, должна переваривать каждую строку в бинарную структуру одинаковой длины. Это позволит быстрее обрабатывать данные, быстрее ориентироваться и переходить к нужной строке. Структура бинарной строки, должна зависеть от поддерживаемых (G/M/..) кодов.
Вторая фаза - переварить сложный бинарный G код в более простой. Т.е. раскрыть все циклы и сложные G коды (G2/G3/..), превратив их в простые линейные кусочки.
Третья фаза - разбить простой бинарный G код на кусочки указанной длины по времени. С учётом формул и зависимостей (ускорения, макс. скорость и прочие параметры).
я бы тогда в целом мух от котлет отделял, g код просто форма представления команды. как постпроцессор генерирует g код из набора перемещений и т.д., так и перед планировщиком должен быть препроцессор по идее.
Эта штука называется - интерполятор, самая сложная часть ЧПУ, особенно многокоординатного. Сомневаюсь, что нечто подобное можно сделать в рамках озвученного ТЗ. Если, конечно, речь о РВ.
На современных микроконтроллерах жкод обрабатывается влет.достаточно буфера в одну команду.тем более если куски более 0.1 мм. за время движения не проблема обработать следующую команду.
MX_Master писал(а): ↑
Нарезка G кода на кусочки траектории указанной длины по времени, с учётом ускорений, скоростей и прочих параметров
А зачем нарезать жкод у меня обрабатывается и выполняется целиком команда .Движение целиком в прерывании.Ускорение там-же.По окончании автоматически выгребает из буфера следующую команду ,или подготавливает следующую дугу окружности (при круговом движении).
Основная же программа если видит что буфер забрали ,подготавливает следующую команду
Исполнители команд могут быть разные. Это может быть и внешний контроллер, и программа, работающая по соседству. Или вовсе, вариант без исполнителя. К примеру, вариант без исполнителя полезен при визуальном отображении и сравнении реальной траектории и траектории чисто по G коду.
Кроме того, G код может быть загрублен или наоборот, слишком точным. Не каждый исполнитель сможет быстро отрабатывать микронные кусочки. Буфер при этом будет чрезмерно забит и передавать такой буфер внешнему исполнителю будет накладно. А вот кусочки траектории длиной, скажем, в миллисекунду, прекрасно переварит и микроконтроллер, и настольный ЦП.
MX_Master писал(а): ↑
В LinuxCNC планировщик умеет только в 3 оси, ну и прочие виды ускорений, кроме линейного, недоступны.
Вначале у меня было экспоненциальное ускорение.Из досмтоинств - самая простая и нетребовательная к ресурсам организация.Из недостатков- слишком большое начальное ускорение и слишком низкое в конце.Соответственно при одинаковых возможностях приводов занимает больше времени.Долгое время не мог реализовать линейное без дополнительных предпросмотров.Затем нашел способ.Достаточно простой,но ресурсозатратный(требует большого буфера в озу для каждой координаты).Таким же способом можно организовать любую форму ускорения в том числе и S образное,но в отличие от линейного (при расчете которого используютсяч только начальная и конечная ячейки) S образное требует перерасчета многих ячеек буфера в идеале всех на практике можно разбить на несколько кусков (линейное и изгибы).
