А кто-нибудь подробно с linuxcnc имел дело?

atrus

О, бот, а напиши топ пользователей этого сайта

у меня есть специальный контроллер, управляющий шаговиками

какой?

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

Т.е. ему требуется внешний планировщик

По linuxcnc лучше на cnc-club.ru, там есть юзер - Nick, он поможет. Но по сабжу, не особо ясно. Есть LinuxCNC, есть твой контроллер. Скармливаешь gcode, получаешь импульс в контроллер. Ему без разницы, самопальный он или покупной. Уточни задачу - станок строишь, робота или ещё что.

Ну вот я хочу, чтобы генерацией импульсов как раз контроллер занимался. А всей планировкой движения, разгон, торможение, итд - linuxcnc. Небольшой чпу-фрезер. Механику готовую купил, а вот с софтом сам вожусь

Ну он так и работает же....

LinuxCNC, как я понял, сам генерит импульсы на шаговики. Именно поэтому он требует realtime ядро.

сам генерит импульсы на шаговики

ты хочешь шаговый двигатель к ПК с LinuxCNC подключить?) В общем, мы друг друга не понимаем. Но в любом случае можно реализовать ооочень много, здесь придётся понять как работает HAL. Начни с этого http://www.cnc-club.com/forum/viewtopic.php?f=15&t=106&sid=a2cf7fa690...

ты хочешь шаговый двигатель к ПК с LinuxCNC подключить?)

Нет. Шаговый двигатель подключен к stm32 микроконтроллеру. Этот микроконтроллер принимает команды по Com порту. Команды содержат точку, куда переместиться и параметры движения/разгона/торможения.

Я пытаюсь разобраться, как добавить поддержку моего контроллера в linuxcnc

Читай про HAL, classicladder и всё такое.

Ещё погугли про linuxcnc + arduino и глянь сюда -> https://github.com/dewy721/EMC-2-Arduino

Команды к stm32 контроллеру вида

«G01F200P42L0T1000 X10.00 Y10.00 Z0.00» - переместись в 10,10, со скоростью 200, при этом начальная скорость 42, конечная скорость 0, а ускорение 1000.

Здесь в принципе мог быть и не g-code. Это просто промежуточное представление для передачи команд между планировщиком и контроллером

Смотри как сделано в HAL2Arduino.

Но погуглить про HAL и ladder всё равно не помешает.

Посмотрю, спасибо

torvn77

А зачем было мастерить свой контроллер для шаговика, если уже есть хренова куча готовых (и более дешевых), которые «из коробки» поддерживаются практически любыми прошивками и прочим сервисным софтом для разных самоделок ?

Не имел дел лично. Помогал другу в настройке и по этому интересовался.

ну валялась у меня на полке платка с stm32

Я просто вот к чему. Существующие драйверы управления шаговиками, такие как A4988, DRV8825 или LV8729 - берут на себя в основном силовую часть вопроса, а само управление шаговиками через них всё-равно остаётся достаточно низкоуровневым. Это уже более-менее устоявшаяся практика - там используются сигналы на установку направления движения и количество шагов. Ничего подобного что вы сделали на своём контроллере - там и в помине нет. Всю ту логику что вы реализовали в своём контроллере, а, именно, планировку движений, расчёт ускорений и прочее, обычно берёт на себя непосредственно прошивка CNC машины (LinuxCNC в вашем случае), и подаёт управляющие импульсы контроллеру шаговика, который уже формирует силовые импульсы непосредственно для обмоток двигателя. Если я правильно понял, то LinuxCNC управляет драйвером шагового двигателя через параллельный порт (http://linuxcnc.org/docs/html/config/stepconf.html#cha:stepconf-wizard), что, наверное, является единственным способом для прямого IO на современных X86 PC.

Не совсем понятно, как можно бесшовно интегрировать ваш контроллер в такую схему, и нужно-ли это делать вообще. Так как задачи которые вы реализовали на вашем контроллере - обычно с успехом выполняют прошивки CNC машин вроде GRBL, Marlin (для 3D принтеров), ну, или LinuxCNC. И, наверняка, они это делают лучше. Не в упрёк вам сказано, просто они развиваются десятилетиями уже и мейнтейнеров только на эту задачу там побольше будет. И, возможно, не стоит тратить время чтобы интегрировать ваш велосипед во всю эту отлаженную схему, насколько хорошим он бы ни был. То что вы сделали уже само по себе больше смахивает на CNC прошивку, чем на контроллер шагового двигателя в привычном смысле.

И всё же, теперь самому интересно) Схему или фото хотя бы скинь. У тебя уже с драйверами ШД контроллер? Управление с ПК по USB или LPT?

LinuxCNC управляет драйвером шагового двигателя через параллельный порт

