IMHO: Раз уж появился кодер, давайте не усложнять ТЗ сразу.
Может попробуем сначала воспроизвести поделку Таноса, только с открытым кодом?

Посмотрел на arduino. Интересно.

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


(Добавление)
Но у меня на изготовление платы уйдет минимум пара недель

Если с выбором МК определились, то надо решить, на какую ногу и что мы будем вешать. Где и как будут храниться настройки, которых по всей видимости будет немало.

Ale писал(а):С этой точки зрения - приобретение arduino - выигрыш по времени, и не маленький.

Тут как сказать. У меня сейчас на изготовление с лужением уходит 1,5-2 часа максимум. Конечно сама разводка платы отнимает время, но мне это как и остальной процесс доставляет удовольствие. Ради чего я этим всем и занимаюсь. Кроме того можно сделать удобную плату для конкретных целей, а не нечто усредненное.

Хорошо. Давайте определяться.

Схемотехника - а ля Танос но с поддержкой енкодеров вместо (или вместе с) резисторов обратной связи / датчиков Холла.
Поскольку у енкодера надо заводить на проц две ножки, то может возникнуть проблема нехватки ног, если замахиваться на 4 канала. И хотя у 8535 4 канала PWM (два -16-битных и два 8-битных) предлагаю все же ориентироваться на 3-канальную систему на одной плате.
Теперь - по исполнительным механизмам. Полумост Таноса питается цифрой (ШИМ/PWM).
Для использования асинхронных двигателей с частотным преобразователем нужен аналоговый сигнал. Будем получать его из того же ШИМ с помощью интегратора на операционнике?
Теперь, что касается алгоритма управления двигателем. Насколько я понимаю, от компа софт посылает просто новое положение оси? А уже скорость перемещения, плавность разгона и т.д. задается при настройке контроллера под конкретный сим? Тогда, ИМХО, не за чем "раскручивать" всякие PID регуляторы. Фактически на каждую ось надо задавать несколько констант - максимальная скорость (т.е. ограничения по "амплитуде" сигналов управления двигателями), скорость разгона/торможения (т.е. время выхода с нуля до максимальной скорости), при этом момент начала торможения определять по датчику обратной связи). Ну, плюс к этому, естественно, калибровка концевиков (кстати - оптопара или кнопка?) и собственно диапазона хода для энкодера.

Как-то так получается.

Кстати, кто юзает полумост Таноса - для чего там сигналы Motor IN1/ IN2? Просто для включения каждого плеча?

Ale писал(а):Схемотехника - а ля Танос но с поддержкой енкодеров вместо (или вместе с) резисторов обратной связи / датчиков Холла.

Да, при желании перенести не базу ардуино не составит проблем

Ale писал(а):Теперь - по исполнительным механизмам. Полумост Таноса питается цифрой (ШИМ/PWM).
Для использования асинхронных двигателей с частотным преобразователем нужен аналоговый сигнал. Будем получать его из того же ШИМ с помощью интегратора на операционнике?

Стоп. Н-мост может служить преобразователем ШИМ 0В...5В в -10В...+10В (-5В...+5В), который замечательно понимают частотники. Никаких интеграторов и операционников не нужно, максимум RC цепочка.

Ale писал(а):Кстати, кто юзает полумост Таноса - для чего там сигналы Motor IN1/ IN2? Просто для включения каждого плеча?

Сигналы работают попарно с PWM. Логика HC7408N "и" (на выходе 1 только когда на обоих входах 1, в остальных случаях 0). Сделано это для управления реверсом Н-моста.

Для использования асинхронных двигателей с частотным преобразователем нужен аналоговый сигнал. Будем получать его из того же ШИМ с помощью интегратора на операционнике?

А как влияет битность ШИМ на аналоговый выход ?

Ale писал(а):Поскольку у енкодера надо заводить на проц две ножки, то может возникнуть проблема нехватки ног, если замахиваться на 4 канала.

Для того чтобы сделать 4 оси, я бы с удовольствием выкинул ЖК индикатор, в который я не заглядывал очень давно и освободил ноги МК. А для настройки использовал бы ком порт и гипертерминал. Хотя мне сейчас и двух осей хватает. Тут еще момент - хватит ли производительности МК, но я никогда не писал ничего особо сложного и не могу для себя представить нагрузку.

Ale писал(а):скорость перемещения, плавность разгона и т.д. задается при настройке контроллера под конкретный сим?

Контроллер таноса по сути имеет только одну настройку - пропорциональную составлящую, т.н. KP settings. И устанавливается она как правило один раз. Как работает регулирование только с пропорциональной составляющей вполне доступно и с графиками описано здесь http://roboforum.ru/wiki/%D0%9F%D0%B5%D1%80%D0%B5%D0%B2%D0%BE%D0%B4_%D1%81%D1%82%D0%B0%D1%82%D1%8C%D0%B8_%22%D0%9F%D1%80%D0%BE%D1%81%D1%82%D0%BE_%D0%BE_%D0%9F%D0%98%D0%94-%D0%B0%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC%D0%B0%D1%85%22

Ale писал(а):Тогда, ИМХО, не за чем "раскручивать" всякие PID регуляторы. Фактически на каждую ось надо задавать несколько констант - максимальная скорость (т.е. ограничения по "амплитуде" сигналов управления двигателями), скорость разгона/торможения (т.е. время выхода с нуля до максимальной скорости), при этом момент начала торможения определять по датчику обратной связи).

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

Pavel155 писал(а):А как влияет битность ШИМ на аналоговый выход ?

Разрядность ШИМ влияет на дискретность изменения напряжения. 8бит = FF = 255, 16бит = FF FF = 65535 значений.

Контроллер таноса по сути имеет только одну настройку - пропорциональную составлящую, т.н. KP settings.

