История изменений

У тебя как я помню идея в том, чтобы заранее предрасчитывать массив бинарных сигналов step/dir и не RT, асинхронно посылать их блоками в буфер контролёра который будет их выдавать уже по реалтайму с некоторой частотой.

Это действительно позволит тебе двигаться быстрее, чем может двинуться LinuxCNC, но даже если ты сделаешь контроль координат то
1. RT связи с контролёром у тебя нет и по этому увязать координаты с конкретным выдаваемым контролёром шагом ты не можешь
2. Когда контроль координат себя оправдает и покажет отклонение, то он весь твой предрасчитанный массив сигналов step-dir должен перерасчитываться заново, а станок в это время видимо резко остановится.

3. Основная причина медленности LinuxCNC состоит в том, что для прохождения кривой с некоторой точностью её надо разбить не менее чем на k линейных сегментов и за один сервопериод можно пройти только один сегмент.

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

Ну конечно есть выход оставить часть сегментов без контроля, но на сколько это будет хорошо?

Причём тоже самое можно получить если добавить в hal обмен блоками и пересылать несколько координат вершин сегментов за раз.

Но для этого не надо писать СВОЁ ЧПУ, для этого надо сделать форк linuxcnc и наверено нескольких библиотек и модулей ядра и после отработки влить свой код в основной проект.

Вот это было бы реально полезно, причём не только LinuxCNC.

У тебя как я помню идея в том, чтобы заранее предрасчитывать массив бинарных сигналов step/dir и не RT, асинхронно посылать их блоками в буфер контролёра который будет их выдавать уже по реалтайму с некоторой частотой.

Это действительно позволит тебе двигаться быстрее, чем может двинуться LinuxCNC, но даже если ты сделаешь контроль координат то
1. RT связи с контролёром у тебя нет и по этому увязать координаты с конкретным выдаваемым контролёром шагом ты не можешь
2. Когда контроль координат себя оправдает и покажет отклонение, то он весь твой предрасчитанный массив сигналов step-dir должен перерасчитываться заново, а станок в это время видимо резко остановится.

3. Основная причина медленности LinuxCNC состоит в том, что для прохождения кривой с некоторой точностью её надо разбить не менее чем на k линейных сегментов и за один сервопериод можно пройти только один сегмент.

И как только ты введёшь контроль координат у тебя будет та же скорость, так как ты не сможешь контролировать координаты чаще, чем это делает LinuxCNC.

Ну конечно есть выход оставить часть сегментов без контроля, но на сколько это будет хорошо?

Причём тоже самое можно получить если добавить в hal обмен блоками и пересылать несколько координат вершин сегментов за раз.

Но для этого не надо писать СВОЁ ЧПУ, для этого надо сделать форк linuxcnc и наверено нескольких библиотек и модулей ядра и после отработки влить свой код в основной проект.

Вот это было бы реально полезно, причём не только LinuxCNC.

У тебя как я помню идея в том, чтобы заранее предрасчитывать массив бинарных сигналов step/dir и не RT, асинхронно посылать их блоками в буфер контролёра который будет их выдавать уже по реалтайму с некоторой частотой.

Это действительно позволит тебе двигаться быстрее, чем может двинуться LinuxCNC, но даже если ты сделаешь контроль координат то
1. RT связи с контролёром у тебя нет и по этому увязать координаты с конкретным выдаваемым контролёром шагом ты не можешь
2. Когда контроль координат себя оправдает и покажет отклонение, то он весь твой предрасчитанный массив сигналов step-dir должен перерасчитываться заново, а станок в это время видимо резко остановится.

3. Основная причина медленности LinuxCNC состоит в том, что для прохождения кривой с некоторой точностью её надо разбить не менее чем на k линейных сегментов и за один сервопериод можно пройти только один сегмент.

И как только ты введёшь контроль координат у тебя будет та же скорость, так как ты не сможешь контролировать координаты чаще, чем это делает LinuxCNC.

Ну конечно есть выход оставить часть сегментов без контроля, но на сколько это будет хорошо?

Причём тоже самое можно получить если добавить в hal обмен блоками и пересылать несколько координат вершин сегментов за раз.

Но для этого не надо писать СВОЁ ЧПУ, для этого надо сделать форк linuxcnc и наверено нескольких библиотек и модулей ядра и после отработки влить свой код в основной проект.

Вот это было бы реально полезно, причём не только linuxcnc

У тебя как я помню идея в том, чтобы заранее предрасчитывать массив бинарных сигналов step/dir и не RT, асинхронно посылать их блоками в буфер контролёра который будет их выдавать уже по реалтайму с некоторой частотой.

Это действительно позволит тебе двигаться быстрее, чем может двинуться LinuxCNC, но даже если ты сделаешь контроль координат то
1. RT связи с контролёром у тебя нет и по этому увязать координаты с конкретным выдаваемым контролёром шагом ты не можешь
2. Когда контроль координат себя оправдает и покажет отклонение, то он весь твой предрасчитанный массив сигналов step-dir должен перерасчитываться заново, а станок в это время видимо резко остановится.

3. Основная причина медленности LinuxCNC состоит в том, что для прохождения кривой с некоторой точностью её надо разбить не менее чем на k линейных сегментов и за один сервопериод можно пройти только один сегмент.

И как только ты введёшь контроль координат у тебя будет та же скорость, так как ты не сможешь контролировать координаты чаще, чем это делает LinuxCNC.

Ну конечно есть выход оставить часть сегментов без контроля, но на сколько это будет хорошо?

Причём тоже самое можно получить если добавить в hal обмен блоками и пересылать несколько координат вершин сегментов за раз.

Но для этого не надо писать СВОЁ ЧПУ, для этого надо сделать форк linuxcnc и наверено нескольких библиотек и модулей ядра и после отработки влить свой код в основной проект.