LINUX.ORG.RU
ФорумTalks

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

 


1

3

А именно, достаточно ли он модульно устроен и есть ли у него API для того, чтобы не самостоятельно импульсы на шаговики слать, а чтобы можно было сделать модуль для него, который будет слать команды в специальный контроллер. Я как-то внятного описания по этой теме не нашел.

Можно конечно самому в исходниках поковыряться, но вдруг уже есть описание?

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

★★★★★

Последнее исправление: cvs-255 (всего исправлений: 4)
Ответ на: комментарий от cvs-255

К примеру, чтобы ось Х проехала 5мм пути, на драйвер необходимо отправить какое-то количество импульсов. Считаем, контроллер твой дробит шаг на 16, получаем микрошаг 1/16. Т.е. чтобы ось Х проехала 1мм, движку надо сделать 640 шагов (16*200)/5. Дальше хз) Бери либы готовые, ковыряй. Как разберёшься, бери строку gcode. G0X100, т.е. надо проехать 100мм, а зная, какая длина импульса на 1мм, перемножением найдёшь нужное значение. Короч, брось ты это дело. Если осилишь всё таки, то будешь разачарован результатом. Скорость работы будет крайне мала. upd: зацени хоть плату-то

Deleted
()
Последнее исправление: medossa (всего исправлений: 1)
Ответ на: комментарий от Deleted

Перемещаться он прекрасно у меня уже умеет. И разгоняться, и тормозить. Но надо, чтобы ему кто-то посчитал параметры движения. Пока что я вручную это делал. В строке G0X100 совершенно отсутствует, например, информация о том, надо ли ему замедляться в конце, или нет. Поэтому требуется внешний компьютер, который проанализирует g-code, и скажет, где как надо двигаться

https://pp.userapi.com/c849136/v849136922/5bed6/RLCWkBWcd9Q.jpg

cvs-255 ★★★★★
() автор топика
Последнее исправление: cvs-255 (всего исправлений: 4)
Ответ на: комментарий от cvs-255

Ну так у тебя норм железо-то)) Я думал там самопал на 100%. Драйвера норм, а stm-ка на ардуину похожа чё-то)) G0X100 должна разогнаться до максимальной скорости, если не указана иная. G0 X100 F800 говорит явную скорость. А ускорение/торможение это расчёты

Для наиболее общего случая требуется знать зависимость длительности шага от текущей скорости. Количество шагов, которое осуществляет двигатель при разгоне за время t равно:
N = 1/2At2+Vt, где N – число шагов, t – время, V – скорость, выраженная в шагах в единицу времени, A – ускорение, выраженное в шагах, деленных на время в квадрате.
Для одного шага N = 1, тогда длительность шага t1 = T = (-V+(V2+2A)0.5)/A
В результате осуществления шага скорость становится равной Vnew = (V2+2A)0.5
И т.д. В общем, всё. Больше я не советчик. Всё сложно. Возьми проект какой-нить, посмотри.

Deleted
()
Ответ на: комментарий от Deleted

G0 X100 F800 говорит явную скорость.

Вот только оно не говорит, с какой скоростью шпиндель движется в начальной точке линии и не говорит, какова должна быть скорость в конце. Конечно, можно сделать по-глупому, и везде брать начальную и конечную скорости, равные 0, но тогда производительность вообще никакая будет.

Это определяется планировщиком исходя из того, какие команды были до этой команды и какие будут после. И, вообще говоря, это требует вычислений тригонометрии и прочего. И возлагать все эти расчеты на stm32f103, не имеющей к тому же FPU, как-то не хочется.

Поэтому я хочу в микроконтроллер слать не G0 X100 F800, а, например, G0 X100 F800 P200 L300 - тогда контроллер будет знать, что на момент начала перемещения скорость шпинделя 200 мм/мин, а в конце должна быть 300 мм/мин.

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от Deleted

Ну так у тебя норм железо-то))

Ну так я с самого начала говорю, что вопрос не в железе, а в софте

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от Deleted

Например, вот для такого

G91
G1F100 X1
G1F100 X1
G1F100 X1
G1F100 X1
G1F100 X1
G1F100 X1
G1F100 X1
G1F100 X1

шпиндель должен переместиться на 8 мм непрерывным перемещением, а не останавливаясь на каждом миллиметре.

Для этого я хочу преобразовать его в такой g-code, явно содержащий в себе указание, что на каждом миллиметровом участке не надо останавливаться в его конц

G1F100L100 X1
G1F100P100L100 X1
G1F100P100L100 X1
G1F100P100L100 X1
G1F100P100L100 X1
G1F100P100L100 X1
G1F100P100L100 X1
G1F100P100 X1

И его уже отправить на контроллер

cvs-255 ★★★★★
() автор топика
Последнее исправление: cvs-255 (всего исправлений: 3)
Ответ на: комментарий от cvs-255

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

