Страница 21 из 22 Первая ... 1119202122 Последняя
Показано с 401 по 420 из 433

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

  1. #1 Показать/скрыть первое сообщение.
    Завсегдатай
    Автор темы
    Аватар для Turbo_man
    Регистрация
    06.04.2010
    Адрес
    Moscow
    Сообщений
    5,553

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

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

  2. #401
    Старый знакомый Аватар для Bobby_ii
    Регистрация
    16.03.2011
    Адрес
    Spb
    Сообщений
    822

    По умолчанию Re: Счётчик ленты в реальном времени

    Цитата Сообщение от DrLithium Посмотреть сообщение
    Если лента была склеена и этот кусок попал в расчёты, то...
    Не страшно. Он же не штангель-циркулем мерит.

    Цитата Сообщение от DrLithium Посмотреть сообщение
    Т.е. понятно, что на определение толщины ленты придётся потратить какое-то время и в старых видиках тест остатка ленты длился несколько минут.
    +

    Цитата Сообщение от DrLithium Посмотреть сообщение
    малое время определения толщины даст большую погрешность,
    Толщина лент не сильно отличается. Не в 2 раза. Задаются границы, думаю, +/-15% - это сильно упрощает дело. А на погрешность вычислений влияет еще меньше.
    Плюс если включено воспроизведение, можно почти сразу определить общую длительность кассеты и использовать соотв. презет, коих не особо много: 60, 90, 120 + несколько 40-минутных.

    ID - дело хорошее. Особенно если есть список песен, .... и можно сделать плэйлист.

    ---------- Сообщение добавлено 20:20 ---------- Предыдущее сообщение было 20:19 ----------

    Цитата Сообщение от Turbo_man Посмотреть сообщение
    может быть после демонстрации реальной работы.
    Я - теоретик. Но ежель объединиться с практиком ... . Нужно запрограммировать МК. Тот, кто может спаять, тоже есть. Предварительно.

    ---------- Сообщение добавлено 20:22 ---------- Предыдущее сообщение было 20:20 ----------

    Цитата Сообщение от Turbo_man Посмотреть сообщение
    Они и есть главные виновники всех наших "проблем".
    Несколько пресетов решат вопрос. Ничего вручную вводить не надо.

    ---------- Сообщение добавлено 20:25 ---------- Предыдущее сообщение было 20:22 ----------

    Отлично. Попробуем на Фортране запрограммировать ОООооооо. Какая разница? Алгоритм-то один и тот же.
    "Лучше промолчать и показаться дураком, чем раскрыть рот и развеять все сомнения" Марк Твен.

  3. #402
    Частый гость Аватар для TheCalligrapher
    Регистрация
    10.01.2020
    Сообщений
    224

    По умолчанию Re: Счётчик ленты в реальном времени

    Цитата Сообщение от alias Посмотреть сообщение
    Я так понимаю, данные идут - слева направо и сверху вниз... по каждому пакету.
    В приведенных мною файлах данные по каждому узлу записаны в одну строчку. В одну очень длинную строчку. То есть если проигнорировать косметическую разметку, то каждый файл содержит лишь две длиннющих строки: первая строка - подающий узел, вторая строка - принимающий узел. Все.

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

    Цитата Сообщение от alias Посмотреть сообщение
    Через F3 нормально открывается.
    О каком "F3" идет речь? FAR Manager? Да, в FAR Manager все сразу отображается правильно.
    Последний раз редактировалось TheCalligrapher; 09.02.2022 в 03:18.

  4. #403
    Новичок Аватар для alias
    Регистрация
    05.01.2022
    Сообщений
    27

    По умолчанию Re: Счётчик ленты в реальном времени

    Цитата Сообщение от TheCalligrapher Посмотреть сообщение
    О каком "F3" идет речь?
    То была кнопка F3(View) на клавиатуре, а в pspad тоже открывается как очень длинные строки, как и заявлено.

  5. #404
    Новичок Аватар для alias
    Регистрация
    05.01.2022
    Сообщений
    27

    По умолчанию Re: Счётчик ленты в реальном времени

    Подскажите, как правильно расположить оптроны энкодера по отношению к набегающим лопаткам крыльчатки.
    Вариант 1, симметрично:
    CW: 1)сначала закрывается диод, потом транзистор 2)сначала закрывается транзистор, потом диод.
    CCW: 2)сначала закрывается диод, потом транзистор 1)сначала закрывается транзистор, потом диод.

    Вариант 2, несимметрично:
    CW: сначала закрываются диоды, потом транзисторы
    CCW: сначала закрываются транзисторы, потом диоды

  6. #405
    Старый знакомый Аватар для DrLithium
    Регистрация
    24.12.2006
    Адрес
    SPb
    Сообщений
    652

    По умолчанию Re: Счётчик ленты в реальном времени

    Первый день как начал по теме, т.е. непосредственно принялся писать прошивку. Оптику честно скомуниздил у Leoniv (на LM393), но сразу не заработало, т.к. мышиная оптика не подтягивала до порога и H21э вместо 800 (BC857C), был всего 100 (MMBT4403LT1). Пришлось параллелить обе половинки фотоприёмника (3-пиновый с + по середине), т.к. лень было разбирать и подбирать номиналы. Если нужно, то кину фотку или две...

    Сейчас вспоминаю(читаю и вспоминаю), что я там напридумывал со стаканом(16и битным таймером) для замеров длин импульсов.

    Думаю в первой версии делить и выплёвывать в USART раз в секунду. Ну уж а далее...


    Offтопик:
    Функции счётчика ZX9 раскурил. Японцы хитрецы оказались... Нуль ловит, плей при желании включает, по РЕСЕТ на ноль откатывает. Пока были проблемы с перемотками не мог на ноль попасть. Движок поменянный и чуть слабее, по этому домотка к нулю по *MotorSlow* тупо не тянула. Воткнул ШИМ и ещё буду его подстраивать под движок. Заказал мотор RF-500TB-12560 (придётся ему дырки сверить и резьбу резать) и окончательно подстрою под него. М.б. совсем от ШИМ-а откажусь, если будет тянуть нормально. Тут главная проблема перехода через ноль по инерции и если проскочили, то нужно медленно домотать обратно с *MotorSlow*. Мой текущий, не родной движок (другие совсем не подошли) на довольно низком напряжении просто останавливается. Пришлось чуть убить поверхность шкива мелкой шкуркой, после полировки оказалось мало зацепа. Вообще можно было бы ловить не ноль, а значение (условно *0005*) не доходя до нуля и врубать *MotorSlow*. Но на разном расстоянии от *0000* можно или не успеть получить реакцию замедления и пролететь ноль или долго ждать подмотки на низкой скорости (условно если *0025*->*0000*). На эту тему подумаю в СРВ для перемотки.

  7. #406
    Завсегдатай
    Автор темы
    Аватар для Turbo_man
    Регистрация
    06.04.2010
    Адрес
    Moscow
    Сообщений
    5,553

    По умолчанию Re: Счётчик ленты в реальном времени

    Цитата Сообщение от DrLithium Посмотреть сообщение
    Ну уж а далее...
    Ждём с нетерпением.

  8. #407
    Новичок Аватар для alias
    Регистрация
    05.01.2022
    Сообщений
    27

    По умолчанию Re: Счётчик ленты в реальном времени

    Цитата Сообщение от DrLithium Посмотреть сообщение
    Оптику честно скомуниздил у Leoniv (на LM393)
    Аналогично. Схемку обрал на макетке. Пока застрял на оптопарах, жду когда приедут. Картинка тут.

    Цитата Сообщение от DrLithium Посмотреть сообщение
    Думаю в первой версии делить и выплёвывать в USART раз в секунду.
    У себя планирую сливать в USART по факту обновления данных.

  9. #408
    Старый знакомый Аватар для DrLithium
    Регистрация
    24.12.2006
    Адрес
    SPb
    Сообщений
    652

    По умолчанию Re: Счётчик ленты в реальном времени

    Цитата Сообщение от alias Посмотреть сообщение
    У себя планирую сливать в USART по факту обновления данных.
    Мне не надо так часто. Поток может прибить точность замеров, а выигрыша от частоты данных можно не получить вовсе. Для меня важна максимально точная формула по данным. Отправка данных это тоже прерывания и чем чаще, тем менее точны будут замеры, не сильно, но всё же стоит исключить дополнительную кривизну на сколько это возможно. Надо взвесить предел точности, выйти на приемлемое значение частоты вывода, USART тоже иногда не всё посылает верно. У меня вроде как (за давностью уже забыл) 24 имульса на оборот, т.ч. в начале кассеты я могу получить 16+7=23 блока данных в секунду. При 5-и - 3,44+1,46=5, тоже не мало, при этом данные, при кривой геометрии, ещё и плясать будут. Хотя проверить на практике можно, а после сравнить результаты.

    Следующий момент это ID блока. У меня это два байта, в секундах 2700 (С90 - 45 минут сторона) - 0x0A8C, т.е. места достаточно. Пока получается: 2 байта ID блока + 5 байт результат + 2 перевод строки и возврат каретки = 9 байт на блок. Скорость USART постараюсь поставить на максимум, что б данные не спотыкались. В принципе можно от ID вообще отказаться и назначать соответствие блока секунде уже в таблице, но это риск. При потере части данных будет не сразу ясно, что произошла эта потеря.

    Максимальный поток у меня 23*9=207 байт в секунду! При пяти и тех же 9 байтах =45. Или ограничится 9-ю байтами в секунду, которые можно посылать сразу после расчёта этой самой секунды и дальнейшее влияние во время отправки, будет только на те импульсы, которые не будут участвовать в расчётах. Т.е. желательно развести расчёт значимого и время вывода по разным временным окнам.

    Свои 24-е, могу программно поделить на 2, на 3, на 4, на 6 и расчёты можно будет делать реже при желании.

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

    Это местами предварительно и что-то ещё будет меняться-подгоняться...

    З.Ы. Наливаю проект переменными, константами, инициализацию расписал, попутно пытаюсь не запутаться. 16-и битный стакан (таймер для замеров жирности импульсов) умножил на 8, т.е. 24бита. При 16МГц, чуть более секунды для замера (по переполнению - автостоп как бонус), а в миллилитрах - 200*8=1.6 литра! Побежал в магаз, а то топлива не хватает.

    ---------- Сообщение добавлено 06.04.2022 в 13:47 ---------- Предыдущее сообщение было 05.04.2022 в 20:13 ----------

    Вспух мозг! Спать лечь не смог. Больно. Это состояние моего мозга пытающегося вспомнить математику.

    Упёрся вот во что:
    Знал и помнил, что у меня отработано деление. Для справки: деления в AVR Atmega328P - нету! По этому мне для счёта, нужна ассемблерная библиотека с этим делом и по возможности скорострельная.
    Нашёл у себя, прочитал описание и всё понял... Типа понял.
    Проверить же надо! Ура-ура! Вперёд-вперёд!
    Набросал пример в Excel-е. Простой такой пример: 399266 / 1380322 = 0,28925569541020138779212386674993. Упростить не смог, вспухло.
    Закидываю в гексах это дело туды, т.е. в регистры для счёта библиотекой: 0x0617A2 / 0x150FE2 = 0x0000004A0CA9 - это посчиталось (тут ещё точка д.б., но не выводится).
    Калькулятор меньше нуля не кажет!
    Что соответствует в деках (где-то это я уже слышал , не помню, вспухло)... 4852905
    С 2892556 чего-то не бьётся совсем.
    Полез рыть.
    Нарыл в сети 32/32 (это в битах, т.е. 4/4 байта).
    Порезал до 24/24 (3/3).
    Получил 0x4A010B2B.
    Наверное криво порезал, но порядок тот же. М.б. остаток от деления окривел или ещё что... Не суть
    Полез в закрома.
    Отрыл 48/32.
    Получил 0x0000004a0ca9, но дольше считалось.
    Тоже, что и в первый раз.
    Что за хрень? Я чего-то тут не понимаю, а оно работает?

    Спустя время опухоль отпустила и я вкурил...
    Оказалось, что 399266 из дек в гексы, вроде как получается 0x0617A2. Но! где-то в закромах алгоритма значение умножается на 0xFFFFFF+1, т.е. к делимому, что б избежать работы с дробной частью дописывается справа "000000" в гексах или число умножается на 16777216. Делимое выглядит уже иначе - 0x617A2000000, что в деках = 6698571923456!
    Т.е. умнож я просто 0,28925569541020138779212386674993 на 16777216 в уме - сразу бы всё понял. Но в школе, в первом классе, я прогуливал математику. Отсутствие своевременной закалки в школе теперь сказывается... вспухло. А мог бы сразу получить заветные 4852905.281!

    З.Ы. Описание по сути подвело. Не подумал, что надо было добавить описание этой особенности, что встроено умножение, смещением 3-х байтного делимого, влево на три байта! Принцип-то избавления от точки я помнил, а вот что значение меняется - забыл. Т.е. делиться уже 6 на 3 байта, а принимается два аргумента 3 + 3 байта. Да и формат вывода у меня не описан. Сам стараюсь описывать всё, что могу, но не до всего могу догадаться что надо описать. Не смутило то, что должен получать в результате целую и дробную часть, как думал сначала. Реально же получаю только целую часть слева от точки из-за умножения!
    Последний раз редактировалось DrLithium; 07.04.2022 в 04:33.

  10. #409
    Частый гость Аватар для TheCalligrapher
    Регистрация
    10.01.2020
    Сообщений
    224

    По умолчанию Re: Счётчик ленты в реальном времени

    Цитата Сообщение от DrLithium Посмотреть сообщение
    Вспухло! Вспух и день забот! Вспухло всё!
    Слишком много ненужной воды. Трудно читать.

    Цитата Сообщение от DrLithium Посмотреть сообщение
    Что соответствует в деках (где-то это я уже слышал , не помню, вспухло)... 4852905
    С 2892556 чего-то не бьётся совсем.
    Ну здрасьте! Дробную часть в арифметике с фиксированной точкой нельзя просто брать и тупо переводить из одной системы счисления в другую, как обычное число.

    Например, десятичное число 0.510 в двоичной записи выглядит как 0.12, то есть в вашем формате с фиксированной точкой (24.24) будет представлено как 0x00000080000016. Переводить это 816 в десятичную систему счисления напрямую бесполезно - получится ерунда.

    Перевод шестнадцатеричной дробной части в десятичную делается путем умножения на другие веса разрядов: 16-1, 16-2, 16-3 и т.д.

    Таким образом 0x00000080000016 - это 8 * 16-1 = 0.510. Все сходится.

    Ваше 0x0000004A0CA9 - это 4 * 16-1 + 10 * 16-2 + 12 * 16-4 + 10 * 16-5 + 9 * 16-6 = 0.28925567865371704101562510. Все сходится.

    ---

    Альтернативно, вы можете перевести результат "как обычное число", но потом не забыть разделить на 224. 4A0CA916 = 485290510. Делим на 224, получаем 0.289255678653717041015625.

  11. #410
    Старый знакомый Аватар для DrLithium
    Регистрация
    24.12.2006
    Адрес
    SPb
    Сообщений
    652

    По умолчанию Re: Счётчик ленты в реальном времени

    Цитата Сообщение от TheCalligrapher Посмотреть сообщение
    Ну здрасьте!
    Вы вообще ни чего не поняли.

    Я отбрасываю дробную часть совсем и она ни как участвует в расчётах. При этом у меня всё сходится и проблема была в другом: в умножении одного аргумента, на не круглое (с точки зрения десятичной системы) число. Это особенности библиотеки для удобства дальнейшей работы и ни какие "Ну здрасьте!" тут прилепить нельзя. А то что вы написали мне ни как не пригодиться, т.к. время вычисления может значительно увеличиться! Я ограничен точностью в 10 знаков десятичной системы счисления. Меньше нельзя (если есть данные с такой точностью) и больше, т.к. долго. Если бы я хотел использовать дробную часть, то подыскал бы другую библиотеку, которая сама решает как считать части и ставить точку. Библиотека 48/32 произвела деление за 1075 такта, 24/24 уже за 875. Для меня это критично, т.к. по мимо этого есть ещё что посчитать. Приходиться хитрить.

    Цитата Сообщение от TheCalligrapher Посмотреть сообщение
    есть в вашем формате с фиксированной точкой (24.24)
    У меня его нету. 24/24 это деление 3-х байт на 3-и байта, а не формат. Думал "знак деления" даст понять суть назначения функции, ну и сам контекст именно о делении.

    Спасибо за интерес.
    Последний раз редактировалось DrLithium; 07.04.2022 в 02:32.

  12. #411
    Частый гость Аватар для TheCalligrapher
    Регистрация
    10.01.2020
    Сообщений
    224

    По умолчанию Re: Счётчик ленты в реальном времени

    Цитата Сообщение от DrLithium Посмотреть сообщение
    А то что вы написали мне ни как не пригодиться, т.к. время вычисления может значительно увеличиться!
    Ничего не понял.

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

    Цитата Сообщение от DrLithium Посмотреть сообщение
    т.к. время вычисления может значительно увеличиться!
    О чем речь? Еще раз: то, что я написал, это не более чем способ интерпретации результатов вами лично. Вашей программе это не нужно. Никакого отношения к "времени вычисления" это не имеет вообще и никак на него не влияет.

    Цитата Сообщение от DrLithium Посмотреть сообщение
    У меня его нету. 24/24 это деление 3-х байт на 3-и байта, а не формат. Думал "знак деления" даст понять суть назначения функции, ну и сам контекст именно о делении.
    Что вы несете? Не "у меня его нету", а именно с ним вы все это время и работали! Какое "деление", о чем вы? Что это за запись вообще: "24/24"? Где вы ее взяли?

    Формат 24.24 - это двоичное представление с фиксированной точкой в 48 битах, среди которых 24 младших бита представляют дробную часть (а 24 старших - целую). Ваше 16777216, которые вы самостоятельно раскопали в конце концов - это и есть 224, о котором я вам говорю в своем сообщении, то есть множитель/делитель, используемый для перехода от обычного представления в 24.24 и обратно.

    0x0000004A0CA9 - это представление числа 0.289255678653717041015625 в формате 24.24. 000000 - целая часть, 4A0CA9 - дробная часть.

  13. #412
    Старый знакомый Аватар для DrLithium
    Регистрация
    24.12.2006
    Адрес
    SPb
    Сообщений
    652

    По умолчанию Re: Счётчик ленты в реальном времени

    Цитата Сообщение от TheCalligrapher Посмотреть сообщение
    Делать вы это будете именно так, как я написал, без вариантов, ибо это не что иное, как определение позиционной системы счисления и никуда вы от него не денетесь.
    Что ж. Буду подчиняться законам. Но зачем соблюдать их всех? Проще отбросить не нужные.

    Цитата Сообщение от TheCalligrapher Посмотреть сообщение
    Никакого отношения к "времени вычисления" это не имеет вообще и никак на него не влияет.
    Вы указали у меня формат числа 24.24, т.е. что я использую числа с плавающей точкой. Я уточнил этот момент для вас и указал на факт того, что для моей реализации есть смысл использовать целочисленное вычисление, т.к. это реально сокращает время выполнения. Надеюсь недопонимание тут закончится.


    Цитата Сообщение от TheCalligrapher Посмотреть сообщение
    Что вы несете? Не "у меня его нету", а именно с ним вы все это время и работали! Какое "деление", о чем вы? Что это за запись вообще: "24/24"? Где вы ее взяли?

    Формат 24.24 - это двоичное представление с фиксированной точкой в 48 битах, среди которых 24 младших бита представляют дробную часть (а 24 старших - целую). Ваше 16777216, которые вы самостоятельно раскопали в конце концов - это и есть 224, о котором я вам говорю в своем сообщении, то есть множитель/делитель, используемый для перехода от обычного представления в 24.24 и обратно.

    0x0000004A0CA9 - это представление числа 0.289255678653717041015625 в формате 24.24. 000000 - целая часть, 4A0CA9 - дробная часть.
    По пунктам:
    Где взял? Ну например здесь.

    Формат 24.24 - это чудесно, но только я писал о... 24/24, как о функции деления. Т.е. к вашему формату о 48 битах, я отношения не имею. И пусть я использую переход "от обычного представления в 24.24 и обратно", но я не думал о переходах между форматами, т.к. реально получаю только 24 бита данных. А далее имею доп.функцию умножения аргумента, просто записав значение в регистры со смещением на 3-и байта левее, т.ч. фактически не конвертил данные из с плавающей точкой в целочисленные.

    Для себя 0x0000004A0CA9 я представляю это число как 6-и байтное (т.е. зарезервированное место в регистрах), но при этом не имеющее веса в 3-х старших байтах. Рассматриваю его исключительно как целочисленное для вычислений, но как результат деления я помню это что число до умножения на 16777216, было числом меньше единицы, что для меня не критично и является плюсом.

    З.Ы.
    Цитата Сообщение от TheCalligrapher Посмотреть сообщение
    Слишком много ненужной воды. Трудно читать.
    Ладно чуть сокращу.... А щас сожрал Анальгинку - станцую Лезгинку!

  14. #413
    Новичок Аватар для alias
    Регистрация
    05.01.2022
    Сообщений
    27

    По умолчанию Re: Счётчик ленты в реальном времени

    Опаньки, форум ожил! А то что-то как-то долго его колбасило. Странички с постами, и те частично потерялись.

    Так вот, появилась еще одна "точилка" для счетчика квази-реального времени. Собственно сама реализация в железе описана тут: http://www.rt20.getbb.ru/viewtopic.p...845&start=2200
    И видео там тоже немного есть. Сейчас собираю данные по кассетам и осмысливаю результаты.

  15. #414
    Завсегдатай
    Автор темы
    Аватар для Turbo_man
    Регистрация
    06.04.2010
    Адрес
    Moscow
    Сообщений
    5,553

    По умолчанию Re: Счётчик ленты в реальном времени

    DrLithium привет, что-то новое по теме есть?

  16. #415
    Новичок Аватар для Fifan
    Регистрация
    05.05.2019
    Сообщений
    72

    По умолчанию Re: Счётчик ленты в реальном времени

    Меня это тоже интересует.

  17. #416
    Старый знакомый Аватар для DrLithium
    Регистрация
    24.12.2006
    Адрес
    SPb
    Сообщений
    652

    По умолчанию Re: Счётчик ленты в реальном времени

    Цитата Сообщение от Turbo_man Посмотреть сообщение
    DrLithium привет, что-то новое по теме есть?
    Есть.
    Проблема: данные поступающие с датчиков имеют постоянное хаотичное отклонение, даже от предыдущего оборота! И что это именно, геометрия, наводки мотора, импульсы питания, не ясно.

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

    Суть инструмента такая: собираю в буфер замеры для каждой лопасти. На следующем обороте вычитаю предыдущий замер, разницу выкидываю в ардуиновский "плоттер". Получаю график нестабильности, который показывается в реальном времени. Это сделано для учёта того, что каждая лопасть имеет свой размер отличный от остальных из-за неидеальности изготовления. Теперь можно воздействовать на узлы и платы и видеть отклик.

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

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

    Минимальная дельта получается на перемотке при подаче 9V на мотор. По оси Y - значения в тактах, т.е. дельта между текущим замером одной лопасти и её же замером с предыдущего оборота. На воспроизведении Y раздувает от 60000-200000 и это плохо.
    Нажмите на изображение для увеличения. 

