Search in topic

Шаговые vs Коллекторных

Не оч хороший пример ведь то, что строим по определению не должно быть зависимым от люфтов и зазоров.

В чем и вся фишка - система командует: - Шаг! Контроллер исполняет, вносит коррекцию. При следующем шаге и даже при смене направления (самый момент для люфта) контроллер исправит ситуацию за время, превышающее время прихода следущей команды.

В чем и вся фишка - система командует: - Шаг! Контроллер исполняет, вносит коррекцию. При следующем шаге и даже при смене направления (самый момент для люфта) контроллер исправит ситуацию за время, превышающее время прихода следущей команды.

А можно и по другому.
Система командует: - Движение на 25 мм от текущей координаты со скоростью 100 мм/мин
Контроллер исполняет:

1. Разгон до скорости 100 мм/мин на дистанции 5 мм
2. Движение с заданой скоростью до зоны подхода к координате 25-5 мм
3. Снижение скорости до величины 10 мм/мин
4. Движение с заданой скоростью до зоны торможения к координате 25-1 мм
5. Стоп

Но к сожалению пример который я привел канает только для прямолинейных перемещений. Для криволинейных перемещений канает только пошаговая дискретизация и разложение траектории движения на кусочно-линейные участки для чего надо писать программу под контроллер сервопривода… Но вот вопрос, и нафига все это городить, если уже есть готовое программное обеспечение под шаговики, готовый драйвер (и не один), КАД-КАМ программы, создающие профиль, траекторию и управляющие движением… Могу понять лишь один ответ в данном случае: “А подолбаться?..”

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

Я бы действовал по другому:
получение команды шаг
получение команды дир
комутация направления вращения
получение команды шаг(2)
оценка интервала времени между шагом 1 и шагом 2
установка скорости(или количества шагов) для перемещения
получение команды шаг(3)
перемещение в точку, определенную шагом 2(на заданное расстояние)
оценка интервала времени между шагом 2 и 3
если не изменилось, оценка правильности перемещения между точками заданными шагами 1 и 2, коррекция скорости(если нужно) продолжить движение до точки определенной шагом 3
если ожидаемое перемещение не совпало по времени, увеличить или уменьшить скорость
получение сигнала шаг 4, повторить те же операции что и после шага 3
-----------------------------------------------
неполучение сигнала 4 в ожидаемое время - замедлить скорость, с расчетом остановки в точке, определенной шагом 3
перемещение в точку, определенную шагом 3 и остановка до получения команд шаг 4 и дир

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

Но к сожалению пример который я привел канает только для прямолинейных перемещений. Для криволинейных перемещений канает только пошаговая дискретизация и разложение траектории движения на кусочно-линейные участки для чего надо писать программу под контроллер сервопривода… Но вот вопрос, и нафига все это городить, если уже есть готовое программное обеспечение под шаговики, готовый драйвер (и не один), КАД-КАМ программы, создающие профиль, траекторию и управляющие движением… Могу понять лишь один ответ в данном случае: “А подолбаться?..”

А мне не нужен очень умный контроллер который будет принимать данные, сам их обрабатывать и сам что-то делать. Мне нужен простой в построении, т.е. который будет обрабатывать рутину (такую как двинуться именно на шаг + исправление возможных ситуаций). А как я им буду управлять - это уже другой вопрос. Любую сложную задачу можно разбить на более простые задачки. И никто не мешает мне построить другой контроллер который будет управлять именно этим контроллером… и так далее. Вот наглядный пример - была тут задачка с концевиками. Ставить их или нет? С одной стороны вещь нужная, с другой - бесполезная на ШД. И никто не догадался их ввести аппаратно как логику на простых и-не в сигнал шага. Дополз до концевика - команды идут а двигатель стоит. А если пойти дальше то можно и прерывать поток на концевике. Но это так, кслову. А городить еще один компьютер к уже сущевствующему - занятие бесполезное.

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

Я бы действовал по другому:
получение команды шаг
получение команды дир
комутация направления вращения
получение команды шаг(2)
оценка интервала времени между шагом 1 и шагом 2
установка скорости(или количества шагов) для перемещения
получение команды шаг(3)
перемещение в точку, определенную шагом 2(на заданное расстояние)
оценка интервала времени между шагом 2 и 3
если не изменилось, оценка правильности перемещения между точками заданными шагами 1 и 2, коррекция скорости(если нужно) продолжить движение до точки определенной шагом 3
если ожидаемое перемещение не совпало по времени, увеличить или уменьшить скорость
получение сигнала шаг 4, повторить те же операции что и после шага 3
-----------------------------------------------
неполучение сигнала 4 в ожидаемое время - замедлить скорость, с расчетом остановки в точке, определенной шагом 3
перемещение в точку, определенную шагом 3 и остановка до получения команд шаг 4 и дир

