cnc-club.ru

staltech писал(а):Микрухи судя по всему древние

На счет древние это я наверное зря, просто шина параллельная. Вот более продвинутая версия PcL6045B и цена на нее: https://ru.aliexpress.com/item/Free-shi ... .16.0npIpC. Что то страшно с такими экспериментировать, да и разводка платы будет та еще.
Вариант контроллера на ARM9 и PCL6045: http://www.ucancad.com/pcl6045b.html

Всё понял, дёргаться в эту сторону не стоит. Курю дальше STM32 HAL..

sidor094 писал(а):Несмотря на достаточно крутые таймеры ,уменя не получилось читать STEP/DIR.полностью аппаратно.Таймеры у STM32 двунаправленные.С интерфейсом энкодера всё в порядке.А вот менять направления счета STEP по сигналу DIR не получилось.Пришлось вводить прерывание по сигналу DIR .И уже внутри прерывания переключать направление счета таймера STEP.Если кто-то знает как это сделать полностью аппаратно .Подскажите.

А что ты подразумеваешь под "читать STEP/DIR аппаратно" ? В STM32 под это определение подходит только аппаратный отлов внешних прерываний. Такой же, каким ты отлавливаешь DIR.

Для управления сервоприводом требуется знать состояние счетчика шагов и счетчика положения энкодера в определённое строго заданное время(например через 1мс).В остальное время их состояние меня вообще не интересует.Программируя таймер в качестве контроллера энкодера я на STM32 для энкодера этот вопрос решаю.Для счетчика шагов я подаю сигнал степ на вход любого таймера и таймер считает шаги.Но при смене направления мне приходится сажать сигнал дир на прерывание и внутри прерывания менять направление счета таймера.Если бы удалось вывести сигнал направления счета на любую ногу то прерывания стали бы не нужны и не отнимали процессорного времени.Но как я не пробовалЭтого сделать не получается,хотя в режиме работы с энкодером сигнал таймера для изменения счета задействуется аппаратно.Неужели разработчики не предусмотрели работу этого сигнала в режиме простого счета?Или я не разобрался в документации.

sidor094 писал(а):Этого сделать не получается,хотя в режиме работы с энкодером сигнал таймера для изменения счета задействуется аппаратно.Неужели разработчики не предусмотрели работу этого сигнала в режиме простого счета?Или я не разобрался в документации.

Есть 3 разных режима энкодера:

SMS=001 – режим энкодера №1; счетчик считает вверх или вниз по сигналу TI2FP2 (тактируется от него), в зависимости от уровня сигнала TI1FP1;
SMS=010 – режим энкодера №2; счетчик считает вверх или вниз по сигналу TI1FP1 (тактируется от него), в зависимости от уровня сигнала TI2FP2;
SMS=011 – режим энкодера №3; счетчик считает вверх или вниз по сигналам TI1FP1 и TI2FP2, в зависимости от уровня сигнала на другом входе;

И первые 2 очень похожи на то что ты хочешь, если не заленюсь проверю. Еще можно логикой преобразовывать Step/Dir к нужному виду, а еще лучше для этого подходит FPGA.

staltech писал(а):а еще лучше для этого подходит FPGA

Я изначально говорил, что задача "Умножитель STEP/DIR" идеально вписывается в FPGA

AndyBig писал(а):Я изначально говорил, что задача "Умножитель STEP/DIR" идеально вписывается в FPGA

Не-не-не это я по вопросу:

sidor094 писал(а):Для управления сервоприводом требуется знать состояние счетчика шагов и счетчика положения энкодера в определённое строго заданное время(например через 1мс).В остальное время их состояние меня вообще не интересует.Программируя таймер в качестве контроллера энкодера я на STM32 для энкодера этот вопрос решаю.Для счетчика шагов я подаю сигнал степ на вход любого таймера и таймер считает шаги.Но при смене направления мне приходится сажать сигнал дир на прерывание и внутри прерывания менять направление счета таймера.Если бы удалось вывести сигнал направления счета на любую ногу то прерывания стали бы не нужны и не отнимали процессорного времени.Но как я не пробовалЭтого сделать не получается,хотя в режиме работы с энкодером сигнал таймера для изменения счета задействуется аппаратно.Неужели разработчики не предусмотрели работу этого сигнала в режиме простого счета?Или я не разобрался в документации.