Название:	4_с_кассетой_без_тормозов3+без_пасика_счётчика_+9V_перемотка.jpg 
Просмотров:	35 
Размер:	151.8 Кб 
ID:	426828

    Условно:
    При 16000000 тактов с секунду имеем период обращения приёмного (пустого) подкассетника 0,24 секунды. Лопастей 24, делим, получаем 160000 тактов на лопасть. А разница набегает минимум 60000. Не ужели так сильно дрожит сам свеженачатый рулон? Что-то не верится.

    Побьюсь ещё и если будет сдвиг, то оформлюсь в своей ветке и дам готовую прошивку инструмента со схемами и инструкциями. Число лопастей можно менять от 1 до 180.

    Далее только вопрос озарения: или улучшить механику/электронику или решать вопрос программно. Есть какие-то идеи как, но пока чёткого понимания нету. Т.е. основная идея лежит в том, что б находить текущее время точнее, за какой-то период (отображать что-то типа "CALC") и далее поддерживать рассчитывая размер приращения, вычисляемое по поступающим данным. Определить положение времени на ленте - это есть и этого уже достаточно, а вот считать усреднённый шаг приращения - тут надо думать и тестить на предмет вранья при разных условиях. В перемотке шаг можно не считать, т.к. точность не нужна и того что есть, так же достаточно.

  18. #417
    Завсегдатай
    Автор темы
    Аватар для Turbo_man
    Регистрация
    06.04.2010
    Адрес
    Moscow
    Сообщений
    5,553

    По умолчанию Re: Счётчик ленты в реальном времени

    Аппаратный подавитель дребезга датчиков есть (триггер Шмитта)?

  19. #418
    Старый знакомый Аватар для DrLithium
    Регистрация
    24.12.2006
    Адрес
    SPb
    Сообщений
    652

    По умолчанию Re: Счётчик ленты в реальном времени

    Цитата Сообщение от Turbo_man Посмотреть сообщение
    Аппаратный подавитель дребезга датчиков есть (триггер Шмитта)?
    Оптику обслуживает схема оптики от счётчика от Leoniv. И, если МК дребезг начнёт криво обрабатывать, то счёт станет нереальным в принципе, короткий замер сразу всё испортит. Думаю уверенности в правильности работы инструмента, добавит тест от генератора прямо на светодиоды.

    По логам всегда были только длинные замеры, но с какой-то кривой дельтой.

    Скрытый текст

    004528:07B927000000/05AAF6
    004528:0000015CD6A6 2286
    00456A:M1-000000-1B0700-1AB793-1B96A3-1A34CC-1B5EEF-1A72EB-1B82EA
    -1A87FC-1AE803-1AFA82-1AE50F-1C0A91-19DBED-1BEB4A-1A901B-1BB5F9
    -1B1915-1A3922-1BCA83-19FC45-1BB747-1AC17B-1B911F-1AF9DE-000000
    00456D:028862F0/18=0005AECA
    00456E:05AECA i11
    00456E:
    00456E:07B927000000/05AECA
    00456F:0000015BEBA8 2280
    00456F:M0-000000-12751B-124B5B-124054-13279D-12490C-12A22A-12055A
    -12501D-128DC6-127C3D-121093-125C21-127FA5-12287D-1245B3-122384
    -127CEB-12553B-125A00-125F3F-126F54-129380-1283D2-124794-000000
    004572:01B94AC3/18=0007B872
    004573:07B872 i01
    004573:
    004573:07B872000000/05AECA
    004574:0000015BCBCE 2279
    0045B9:M0-000000-000000-124B5B-124054-13279D-12490C-12A22A-12055A
    -12501D-128DC6-127C3D-121093-125C21-127FA5-12287D-1245B3-122384
    -127CEB-12553B-125A00-125F3F-126F54-129380-1283D2-124794-127549
    0045BC:01B94AF1/18=0007B874
    0045BD:07B874 i01
    0045BD:
    0045BD:07B874000000/05AECA
    0045BE:0000015BCC29 2279
    0045D6:M1-000000-000000-1AB793-1B96A3-1A34CC-1B5EEF-1A72EB-1B82EA
    -1A87FC-1AE803-1AFA82-1AE50F-1C0A91-19DBED-1BEB4A-1A901B-1BB5F9
    -1B1915-1A3922-1BCA83-19FC45-1BB747-1AC17B-1B911F-1AF9DE-1A951B
    0045D9:0287F10B/18=0005AA0B
    0045DA:05AA0B i11
    0045DA:
    0045DA:07B874000000/05AA0B
    0045DB:0000015CEF94 2286
    004604:M0-124E1C-000000-000000-124054-13279D-12490C-12A22A-12055A
    -12501D-128DC6-127C3D-121093-125C21-127FA5-12287D-1245B3-122384
    -127CEB-12553B-125A00-125F3F-126F54-129380-1283D2-124794-127549
    004607:01B94DB2/18=0007B892
    004607:07B892 i01
    004608:
    004608:07B892000000/05AA0B
    004608:0000015CF4E0 2286
    004645:M1-1B5BE3-000000-000000-1B96A3-1A34CC-1B5EEF-1A72EB-1B82EA
    -1A87FC-1AE803-1AFA82-1AE50F-1C0A91-19DBED-1BEB4A-1A901B-1BB5F9
    -1B1915-1A3922-1BCA83-19FC45-1BB747-1AC17B-1B911F-1AF9DE-1A951B
    004649:0288955B/18=0005B0E3
    004649:05B0E3 i11
    004649:
    00464A:07B892000000/05B0E3
    00464A:0000015B513C 2276
    00464D:M0-124E1C-122AFD-000000-000000-13279D-12490C-12A22A-12055A
    -12501D-128DC6-127C3D-121093-125C21-127FA5-12287D-1245B3-122384
    -127CEB-12553B-125A00-125F3F-126F54-129380-1283D2-124794-127549
    004651:01B9385B/18=0007B7AE
    004651:07B7AE i01
    004651:
    004652:07B7AE000000/05B0E3
    004652:0000015B292C 2275
    00469B:M0-124E1C-122AFD-132DCD-000000-000000-12490C-12A22A-12055A
    -12501D-128DC6-127C3D-121093-125C21-127FA5-12287D-1245B3-122384
    -127CEB-12553B-125A00-125F3F-126F54-129380-1283D2-124794-127549

    = : D без пробела
    [свернуть]


    Тут возможно, что текущее аппаратное решение подавления дребезга работает по своему и вносит что-то своё. Т.е. проектировалось под работу с фактом наличия импульсов, а для работы именно на замер, не подходит. Или как вариант, можно поиграть с параметрами схемы. У меня стоят транзисторы с малым h21э (вроде бы 100 против 800 у родного), м.б. это влияет на работу. И хорошо бы что б это было так!

  20. #419
    Старый знакомый Аватар для Bobby_ii
    Регистрация
    16.03.2011
    Адрес
    Spb
    Сообщений
    822

    По умолчанию Re: Счётчик ленты в реальном времени

    Цитата Сообщение от DrLithium Посмотреть сообщение
    Условно:
    При 16000000 тактов с секунду имеем период обращения приёмного (пустого) подкассетника 0,24 секунды. Лопастей 24, делим, получаем 160000 тактов на лопасть. А разница набегает минимум 60000. Не ужели так сильно дрожит сам свеженачатый рулон? Что-то не верится.
    Что-то фигня какая-то. Как вы считаете? Сбрасываете счетчик? ИМХО, надо считать "нарастающим". Далее - медианная фильтрация для получения среднего по палате.
    Последний раз редактировалось Bobby_ii; 30.10.2022 в 22:02.
    "Лучше промолчать и показаться дураком, чем раскрыть рот и развеять все сомнения" Марк Твен.

  21. #420
    Старый знакомый Аватар для DrLithium
    Регистрация
    24.12.2006
    Адрес
    SPb
    Сообщений
    652

    По умолчанию Re: Счётчик ленты в реальном времени

    Цитата Сообщение от Bobby_ii Посмотреть сообщение
    Что-то фигня какая-то. Как вы считаете? Сбрасываете счетчик? ИМХО, надо считать "нарастающим". Далее - медианная фильтрация для получения среднего по палате.
    Фигня тут такая! Пишу ещё раз то, что происходит и что измеряется.

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

    Суть идеи инструмента.
    Я беру два замера одной и той же лопасти, но с разных оборотов. За оборот получили (если на приёмном подкассетнике) приращение к диаметру за счёт добавление витка ленты. Соответственно есть дельта (последний замер лопасти минус её же предыдущий) и эта дельта теоретически д.б. стабильна! Размер дельты зависит от толщины ленты, но в данном случае это не важно. Важно получить стабильное приращение для всех лопастей крыльчатки. То, что получается в реале и определяет дрожание данных при расчёте отношения. На вывод идут только размеры дельт от каждой лопасти. Т.е. в идеале д.б. ровная линия не равная нулю. Для того, что б из значения нового замера лопасти вычиталось прошлое и точно своё, предусмотрена возможность задать кол-во лопастей без кавычек: для 6-и - "b6", для 24-х - "b24", для 180-и - "b180". Задание кол-ва лопастей позволит уменьшить значения выводимых данных.

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

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

    Это не реальные данные, а тестовые для инструмента!
    При подаче данных с генератора получается такая картина:
    Нажмите на изображение для увеличения. 

Название:	Тест с генератора_10.05Гц+14Гц_04.jpg 
Просмотров:	28 
Размер:	172.7 Кб 
ID:	427326
    А если случаются пресечения по прерываниям, то картина такая:
    Нажмите на изображение для увеличения. 

Название:	Тест с генератора_10.05Гц+14Гц_05.jpg 
Просмотров:	21 
Размер:	87.6 Кб 
ID:	427325
    А это проверка алгоритма в протеусе (чисто программная проверка теории):
    Нажмите на изображение для увеличения. 

Название:	10Hz+14Hz.jpg 
Просмотров:	25 
Размер:	58.8 Кб 
ID:	427327

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

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

    З.Ы. А не сродни ли проблема дрожания стрелки динамометрической кассеты?
    Последний раз редактировалось DrLithium; 31.10.2022 в 04:56.

Страница 21 из 22 Первая ... 1119202122 Последняя

Социальные закладки

Социальные закладки

Ваши права

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