Написание плагинов движения для mach3

[Impartial]

Бонусом получаем буферизацию команд (которой, если я правильно понял, в плуто нет).

О каких командах идет речь?

[ipr]

Почему не допустимо? При буферизации команд как раз допустимо. В пик я ухитрялся запихнуть буфер на 2 секунды! Конечно, при таком варианте мы теряем возможность оперативно реагировать на изменение входов... Но для этого и нужен микроконтроллер. Все действия, требующие оперативной реакции (например, установку нуля), придется реализовывать в нем. Если генерацией шагов будет занята плис - ресурсов микроконтроллера должно хватать (а если и не хватит, то можно расчеты производить в плагине, и отправлять их результат в контроллер). Тот же разгон, можно задать скорость и ускорение (и пересчитывать в шаги в контроллере), а можно и массив чисел, каждое из которых - количество шагов по сервоциклам.

[ipr]

О каких командах идет речь?

Параметры одного сервоцикла - количество шагов в нем.

[Impartial]

Скорость и ускорение нельзя отвязывать от траектории расчитаной мачем. На мой взгляд это бессмысленно.
Буфферизировать скоростные задания на сервоцикле (количество шагов в сервоцикле это и есть скорость на сервоцикле) можно, но это имеет смысл только при применении шагового привода. Но в мач то нужно выводить состояние координат выданный генератором шагов. Как быть с этим?
Если использовать сервопривод с возможностью ввода в мач текущих координат с энкодеров, то смысл теряется.
Ну и плюс справедливо замеченная задержка по срабатыванию концевиков. Для хоминга это может оказаться недопустимым не говоря уже о поиске начала заготовки или высоты плазмотрона.

[ipr]

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

[Impartial]

Mach3 не использует возвращенные из генератора значения координат для расчетов. Он работает без обратной связи. Поэтому возвращать ему координаты в реалтайме нет необходимости.

Для расчета да, не использует. Для индикации.
Меня интересует подключение к мач сервоприводов и Ваш опыт по написанию плагина пришелся кстати.

Хоминг нужно реализовывать в контролллере, тут других вариантов просто нет...

Так наверное тоже не получится. Будет потеря информации о координатах для мача.

[ipr]

Для индикации

Информация о выполненных шагах же не пропадает. Вряд ли кто-то способен заметить, что отображаемые координаты будут меняться не каждую микросекунду, а каждые 10 миллисекунд

Будет потеря информации о координатах для мача

То же самое, мы же сами будем реализовывать алгоритм хоминга - значит, и обладать этой информацией тоже будем. Ведь внутренние машинные координаты (в терминах Mach3) - измеряются в выполненных шагах, а сколько шагов сделано, мы всегда знаем.

подключение к мач сервоприводов

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

[Impartial]

а сколько шагов сделано, мы всегда знаем.

Мы то знаем, мач не знает. И узнает он только получив ответ от контроллера. Ответ задержался на несколько сервоциклов. У мача на уме последние координаты, которые он выдал.

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

До блока реализующего преобразование скорости в управление приводом ничем не отличается.
Управление по степ/дир сервоприводом это извращение. В идеале нужно получить данные с энкодера, просчитать ПИД и сформировать ШИМ для управления выходными ключами серво усилителя. Все это делает плата которую я выше привел.
В ЕМС, для которой эта плата изначально предназначена сделано более разумно. В маче нет внутреннего просчета ПИД. Он под шаговики заточен.

[ipr]

У мача на уме последние координаты, которые он выдал.

И что в этом страшного, мы даже не заметим этого, а самому мачу пофиг

получить данные с энкодера, просчитать ПИД и сформировать ШИМ

Ужас. Я раньше считал, что все это делает сам сервопривод... Конечно, в маче этого нет, все-таки он действительно заточен для шаговых моторов.
А плата pluto, она как понимаю, производит все эти действия, и ей достаточно подать на вход данные о скорости на сервоцикле? Или только ШИМ просчитывает?

[Impartial]

И что в этом страшного, мы даже не заметим этого, а самому мачу пофиг

Как это пофиг? Какую координату в качестве нома он запомнит?

А плата pluto, она как понимаю, производит все эти действия, и ей достаточно подать на вход данные о скорости на сервоцикле?

