Твик управления деки VILMA 204-STEREO [2022]

[Vygandas]

Не нужен подстроечник вообще - задать резисторами 9 В, и всё.

По мне можно ставить 7809 или 7812 , или вообще перемычку

Моторы не такое точное изделие чтоб доли вольта там ловить

[Liv]

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

[DrLithium]

Для другого аппарата просто указать другие номиналы, и всё.

Тогда и допуски нужно указать. Оказаться от подстроечника - никогда не против. Но, если человек не попадает в коридор допусков со своей базой деталей используя подручное, то пусть имеет возможность поставить подстроечник. А нет проблем, резистор + перемычка.

Чуть освобожусь и что-то дорисую...

[Liv]

Делаете проблему на ровном месте. Это напряжение совершенно не критично, всего лишь определяет максимальную скорость перемотки. Гораздо больший вред - возможность менять это напряжение. Оно должно быть постоянным, но каким именно - не так важно. Момент подмотки будет задаваться ШИМ-ом и настраиваться из сервисного меню (себе планирую сделать настройку только с компьютера через сервисный разъем, чтобы не программировать сервисные менюшки на самой деке).

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

[DrLithium]

Делаете проблему на ровном месте.

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

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

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

[Liv]

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

Да, это более современный подход. Вместе с моментом подмотки планировал в сервисной программе устанавливать некторые параметры для перемотки - скорость плавного разгона, максимальную скорость, скорость поиска/обзора, может что-то еще. Если все делать подстроечниками, то будет ужас.

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

Жалко, что так мало голосов.

[Liv]

Пока не совсем понятно, как технологично установить на ЛПМ оптические датчики счетчика. С обработкой сигналов датчиков тоже вопрос, хочется получить индикацию более-менее реального времени. По этой теме есть множество патентов, но разбираться с ними - та еще задача.

[DrLithium]

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

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

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

З.Ы. Схемку набросал, но надо с ПП решать и если что, то чуть подправить в схемке. Да и деталюшки можно будет заказать, пока куски прошивки зреют, да плата травится...

[alias]

не определён вопрос с направлением

В старом КР его можно снять снять через оптрон PC817, а тут в МК назначить переменную "Direction" и работать с ней. Но энкодер на обоих подкассетника это намного интереснее, да и работает свегда.

В качестве offtop-а, СРВ для катушечника из 1-го класса, датчики уже стоят.

[Liv]

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

Не хочется сильно усложнять алгоритм счетчика. Будет хорошо, если СРВ будет работать не хуже, чем у моего Technics RS-B965. Там он работает как в режиме рабочего хода, так и на перемотках. Длительность кассеты вводить не надо. Даже для такой нестандартной кассеты, как C46, погрешность на всей длине составляет всего 3 мин., что прекрасно. В основном нужны C90.

Тут еще вопрос - что именно хотим от счетчика. В RS-B965 просто тикают секунды от какого-то начального значения. Не особо информативно. В своей TK-140 делал по-другому: там при включении воспроизведения всегда делается расчет времени от начала кассеты. На практике это оказалось очень удобным, всегда видно, в каком месте кассеты находимся. В какой-то деке встречал специальную кнопку для расчета абсолютного времени. Даже не знаю, на чем остановиться.

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

Оба датчика однозначно надо делать квадратурными, с двумя фотоприемниками. Кроме определения направления, это дает еще удвоение разрешающей способности.

Точность замеров импульсов уже достаточно отполировал для работы с одним таймером.

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

З.Ы. Схемку набросал, но надо с ПП решать

Отладку обычно веду на макетках, для счетчика катушечника сделал модуль индикации, который подключаю к штырькам процессорной платы (что-то типа самодельной Arduino). А можно и мелкий OLED для вывода значений подключить.

[alias]

Жалко, что так мало голосов.

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

По этой теме есть множество патентов, но разбираться с ними - та еще задача.

Если есть на примете что-то конкретное, может быть поделитесь? Интересно посмотреть, почитать.

[DrLithium]

Но энкодер на обоих подкассетника это намного интереснее, да и работает свегда.

Иметь направление в момент начала счётного импульса лучше, чем от логики ЛПМ. Тут ни куда не денемся. Вопрос только как именно внедрить.

Не хочется сильно усложнять алгоритм счетчика.

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

Длительность кассеты вводить не надо.

Задать основные "кривые" для нескольких кассет можно в EEPROM. Если нужен больший выбор, то не вопрос организовать загрузку вариантов длин кассет с внешнего источника данных. При получении точного расчёта можно уже и автовыбор нарисовать. Логически это легко.

