Система управления приводами. Технические требования.

[spike]

Хотел вот сформулировать требования к системе управления приводами... )bw3(
Думается, что тема эта должна разделиться на несколько веток, содержащих особые свойства:

• шаговый привод - сервопривод
• поддержка G-кодов - поддержка внутреннего протокола
• на платформе PC - на платформе МК
• повторяемость в домашних условиях - промышленное производство

Ну и каждая в себе может несть числа....добавьте товарищи, что забыл?...

Есть вот такие требования:

1. управление от PC, выполняющего обсчет траектории (интерполяцию)
2. шаговый электропривод (т.е. выходные сигналы - STEP/DIR)
3. RS-485 (CAN) - интерфейс
4. и/или внешняя память для УП на флешке (УП в этом случае готовый файл траектории)
5. модульная силовая часть (отдельный, подключаемый силовой модуль на каждый привод)
6. единая "умная" часть, с поддержкой до 8 приводов с заявленной частотой, например, 100кГц, реально?
7. микрошаг (кратность не могу регламентировать пока - тоже вопрос) и регулировка дробления шага "на лету" (перспектива)
8. контроль скорости подачи (по вычисленной скорости или по меткам внутри управляющего спецкода)
9. возможность ускоренного движения и lookahead
10. обработка обратной связи: концевых выключателей, "красной" кнопки
11. конфигурирование от РС
12. релейные сигналы (скажем, штуки 4-5)

[kentawrik]

забыли линейные двигатели...
100 кГц для микростепа 1/32 это для 1.8 градусного движка это 15.5 оборотов в секунду или 900 оборотов в минуту...
а для сервы - (если 1 импульс на оборот) даже и много 100кГц...
т.е. применимо только для приводов без редукторов (пусть не только, но в подавляющем большинстве случаев.)
контроль скорости подачи это же команды G9*, поэтому для с "хранимой" траекторией не стыкуются - т.е. УП должен обрабатывать контроллер отслеживая скорость шпинделя...
обратная связь - только концевики или еще и датчики абсолютного положения и прочие?

Тут диллема стоит. Танцевать от конкретного станка. Или сделать универсальную систему управления.
Как не крути - прийдется танцевать от станка.
А универсализм проще сделать на или МК или на PC-104, и то - только систему управления без драйверов...
Наверное надо взять несколько гипотетических и существующих станков обдумать их, вычленить закономерности, и сделать "кирпичики" - множество которых будет покрывать 90% требуемых узлов из системы управления...

[spike]

Универсальность тоже должна быть ограничена, т.е. вряд ли целесообразно делать супер комбайн, у которого большая часть функциональности будет в запасе... Почему я настаиваю на интерполяции на уровне РС - простое обновление ПО, готовые математические библиотеки, относительная простота отладки, большие вычислительные мощности, память и пр. Т.е. при создании систем ЧПУ и управления приводами (согласно модели) немаловажно то, что не придется на начальных этапах отвлекаться на тщательную шлифовку алгоритмов в плане оптимизации вычислений и задействованной памяти. Есть четкая узкая задача, для которой идеален МК - точное время, остальное приблуды...
Я за минимум вычислений в микроконтроллере. С этого можно хотя бы начать, а дальше на базе такого контроллера пробовать и интерполяцию...
Драйвера, конечно отдельно.

[kentawrik]

PC или МК вот в чем вопрос.
Надо прыгать от станка...
И я считаю если на станок необходимо выделять отдельный блок ЧПУ то есть смысл заморочиться на интеллектуальный контроллер.
если этот блок чпу будет использоваться как обычный компьютер также - то МК не очень и нужен-то.
Аргументы по производительности и памяти - все равно что утверждать что белаз хорошая машина а Москвич - пирожок плохая...
Если мне надо перевезти 2 мешка картошки, я выберу МК...
причем на МК легче реализовать концепцию наращиваемости, масштабируемости, т.е. "кубизм"
и еще МК располагает к написанию более экономичного кода - что повышает качество программ, т.к. код более вылизан получается...

[VShaclein]

> шаговый привод - сервопривод
Для маленьких/домашних - мощные шаговики, для остальных - серва как-то предпочтительней

> поддержка G-кодов - поддержка внутреннего протокола
Что значит внутренний ? Если будет шина, то однозначно будет внутренний, причем однозначно не G
Если идет речь о предварительной компиляции/парсинга G-кода в X-код - почему бы и нет.

> на платформе PC - на платформе МК
На МК. Но это сложно. Поэтому правильно - сделать на PC, но с прицелом на дальнейшую компиляцию в МК. Очень интересный вариант - framework (Delphi8). Микрософт захватывает этот (ЦНЦ) рынок, поэтому, в частности, уже давно есть робо-студия для программирования роботов, а значит и библиотеки и разработчики. МК так же есть, например системы на ARM, не знаю, как с framework(есть ли он - я не искал), но unix на них ходит на раз.

> повторяемость в домашних условиях - промышленное производство
Тут явно первое. +То, что можно заказать. Впрочем, не стоит разграничивать.

> RS-485 (CAN) - интерфейс
Не вопрос. 485 - бюджетнее, CAN - лучше.

> модульная силовая часть (отдельный, подключаемый силовой модуль на каждый привод)
Правильно - интеллектуальный привод, полностью законченный узел.

> единая "умная" часть, с поддержкой до 8 приводов с заявленной частотой, например, 100кГц, реально?
Оптимально 16мгц/256 - примерно 60..66кгц. Меньше 20кгц нельзя, больше 100кгц - начинаются разные электрические сложности.
Вообще, промышленными считаются частоты (18), 22, 44, 66, (440) кгц. Из чего и следует исходить.
8 приводов - круто. Шести вроде бы достаточно на все случаи.

[VShaclein]

100 кГц для микростепа 1/32 это для 1.8 градусного движка это 15.5 оборотов в секунду или 900 оборотов в минуту...
а для сервы - (если 1 импульс на оборот) даже и много 100кГц...

Не надо 1/32. Из вроде бы реальных тестов достаточно 1/8 и даже много, на высоких оборотах.

обратная связь - только концевики или еще и датчики абсолютного положения и прочие?

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

Тут диллема стоит. Танцевать от конкретного станка. Или сделать универсальную систему управления.
Как не крути - прийдется танцевать от станка.

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

[spike]

Окей, не будем сравнивать БеЛАЗ и Москвич: в техтребования включим описание задач, выполняемых системой управления приводами - т.е. конкретные приложения.

Поправлюсь со своим видением системы управления приводами:
1. управление от PC, выполняющего обсчет траектории (интерполяцию)
2. шаговый электропривод (т.е. выходные сигналы - STEP/DIR)
3. RS-485 (CAN) - интерфейс и/или внешняя память для "низкоуровневой" УП на флешке ("низкоуровневая" УП - это готовый файл траектории)
4. модульная силовая часть (отдельный, подключаемый драйвер на каждый привод)
5. единая "умная" часть, с поддержкой до 8 (пока хватит) приводов с частотой до 100кГц (66кГц)
6. драйвера с микрошагом (скажем до 1/32) с возможностью регулировки дробления шага "на лету" (перспектива)
7. контроль скорости приводов (по "низкоуровневой" УП)
8. обработка обратной связи: концевых выключателей, "красной" кнопки
9. конфигурирование от РС
10. релейные сигналы (4-5)
11. поддержка простых команд типа "поехать такому-то приводу до концевика"

[VShaclein]

3. RS-485 (CAN) - интерфейс и/или внешняя память для "низкоуровневой" УП на флешке ("низкоуровневая" УП - это готовый файл траектории)

От перестановки слагаемых сумма...меняется. Интересно. Тогда USB - лучше. Правда придется реализовывать поддержку файловой системы плюс USB-хост. Ну и могут быть некие проблеммы с приобретением лицензии/регистрации usb-номеров.

зы: в общем, в качестве интерфейса с компьютером - таки старый, добрый rs232. Который легко масштабируется до usb с обоих сторон. Правда, с флешкой в этом случае будут проблемы. Зато просто и реально.
Аха, вообще-то, есть еще эзернет. И как не смешно, в составе Arm.
Я жеж предлагал уже посчитать такты, чтобы оценить требуемую частоту, например, для avr32. Жаль, что прога не на С и один в один не скомпилить.

8. обработка обратной связи: концевых выключателей, "красной" кнопки

Кнопок должно быть больше - могут использоваться в программе.

10. релейные сигналы (4-5)

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

11. поддержка простых команд типа "поехать такому-то приводу до концевика"

Вот-вот, тогда и кнопка должна быть, типо ехать до концевика. По каждой оси.

[VShaclein]

Перечитал - ничего не понял. Решил запутать еще сильнее )
- rs485/can - далеко не лучшие интерфейсы для связи с PC, садить PC прямо на внутреннюю шину - тоже не айс.
- все выше сказанное имеет смысл в контексте оптимизации по цене, исходя из наличия определенных интерфейсов на борту МК. Конечно, если цена не важна, нужно ставить тот интерфейс, который хочется. Или все сразу. В общем, не стоит зацикливаться, т.к. интерфейс - это лишь небольшая часть задачи.
- я пока остановился на LPT, внутренняя шина - RS485. В дальнейшем (когда spike прогу напишет ) ) вместо LPT будет COM/USB, а внутренняя шина, когда приедут дешевые чипы, возможно, на CAN.
- эзернет - хорош, у него очень высокая пропускная способность и гальваническая развязка, а так же он идет на борту c ARM.
- в общем, все упирается в чип МК, а он упирается в необходимую производительность.
- а под юниксом, пожалуй, может пойти опенсорсная EMC. Может кто и возьмется. Либо пытаться на ARM ставить Linux. Жаль, что я не юниксоид. И не линуксоид.

