История изменений
Исправление Stanson, (текущая версия) :
В таком виде 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 и подобных гадостей не так сильно мешает. Это два.
Исходная версия Stanson, :
В таком виде LinuxCNC задействавать не выйдет
Запросто. ladder в зуббы и пишешь что-то типа
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 и подобных гадостей не так сильно мешает. Это два.