Тут еще вопрос - что именно хотим от счетчика. В RS-B965 просто тикают секунды от какого-то начального значения. Не особо информативно. В своей TK-140 делал по-другому: там при включении воспроизведения всегда делается расчет времени от начала кассеты. На практике это оказалось очень удобным, всегда видно, в каком месте кассеты находимся. В какой-то деке встречал специальную кнопку для расчета абсолютного времени. Даже не знаю, на чем остановиться.

Я на будущее, прикидывал что да как. Думаю, что время от начала альбома/первого трека, самая важная информация при прослушивании. А время остатка рабочей поверхности - важно при записи. Надо уметь определять место на ленте относительно начала (значение смещения можно корректировать, это не сложно) после набора данных от датчиков и их усреднения. Заранее знать длительность и тупым вычитанием будем знать столько осталось. Имея информацию по альбому (когда до этого руки дойдут) можно и по конкретной песне выводить время и поиск трека сделать по времени. Обнуление по сбросу (запомнив смещение), как метку для чего-то (дописка, возврат на метку после теста) сделать не вопрос, но надо ли? Помнить конкретное значение можно, указать время для перехода то же. Возврат в РВ после обнуления вообще просто - тупо обнуляем смещение запомненное при первом обнулении. Функционал дело наживное. Попугаи настолько отбили смысл в ведении счёта, что и функции на основе счётчика у "нас" не развивались, почти. По скольку задача в основном программная (датчики на подкассетники в любом случае вешать, пока надо на один), то можно себе позволить не торопиться загадывать... А потом хоть караоке!

Расчёт РВ д.б. отдельной функцией срабатывающей периодично и скрытно. Так сказать эта функция д.б. опорной точкой для коррекции текущего счёта. Поэтому отдельно ставить кнопку вычисления не надо. А вот дать возможность добавить кнопок (при реанимации аппарата) можно, типа выбора из набора длин и для работы с большими катками. Стал прорабатывать этот функционал со скуки, пока был в очередном тупике. Успеется ещё...

Оба датчика однозначно надо делать квадратурными, с двумя фотоприемниками. Кроме определения направления, это дает еще удвоение разрешающей способности.

Думаю что количество лопастей на круг, не должно быть чем-то определяющем. От 2-х до 24 и более (программно можно поделить, уменьшить) СРВ должен уметь съесть и выкормить дисплей.

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

Теоретически да, не важно и при последнем наблюдении стало понятно. Пока надеялся на относительную стабильность вращения, думал рассчитывать коэффициент поправки в процентах от среднего арифметического длины всех импульсов, для каждого импульса свою персональную и держать в массиве. Вот и добивал точность замеров. Прирост на оборот сглаживался усреднением и уже усреднённые значения аргументов отношения, частично решали проблему. Но исходя из того, что нужно строить "коридор" (формулу) для определения текущего места, лучше всё же не портить себе данные лишним враньём. Два прерывания INT не жалко отдать (PCINT от нас ни куда не денется), для направления второй датчик того же подкассетника не нужно цеплять на прерывание. Просто поставить на вход, что б опросить в прерывании: "Как ты там? Типа куда смотришь?". Один 16-и битный таймер при этом то же зарезервирован для замеров. А вот дальше нужно чудить. Нужен ещё один для отсчёта миллисекунд, что б дать возможность выдать данные для формулы, а после выбирать длину ленты автоматически. Заумно, но это минимум и по другому пока не вижу. Дальше ещё хуже...

Т.е. самые сложные вопросы, это начало счёта (надо точно определить где находимся) и достаточная точность рассчитанных значений для вывода. Основная "платформа" работает, но нужны новые методы на "Костю Сапрыкина".

Отладку обычно веду на макетках, для счетчика катушечника сделал модуль индикации, который подключаю к штырькам процессорной платы (что-то типа самодельной Arduino). А можно и мелкий OLED для вывода значений подключить.

Прикольно. Чистенько. Аккуратненько.
У меня есть бредборд, стараюсь на нём проверять. Но чистить лень от старых проектов и выводные набирать надо... А ПП сделать думаю сразу, просто соскучился по вкусу и запаху хлорного железа! Пусть и промежуточную, но иметь возможность отлаживать в аппарате приносит больше удовольствия.
Хотя посмотрю ещё... А детальки какие-то заказал.

[Liv]

Если есть на примете что-то конкретное, может быть поделитесь? Интересно посмотреть, почитать.