[kentawrik]

Флэш MMC/SD имеют SPI интерфейс... зачем ЮСБ? Тем более что кардридеров завались сейчас...
сажать на ОС обработчик УП даже на относительно мощный МК - ненужное усложнение.
ARM ядро не самое производительное, и покажите мне инфу на процессоры с таким ядром которая однозначно указывает на уровень ЭМП при котором этот МК будет функционировать нормально...
микростеп может и больше чем 1/32 нужен - если адаптивный...
можно намудрить и с разными ...нетами - но смысла не вижу акромя как цех с полсотней станков без присутствия людей. и такие решения никак бюджетными не назовешь да и не позовут туда нас...
Я считаю что наверное необходимо определить класс станков которые должна обслуживать разрабатываемая электроника...
Ну типа количество и мощность приводов, производительность, частота смены программы, месторасположение станка относительно транслятора УП и прочее...

[VShaclein]

Флэш MMC/SD имеют SPI интерфейс... зачем ЮСБ? Тем более что кардридеров завались сейчас...

В общем-то и MMC/SD/картридер не нужен. Хотя я все же купил на днях картридер, дабы снять с него разъем под MMC, которая у меня валяется с незапамятных времен - глядишь, соберусь и платку разведу под нее. А USB - красиво - можно и втыкнуть и вытыкнуть. In/Out то бишь.