Вот как раз через HAL можно реализовать любой интерфейс: usb, lpt, rs232, lan и т.д. Иногда между ПК - и LPT контроллером USB прослойкой служит ардуина. Прошивок полно, можно взять любую и посмотреть обработку сигналов step/dir. А затем реализовать свой костыль.

Какое LPT, при чем здесь LPT? Драйверами ШД управляет stm32. А команды от компьютера получает через rs232

Какое LPT, при чем здесь LPT?

Вот поэтому и нужна схема. Телепатия для избранных.

https://pp.userapi.com/c845219/v845219917/cad41/xT9Qqf9t544.jpg

Вижу три пути:
1. Переписывать grbl прошивку для stm, т.к. принцип такой же как на схеме
2. Делать автономный контроллер с экраном и картой памяти
3. Всё таки задать вопрос на cnc-club.ru

порт grbl даже есть под stm32, Но не понравилось там несколько моментов. Можно, конечно, патчить ее.

в grbl содержится полноценный интерпретатор g-code в самом контроллере. У такого подхода есть свои минусы

UPD: чего я хочу: у меня есть специальный контроллер, управляющий шаговиками. Я хочу сделать для LinuxCNC модуль, который будет слать команды в этот контроллер, но при этом по-минимуму ковырять внутренности LinuxCNC

По такому принципу работает Mesa и ещё несколько соотечественников разрабатвают свои контролёры.

Команды к stm32 контроллеру вида
«G01F200P42L0T1000 X10.00 Y10.00 Z0.00» - переместись в 10,10, со скоростью 200, при этом начальная скорость 42, конечная скорость 0, а ускорение 1000.

Здесь в принципе мог быть и не g-code.

В таком виде LinuxCNC задействавать не выйдет да и зачем, если и команда cat с этой задачей достаточно хорошо справится?

В таком виде LinuxCNC задействавать не выйдет

Запросто. HAL в зуббы и пишешь что-то типа

net xpos-cmd axis.0.motor-pos-cmd => your_hal.xpos
net ypos-cmd axis.1.motor-pos-cmd => your_hal.ypos
net zpos-cmd axis.2.motor-pos-cmd => your_hal.zpos

Потом сочинаешь hal, у которого есть 3 входа xpos, ypos и zpos, и который данные с этих трёх входов отправляет, например, через USB в контроллер двигла, который уже сам занимается низкоуровневыми задачами типа вращения двигателей до нужных позиций.

например, если хочется использовать motion planner от linuxcnc, но чтобы двиглом управлял контроллер, а не штатный stepgen.

да и зачем, если и команда cat с этой задачей достаточно хорошо справится?

motion planner в linuxcnc гораздо круче любых grbl. Это раз.

Сейчас практически нереально добыть комп, который бы не засирал RT latency всякими сраными IntelME, PSP и прочим неудаляемым анальнозондовым дерьмом. Сейчас выбор железа для linuxcnc на жостком RT ограничен либо x86 мамкой и процом с помойки 2000-х, либо BBB, либо что-то очень промышленное и мелкосерийное с соответствующей ценой. Поэтому, очень актуально и насущно сейчас снять жёсткие реалтаймовые задачи с компа и перенести их в копеечную железку на том же STM32 или другом микроконтроллере в которм заведомо нет IntelME и на котором легко можно обеспечить жёсткий и быстрый реалтайм, а задачи парсинга G-code, планирования движений, отображения красивых 3D свистелок и перделок оставить на медленный RT тред в «большом» компе, ибо для медленного треда говно от IntelME и подобных гадостей не так сильно мешает. Это два.

А расчитывать разгон/торможение, обход углов, итп кто будет?

Ну раз у тебя интерпретатор gcode в контролёре, то он видимо рассчитывать и будет.

Или ты хочешь что-то вроде того, о чём Stanson постом выше пишет? Тогда протокол обмена с контролёром будет несколько иным.

Ну раз у тебя интерпретатор gcode в контролёре, то он видимо рассчитывать и будет.

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

Я думаю, тебе нужно посмотреть, как цепляются сервоприводы с их контроллерами. Ещё вариант посмотреть на плату smoothstepper (не помню названия) чел с вышеназванного форума делал и продавал. Там у него одна или 2 стмки на плате, для генерирования импульсов для драйверов с большим микрошагом, тоже интересно

Ну тогда лелай по рецепту stanson:

Запросто. HAL в зуббы и пишешь что-то типа

net xpos-cmd axis.0.motor-pos-cmd => your_hal.xpos
net ypos-cmd axis.1.motor-pos-cmd => your_hal.ypos
net zpos-cmd axis.2.motor-pos-cmd => your_hal.zpos