Пока еще сам их только бегло просмотрел. Например: EP0091202A2, EP0216260B1, GB2039127A, KR950020677A, NL7909146A, US4044233, US4140896, US4239957, US4280159, US4292509, US4338645, US4352472, US4370684, US4398300, US4411008, US4423455, US4644436, US4866547, US5321463, US5323286, JPH01165057A, JP2540993B2. Патенты скачиваются с Google, на странице каждого патента есть список цитирования и список похожих документов, по этому дереву можно долго лазать.

Просветление приходит с прогрессом.

Сейчас читаю основную ветку по "Вильмам", дошел до страницы 48. Сначала было скучно, особенно, когда про ремонты. Изредка попадались интересные факты и доработки. Иногда попадались заблуждения. Но под конец ветки стало жарко, когда стал обсуждаться счетчик. Словно фантастический сериал.

Надо уметь определять место на ленте относительно начала

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

Имея информацию по альбому (когда до этого руки дойдут) можно и по конкретной песне выводить время и поиск трека сделать по времени.

Давайте не будем здесь озвучивать фантазии. Этого никогда не будет и это никому не надо. Задача - сделать более-менее вменяемый счетчик реального времени, как делали в конце 80-х в фирменных деках.

Обнуление по сбросу (запомнив смещение), как метку для чего-то (дописка, возврат на метку после теста) сделать не вопрос, но надо ли?

Обычно кнопка сброса есть. Может потребоваться отмерять время от начала записи где-то в середине кассеты. Можно по длительному удержанию кнопки сброса возвращаться в режим абсолютного времени. Но это действительно не принципиально, имея ядро СРВ, разные функции добавить не проблема.

А вот дать возможность добавить кнопок (при реанимации аппарата) можно, типа выбора из набора длин и для работы с большими катками.

Т.е. кнопка выбора типа кассеты все-таки нужна?

Думаю что количество лопастей на круг, не должно быть чем-то определяющем. От 2-х до 24 и более (программно можно поделить, уменьшить) СРВ должен уметь съесть и выкормить дисплей.

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

Два прерывания INT не жалко отдать (PCINT от нас ни куда не денется), для направления второй датчик того же подкассетника не нужно цеплять на прерывание. Просто поставить на вход, что б опросить в прерывании

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

Один 16-и битный таймер при этом то же зарезервирован для замеров. А вот дальше нужно чудить. Нужен ещё один для отсчёта миллисекунд

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

Т.е. самые сложные вопросы, это начало счёта (надо точно определить где находимся) и достаточная точность рассчитанных значений для вывода.

Пока практически ничего не делал для СРВ кассетника, играюсь с моделью. Сейчас надо создать файлы с набором параметров для нескольких разных кассет (хотя бы из наиболее распрстраненных) и посмотреть, какая погрешность получится. Модель не учитывает всякие неидеальности типа ракорда, но это я считаю мелочью, погрешность в десяток секунд устроит, а на редких кассетах - и до минут.



Точная формула расчета времени: Time = PI / H / S * (D^2 - D1^2), где H - толщина ленты, S - скорость ленты, D - диаметр рулона, D1 - диаметр сердечника. Для режима Play, когда S = const, формула сводится к Time = A * (P^2 - B), где P - период вращения приемного узла, A и B - некоторые коэффициенты. Так сделано у меня в TK-140. Но на перемотке это не работает, поскольку появляется вторая неизвестная S. Имея данные еще и с подающего узла, можно построить систему из двух уравнений и исключить S. Но константы H и D1 все равно надо задавать, и они разные для разных кассет.

Функция "память" счетчика в TK-140 работает по счетчику условных единиц, а не по СРВ. У счетчика есть кнопка, когда и индикацию можно переключить в режим условных единиц. Но на практике все время пользовался только СРВ.

[devel]