А можно подробнее, на что влияет эта настройка и как она определяется, т.е. от чего зависит? У кого есть опыт настройки?

Для того чтобы сделать 4 оси, я бы с удовольствием выкинул ЖК индикатор, в который я не заглядывал очень давно и освободил ноги МК. А для настройки использовал бы ком порт и гипертерминал. Хотя мне сейчас и двух осей хватает. Тут еще момент - хватит ли производительности МК, но я никогда не писал ничего особо сложного и не могу для себя представить нагрузку.

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

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



(Добавление)

IMHO: Раз уж появился кодер, давайте не усложнять ТЗ сразу.
Может попробуем сначала воспроизвести поделку Таноса, только с открытым кодом?

Код будет открытым

Ale писал(а):А можно подробнее, на что влияет эта настройка и как она определяется, т.е. от чего зависит? У кого есть опыт настройки?

Я как бы достаточно поэксперементировал с этим параметром, поэтому меня крайне беспокоит именно эта тема. С остальным как бы я разобрался и при имеющихся возможностях.
При низких значениях KP мотор перемещается вяло, часто недобивает до назначения. В игре теряются мелкие рывки, имитирующие наезды на поребрики и т.п. При высоких значениях мотор перепрыгивает, а потом возвращается назад. Так как мощности магнита который я использую с датчиком холла едва хватает, такие проскоки несмотря на все мои усилия иногда все же приводят к провороту двигателя. Конструкция у меня от этого не страдает совершенно, но ничего хорошего в этом конечно нет. Золотую середину я для себя так и не нашел. Еще раз скажу, что очень точно все эти процессы отображены на графиках в статье по ссылке, которую я дал выше.

Ale писал(а):Думаю, что проц вполне потянет 4 канала. Фактически, довольно узкое и требовательное к ресурсам место - как раз енкодеры.

Вот кстати интересный вариант http://easyelectronics.ru/obrabotka-mnozhestva-inkrementalnyx-enkoderov-odnovremenno.html. Кроме того для ПИД важно чтобы получение состояния было через какой-то определенный промежуток времени. Поэтому в случае его использования, вариант с прерываниями от энкодера отпадает.

Ale писал(а):А на счет индикатора полностью согласен. Единственное "но" - настройка должна производиться так сказать "офлайн", т.е при выключенном симуляторном софте.

Так и запишем.

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

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

За ссылки на статьи по ПИД и ЭНКОДЕРАМ спасибо

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

1 - что во время симуляции посылает софт на контроллер кроме "АБ~a0~~a1~..."?
2 - есть ли определенный период для передачи управляющих посылок, или они могут возникать в произвольные моменты времени. и какова минимальная пауза (таймаут) между двумя последовательными посылками?
3 - длина посылок строго постоянна и зависит от настроек количества осей в софте?
4 - с какой частотой (примерно) контроллер Таноса производит считывание показаний датчиков и производит собственно регулирование осей?

Ale писал(а):1 - что во время симуляции посылает софт на контроллер кроме "АБ~a0~~a1~..."?

Ничего.

Ale писал(а):2 - есть ли определенный период для передачи управляющих посылок, или они могут возникать в произвольные моменты времени. и какова минимальная пауза (таймаут) между двумя последовательными посылками?

Настраивается в софте в миллисекундах.

Ale писал(а):3 - длина посылок строго постоянна и зависит от настроек количества осей в софте?

Да.

Ale писал(а):4 - с какой частотой (примерно) контроллер Таноса производит считывание показаний датчиков и производит собственно регулирование осей?

Неизвестно совсем. У него спрашивать безполезно, так как он там только плату разводил.

Давайте тогда попробуем охватить используемое железо. Какие типы датчиков обратной связи намечается юзать? (Резисторы, Холла, Энкодеры и проч) Именно типы, что бы можно было в доках посмотреть характеристики.

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

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

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

я думаю надо сделать выход на мост. А переделать под частотники и типы энкодеров можно будет самому при наличии исходников.

Переменные резисторы любые, я пробовал 100КОМ. Аналоговые датчики холла SS495. По энкодерам сложно сразу сказать, но можно порассуждать. Я с большой вероятностью буду использовать вот эти. Спецификаций пока найти не могу.

http://fotki.yandex.ru/users/nullrnd/view/492103/

http://fotki.yandex.ru/users/nullrnd/view/492104/
Каким образом и с каким передаточным числом я соединю энкодер с двигателем еще не решил, но буду стремиться получить около 300+ импульсов на весь диапазон перемещения (это не станок с ЧПУ). От крайней верхней до крайней нижней точки мотор проходит предположим около 0,5сек (на самом деле я думаю медленнее). Итого получаем 600имп/сек. В этих идельных условиях частота как бы не слишком высокая. Поэтому особых проблем с опросом на мой взгляд быть не должно. Хотя у тебя по всей видимости опыта больше, тебе и виднее .

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

В этой же теме я просчитывал. Вот страничка http://mal4x.ru/forum/topic.php?...topic=23&p=3

Энкодер у меня механический - при попытке вращать его 25 раз в секунду (мой асинхроник) забрасывает контроллер дребезгом контактов так, что тому плохеет.
Адекватно моя схема производит калибровку (доходит до 2-ух концевиков и останавливается посредине, готовая считать импульсы) при вращении до 2-ух оборотов в секунду. Выход - оптический энкодер, можно простейший из мышки. Можно как у null - те же 30 импульсов за оборот.


(Добавление)
Вот ссылочка
http://soldering.pp.ua/samodelny...enkoder/#more-24

- для наших целей большего и не надо, при условии, что энкодер цепляется на вал самих двигателей. Если на вторичный вал - разрешение минимум 360 имп/об.