Давайте посмотрим.Давайте больше инфы, мы решим Вашу задачу по-другому.
Мы имеем вполне себе простую задачу:
Каретка перемещается сверху вниз по направляющей с использованием передачи шестерня-рейка. На направляющей размещается оптическая линейка абсолютного энкодера (разрешение 50 нм.). Режим движения - движение с постоянной скоростью. В текущем варианте системы используются СУ MR-J4-A. Сама задача состоит в том, что по мере прохождения каретки по оси с постояннной скоростью необходимо генерировать триггеры при достижении заданного набора точек (следующих с равным периодом) (да, режим электронного кулачка был бы вполне удовлетворительным, и изначально так и предполагалось).
В общем-то и весь синопсис. А дальше начинаются проблемы. Количество точек, на которые нужно стригериться за один проход превышает количество точек, с которыми можно работать в табличном режиме СУ, не говоря уже о том, что эту таблицу каждый раз нужно генерировать заново, что для движения по точкам с постоянным периодом генерация такой таблицы не выглядит корректным решением. Была попытка решить задачу в режиме програмного управления, но мне почему-то не удалось получить от СУ генерацию тригеров превышающую по частоте 20 ГЦ, в то время, как наша сетка может быть гораздо более плотной.
Сейчас я (как и было указано выше alex_ugrumov) считываю по мере прохождения импульсы с виртуального энкодера. Но виртуальный энкодер имеет предел физической генерации частоты импульсов 4МГЦ, что одновременно очень много и очень мало. С одной стороны, для подсчета импульсов с интересующей нас точностью на интересующей нас скорости это мало. Мне пришлось зарезать точность системы в 50 раз. С другой стороны такая частота редко поддерживается ПЛК и прочими декодерами квадратурной модуляции типовая частота пропускания - сотни килогерц. Я решил это с использованием самопальной платы на STM32F407, который имеет 2 квадратурных счетчика с разрядностью 32 бита и прерывания, что позволяет уйти от проблемы, связанной с тем, что ПЛК реагируют на изменения данных только по факту прохода по циклу, что не позволяло получить нужного быстродействия.
В общем, сейчас между внешним уровнем (который реализован на компьютере с не реалтаймовым вариантом Linux) и СУ вставлен реалтаймовый самопал на контроллере ARM, который занимается подсчетом импульсов виртуального энкодера и генерацией триггеров. Думаю, что это не есть правильное решение.
Полагаю, что проблема состоит в первую очередь в том, что сервоусилители MR-J4 не поддерживают нужных нам функций. Может я и не прав.
Как это можно решить более правильно?