Нечто в этом роде

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

ИМХО, лучше вносить на обсуждение хоть какието идеи, даже бредовые, что бы это можно было обсудить и вынести приговор, это позволит всем читающим данный форум (да и другие подобные), избежать многих ошибок и съэкономить время для других свершений.

Вот я и вношу на обсуждение новую идею. Она в том, что раз мы пользуемся ворованными CAD/CAMами и палёным Виндовсом то не будет страхом уворовать идеи и готовые наработки у тех же немцев. Я же почти открытым текстом дал понять, что раздербанил несколько буржуйских моушен контроллеров и посмотрел что и как устроено, дал ссылку на чипы, которые может купить любой ( у меня они уже давно есть ) . Хочу растрясти всех от спячки и заставить почитать даташит на PCL6143. Всё что вы обсуждаете и ещё не обсудили уже реализовано NIPPON в одном чипе ещё в 2000 году. Чип конечно уже отстойный, но даже с тем что там есть можно горы двигать. Использовать его - это лучше чем городить с нуля своё. У меня просто нет времени довести своой моушен до ума. Он уже двигает, но у меня не получилось корректно реализовать перезапуск интерполяции по ошибке одной из осей. Похоже в даташите ошибки или что-то не дописано. И вообще - я почти год мудохаюсь. Хотел по ZigBee заливку делать.
У меня готовый моушен на этом чипе есть, шаговики совмесно с ним делают такую крутую динамику что напрочь отшибает желание сравнивать их с серваками

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

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

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

Да собсвенно никакой приамбулы нет. Работал я в Польше. Там был ржавый широкоформатный резак по стеклу и мы с моим польским коллегой переделали его в гравер по стеклу. На календаре 2000 год был, этого форума и в помине не было. Ездил он долго и мудоошно и мы начали его модерновать. Сначала шаговики заменили на серваки от мицубиши - дорого тогда было аж по 1700 долл каждый стало значительно лучше, но всё равно мы не успевали с заказами - станок медленный. Потом подвернулась немецкая контора с ЭКОСТЕПами и мы по дешевке ( типа для ознакомления ) купили 3 штуки СТЕП100. Разница сразу ошеломительная - стало страшно стоять возле станка, особенно эффектно шёл возврат в 0 в конце программы. Нам пришлось пришпиливать станок к полу и немного раму подварили. Программировал всё поляк , я на тот момент ещё не понимал многого. Я CADил и САМил ну и поближе к кассе. Вполне возможно, что на мицубишевских приводах редукторы стояли с неоптимальным передаточным числом. Но менять их дорогое удовольствие, а после того как я увидел что шестерни там пластиковые - настроение упало. Никаких характеристик у меня нет и сравнение у меня только визуальное ( мы же не исследовательский центр ) . Я сравниваю только по содержимому кошелька. 😃
Потом по стеклу дела немного упали и мы лазер поставили, чтобы пластик резать. Потом зажрались немного и почти 2 года не работали - денег хватало.
Я не могу обнародовать конструкцию - она ведь совмесная. Мой польский друг отлично читает по русски. У нас уговор и я друзей не сдаю. Я и так много тут нарасказывал , пинаков низачто наполучал. 😃

Вот я и вношу на обсуждение новую идею. Она в том, что раз мы пользуемся ворованными CAD/CAMами и палёным Виндовсом то не будет страхом уворовать идеи и готовые наработки у тех же немцев. Я же почти открытым текстом дал понять, что раздербанил несколько буржуйских моушен контроллеров и посмотрел что и как устроено, дал ссылку на чипы, которые может купить любой ( у меня они уже давно есть ) . Хочу растрясти всех от спячки и заставить почитать даташит на PCL6143. Всё что вы обсуждаете и ещё не обсудили уже реализовано NIPPON в одном чипе ещё в 2000 году. Чип конечно уже отстойный, но даже с тем что там есть можно горы двигать. Использовать его - это лучше чем городить с нуля своё. У меня просто нет времени довести своой моушен до ума. Он уже двигает, но у меня не получилось корректно реализовать перезапуск интерполяции по ошибке одной из осей. Похоже в даташите ошибки или что-то не дописано. И вообще - я почти год мудохаюсь. Хотел по ZigBee заливку делать.
У меня готовый моушен на этом чипе есть, шаговики совмесно с ним делают такую крутую динамику что напрочь отшибает желание сравнивать их с серваками

