FlProg

у вас явные проблемы с ЭМС . Что то на эту тему было на форуме. Если память не изменяет то там использовались RC цепи для борьбы с этим злом.

Протестил все три таймера. FLProg 7.3.8 (9.5.6 даже с отключенным автоформатированием у меня не компилятся) . Положение вывел через KaScada на планшет. Проверил точность на больших дистанциях ( более 1 миллиона отсчетов) и при частых реверсах. Позиция не убегает. С точки зрения пользователя ...

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

Phazz писал(а): 12 дек 2025, 16:31 2025-12-12_18-31-00.png

Спасибо!

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

работает в версии FLProg7/3/8!!!!

Я нашел где собака порылась.
В среде разработки 7.3.8 все блоки, и ваш и пересобранный мой, компилируются и работают нормально. выходят в обе стороны за пределы 16 бит. Спасибо за блок , буду им пользоваться .
Блок испытывался с оптическим энкодером 2500 имп/ об. на выходе на каждый оборот 10000 ...

В версии 7.3.8. блок компилируется без ошибок

Но это дело второе , откройте блок редактором там все видно

да чего то я видимо не понимаю, В моем ругается на форму записи #define TIM2_ARR((volatile uint32_t *)(TIM2_BASE+0x2C)). их в проекте 16 штук, вот 16 ошибок и выдает ( pr10:33:19: ошибка: ожидалось имя параметра, найдено "("

посмотрите файл во вложении , он как и ваш отказывается компилироваться выдает какие то обидки на tokenы, ( подозреваю связано с версиями FlProg) но смысл наверное будет понятен Выход Vx- счет в пределах 16 бит ST -счетчик переполнений.

Хороший программный энкодер выставлял Drundel в теме Энкодер Pro,но он для AVR/ Я делал для себя аппаратный, на регистрах для STM но он более громоздкий чем ваш, ( я не программист, делал по образцу из аппаратного генератора, долго разбирался с регистрами) хотя в пределах 16 бит работал.

почему то проект не компилируется
Arduino: 1.8.19 (Windows 10), Плата:"Generic STM32F1 series, BluePill F103CB (or C8 with 128k), STM32CubeProgrammer (SWD), Enabled (generic 'Serial'), None, Low/Full Speed, Smallest (-Os default), None, Newlib Nano (default)"

C:\Users\ММА\AppData\Local\Temp\flprog ...

Обязательно потестю , постараюсь сегодня или в понедельник

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

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

А какой энкодер использовали? импульсы должны быть пропорциональны углу поворота
А просадку в скоростях дает программное расширение до 32 бит?
А какой таймер использовали и к каким пинам подключали треки А иВ?

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

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

Энкодер на прерываниях можно использовать только на малых скоростях , прерывания останавливают исполнение кода, а если у вас 4 энкодера то это может сказаться на времени цикла с увеличением скоростей перемещения