Мнений маловато, т.к. чтобы задать правильный вопрос надо знать половину ответа, а мы тут больше наблюдатели =)
Но я попробую.
Тут дискуссию немного "штормит", и обсуждаются сразу все идеи, без какой-то определенной последовательности. Но это и неплохо, потому что некоторые моменты снова возвращают к КР/КМ/Р, а значит требуют внесения поправок.
Мой вопрос будет о применяемых оптодатчиках, и способе снятия с них данных. Вариантов обсуждали два: оптрон "на просвет" (такие применяются в принтерах как датчики закрытия всевозможных крышек, положения заслонок и т.п), и оптрон "на отражение". На чём в итоге остановились?
Мне кажется компактные АОТ137Б1 позволят использовать их по 2шт на узел, что даст возможность определять в т.ч. и направление вращения. Точнее, достаточно на приемном узле 2шт, а на падающем 1шт.
Поскольку в базе только 4 режима (ВОСПР. ЗАПИСЬ, ПВ, ПН), а первые два по сути - один и тот же, и вторые два - идентичны между собой, то получается всего два режима работы датчиков - режим хода (ВОСПР или ЗАПИСЬ), и режим перемоток (ПВ,ПН), плюс флаг направления.
Режим хода включается через кратковременную паузу, и импульс подмотки (выбор петли). Не знаю, насколько он может быть точен в плане определения направления (да и в целом, ВОСПР всегда в одном направлении (по крайней мере в этом ЛПМ)), но наверно лучше направление начинать определять после того, как движение МЛ началось, игнорируя выбор петли (т.к. в каком-нибудь другом ЛПМ он может быть не реализован). При этом, счет снимать с одного из датчиков приемного узла, а второй использовать только в начале движения, для определения на каком из датчиков импульс появился первым. В дальнейшем, если активный режим работы не меняется, не опрашивать второй датчик вовсе, запомнив направление.
Чтобы увеличить точность счета, если кол-во секторов отражающего барабана/наклейки мало, можно считать не сами импульсы от датчиков, а кол-во импульсов от задающего генератора импульсов с более высокой частотой, и считать, сколько их набежало за один сектор, и далее считать среднее арифметическое за один оборот, снижая ошибку разной отражающей способности или геометрии отдельных секторов. По-моему, такой вариант обсуждался в основной теме по Вильмам.
Почему поднимаю снова этот вопрос. У Леонида использовано колесико от мышки, и датчик на просвет, насколько я понимаю. У DrLithium что? Какую конструкцию в итоге выбрали, колесико от мыши+оптрон на просвет, или секторный барабан/наклейку по типу Вильма 312/212 и оптрон на отражение?
Я думаю, можно уже попробовать снять размеры с платы В207, которая крепится к задней крышке ЛПМ, и начинать вытаскивать из ЛПМ на нее выводы датчиков, и т.п. Возможно, у В102,104,204,207, 207-1, и Орбита 121 разные размеры крышки, я не проверял расстояния между винтами, но подправить под все случаи будет не сложно.

[Liv]

обсуждаются сразу все идеи, без какой-то определенной последовательности

Это крайне плохо. Надо двигаться шаг за шагом. Для начала надо довести до конца хотя бы простейшую реализацию СРВ.

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

На данный момент это полный тупик. ЛПМ сделан так, что не позволяет просто и удобно разместить датчики. Крепить на задней плите не хотелось бы (но придется, наверное). Крепить в передней части ЛПМ не за что, еще пробема усугубляется тем, что есть разные варианты крепления ведущего двигателя, и что еще хуже, есть вариант с магнитами внутри ЛПМ. Нормальной конструкции датчиков пока нет.

[devel]

Предложу вариант:

[Liv]

Предложу вариант:

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

А что там с подающим подкассетником получается?

[devel]

Вот так выглядит готовое:

Это одинарные оптодатчики от видеомагнитофонов. Суть идеи - просверлить мет. крышку ЛПМ, и в эти отверстия просунуть вот такие пластиковые стойки. Сами стойки крепятся к back-plate, делать которую такой "высоты" нет нужды.

[devel]

Прикинул к ЛПМ (ЛПМ тут какой-то франкенштейн для опытов):

[devel]

В общем, нужно сделать 3Д-модель подобной стойки.

[Liv]

В общем, нужно сделать 3Д-модель подобной стойки.

Не думаю, что это хороший вариант. Лучше сделать конструкцию из нескольких печатных плат, которые будут спаяны между собой. Китайцы делают фрезеровку плат любой сложности, а в случае чего и вручную повторить можно. Использовать надо максимальный доступный радиус крыльчатки, поэтому отражательные оптроны лучше всего направить на торец барабана с рисками. Как сделать такой барабан из конденсатора, я показывал в этой ветке. Как некую демонстрацию возможности "лепки" из печатных плат могу привести фото датчика окончания ленты работы мастера Fagear:

[devel]

Собрать "стойку" оптронов из стеклотекстолита - первое, что пришло в голову. Собственно, на первой картинке, что я выше кинул, как раз такой вариант ))) Видел у блогера Fager подобные конструкции. Если делать в одной части дополнительный шип, а в другой паз, и все пропаять с двух сторон - должно быть достаточно надежно.
Тогда еще раз уточню: двух оптронов на приемном узле, и одного на подающем - хватит? Нет возражений по АОТ137Б1? Они доступны и довольно дешевы.

[Liv]

двух оптронов на приемном узле, и одного на подающем - хватит? Нет возражений по АОТ137Б1? Они доступны и довольно дешевы.

Я бы ставил по два оптрона на каждом узле, датчики делал бы одинаковыми. Оптроны - самые распространенные SMD - ITR8307.