А то сейчас и тут война разразится.

staltech писал(а):И первые 2 очень похожи на то что ты хочешь, если не заленюсь проверю. Еще можно логикой преобразовывать Step/Dir к нужному виду, а еще лучше для этого подходит FPGA.

Знаю.Пробовал.Но почему-то не получилось .Если получится хотелось бы посмотреть код инициализации.

sidor094 писал(а):Знаю.Пробовал.Но почему-то не получилось .Если получится хотелось бы посмотреть код инициализации.

Хорошо, отпишусь по результату в личку.

Спасибо.

AndyBig писал(а):

staltech писал(а):а еще лучше для этого подходит FPGA

Я изначально говорил, что задача "Умножитель STEP/DIR" идеально вписывается в FPGA

В ближайшем будущем, возможно, к этому и придём.. Просто, параллельно изучать работу трёх устройств довольно сложно.

sidor094 писал(а):staltech писал(а):
И первые 2 очень похожи на то что ты хочешь, если не заленюсь проверю. Еще можно логикой преобразовывать Step/Dir к нужному виду, а еще лучше для этого подходит FPGA.
Знаю.Пробовал.Но почему-то не получилось .Если получится хотелось бы посмотреть код инициализации.

Короче задача хитрой настройкой энкодеров потерпела крах, я просто попался на особенностях перевода. Зато освежил мозги и освоил инициализацию энкодеров в STM32Cube.

MX_Master писал(а):AndyBig писал(а):
staltech писал(а):
а еще лучше для этого подходит FPGA

Я изначально говорил, что задача "Умножитель STEP/DIR" идеально вписывается в FPGA

В ближайшем будущем, возможно, к этому и придём.. Просто, параллельно изучать работу трёх устройств довольно сложно.

FPGA все же лучше использовать на начальном этапе генерации Ste/Dir тот же Pluto или что то свое.
Задача фильтра-умножителя Step/Dir сама по себе гораздо интересней в плане реализации, так что постараюсь следить за развитием темы.

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

Использую 6N137, хотя может и не самый оптимальный вариант.
Есть двухканальный вариант - HCPL2630.

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

Про драйвер согласен, но он на выходе будет. За мегу2560 переживаний нет, а вот за STM32F4 есть опасения. На входе хотя б минимальные резисторы должны быть. Над опторазвязкой подумываю. Всё, что у меня есть из шагогенераторов - это LCNC с 5V платой развязки без резисторов и опторазвязки на выходе. И есть китайская Smoothieboard с LPC1768FBD100 (3.3V), где только резисторы 100 Ом на выходе.

tmr писал(а):Кроме того, если использовать арм, там ттл 3.3В, т.е. в любом случае потребуется логический буфер, который и будет выполнять защитную роль.

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

MX_Master писал(а):И есть китайская Smoothieboard с LPC1768FBD100 (3.3V), где только резисторы 100 Ом на выходе.

Здесь проще если питать от одного источника (общая земля) и у стмки используются входы толерантные к 5в. то можно ни чего не ставить.

В том и дело, что питание всегда от разных источников. Например, в тестах STM'кa питается от USB ноута, китайская Smoothieboard от 24V импульсника, а плата развязки от 5V компьютерного БП. В общем, ищу какое-ньть универсальное решение, чтоб можно было на вход к STM'ке подключить любой шагогенератор (5V, 3.3V) без хардкорных последствий.

Завалялась еще китайская плата USBCNC Mk1, на выходах есть и оптроны, и резисторы. Но это чисто для проверки. Основные шагогенераторы, которые я использую - это LCNC с обычной плата развязки и чуток позже планирую связку LCNC + Beaglebone Black.

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

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

tmr писал(а):У китайцев есть готовый для макетки трансивер на 16 каналов, например. Только ноги перекинуть на обратную сторону, мне оригинальная раскладка показалась неудобной.

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