Счётчик ленты в реальном времени

[Turbo_man]

Т.к. меня интересуют МК технологии в применении к кассетникам, то возник вот такой вопрос. Давно хотел выяснить, как ведутся подсчёты в счётчиках ленты в реальном времени? Если кто-то уже делал такую систему или знаком с этим вопросом прошу рассказать или дать ссылки. И как сделать так, чтобы не нужно было вводить в систему размер кассеты - С90, 120, 60, 46L?

[alexf52]

гораздо проще и точнее вычислить рычаг по скорости вращения приемного/подающего узла.

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

[intell]

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

как эта схема учитывает трение (часто неравномерное) в механизме кассеты? в катушечниках его просто нет.

[alexf52]

как эта схема учитывает трение

Если есть динамометрическая кассета то можно легко померить подтормаживание с отключенным тормозом. Я могу только гадать что трение в несколько раз меньше нужного усилия.
И наверное можно отследить зависимость трения от толщины рулона и тоже внести поправку.

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

[DrLithium]

Может как-то так?

Уже ошибочку нашёл. Поправлю, обновлю...

----------------
Обновил. Позже надо будет проверить графиком.

[Turbo_man]

DrLithium, У меня толщина ленты для С90 получается 0,01166мм, а у вас 0,02. Отсюда при T2 (по моим обозначениям) = 2 сек, получается время с начала кассеты = 627,79 сек.
Толщину я считаю как разность радиусов полного и пустого рулона, делённое на количество витков в полном рулоне. Количество витков (1200,33) в полном рулоне равно: длина ленты С90 135м, деленная на средний диаметр рулона (21,8+49,8)/2=35,8мм, и делённое ещё на пи.

---------- Добавлено в 12:24 ---------- Предыдущее сообщение в 12:17 ----------

Когда я подставил в ваши формулы S=0,01166мм и D=21,8мм (такие цифры я использовал в своих рассчётах), то получилось как и у меня 627,303 сек. УРА!!!!
Наши результаты совпали, хотя я по-другому выводил свои формулы.

---------- Добавлено в 12:31 ---------- Предыдущее сообщение в 12:24 ----------

В своих макетах я планирую оставить число секторов в датчиках = 5, как и было в оригинале.
Иначе получается слишком высокая частота для подсчётов с помощью МК.

[DrLithium]

УРА.

А то! Или одинаковые ошибки сделали. Только надо вас поругать. Я чуть, блин не отказался совсем от этой идеи. Как-то по чётче надо было выражать мыслю. Еле докумекал. Пока за Excel не зесел. Ну да ладно. Теперь проверить и в путь, писать прошивку. Только отказываться от индикации в перемотках совсем не хочется. Но для начала хватит.
З.Ы. Зелёные поля на то и зелёные.

Число секторов можно менять в прошивках. Кому сколько надо. Или вообще, переменные надо регулировать, меняя в родной флеш памяти.

[Turbo_man]

Как-то по чётче надо было выражать мыслю.

У меня самого эта мысля еле теплилась.
И Excel-ем я так умело не могу пользоваться.
Но геометрию нам всё-таки сумели вдолбить в школе.

---------- Добавлено в 13:02 ---------- Предыдущее сообщение в 13:00 ----------

Только отказываться от индикации в перемотках совсем не хочется.

Для этого надо брать всем известный упрощённый алгоритм.
К своему алгоритму я бы добавил коррекцию от реальных часов для устранения погрешностей.

[DrLithium]

И Excel-ем я так умело не могу пользоваться.

Тут я могу похвастаться. Съел: собаку запеченную в жирафе, котого съел крокодил, которого поймали и запекли в верблюде, которым нашпиговали мамонта. Соли и всяческих приправ - просто много. Жаль сейчас плохо Excel знают. Что-то посчитать - просто глаза открываются. Потому как в голове держать много вещей не реально. А тем более ими оперировать. Рекомендую Олафа Коха "MS Excel 4.0 для пользователя". Фишка книги в том, что в конце есть справочник. Правда команды английские, но я всегда оперировал ими. На русском они же как-то коряво звучат. В природе есть справочник соответствия русских команд английским.

Для этого надо брать всем известный упрощённый алгоритм.

Пока давай пока это распишем и отмакетируем. А опосля взвеся ++ и -- продолжим эпопею.

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

Почему бы не довериться кварцу МК? Погрешности которую он даст нам точно хватит. У нас же не месяц время звучания?

[Turbo_man]

Почему бы не довериться кварцу МК?

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

---------- Добавлено в 15:59 ---------- Предыдущее сообщение в 15:52 ----------

давай пока это распишем и отмакетируем.

У меня рассчёт получается очень простой. Выше была формула - t2=(T2+T0)*(T2-T0)/(2*dT2)
T0 - период пустой бобышки = 1,438041362 сек. T2 и dT2 я собираюсь измерять частотой 100кГц (или 500 кГц при 5 секторах в датчике).

---------- Добавлено в 16:15 ---------- Предыдущее сообщение в 15:59 ----------

