Comments 29
Не очень понятно в даташите, какой там выход? Открытый коллектор? Такое впечатление, что ТТЛ, судя по токам.
А на осциллограмме выше - это сигнал с выхода датчика или после делителя?
Некоторые характеристики TTL-выхода:
Напряжение логического нуля: не выше 0,8 В при рабочем выходном токе 8 мА.
Напряжение логической единицы: не ниже 2 В при рабочем выходном токе -0,4 мА.
Не теряются импульсы при высокой скорости вращения? Можно поставить метку на валу, быстро покрутить туда-сюда и снова выставить на метку. Должен вернуться в +-0. Или 360 )
Это сигналы после делителя, тестировал конечно же как Вы и написали, ставил метку на оси и быстро крутил, в 0 возвращается, этот датчик я применяю при пешеходной съемке, максимальная скорость у меня была 4-5 км/ч, можно конечно сделать тест , посадить датчик на шаговый двигатель какой нибудь, кстати попробую:)
Выход у датчика TTL, все верно
Спасибо за комментарий
Ссылка на скачивание исходного кода [ https://t.me/ChipCraft
буду благодарен за подписку на мой ТГ-канал.
На что только люди не идут что бы на них подписались...
Целая статья в которой специально нет ключевых подробностей.
Соблазн посмотреть правильный ли режим таймера STM32 (для работы с энкодером) был выставлен, был мной у себя задавлен с мыслью "Да и пофиг, что там автор сделал. Как нужно я и так знаю".
Достали статьи с лейтмотивом "ну подпишитесь на мой TG канал, что вам стоит то".
Дело каждого, я никого не умоляю подписаться, а по вопросу, настройки таймера и реализации самого кода(с пояснениями), я предоставил всю информацию в данной статье:), надо только внимательно посмотреть статью.
ну ну.
Я вот только по косвенным признакам (Описание режимов..TI1 and TI2) могу догадаться что используется режим работы с энкодером таймера (исходники то инициализации таймера только по ссылке на TG)
Поэтому ценность статьи сомнительная. Для тех кто в теме - ничего нового.
Для тех кто не совсем в теме - "раз раз и работает" (без пояснения ключевых мест). Типа скачайте с TG..
Угу. Скачайте..
Да еще HAL либа (хотя это дело вкуса).
хм, честно говоря у меня не было в планах скрывать информацию о настройке таймера, а уж тем более коварного плана по получению подписчиков:) по факту можно зайти - подписаться (скачать исходник) и отписаться :) я на самом деле думал что достаточно показать настройку таймера в граф.интерфейсе, естественно я не против открыть конфиги, обязательно дополню информацию)
Круто, конечно, что в stm32 есть таймер, который сразу умеет в енкодер. Буду знать ;) перфекционист говорит, что, наверное, у того таймера и прерывания есть ;)
Глянул канал в телеге, расхотелось подписываться, в названии 2 орфографических ошибки, не исскуство, а искусство, и не миксросхем, а микросхем, наверное. Исправьте, пожалуйста.
Вообще то у квадратурных энкодеров надо декодировать запрещённые переходы для подавления дребезга, или там это аппаратно сделано?
Нет, к сожалению в данном датчике нет обработки подавления дребезга, поэтому в настройке таймера я включил параметр Input Filter (3) - для моей небольшой скорости достаточно, проблем не возникало.
Там же аппаратный вход.
И какие переходы у квадратурного энкодера запрещённые?
Сигналы каналов А и В всегда должны быть сдвинуты друг относительно друга на 90 градусов, рисунок (1)являются нормальными переходами, на рисунке 2 переходы не нормальные и такого не должно происходить, это и есть запрещенный переход
И в каком случае на оптическом энкодере будет получен сигнал с картинки 2?
В моих задачах такого не было напишу честно, но такое может произойти :
слишком быстрое вращение вала , к примеру прошли какой - то участок с одной скорости, а потом резко к примеру начали движение в два раза больше чем было;
Далее плохая реализация кабеля, который связывает к примеру датчик и другое устройство , на которое датчик передает информацию, у меня кабель используется Unitronic lapp Li2YCY 4x0,75 с витыми парами;
Еще проблема может быть из - за ну очень длинного кабеля(если он без экрана, то он просто будет работать как антенна и создавать помехи).
слишком быстрое вращение вала , к примеру прошли какой - то участок с одной скорости, а потом резко к примеру начали движение в два раза больше чем было
Если крутизна нарастания фронтов в выходном каскаде энкодера такая низкая, что при быстром вращении сигналы сливаются — значит вы не по задаче выбрали энкодер.
Если крутизна достаточная, но ваш MCU работает на слишком медленной частоте, или вместо прерываний использует опрос, который делается очень редко, то вы неправильно работаете с датчиком.
Это, грубо говоря, как с теоремой Найквиста-Шеннона aka Котельникова — вы должны заранее определиться с максимальной скоростью вращения вала энкодера, вычислить из неё максимальную частоту следования четверть-периодов (квадратур) и выбрать частоту опроса пинов как минимум вдвое больше, чтобы гарантированно ничего не пропустить. Или, если используете прерывания, убедиться, что прерывания успевают вовремя отработать.
Или использовать железную логику и превратить Ch.A + Ch.B в пару Step/Dir, потому что обрабатывать прерывания с такими сигналами должно быть быстрее.
Но в любом случае, если энкодер способен выдавать импульсы чаще, чем МК может обработать, бороться с этим отфильтровыванием запрещённых переходов — бесполезно. Потому что, допустим, вы откинули «запрещённый» переход и отловили легитимный переход. Откуда вы можете быть уверенными, что в интервале между двумя сэмплированиями от энкодера пришёл именно один переход? Может за это время там 3 или 10 переходных edge-в было? Ниоткуда. Поэтому фундаментально правильный подход это гарантированный оверсэмплинг, а не отбрасывание запрещённых переходов.
Любые, при которых 2 бита меняются одновременно, 00-11, 01-10
Кмк, все равно, как вы будете такое обрабатывать. Енкодер будет либо пропускать шаги, либо добавлять, в любом случае ошибка.
В оптическом энкодере да ещё и с интегрированным фронтендом (в котором наверняка есть триггеры Шмитта) такого быть не может.
Если у вас polling вместо event-based обработки сигналов, то при слишком медленном опросе и слишком быстром вращении вы можете пропустить оба фронта в интервале между двумя опросами. Но это не запрещённый переход, это, извините, выбранная вами частота опроса порта не соответствует максимально допустимой скорости вращения, определяемой техзаданием.
В оптическом хорошего качества скорее всего нет, а вот в недорогих механических сплошь и рядом
Ну в энкодеры может быть и не может, а вот в кабеле все может быть, особенно в промышленных условиях. Поэтому полезно иметь критерии по котором сигнал энкодеры признается не валидным и вся система на это как то реагирует.
Промышленность имеет такие особенности, что если Вы даже все экраны и разводки сделаете правильно, завтра все это может измениться после воздействия механиков ( это такие вредители электроники).
А точные показания энкодеры бывают критически важны для безопасности.
Знаете, бороться с помехами на уровне кода — это последнее дело. В прямом смысле последнее — это значит вы на предыдущих рубежах ничего не смогли сделать с помехами. А должны были.
Когда говорят «разводку сделали правильно, но помехи всё равно одерживают верх», чаще всего это означает, что разводку сделали неправильно, но к своему несчастью неправильные решения считают за правильные.
Я вообще не писал о борьбе с помехами.
Хотя, бороться с ними нужно на всех уровнях.
Я писал, что если помехи почему то возникли - контроллер должен это понять и принять решении (скорее всего остановка механизма до устранения проблем)
Рессурсы STM32 вполне позволяют отличить правильные сигналы от помех или сбоев, почему бы этим не пользоваться.
К примеру, на одном проекте, у меня основной функционал занимал только 1/6 часть кода, а 5/6 - это контроль целостности самой системы (что все датчики и проводки действительно работают, ничего не оборвано, не закорочено, и т.д.) Все зависит от цены ошибки, а в промышленности она обычно очень высокая.
Оффтоп. А почему в энкодерах не принято передавать свет по оптическому волноводу и уже на месте ставить компараторы? У меня двигатель шумел и энкрдер сбоил, решилось экранированием, но осталось впечатление, что это это ненадёжно...
Могу рассказать свой личный опыт, я лет 10 назад использовал метод передачи по кабелю ШОС, в качестве передатчика был HFBR-1412-TMZ, безусловно если использовать для датчика который находится в помещении, это хорошо, но если его использовать на улице при -10 к примеру , кабель ШОС дублет просто и ломается .. передатчик постоянно загрязняется и тоже выходит из строя… но единственный + что помех конечно вообще не создает такое соединение!!Интересно кстати проанализировать не будут ли теряться данные на высоких скоростях, высоких но приемлемых для датчика имею в виду, и сравнить, откопаю как нибудь посмотрю
Энкодер на базе HEDR и STM32