Не, ты будешь получать новые данные по всем осям (joint'ам) каждый цикл base thread.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

Посмотрел я, как они ардуино прицепляют. Как я понял, они позволяют linuxcnc дергать пины ардуины. При этом linuxcnc по прежнему требует realtime

cvs-255 ★★★★★
() автор топика
Последнее исправление: cvs-255 (всего исправлений: 1)
Ответ на: комментарий от torvn77

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

Ну вроде для STM прошивку явно не на пистоне написал. :)

Stanson ★★★★★
()
Ответ на: комментарий от cvs-255

Да какая разница, _зачем_ они цепляют, тебе надо увидеть _как_ они это делают.

Stanson ★★★★★
()
Ответ на: комментарий от cvs-255

Поэтому я хочу в микроконтроллер слать не G0 X100 F800, а, например, G0 X100 F800 P200 L300 - тогда контроллер будет знать, что на момент начала перемещения скорость шпинделя 200 мм/мин, а в конце должна быть 300 мм/мин.

Тебе это не нужно.

У тебя motion planner каждые TRAJ_PERIOD наносекунд будет дёргать подключённый к axis.N.motor-pos-cmd твой модуль HAL. И выдавать ему очередные координаты. Всё, что тебе надо в твоей STM сделать - это посчитать расстояние от текущего положения до нового и поделить на период твоего планировщика траектории. Получишь скорость и, соответственно, период твоих микрошагов для каждого двигателя. То, что будет получать твоя платка это типа

G1 X123 Y234 Z456
G1 X456 Y789 Z543
G1 X321 Y432 Z765

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

Крайне рекомендую привязать период к USB'шному Start-Of-Frame ( 125uS HighSpeed, 1mS FullSpeed ), чтобы твой пакет для контроллера гарантированно уезжал за это время через USB-стек.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

У тебя motion planner каждые TRAJ_PERIOD наносекунд будет дёргать подключённый к axis.N.motor-pos-cmd твой модуль HAL. И выдавать ему очередные координаты.

Это плохая идея. От ноута к stm32 идет usb -> rs232. Даже если я подключу контроллер через usb напрямую, usb не гарантирует правильных таймингов доставки. Если я правильно помню, usb гарантирует точность до 1 ms, что очень много. Я бы предпочел весь реалтайм полностью вынести на stm32, а все планирование и расчеты оставить на ноуте

cvs-255 ★★★★★
() автор топика
Последнее исправление: cvs-255 (всего исправлений: 3)
Ответ на: комментарий от cvs-255

Это плохая идея. От ноута к stm32 идет usb -> rs232. Даже если я подключу контроллер через usb напрямую, usb не гарантирует правильных таймингов доставки. Если я правильно помню, usb гарантирует точность до 1 ms, что очень много.

Нет, точность будет равна периоду фрейма USB. Для FullSpeed это 1mS, для HighSpeed 125uS. Даже 1mS более чем достаточна для задачи.

Ну представь - тебе каждую миллисекунду будут выдавать новые координаты, и ты недоволен? Это же 1кГц! Тысяча новых точек траектории в секунду! Плавность даже на FullSpeed будет такая, что даже пропуск пары периодов не заметишь.

USB как транспорт совершенно не годится для передачи сигналов для шаговиков - это несомненно. Там микросекунды нужны, чтобы плавно и без дёрганий. Но тебе же не надо каждый шаг передавать, движки крутить будет твой STM. В этом и суть заморочки.

Stanson ★★★★★
()
Ответ на: комментарий от cvs-255

Да, кстати, без реалтайма ты не обойдёшься. Планировщик у тебя тоже должен быть реалтаймовый. Просто если у тебя период реалтайма 1mS, то совершенно неприемленый для треда генерирующего шаги для шаговиков джиттер в 10мкс из-за сраного говно_интель_говно_МЕ, для этого реалтаймового треда планировщика будет практически незаметен.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

Да, кстати, без реалтайма ты не обойдёшься. Планировщик у тебя тоже должен быть реалтаймовый.

Это печально

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от cvs-255

Это печально

Почему? RTAI и, может быть немного пошаманить - и у тебя будет вполне приличная миллисекунда.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

ну было бы лучше, если бы на ноуте (к тому же не самом шустром) не требовался реалтайм

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от Stanson

кстати, насчет использования usb в realtime. надеюсь, в linuxcnc есть драйвера для работы с usb и usb->rs232 из rt?

На 2015 год пишут что не было https://forum.linuxcnc.org/49-basic-configuration/29976-will-linuxcnc-run-wit...

cvs-255 ★★★★★
() автор топика
Последнее исправление: cvs-255 (всего исправлений: 3)
Ответ на: комментарий от cvs-255

Хотя если hal2arduino работает, то наверно и тут получится

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от cvs-255