Да, так и есть.

[Impartial]

Я раньше считал, что все это делает сам сервопривод...

Внешний сервопривод так и делает. Вопрос в том как в него впихнуть эту самую скорость.

[ipr]

Как это пофиг? Какую координату в качестве нома он запомнит?

Пока контроллер не рапортует о успешном нахождении хома, мач каких-то других действий производить не будет. Все просто

[Impartial]

мач каких-то других действий производить не будет.

Как это не будет? Он будет гнать сервоциклы, искать хом.

[ipr]

Он будет гнать сервоциклы, искать хом

Нет. Он однократно подает команду в контроллер "ищи хоум по оси <номер оси>", все остальное делает контроллер.

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

[Impartial]

Нет. Он однократно подает команду в контроллер "ищи хоум по оси <номер оси>", все остальное делает контроллер.

Так возможно. Непонятно кто определяет скорость на траектории поиска.

Используя юсб (да впрочем, и другие способы соединения - кроме прямого ногодрыжества параллельным портом)

Все правильно, только времена гарантированной доставки разные. USB и EPP LPT (сидящий на PCI) разные порядки времени. Тем более, что обращение к LPT идет не на уровне драйвера винды а прямым общением с портом.

[ipr]

кто определяет скорость на траектории поиска

Мы сами (точнее наш плагин). После реконфигурации настроек моторов, мы знаем их допустимые разгонные характеристики. И либо отправляем их в неизменном виде (скорость и ускорение) в контроллер (и контроллер их пересчитывает в сервоциклы), либо делаем это в плагине, и в контроллер отправляем цепочку сервоциклов, и там запоминаем. Нам хватит 2х цепочек - быстрого движения (до срабатывания концевика) и медленного для точного останова (подвод оси до размыкания концевика).
Принцип такой:
1. Разгоняемся и быстро едем в сторону концевика
2. Замыкается концевик, запоминаем координату, реверсируем цепочку "быстрого" сервоцикла
3. Останавливаемся
4. Вычислив количество шагов до размыкания концевика, по медленной цепочке сервоциклов движемся в обратную сторону.
как-то так...

не на уровне драйвера винды а прямым общением с портом

Вот именно, поэтому про принципы управления через LPT лучше сразу забыть. Тут нужен другой подход...

[ipr]

Собственно о протоколе обмена. Набросал примерную структуру команд, которую точно буду реализовывать в плагине. Несколько отличается от выложенного ранее плагина, но не сильно.
Критика и пожелания приветствуются!

[Impartial]

Мне кажется лишним перекладывать функции планировщика траектории на плагин, а тем более на внешний контроллер.
Это не такая простая задача, как кажется. И очень требовательна к ресурсам.
Мне нужно просто получить входные порты,позицию и передать в контроллер скорость, состояние выходных портов один раз в самом начале сервоцикла.
Я против использования USB для управления подсистемой движения. Можно пульт повесить на нее, кнопки разные, но не более.

[ipr]

перекладывать функции планировщика траектории на плагин

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

Мне нужно просто получить входные порты,позицию и передать в контроллер скорость, состояние выходных портов один раз в самом начале сервоцикла.

Это возможно. Только скорость придется пересчитывать из "шагов за сервоцикл" в нужные Вам величины. Впрочем, может быть все уже посчитано (что скорее всего), в SDK по заголовочным файлам посмотрите...

Я против использования USB

А почему? Только из-за того, что не нормировано время доставки? Или вы против буферизации в принципе?
Не забывайте, что я начал всю эту разработку по простой причине - отсутствию LPT на имеющихся в моем распоряжении компьютерах, и вариантов у меня было немного: RS232 (не хватило скорости), USB (пока обнадеживающие результаты) и Ethernet (не пробовал). Ни один из этих способов без буферизации нормально работать не будет.

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

[Impartial]

Или вы против буферизации в принципе?

Да, именно так.
Я хочу сделать универсальную плату для ЕМС и МАЧ.
Например такую задачу как визуализация настройки ПИД уже невозможно сделать с идеей буферизации. Эта идея (буферизация) неоднократно обсуждалась и я даже сначала пытался ее реализовать. Долго объяснять все нюансы, но пришел к выводу, что не получится.
Для шаговиков, возможно, имеет смысл.