roboforum.ru

многие нынче собирают станочки с ЧПУ, но ЧПУ это комп + шаговики на Step/Dir интерфейсе.. а реально ли разработать свою "стойку" ЧПУ.. т.е. прием G-кодов, поддержка всяких там окружностей на уровне ЧПУ, работа с нормальными сервоприводами.. как считаете? реально ?

ну и соответственно если есть куда ткнуть носом - милости просим ) вообще хотелось бы почитать о принципах работы ЧПУ, способах синхронизации осей и т.д... буду скоро активно копать в этом направлении...

бррррррррр, а в чём именно задумка, избавиться от компа? или запихать всю электронику в одину небольшую коробку?

Angel71 писал(а):бррррррррр, а в чём именно задумка, избавиться от компа? или запихать всю электронику в одину небольшую коробку?

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

Но и проблем тоже много, спору нет.

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

Кстати, проекты такие есть и довольно много ( только вот открытые не попадались, но я, правда, и не искал особо ).

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

да да да.. нормальные сервоприводы.. в частности сейчас стоит в 15 метрах от меня обрабатывающий центр ВМФчотатамцыферки.. у которого стояка еле живая, хотя ее наши мужики упорно пытаются починить, но и сам формат команд там до ужаса кривой по отзывам опять же мужиков.. следом - возможно скоро появится еще железяка без электроники... ну и детали есть на станочек еще один.. + токарники 16к20 стоят, их переоборудовать тоже можно бы..

всяческие MACH3 и прочее не интересны на самом деле.. в наличии есть пара HAASовских станков с нормальными ЧПУ.. и проблемы не на чем выточить в принципе не стоит.. стоит проблема оживить то, у чего морально устарела электроника, но вполне живое железо..

ПС АВР, вы, право, оригинальны.. я ожидал ссылки на lmgtfy.com..

на самом деле толком в гугл еще не ходил, но занятие это неблагодарное в этой области, ибо куча инфы по ЧПУшкам на ШД и иже с ними..

по синхронизации осей - тут может я просто лишний раз парюсь на самом деле ? или все-таки нет ?

просто по сути я вижу два варианта - ЧПУ верит приводам и просто отдает на них задания.. либо контуры положения приводов должны быть все в 1 куче и параллельно обсчитываться и проверяться на предмет рассогласования..

второй вариант выглядит как-то бредово..

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

ваши комментарии?

PS думал а не взять ли что-нибудь такоеза основу


PPS - ну у меня то глобальные планы - как обычно, просто проинтерпретировать Г коды можно бы и мегой, зачем вам там ПЛИС не ясно.. я плату указанную выше если буду брать то для 2-3 проектов одну платформу..

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

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

Duhas писал(а):про синхронизацию я тоже писал.. но нужна ли синхронизаяция типа я прошел 10мм, а я 12 --> блин, косячим!

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

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

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

А вот мне не совсем понятно, как это регулировать моторы кучей. Вот есть у меня задания x, y из брезенхема, ОС posx, posy с энкодеров и надо на выходе получить условно говоря pwm1, pwm2 на моторы (пусть система пока для простоты двухкоординатная). Параллельная система выглядит просто:

spdx = PIDx1(x-posx);
spdy = PIDy1(y-posy);
pwmx = PIDx2(spdx-d/dt(posx));
pwmy = PIDy2(spdy-d/dt(posy));

Причем при наличии нормальных сервоприводов я прямо на них эти posx, posy вывалю и пусть отрабатывают, ПИДы у них внутри.

А как предлагается регулировать вместе?