А потом придется брать ружо и идти на охоту за этими PCL6143:) Проще собрать на логике которая уже в каждом радиокружке лежит килограммами… Ну будет у меня размер побольше и ладно! Качество от этого не поменяется.

Ну хоть просветите нас, незрячих, чем же PCL6143 так хороши в общих чертах и какой алгоритм они используют

… дал ссылку на чипы, которые может купить любой (у меня они уже давно есть) . Хочу растрясти всех от спячки и заставить почитать даташит на PCL6143…

Посмотрел в efind, нет ни одного предложения, так что насчет любой - это Вы погорячились. И в этом свете вопрос: а зачем читать про то, чего нет?
Да и цена за чип (на nipponpulse.com) не очень вдохновляет - без малого $US 50. Может все же на чем попроще и подоступнее? Как Chan

Вот еще ссылка из недавних: уважаемый Художник бесплатно дает свои работы по этой теме

Посмотрел в efind, нет ни одного предложения,
Да и цена за чип (на nipponpulse.com) не очень вдохновляет - без малого $US 50. Может все же на чем попроще и подоступнее? Как Chan

Мне очень жаль, что я предлагаю почитать про 4 осевой моушен а мне говорят про некоего кумира Чена с его сервоконтроллером на 50 вт. Господа, это же разные вещи.
И опять про деньги. Неужели для россиян 50$ это неподъёмная сумма? ( за пересылку вы ещё отдадите 25 )
И что такое efind - русский интернет магазин ?? Так в России чего захочешь, того и нет.

Неужели никто так и не понял ничего ??

Мне очень жаль, что я предлагаю почитать про 4 осевой моушен а мне говорят про некоего кумира Чена с его сервоконтроллером на 50 вт. Господа, это же разные вещи…
Неужели никто так и не понял ничего ??

Лично я пока ничего про него не понял. Адепт предлагал же Вам поделиться с нами своими знаниями про этот “programmable pulse generators” (программируемый генератор импульсов).
Ваша ведь цитата:

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

Меня пока даже не столько цена смущает, сколько доступность и удобство работы.
Корпус: 176 выводов на 4 стороны с шагом 0,5 мм - не самый удобный для домашнего хобби.
Доступность (цитата с сайта):
Available In Inventory:
1-9 Qty: In Stock, Ready To Ship
10-24 Qty: 2 week delivery
25-50 Qty: 2 week delivery
Похоже на штучное производство - 10 штук складские запасы, а все что больше - ждите пока сделаем.

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

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

mt.
Дело не в цене. Кроме того, что справедливо сказал ATLab, добавлю только что гораздо удобнее системы управления(драйвера) сейчас собирать на PIC контроллерах, они позволяют оперативно исправлять ошибки, которые на начальном этапе неочевидны в силу особенностей собранного механизма, точности датчиков, параметров двигателя и пр.
Если вы поделитесь своими знаниями этой микрухи, возможно это и съекономит много времени, но врядли перетянет чашу весов.

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

Я бы действовал по другому:
получение команды шаг
получение команды дир
комутация направления вращения
получение команды шаг(2)
оценка интервала времени между шагом 1 и шагом 2
установка скорости(или количества шагов) для перемещения
получение команды шаг(3)
перемещение в точку, определенную шагом 2(на заданное расстояние)
оценка интервала времени между шагом 2 и 3
если не изменилось, оценка правильности перемещения между точками заданными шагами 1 и 2, коррекция скорости(если нужно) продолжить движение до точки определенной шагом 3
если ожидаемое перемещение не совпало по времени, увеличить или уменьшить скорость
получение сигнала шаг 4, повторить те же операции что и после шага 3
-----------------------------------------------
неполучение сигнала 4 в ожидаемое время - замедлить скорость, с расчетом остановки в точке, определенной шагом 3
перемещение в точку, определенную шагом 3 и остановка до получения команд шаг 4 и дир

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