[devel]

Ну вот, теперь есть определенность по этому вопросу, есть от чего отталкиваться.

[alias]

количество лопастей на круг, не должно быть чем-то определяющем. От 2-х до 24 и более

На катушечниках Ростов, Илеть, Союз и т.д. из 1-го класса - 18+18 полосок на обоих подкатушечниках. Больше 18 думаю не стоит делать.

Исходя из личного опыта - не менее 3-х лепестков и число нечетное. Я бы рекомендовал крыльчатку на 5 лепестков как реально выполнимую в реалиях этого ЛПМ. На 3-х лепестках и грубо выпиленных, точность счета 5..6 секунд.

Нормальной конструкции датчиков пока нет.

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

В моем варианте винты креплений для регулировки датчиков ограниченно доступны с лицевой стороны с обеих сторон. НО, у меня магниты снаружи! По настройке: влево/вправо/вверх/вниз +/- 0.5мм и крен по углу(вверх/вниз) +/- 5 градусов. Больше нет смысла, в крайнем положении вниз может цеплять маховики тонвалов.

[Liv]

Я бы рекомендовал крыльчатку на 5 лепестков как реально выполнимую в реалиях этого ЛПМ.

На барабане из конденсатора, что показывал здесь раньше, поместилось 10 полосок. Это близко к максимуму, мельче будет хуже. Для данной задачи сильно много не надо, все равно период измерять придется по целому обороту, чтобы избежать влияния погрешностей. А чтобы индикация не "хромала", надо будет придумать что-то типа цифровой PLL - счет идет сам собой, а данные с датчиков его только подстраивают. А может и хватит частоты обновления с датчиков. Особенно если сделать кольцевой буфер размером с количество лопастей и каждый раз брать данные для целого оборота для каждой лопасти.

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

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

Сейчас поставил рядом Technics RS-B965 и слушаю кассеты с секундомером. Кратко результаты такие: на C-60 врет на полной длине на +1:41, C-90 +0:26, C-120 -2:40. Сейчас играет студийка "The Dark Side of the Moon", на 20 минутах ошибка +2:29. В принципе, такая точность устроит. Зато нет никаких заморочек с вводом типа кассеты или дерганий ЛПМ для определения/калибровки. Показания на перемотке и в режиме Play хорошо совпадают, с точностью до секунды. Т.е. если на этой же деке запомнить момент, то найти его по времени на перемотке нет проблем. Погрешность времени копится монотонно, никаких колебаний вокруг нуля не заметил. Хотя графики не строил, чисто на глаз.

[devel]

Накидал по-быстрому такой чертежик в масштабе 1:1. Поскольку В104/204 встречались с расположением мотора как в общем кронштейне, так и отдельном на стойке, то путь прохождения пассика будет разный. Карандашом заштриховал область, где на мой взгляд оптимально разместить стойку оптронов.

[Liv]

Накидал по-быстрому такой чертежик в масштабе 1:1. Поскольку В104/204 встречались с расположением мотора как в общем кронштейне, так и отдельном на стойке, то путь прохождения пассика будет разный.

На общем кронштейне мотор был не по центру. А вообще надо рассмотреть 3 варианта - и для 102, где два маховика и мотор по центру. И второй подкассетник надо нарисовать, с ним будет еще хуже - тоже 3 варианта, с магнитами сбоку, с магнитами внутри, и с двумя маховиками.

Чтобы можно было практически проверять идеи по счетчику, надо собрать какой-то стенд. Деку разбирать не хочется, но у меня есть несколько отдельных ЛПМ. Надо по-быстрому сделать минимальное управление, пусть пока будет с электромагнитами (редуктор едет с Ali). Вот думаю - сделать mini-версию регулятора ведущего двигателя на ATtiny25 и остальной механикой управлять через PCF8574, или оставить для ведущего двигателя ATmega88 и повесить на нее все остальное по механике. Управляющий контроллер возьму ATmega168, как раз есть макетка с ним. Счетчик, по-моему мнению, должен быть в управляющем контроллере. Прерывание датчиков сделать приоритетным, другие тогда не будут мешать.

[devel]

Добавлю фото, чтобы было понятнее.


Насколько понимаю, оптроны не должны стоять напротив друг друга, поэтому если их размещать близко (менее 90 градусов друг от друга), то можно обойтись одной стойкой. Если размещать по разные стороны от пассика, обозначенного синей ручкой, то тоже должно работать, но расстояние между оптронами великовато, будет задержка.
Ну и для кронштейна В207, В207-1, Орбита МП121 нужно предусмотреть другое место, или даже городить отдельное крепление, т.к. кронштейн там стоит косо, и перекрывает один узел. Надо смотреть, в общем.
Размер платы back plate 109х117мм