кстати, насчет использования usb в realtime. надеюсь, в linuxcnc есть драйвера для работы с usb и usb->rs232 из rt?

Тебе libusb будет более чем достаточно. И твой hal вообще не обязан быть реалтаймовым, как ни странно :)

Единственное что непонятно - это почему usb-rs232, а не напрямую использовать USB STMки

Если у тебя USB-RS232 обычный, то тебе libusb даже не нужно. Открывай /dev/ttyUSBx и пиши-читай туда раз в миллисекунду. TRAJ_PERIOD сделай 2mS - с очень огромной вероятностью ничего не пропустишь.

Stanson ★★★★★
()
Последнее исправление: Stanson (всего исправлений: 1)
Ответ на: комментарий от Stanson

почему usb-rs232, а не напрямую использовать USB STMки

rs232 проще. Да и разъем попрочнее, чем microusb

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от cvs-255

А, т.е. hal работает не из реалтаймовой части linuxcnc?

как угодно может работать. Это просто софтинка такая. Может быть реалтаймовой, нереалтаймовой ядерной и юзерспейсной.

Stanson ★★★★★
()
Ответ на: комментарий от cvs-255

По большому счёту пофиг. Всё равно cdc - это пара bulk endpoint'ов.

Лучше конечно через libusb данные слать - там есть гарантия что весь пакет данных уедет целиком и за один фрейм.

Stanson ★★★★★
()
Последнее исправление: Stanson (всего исправлений: 1)
Ответ на: комментарий от Stanson

ну вот, например, в реалтайм задачах rtlinux есть проблема с линуксовыми драйверами. Так что вопрос не праздный

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от Stanson

ну надо еще на стороне контроллера покодить.

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от cvs-255

Так ты ж не что-то жёсткое пишешь, а всего лишь хрень которая будет брать три циферки и отправлять их в USB/Serial. У тебя с одной стороны твоего модуля realtime trajectory planner, с другой стороны realtime девайс для кручения двигателей. И тот и другой чётко знают какой на самом деле период обновления данных, так что реалтаймовость твоего hal ни к чему вообще.

Stanson ★★★★★
()
Ответ на: комментарий от cvs-255

ну если следующий кадр задержится, то знание периода мало чем поможет...

Если у тебя загрузка машины такая, что процесс даже раз в миллисекунду, плюс-минус миллисекунда не может совершить простейшую операцию, то пиши реалтаймовый hal для Serial(rt_serial) или Ethernet (rt_net).

Stanson ★★★★★
()
Последнее исправление: Stanson (всего исправлений: 1)
Ответ на: комментарий от Stanson

Что-то linuxcnc вообще не видит realtime ядра.

uname -a
Linux vlad 4.9.0-8-rt-amd64 #1 SMP PREEMPT RT Debian 4.9.110-3+deb9u3 (2018-08-19) x86_64 GNU/Linux

suid флаги стоят

$ rtapi_app
Waited 3 seconds for master.  giving up.
Note: Using POSIX non-realtime
cvs-255 ★★★★★
() автор топика
Последнее исправление: cvs-255 (всего исправлений: 1)
Ответ на: комментарий от cvs-255

или это не относится к делу?

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от cvs-255

Что-то linuxcnc вообще не видит realtime ядра.

Потому что у тебя обычное ядро с PREEMPT_RT. Реалтаймовое ядро - это на которое наложены патчи RTAI

С PREEMPT_RT linuxcnc тоже умеет, но вроде его надо за что-то потрогать, чтобы он понял. Возможно пересобрать с поддержкой PREEMPT_RT.

Stanson ★★★★★
()
Последнее исправление: Stanson (всего исправлений: 1)
Ответ на: комментарий от Stanson

Да, собрать надо с --with-rt-preempt-kernel. Но если на дебиане всё будет крутиться, то лучше нативные репы linuxcnc прикрутить.

Deleted
()
Ответ на: комментарий от Deleted

--with-rt-preempt-kernel

такой опции configure не знает

то лучше нативные репы linuxcnc прикрутить.

Они там от пакетов wheezy зависят

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от cvs-255

Хех, изменили:

 --with-realtime=uspace

Build for any realtime platform, or for non-realtime. The resulting LinuxCNC executables will run on both a Linux kernel with Preempt-RT patches (providing realtime machine control) and on a vanilla (un-patched) Linux kernel (providing G-code simulation
but no realtime machine control). If development files are installed for Xenomai (typically from package libxenomai-dev) or RTAI (typically from a package with a name starting "rtai-modules"), support for these real-time kernels will also be enabled.

Deleted
()
Ответ на: комментарий от Deleted

--with-realtime=uspace

А, ну эта опция у меня была выбрана

cvs-255 ★★★★★
() автор топика
Последнее исправление: cvs-255 (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.