Всем привет!
Нужна помощь.
Есть виброплощадка с двумя дебалансными валами, с одной стороны которой через эластические муфты приделаны двигатели, а с другой – инкрементные энкодеры. Площадка крепится через пружины к станине. Двигатели прикручены к станине жестко. Валы площадки не синхронизированы. К площадке крепится датчик ускорения ADXL210 с выходным сигналом ШИМ. Двигатель вращается с частотой 1500 об/мин, следовательно это равно 25об/сек. Энкодер имеет разрешение 1024им/об, это равно 1024*25=25600Гц. Начальное положение определяться перед пуском. Поскольку дебалансный вал имеет эксцентриситет, то соответственно он направлен в низ. Это и есть его начальное положение. Контролер и комп НЕ УПРАВЛЯЕТ ДВИГАТЕЛЯМИ, а они запускаются отдельно через рубильник.
Точность измерения:

• угловое положение +/-0,4градуса;
• угловую скорость(+/-1.0град/сек);
• угловое ускорение (после интерполяции графика скорости. Зависит от метода);
• линейное ускорение(+/-0,1g);

Нужно периодично опрашивать датчики, чтобы знать его положение, ускорение в каждый момент времени. Данные через USB от датчиков должны заливаться на комп.

Нужно измерять положения дебалансных валов и их скорость, ускорение, а также ускорение, скорость, положение площадки. Ловить сдвиг фаз между положениями валов.

Здесь нимного обсуждалось и здесь
Что уже есть: изготовлена площадка, на ней стоят энкодеры. Уже запускал, работает.
Прикупил ARM отладочную плату AT91SAM7S64_DBoard для ARM микроконтроллеров фирмы ATMEL и программатор J-Link - USB JTAG adapter. Хочу на базе этого дивайса решить эту задачу. Опит программирования только AVR. Знаю немного Си и Delphi. Очень нужно. Помогите пожалуйста.

Я грешным делом думал, что printf у Вас под прерывания уже заточен. Тщательнее надо.

Попробовал несколько вариантов обработки сигналов энкодера от PIOA. Целый день промаялся. Что-то ничего не получается. Вот код:

Хочу прутя в одну сторону получить возрастание значения ENCODER1_Position, в другую – убывания.

У Вас получается одинаковая обработка вне зависимости от полярности фронта, что неправильно.

Тогда как лучше сделать?

Я бы сделал примерно так:

Но еще не грех добавить аппаратный или программный антидребезг. В последнем случае прерывания непосредственно от выводов не нужны, все обрабатывается по таймеру.

aaarrr СПАСИБО. ЗАРАБОТАЛО!!!



Не пойму зачем. Я писал, что энкодер оптический, и имеет логику на выходе(0=0в,1 = +5в). Еще одно. Как сюда добавить переменную, которая несет в себе информацию о количестве штришков на энкодере, и связать ее с переменной ENCODER1_Position, то есть, когда ENCODER1_Position ==1023 (1024 импульса/об), то ENCODER1_Position =0,
Но когда ENCODER1_Position ==-1 - ENCODER1_Position =1023?

аaarrr, еще раз спасибо

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


Ну а тут то какие могут быть проблемы?
Только не 1023, а 1024 в первом случае.

aaarrr СПАСИБО.

Заменил volatile int ENCODER1_Position = 0; вместо volatile unsigned int ENCODER1_Position = 0;
и вставил код:

Думаю вопрос о определении положения можно считать РЕШЕННЫМ.

Давайте обсудим вопрос о определении скорости вала энкодера. Какие будут мысли?

Давайте. Только изложите сначала свои, а мы их потом "подумаем", хорошо?