[devel]

На общем кронштейне мотор был не по центру.

Верно, все время наступаю на эти грабли. Там подмоточный мотор мешает.

А вообще надо рассмотреть 3 варианта - и для 102, где два маховика и мотор по центру.

Это самый простой вариант - нужно отзеркалить рисунок сверху. Магниты в 102,104, 204, 212, 312, Орбита 121 - снаружи. Магниты внутри - это В207, В207-1 и Санда 207, 207-1. Одновременно магниты внутри, и два маховика - нереально, конечно.

[Liv]

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

Оптроны должны стоять так, чтобы на выходе получались квадратурные сигналы, сдвинутые на 90 градусов (электрических). Полный период полосатой структуры - это 360 градусов (электрических). Т.е. Между оптронами угол 1/4 углового шага (механического) полос на крыльчатке. Если полос 5, то их шаг 72 градуса, между оптронами надо 18 градусов. Если 10 полос - то 9 градусов. Столь мало обеспечить трудно, поэтому можно добавлять сколько угодно раз 360 градусов (электрических), если полос 10, то это 36 градусов (механических).

Расположение оптронов лучше всего подбирать на 3D-чертеже ЛПМ, он же тут был.

[BillyDOS]

Верно, все время наступаю на эти грабли. Там подмоточный мотор мешает.

[BillyDOS]

Чертеж на косой держатель моторов от 207/212/312/121 я накидал от руки со штангенциркулем. Потом прикладывал оригинальный держатель на чертеж и вышло ооооочень близко

[Liv]

Первый рисунок, который с размерами, можно сохранить в каком-нибудь векторном формате (pdf, ps)? У меня чертежных программ под рукой нет, но в Corel мог бы попробовать затащить.

[devel]

Вот такое видится: Синяя зона - В102-204, желтая зона - В207-312,Орбита 121. Все варианты укладываются в единую прямоугольную область (зеленая), которую можно зарезервировать под датчики на back-plate.

[BillyDOS]

Первый рисунок, который с размерами, можно сохранить в каком-нибудь векторном формате (pdf, ps)? У меня чертежных программ под рукой нет, но в Corel мог бы попробовать затащить.

https://dropmefiles.com/OVsu9
Тут КД https://retro-archive.ru/Аудиотехника

[Liv]

В общем, я не вижу шансов добраться сверху к крыльчаткам. Очень мало места между пассиками.

[BillyDOS]

Только если шашку расположить на шкиве, диском, а не на барабане как в 207. Но как обсуждалось выше, если правильно понимаю, упадет точность. Максимальный диаметр ~15мм

https://dropmefiles.com/pusZM

[devel]

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

[devel]

Общая мысль: в плате сделаны прорези, чтобы можно было двигать стойку (черно-серое - текущее положение для В204, красным - положение, куда можно сдвинуть стойку при другой конфигурации)


Зона расположения стойки для В102/110:


Зона расположения стойки для В104/204:


Зона расположения стойки для В207/О121:

[alias]

не вижу шансов добраться сверху к крыльчаткам

все три варианта одновременно невозможны

Не вполне понимаю, почему восприятие очевидного вызывает такие сложности?

Размещение датчиков при плате сзади см. зеленые сектора.

Про ложную засветку от лампочки подсветки окна кассеты я уже писал. Она имеет ИК и видимый спектр. Не забываем наступить на грабли!

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



В догонку к прочим чертежам ...

[DrLithium]

Т.е. основной режим работы счетчика - время от начала кассеты?

Именно формула привязывает рассчитанное значение от датчиков, как смещение в секундах от начала. Эти данные (время + отношение) снимались, переводились в формулу и МК обратно по ней определяет время.

Вопрос только, получится ли это точно определять на перемотке.

Уже. Скорости хватает, за 1570 тактов вытаскивалась значение - это чисто, но ещё надо добавить накладные расходы. Да и в перемотке, если не будет успевать, то совсем не важно. Того, что успеет посчитать, хватит сориентироваться и принять решение.

Т.е. кнопка выбора типа кассеты все-таки нужна?

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

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

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

INT ничем не отличается от PCINT в плане точности.

Если ни чего больше ресурсоёмкого не будет делается, то не важно. Нас интересует приоритет обработки.

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

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

Но константы H и D1 все равно надо задавать, и они разные для разных кассет.

Понятно. По этому ушел по другой тропинке...

У Леонида использовано колесико от мышки, и датчик на просвет, насколько я понимаю. У DrLithium что?