Новая мысль: раз система с двумя датчиками работает на разности оборотов двигателя - конечного механизма, было бы логичным подлетая к координате на “грубом” датчике (датчик механизма) останавливаться в -1 шаге и дотягивать уже на “точном” датчике. Тогда аппаратно-программная связка предельно упрощается. Только система должна работать на максимуме оборотов, т.е если ставим ДПР - на его номинале (4500 и т.д, зависит от модели) а редукция оптимальной - т.е. на выходе нужно получить максимум подачи и принять за отношение. Если подача метр в минуту (16.66мм в секунду) и шаг на механизме 1мм, то 75/х=16.66 редукция будет 4,5:1. Такое разумно и удобно делать на червяке, будет одна ступень + отпадает надобность в тормозе при удержании. И при точности в 0,01мм (100рисок на механизме) двигатель в итоге будет делать не менее 75 оборотов (я о ДПР, при смещении на мм), что говорит об снижении углового момента а следовательно и претензий к двигателю. Нужно граматно посчитать количество рисок на “точном” датчике (руководствуясь угловым моментом и точностью пересчета на микроконтроллере, а так как там обычно 8 бит, то при 75 оборотах очень легко перепрыгнуть 256) Разве медленно? Если да,то вот тут и влезает мысль об БКД! тем более что он позволяет менять скорости по коэф. в программе, да и скажем тот же самый движок от СД-привода крутится на глаз с большей скоростью чем 4500… А манипулятор скоростью получается простым, если комп видя смещение больше чем на мм будет генерировать сигнал ориентации на “грубый” датчик. Остальное должен обрабатывать контроллер двигателя (КД в дальнейшем) и как я уже не раз говорил брать два сигнала - шаг и направление а отчитыватся он по датчику, но ему никто не мешает самостоятельно генерировать отчет по ситуации (при использовании обратной связи).

Новая мысль: раз система с двумя датчиками работает на разности оборотов двигателя - конечного механизма, было бы логичным подлетая к координате на “грубом” датчике (датчик механизма) останавливаться в -1 шаге и дотягивать уже на “точном” датчике.

Вопрос, а какое быстродействие “грубого” и “точного” датчика? Отвечу: одинаковое и вполне достаточное, чтобы и отсчитывать шаги на максимальных оборотах и скорость считать. Смысл применять два датчика на одном и том же механизме если параметры одного прямо зависимы от другого то есть пропорционально одинаковы? Вот если бы Вы брали разность показаний допустим двух одинаковых датчиков, установленных на разных концах торсионного вала, то можно было бы пасти такой системой момент нагрузки механизма, а так, применять два датчика для отсчета импульсов на самом двигателе до редуктора и на винте после редуктора - это все равно, что поставить на жесткий вал два датчика с разным количеством отсчетных отверстий.

Вопрос, а какое быстродействие “грубого” и “точного” датчика? Отвечу: одинаковое и вполне достаточное, чтобы и отсчитывать шаги на максимальных оборотах и скорость считать. Смысл применять два датчика на одном и том же механизме если параметры одного прямо зависимы от другого то есть пропорционально одинаковы? Вот если бы Вы брали разность показаний допустим двух одинаковых датчиков, установленных на разных концах торсионного вала, то можно было бы пасти такой системой момент нагрузки механизма, а так, применять два датчика для отсчета импульсов на самом двигателе до редуктора и на винте после редуктора - это все равно, что поставить на жесткий вал два датчика с разным количеством отсчетных отверстий.

А еще скорость. На грубом датчике можно долетать к -1 на полном ходу, замыкать двигатель и потом шимовать по точному датчику. Грубый даст позицию с точностью до мм и отстроиться на погрешность по нему не удастся. Плюс ко всему если ставить точный датчик на механизм на нем вразы возрастет поток данных, следовательно нужно увеличивать скорость обработки и вычитания ошибки, а секунды не резиновые… Вал у нас не жесткий, а редуктор. В нем будет минимум люфт и износ, и разность показаний датчиков нам и даст поправку. Или я неправ?

Хорошо. А кто Вам мешает считать датчиком не каждое отверстие, а каждое десятое отверстие, а датчик поставить непосредственно на винт каретки?

Хорошо. А кто Вам мешает считать датчиком не каждое отверстие, а каждое десятое отверстие, а датчик поставить непосредственно на винт каретки?

А как потом посчитать насколько нужно вернуться мотору в результате пролета позиции? (не забываем про редукцию!!!) Или почему в суде нечетное количевство присяжных? Редукция дробная, может создаться ситуация потери 1 импульса и приведет к погрешности. Даже АЦП шумят по младшему разряду, а нам нужна точность. И кто будет считать? Нужно вводить счетчик-делитель хардварный так как на микроконтроллере организовать два процесса параллельно во времени (идущие строго синхронно) нелегко.

А как потом посчитать насколько нужно вернуться мотору в результате пролета позиции? (не забываем про редукцию!!!) Или почему в суде нечетное количевство присяжных? Редукция дробная, может создаться ситуация потери 1 импульса и приведет к погрешности. Даже АЦП шумят по младшему разряду, а нам нужна точность. И кто будет считать? Нужно вводить счетчик-делитель хардварный так как на микроконтроллере организовать два процесса параллельно во времени (идущие строго синхронно) нелегко.

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