Хорошо! Излагаю теорию.
Скорость – первая производная по перемещению от времени Omega(t)=d phi/dt (еще говорят скорость изменения положения), или исходя из определения производной, прирост функции к приросту аргумента Omega(t)=delta phi/ delta t.
Для того, что бы определить скорость нужно от Omega(t)= {ENCODER1_Position_n- ENCODER1_Position_(n-1)}/{ttime_n - ttime_(n-1)}, если неверно формулирую – поправьте. Соответственно ускорение - первая производная по скорости от времени или вторая производная по перемещению от времени (еще говорят скорость изменения скорости).
Тут возникает вопрос связан с переменой ttime, то есть, как ее лучше определить? Что бы она генерировалась таймером?
примечание. Изложена теория относиться как и к линейному перемещению (скорости, ускорению) так и к угловому перемещению(скорости, ускорению), но разница между ними большая.

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

Я на копе хочу выводить зависимость phi(t), Omega(t), но пока не знаю, что выбрать таймер или интервальный таймер (PIT) для генерации временной характеристики ttime. В любом случаи ttime понадобится. Использование таймера мне понадобится для определения ускорения по захвату, так как выходи у акселерометра - сигнал ШИМ. Что насчет этого думаете?

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

to Zliva: Зачем Вам фиксировать и передавать время на каждый "тик" энкодера? Не нужно этого делать!
Все что необходимо в этой задаче - это 1 раз каждую миллисекунду (точно по таймеру) копировать счетчики обоих энкодеров, АЦП-ровать два канала акселерометра, формировать пакет для передачи и передавать его в компьютер. И все!

В компьютере Вы принимаете пакеты последовательно и уже знаете, что время для них отличается на 1мс.
Текущее значение счетчика энкодера - это и есть текущее угловое положение вала, только в отсчетах энкодера.
Домножьте на соответствующий коэффициент - получите радианы или градусы (что Вам нужно?).
Разница между двумя значениями счетчика энкодера из соседних пакетов - это уже и есть угловая скорость, только в размерности [отсчетов энкодера/мс]. Также можете перевести ее в [радиан/сек] или [градус/сек].
Разница между соседними значениями скоростей - это угловое ускорение в [отсчетов энкодера/мс^2]. Переведите
в [радиан/сек^2] или [градус/сек^2]. Дальше можно заниматься аппрокимацией, обработкой и так далее.

Как видите, Ваша задача в основном решается программными методами в ПК. От микроконтроллера требуется только "ведение" счетчиков энкодеров (по прерываниям), периодический съем значений этих счетчиков и двух каналов АЦП (точно 1 раз в 1 мс) и передача пакетов известного формата в компьютер. Напрямую, без всяких запросов со стороны ПК.

Зачем Вы взяли ARM для этой задачи? Это задача для AVR или PIC среднего размера, тем более что c AVR Вы знакомы, как говорили. Зачем связались с USB, если нет опыта работы с ним? Через обычный UART можно спокойно передать всю информацию. Дальше - поставьте готовый мост UART-RS232 или UART-USB, и принимайте данные в ПК через COM-порт...

P.S. Если Ваша цель не только решить задачу, но и попутно освоить ARM, USB-интерфейс и так далее, тогда выбор понятен. Если же Вы решаете конкретную практическую задачу (для заказчика), то, по-моему, Вы только усложняете себе жизнь и выполняете массу бесполезной работы.

Спасибо за наставление. Но я как-то другого пути не вижу кроме намеченного. Чтобы корректно аппроксимировать нужны точки для Х и для Y, тому нужно значение фиксировать. Полученое значение [отсчетов энкодера/мс], будут переводится на компе в(градус/сек, радиан/сек и.т.).


Все верно.
Задача не коммерческая. Работаю над дисером. Сам инженер конструктор торгового оборудования(стеллажи, витрины), а освоение ARM, USB-интерфейс дело для меня принципиальное. Хочу и все.

Собственно, возможных путей-то здесь два.

Первый (по которому Вы идете) - фиксировать время по таймеру при каждой смене положения энкодера и передавать все это в компьютер.

Второй (который Вам предлагается) - фиксировать "набежавшее" значение счетчика энкодера в строго определенные моменты времени - через каждые 1мс. И передавать только последовательность значений счетчиков с известным точным временным интервалом между ними (1мс).

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