Для прошлого твика Вильм-ы и счёта в попугаях, делал на просвет, но через пасик. В СРВ в ЛПМ Нака ZX9, лазерной резкой 24-х лопастные на просвет на самих подкассетниках.

Для начала надо довести до конца хотя бы простейшую реализацию СРВ.

Вот это поворот! Всё ставит с ног на голову. СРВ хорошо бы добить, но для меня это время и не малое. Месяца 1.5-2 потратил на усреднение по методу наименьших квадратов и то не всё хорошо. Новая идея есть, но надо тупо бросить всё, что б двигаться в этом направлении. А вот делать твик управления с возможностью последующего апгрейда до..., можно. И в разумные сроки получить что-то, что можно применить и использовать. Иначе получается сразу строим идеал, а к нему не особо готовы. СРВ лучше пока оставить до поры, но держать в уме для внедрения. Если получится, что альтернативное и удобоваримое, то хорошо - чуть разгружусь...

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

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

Особенно если сделать кольцевой буфер размером с количество лопастей и каждый раз брать данные для целого оборота для каждой лопасти.

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

[devel]

Не вполне понимаю, почему восприятие очевидного вызывает такие сложности?

Размещение датчиков при плате сзади см. зеленые сектора.

Сложностей не вызывает. Идет поиск решения, которое можно повторить любому желающему. Вопрос кол-ва секторов на барабане все еще открыт. Например, частота вращения подающего узла на кассете С60 менее одного оборота в секунду в начале кассеты. Насколько будет критично 3-4 сектора? В В207 барабан состоит из 7 белых + 7 черных секторов. Почему бы не использовать это кол-во? Или есть основания использовать иное кол-во?
На данном этапе не столь важна сама реализация СРВ, сколько кол-во и расположения датчиков, и число импульсов, которые с них будут сняты, и обработаны. Двигаться дальше синхронно можно только договариваясь на промежуточных вопросах, иначе в итоге получим множество разночтений, прошивок, поправочных коэфф-тов в них по лопастям/секторам, и т.п. Поэтому есть предложение выбрать какой-то единый вариант барабана/крыльчатки, выбрать место расположения датчиков, или места (чтобы была возможность датчик запаивать в разные места back-plate на разных вариантах ЛПМ). По кол-ву датчиков вроде определились - их по два на узел. По способу крепления частично тоже решили - текстолитовые направляющие. Предлагаю определиться с кол-вом секторов.

[Liv]

Не вполне понимаю, почему восприятие очевидного вызывает такие сложности?

На левый подкассетник такая конструкция не помещается, если рассматривать все варианты расположения пассиков.

[alias]

частота вращения подающего узла на кассете С60 менее одного оборота в секунду в начале кассеты

Увы, это не так, это слишком оптимистично. До 3-х секунд на 1 оборот по факту для разных типов кассет по метражу.

Различимость секторов для просто оптопары и для нормальной работы энкодера - это разные понятия.

Конкретно для предложенного мной решения оптимальным будет число n=5. Причем для перехода от 3-х лопаток на 5 лопаток у меня достаточно сдвинуть плату на 0,476 мм от оси вращения подкассетника. Но, все требует проверки на практике.



Может и 7 будет нормально, но не факт.

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

На левый подкассетник такая конструкция не помещается

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

Все это у себя я сделал не просто так, они рядом не становятся, не помещаются для нормальной работы, вплоть до засвета друг-друга.

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

[Liv]

Не нравится мне крепление датчиков на задней плите шасси. Буду крепить к шасси ЛПМ, как у В-207. Универсальности не будет, для каждого варианта ЛПМ надо будет делать свои платы датчиков. У меня будет ЛПМ с симметричным кронштейном двигателей, для него и нарисовал (пока приблизительно). Датчики SMD, будут устанавливаться на торце платы и паяться к площадкам на верхней и нижней стороне. Для правильного позиционирования датчиков в плате фрезеруются вырезы. Лопасти пока сделал с шагом 45 градусов.

Скорости хватает, за 1570 тактов вытаскивалась значение - это чисто, но ещё надо добавить накладные расходы.

А зачем так спешить? Вывод значений на дисплей нет смысла делать чаще, чем оператор может их воспринимать. Максимум - раз в несколько десятков мс.

Нас интересует приоритет обработки.

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

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

Точно вычислить "где мы" - это главное, да. Но зачем это делать быстро? Оператор все равно не сумеет считать данные, если они будут быстро меняться.

Вот это поворот! Всё ставит с ног на голову. СРВ хорошо бы добить, но для меня это время и не малое.