Потом сочинаешь hal, у которого есть 3 входа xpos, ypos и zpos, и который данные с этих трёх входов отправляет, например, через USB в контроллер двигла, который уже сам занимается низкоуровневыми задачами типа вращения двигателей до нужных позиций.

]Только данные в контролёр отправляй не в текстовом виде «G01F200P42L0T1000 X10.00 Y10.00 Z0.00», а как бинарную структуру в которой каждая переменная сидит на своём смещении и в таком же виде получай обратно текущие координаты и данные GPIO.

И ещё, тебе стоит к протоколу modbus присмотреться, я предпологаю что тебе тогда и специальный модуль для HAL писать не нужно будет.

Только данные в контролёр отправляй не в текстовом виде «G01F200P42L0T1000 X10.00 Y10.00 Z0.00», а как бинарную структуру в которой каждая переменная сидит на своём смещении и в таком же виде получай обратно текущие координаты и данные GPIO.

Это сугубо личное дело контроллера ТС и модуля HAL для работы с ним. Если у ТС контроллер умеет в укушенный G-code состоящий только из G0/G1 то ничто не мешает отправлять в USB эти G0/G1 в текстовом виде и, кстати, в таком же виде получать обратно feedback, который тоже стоит подключить как

net xpos-fb your_hal.xpos-fb => axis.0.motor-pos-fb
net ypos-fb your_hal.ypos-fb => axis.1.motor-pos-fb
net zpos-fb your_hal.zpos-fb => axis.2.motor-pos-fb

Без feedback тоже можно, но с feedback'ом гораздо интереснее. :)

Ещё можно текущую скорость из motion вытащить как axis.N.joint−vel−cmd, хотя зная период motion не составит труда её в контроллере вычислять.

Как бы он при таком подходе модуль HAL вместо С на python не написал.

меня только беспокоит, если получается, что есть 3 команды на перемещение, по 1 на каждую ось, то не выйдет ли, что linuxcnc пошлет сперва перемещение по одной оси, потом по другой, а потом по третьей? А в общем случае то надо по всем 3-м сразу

Ты не любишь питон?

меня только беспокоит

LinuxCNC, съев gcode, пошлёт сигналы сразу на все нужные пины, указанные в ini/hal. А как ты их обработаешь - зависит от тебя. UPD. в этом вопросе LPT рулит.

А он, увидев в Gcode какой-нибудь «G0X100» сам разобьет эти 100 мм на шаги и для каждого пошлет сигнал, или же предоставит это на усмотрение hal драйвера? Мне то не надо, чтобы он дробил сам. Я хочу, чтобы linuxcnc распланировал движения, ускорения, разгон и торможения, и все это отдал моему контроллеру. А уже мой контроллер на шаги (step/dir) дробит сам.

увидев в Gcode какой-нибудь «G0X100» сам разобьет эти 100 мм на шаги и для каждого пошлет сигнал

Конечно. При условии, что в конфиге микрошаг и пины соответствуют твоему контроллеру.

Тогда мне это не подходит совершенно. Мой контроллер принимает не импульсы, а указания о перемещениях. А импульсы на шаговики генерит сам.

Шли в контроллер строку тогда G0X100Y100Z100 удобным способом, парсь её и генери импульсы.

А планировать разгон и торможение кто будет? Я как раз хочу использовать планировщик от linuxcnc.

Эту твою STM32 перешивать же можно?
Так зачем цепляешся именно к этой прошивке?
Возми или создай более подходящую.

Да, не люблю, но дело не только в этом:))).

Конечно я могу переписать прошивку как хочу. но из интерфейсов к компу у меня usb и rs232 (через usb). Ни то ни другое не обеспечивает возможности непосредственно отсылать импульсы с достаточной скоростью и точность.

Да и вообще, реалтайм задачи должны решаться на отдельном оборудовании, а не там же, где и UI и прочее. А генерация step импульсов это очень реалтайм задача

Чтобы преобразовать g-code в импульсы, надо решить 2 задачи:

1) спланировать движение 2) преобразовать спланированное движение в импульсы

Например, если у меня g-code

G91
G0X10
G0X10
G0X10Y1

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

Это задача 1. Она не требует realtime, но зато требует вычислительных ресурсов. Поэтому ее лучше решать на компе, а не в контроллере.

Задача 2 заключается в том, чтобы полностью распланированное движение преобразовать в импульсы. Она, наоборот, не требует особых вычислительных ресурсов, но очень требует realtime. И потому ее разумно решать на микроконтроллере.

Исходя из этого я и хочу все планирование вести на ноуте, а импульсы генерить на stm32

Попробуй сгенерить на компе из простой строки gcode нужную «длину» импульса и отослать в stm. Но имхо, овчинка выделки не стоит... без костылей никак.

сгенерить на компе из простой строки gcode нужную «длину» импульса

?