сажать на ОС обработчик УП даже на относительно мощный МК - ненужное усложнение.

EMC под Linux. Других открытых вроде бы нет. Можно попробовать EMC оторвать от Linux, но есть огромные сомнения. Конечно, было бы неплохо иметь исходники от одинокой проги, да еще под выбранный МК. Но думаю: нет, сынок, это фантастика(с)

ARM ядро не самое производительное, и покажите мне инфу на процессоры с таким ядром которая однозначно указывает на уровень ЭМП при котором этот МК будет функционировать нормально...

Вряд ли ARM хуже, чем какой-либо другой. По производительности - ARM`ы разные бывают. Просто есть готовые системы на ARM`е и недорого. И с эзернетом.

микростеп может и больше чем 1/32 нужен - если адаптивный...

Можно, только зачем ?

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

Согласен, не нужно.

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

Я б с цены начал, для меня это главное. За бесконечные бапки можно любую систему поднять, но мне вот хочется бюджетное решение. Из него и исхожу. А система должна быть универсальной - есть много задач, которые можно решать при помощи цнц. Вот, единственно, к классификации я бы добавил второе направление, на ряду с G-кодом - микрософтовскую шнягу робостудию и еёйный язык. У них, кстати, и интерфейсы модулей стандартизованы, что позволяет встраивать свои девайсы в любую совместимую систему на раз, что таки довольно важно.