Ничего не понял. А то, что тут делается, это не СРВ?

[DrLithium]

А зачем так спешить? Вывод значений на дисплей нет смысла делать чаще, чем оператор может их воспринимать. Максимум - раз в несколько десятков мс.

Точно вычислить "где мы" - это главное, да. Но зачем это делать быстро? Оператор все равно не сумеет считать данные, если они будут быстро меняться.

Расчёт происходит всегда по факту получение замера и в одной из версий, каждый замер участвовал в общем вкладе. Пропуск гарантировал уход коридора в сторону. До сих пор работало усреднение по набору данных. В данном случае выпадение полезных данных из ряда, однозначно скажутся на точности. Всё остальное считалось быстрее и выкладывалось в буфер для вывода. Когда оттуда происходит забор, не важно.

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

В AVR нет приоритетов прерываний, все делается вручную.

У меня другая информация. "Чем меньше адрес вектора прерывания, тем у него выше приоритет."

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

Разрешить SEI уже в прерывании? Можно будет проверить на досуге...

Ничего не понял. А то, что тут делается, это не СРВ?

Название ветки вроде было "Твик управления деки VILMA 204-STEREO [2022]". Тут вообще хотел развеяться после напрягов по СРВ. А по самому СРВ ещё успеем поговорить и поделать. Хотя одно другому не мешает... развеяться наверное не судьба.

[Liv]

У меня другая информация. "Чем меньше адрес вектора прерывания, тем у него выше приоритет."

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

Разрешить SEI уже в прерывании? Можно будет проверить на досуге...

Да. Это "закат солнца вручную", ну то есть ручная реализация приоритетов. В компиляторе Си от IAR для этого есть даже ключевое слово __nested, которое разрешает вложенные прерывания. У меня в счетчике для катушечника выходы датчика вращения используют прерывание PCINT. Это прерывание я не хочу пропустить, поэтому надо сделать так, чтобы другие не мешали - для всех других добавляю это ключевое слово. Например, вот обработчик прерывания по захвату таймера, которое используется для замера скорости. Захват уже произошел аппаратно, взять данные из регистра можно с задержкой, поэтому я разрешаю для этого прерывания вложенные:

Код: Выделить всё

#pragma vector = TIMER1_CAPT_vect
__nested __interrupt void Capture_Handler(void)
{
  bla-bla-bla...
}

В листинге видим, что компилятор первой командой в обработчик вставил SEI.

Код: Выделить всё

    465          #pragma vector = TIMER1_CAPT_vect

   \                                 In  segment CODE, align 2, keep-with-next
    466          __nested __interrupt void Capture_Handler(void)
   \                     Capture_Handler:
    467          {
   \   00000000   9478               SEI
   \   00000002   93FA               ST      -Y, R31
   \   00000004   93EA               ST      -Y, R30
   ...

Название ветки вроде было "Твик управления деки VILMA 204-STEREO [2022]".

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

[DrLithium]

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

Это понятно что очерёдность, приоритеты многозадачности в той же NT - это другое. Есть задача "выжать всё", знаем что делать, сделаем. Другой вопрос, что два прерывания от INT могут произойти одновременно, что не есть хорошо...

Захват уже произошел аппаратно, взять данные из регистра можно с задержкой, поэтому я разрешаю для этого прерывания вложенные:...

Во! Важно понять в какой момент снова разрешить глобальные прерывания внутри другого прерывания!

Добавлял в прерывание по INT, уже после фотографирования набежавшего в таймере, проверку переполнения таймера. В таймере делал инкремент третьего байта - это дополнительный, в два ни как - мало. Если флаг переполнения таймера взведён, то инкрементировал фото третьего байта и сбрасывал флаг прерывания таймера (теперь инкрементировать уже не зачем), после чего его обнулял. А не то в след. раз в замер могли попасть лишние 65536 тиков. Но это очень редко.

З.Ы. Снова что-то не понравилось в ПП, правлю схему и рисую дальше...

[Liv]

Другой вопрос, что два прерывания от INT могут произойти одновременно, что не есть хорошо...

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

Во! Важно понять в какой момент снова разрешить глобальные прерывания внутри другого прерывания!

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

Добавлял в прерывание по INT, уже после фотографирования набежавшего в таймере, проверку переполнения таймера. В таймере делал инкремент третьего байта - это дополнительный, в два ни как - мало. Если флаг переполнения таймера взведён, то инкрементировал фото третьего байта и сбрасывал флаг прерывания таймера (теперь инкрементировать уже не зачем), после чего его обнулял. А не то в след. раз в замер могли попасть лишние 65536 тиков. Но это очень редко.

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