Частота, с которой измеряем период не принципиальна, главное, чтобы dT=(2*pi*h)/(V*K) (где h - толщина ленты, V - скорость ленты, K - скоростной коэффициент) была достаточно велика - порядка 150 периодов этой частоты. Дальше все рассчёты будут в целых числах этих периодов.

[DrLithium]

Просто нужен такой кварц, чтобы 1 сек легко получалась.

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

Я ожидаю погрешность в самом начале кассеты при выводе прошедшего времени и в самом конце при выводе оставшегося. То есть когда ленты на бобышке очень мало.

А вот это напрасно. Условия в этих случаях вообще никак (глобально) не меняются. Всё в рамках. Запаса по замерам нам хватит на 1-2 порядка.

У меня рассчёт получается очень простой.

Чуть позже отрихтую. Меня тут вискарём накачали. Ясность мозгов под угрозой...

100кГц (или 500 кГц при 5 секторах в датчике)

Вот это совсем непонятно. Зачем себя так ограничивать? 24 Bit даёт 16 лимонов отсчетов. 8МГц у нас туда легко вписывается. Только точность секторов д.б. офигенно большая. Свои 24-х секторные заказывал в лазерной резке. Времени на период импульса меньше, но и тут всё д.б. в рамках для 8 МГц.

Частота, с которой измеряем период не принципиальна, главное, чтобы dT=(2*pi*h)/(V*K) ... была достаточно велика

4-8 МГц достаточно. Меньше уже играть не интересно. Но наверное можно. Нужно проверять в модели. Думаю attiny2313 (со взбитыми сливками) подойдёт!

[Turbo_man]

Вот это совсем непонятно. Зачем себя так ограничивать? 24 Bit даёт 16 лимонов отсчетов.

Просто у вас (впрочем и у меня) мал опыт работы с МК. Там есть понятие "время реакции на прерывание" тут и вся сложность. МК дискретен по времени, и тут любое "движение" его "ест". Все действия в МК выполняются последовательно, кроме его аппаратных модулей.

[DrLithium]

Опыт мал, согласен. Но я проверил в AVR Studio, что происходит с прерываниями. AVR-ка оказывается, весьма гуманно переваривает реакцию на прерывания. Т.е. пока мы заняты обработкой другого прерывания, новое тихонечко ждёт пока отпустит, и доделает то, что нужно по очереди. Потерь вроде как не получаем. Просто задержка на несколько тактов по времени. Кроме того, лишние просто не разрешаем. И вообще в нашем случае драться и выцарапывать не нужно. Это всё будет позже.

[Turbo_man]

Просто задержка на несколько тактов по времени.

Ну не несколько, я думаю. Вы уже быстро научились делать 24-х битную арифметику? Научите.
Хотя я с Атмелом не работал, м.б. там всё быстрее.

[DrLithium]

Да там вроде как (сейчас не помню точно надо освежевать освежить в памяти) по переполнению идёт инкрементирование. По мере продвижения буду выдавать. Уверен, сложностей быть не должно. Будет пару дней на выходных. Тогда и можно начать проект с комментами. Заодно спецы поправят...

Offтопик:
Подпрыгиваю, приговаривая: надо меньше пить, надо меньше пить...

[Turbo_man]

DrLithium, Вы куда будете выводить время?
В своём синтезаторе я уже этот вопрос решил. На штатный дисплей счётчика. Если новый алгоритм счётчика будет лучше штатного, то просто "отрежу" коммутацию их.

---------- Добавлено в 19:09 ---------- Предыдущее сообщение в 19:03 ----------

но и тут всё д.б. в рамках для 8 МГц.

В моём МК всего один 16-битный аппаратный таймер. А в вашем?

[DrLithium]

DrLithium, Вы куда будете выводить время?

Сначала на макетке на четыре восьмёрки, а после естесьно на родной, да бы не нарушить пластику фейса! И ни каких типа: - Игумен Пафнутий руку приложил!

В моём МК всего один 16-битный аппаратный таймер. А в вашем?

Чем хорош 2313 это то, что нам его точно хватит.
Из даташита:

- Один 8-битный Таймер/Счетчик с Отдельным Предделителем
частоты и Режимом сравнения
- Один 16-битный Таймер/Счетчик с Отдельным Предделителем
частоты и Режимом сравнения

Есть какие-то опасения?

[Turbo_man]

Есть какие-то опасения?

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

[Gleb Erty]

Если требуется высокая скорость, то лучше использовать атмелевские контроллеры - у них одна инструкция на такт (у пиков - 4 такта на инструкцию) и более похожая на человеческую система команд. Младшие микрочиповские контроллеры - это скорее набор логики, который может выполнять программу, надёжный и малопотребляющий. Правда сильно сомневаюсь, что для счётчика реального времени в деке на практике нужна высокая скорость.

[Turbo_man]

Правда сильно сомневаюсь, что для счётчика реального времени в деке на практике нужна высокая скорость.

Увидим.

[DrLithium]

Правда сильно сомневаюсь, что для счётчика реального времени в деке на практике нужна высокая скорость.

Это зависит от алгоритма. Текущий точно не будет много "кушать". А с построением кривой, тут запарка будет, но должен успевать.

Я бы хотел "одновременно" обрабатывать оба датчика. Это возможно, но немного труднее.

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