cnc-club.ru

sidor094 писал(а):Отрезки по три сотки реально ограничат скорость даже если из них составить прямую.Просто Линухснс может обрабатывать кадры программы с определенной скоростью.А перемалывание большого количества кода в единицу времени сама по себе грузит процессор.Только никакие внешние контроллеры здесь не помогут.Тут дело в быстродействии именно ПК.

Ну я попробовал "составить прямую" на предложенных условиях. Re: Предложение по увеличению скорости работы LinuxCNC #54
Никакого замедления не заметил.

torvn77 писал(а):Это тоже, но практика настройки linuxcnc показывает что ограничение связанное с сервоциклом проявляется до ограничений механики.

Я всё никак не могу сложить дважды два, а в чём же конечная цель этой темы? Мы все вместе должны собраться и переписать планировщик и stepgen? Или ты сам хочешь это сделать и спрашиваешь совета?

sidor094, нет, вот проблем с нехваткой вычислительной мощности в УП без условных операторов и математики в каждом кадре я не видел.
Но даже при использовании подпрограмм, математики и условных операторов в каждом кадре надо быть осторожным и не задавать слишком много вычеслений, но в разумных пределах даже так мощности ПК всё равнро будет хватать.

Лело именно в взаимодействии геометрии траектори и допусков с сервопериодом и подачей.

Идеология LinuxCNC предполагает, что за время одного сервоцикла ничего существенного (скорость, направление) измениться не может. Если для какой-то системы это не так, надо уменьшать время сервоцикла, а не пытаться "впихнуть невпихуемое".

Я в основном опираюсь на опыт чпу на микроконтроллерах.У меня на 120 мгц микроконтроллере скорость уменьшалась.Сейчас более мощный 216 мгц,значительно шустрее.Но все относительно.При увеличении скорости подач и дроблении отрезка эффект должен проявиться всегда,так как мощность любого процессора не бесконечна.

MX_Master писал(а):Мы все вместе должны собраться и переписать планировщик и stepgen?

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

Сергей Саныч писал(а):Идеология LinuxCNC предполагает, что за время одного сервоцикла ничего существенного (скорость, направление) измениться не может. Если для какой-то системы это не так, надо уменьшать время сервоцикла, а не пытаться "впихнуть невпихуемое".

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

torvn77 писал(а):

MX_Master писал(а):Мы все вместе должны собраться и переписать планировщик и stepgen?

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

Я не переносил планировщик в микроконтроллер, я перенёс stepgen. Это всё уже делали до меня. И не раз. Популярность LinuxCNC от этого всегда только росла. После того, как LinuxCNC поселился на микро ПК, спрос стал ещё больше. Не удивлюсь, если когда-нибудь кто-то запихает все компоненты LinuxCNC по разным МК и fpga. И спрос станет ещё выше.

Но я так и не понял, более короткий сервоцикл разве не решает твои задачи по обработке клише?

torvn77 писал(а):Похоже что как минимум два человека помимо тебя стараются перенести планировщик на микроконтролёр с целью получения большей скорости работы.

По-моему это перебор.Тогда за ПК останется только разбор ж-кода.А предпросмотр тоже будет делать микроконтроллер?Тут надо либо вообще все делать на микроконтроллере(в том числе и разбор команд),а за ПК оставить только отображение и кнопочки.Либо не трогать планировщик.
Тут шел разговор об увеличении частоты сервоцикла .Второй вариант был ,я так понял оставить частоту той же ,но в одном цикле передавать несколько точек цикла.Разницы вроде никакой.Но во втором случае требуется больше переделок программы.Не знаю,целесообразно ,или увеличивать частоту выдачи свыше 1 кгц.Как я уже писал ,в ГОСТе на сервопривода прописана 1 мс.Считается значит,что подымать выше не нужно.

MX_Master писал(а):Я всё никак не могу сложить дважды два, а в чём же конечная цель этой темы?

Киберпланировщик и облачный stepgen с ИИ.

sidor094 писал(а):в ГОСТе на сервопривода прописана 1 мс.

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

UAVpilot писал(а):Киберпланировщик и облачный stepgen с ИИ.

Нет, сам планировщик я особо менять не предлагаю, у я предлагаю другое.
Основная проблема в том, что из-за аппаратных ограничений частоты обращений к микроконтролёру уменьшение сервопериода, как это предложил Сергей Саныч получается невозможным, по крайней мере у плат 6i25 и 7i76E.
Преодолевать аппаратные ограничения это значит либо покупку серв SSCNET III и поиск материнки с процессором целерон J3455, либо развитие freehardware, то есть создание своих свободных процессоров и контролёров.
Первое саму возможность построения ЧПУ отдаёт на откуп отделам маркетинга крупных фирм, для которых чпущники ничто и никто, второе даст хороший плод, но и прилагаемые для получения такого результата усилия будут тяжелы и дороги.

Я предлагаю сделать самое простое, не столько уменьшать сервопериод, сколько улучшить организацию ЧПУ и эффективность использования им имеющихся ресурсов.
Нельзя обращаться к котролёру чаще чем раз в 750 мкс?
Значит надо увеличить размер блока и передавать за один цикл больше информации.
"Идеология LinuxCNC предполагает, что за время одного сервоцикла ничего существенного (скорость, направление) измениться не может. " значит планировщик дрлжен определять участки где это происходит и где это не происходит и там где происходит либо на место изменения подгонять конец сервоцикла, либо проесжать его на пониженной скорости как он это делает сейчас, нет таких изменений значит ехать с полной подачей и отправлять степгену по несколько координат за раз.

torvn77 писал(а):Нельзя обращаться к котролёру чаще чем раз в 750 мкс?

Откуда такая инфа?
И разве это проблема LinuxCNC? Или, всё-таки, RT-PREEMPT ядра и плат Mesa?

torvn77 писал(а):микроконтролёр

Зачем ты слова с ошибками пишешь? Ведь целенаправленно!
Микроконтроллер и контроллер пишется с двумя "л" и без "ё".

Кстати, если время отклика контроллера имеет большое значение, надо юзать чипы с сопроцессорами и аппаратными генераторами. Типа Cortex-A + Cortex-M/FPGA. Там время передачи сообщения сводится к микросекундам. Да чё там, даже доступ к регистрам аппаратного SPI в чипе даёт неплохой прирост скорости общения с внешним контроллером.

MX_Master писал(а):Кстати, если время отклика контроллера имеет большое значение, надо юзать чипы с сопроцессорами и аппаратными генераторами.

Это о чем?Что подразумевается под временем отклика?

Длительность пары вопрос-ответ.

Я больше сталкивался с задержкой из-за операционки в ПК чем из-за микроконтроллера.И вообще откуда в ПК SPI?

Ответ смотреть чуть выше (:

А что насчет SPI? Откуда он в компе?А как измеряли время реакции? Если имеется ввиду ответ контроллера на запрос ПК ,то тут согласен,А вот время от того когда основная программа в ПК закажет передачу,до времени когда эта же программа дождется ответа мне кажется значительно больше.Я понимаю,что LinuxCNC почти система реального времени и,в отличие от WINDOWS время между командой API для порта и началом передачи намного меньше,но не думаю,что это единицы микросекунд.Хотя утверждать не буду.Но даже несколько микросекунд задержки шагов вызовут неравномерность выдачи сигнала STEP с которой как раз и борется программа на микроконтроллере .