Ну если счётчик аппаратный тогда ОК

Решил вернутся к теме. То есть как решил - жизнь заставила.
Для 3-х моторов взял STM32F303VCT6. Там хватает таймеров для 3-х PWM и 3-х encoders . Но сейчас поставлена задача - управлять пятью моторами. Есть камень с достаточными ресурсами? Не обязательно STM32.
Я бы с большим удовольствием поставил FPGA но цены на них сумашедшие.

Странно. Вы наверное смотрите что-то из последних моделей, недавно присмотрел себе серию SmartFusion Microsemi - это AFE+Cortex-M3+FPGA в одном чипе, например A2F060 550р. в корпусе TQFP-144.

я смотрю чипы от Altera так как я работал только с ними, они мне знакомы, с ними как то легче.

Цены на них очень приемлемы, особенно с появлением дешевых китайских плат с Циклонами4. Много конструкций на них появилось в последнее время. Но вот вопрос- какую архитектуру Вы планируете впихнуть в эту FPGA?
Будет синтезированное ядро типа ARM или MIPS c сопроцессором плавающей точки для рассчета траектории движения или только ШИМ таймера и таймера-счетчики энкодеров а процессор внешний? Потому что эти два подхода очень разные по требованию к обьему и быстродействию FPGA.
Последняя философия реализована в картах mesa drive http://www.mesanet.com/, для которых и исходники прошивок есть и их достаточно легко адаптировать под любую ПЛИС, хотя изначально там Xilinx применен.
Данные для движения им готовит хост- компьютер, и подает или по PCI, или по Ethernet готовые микрокадры движения. Петли обратной связи по позиции замкнуты через софт.
Хотя после долгого перерыва у них появилась и карта с микропроцессором. 4C81 - WIRELESS ORIENTED PC/104-PCI CPU http://www.mesanet.com/cpucardinfo.html но там полноценный линух используется в виде NetBSD. Соответственно можно пакет править под свои задачи, но это не так уж просто.

спасибо. посмотрю.

Сообщение отредактировал Herz - Oct 30 2017, 08:34

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



Вот уж ПЛИСы здесь точно из пушки по комарам

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



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

Сообщение отредактировал Огурцов - Oct 29 2017, 08:31

Ну это от задачи зависит. Например CNC фрезерный станок с задачей фрезеровки внутренней резьбы в отверстиях. Т.е подача по трем осям с хеликальной интерполяцией, при этом скорость подачи задает энкодер шпинделя. При этом шпиндель может притормозить от нагрузки на фрезу, и соответственно надо замедлить подачу. На микроконтроллерах с такой задачей справится оказалось сложно. Пришлось уходить на ПЛИС.

Прихожу к мысли, что нужно делать модуль контроль+сила, который может работать автономно. Причем такой чтоб умел драйвить и 3-х фазные и ДС моторы, так как есть системы с 3-х фазными моторами, еще одно нововведение на мою ж... голову.
А понадобиться драйвить Х осей - связывать модули по CAN/SPI/UART c мастером который будет axis manager.

У вас похоже кто-то не особо дружит с головой, кто ТЗ делает, ибо целиком задачу не видит и каждый раз придумывает что-то новое. Тут выход один - делать что-то сверхмасштабируемое и дорогое или сменить конструктора по ТЗ

а тригонометрию вы покупали ? а реализация сколько ячеек заняла ? для мк же оно ничего не стоит ни по софту, ни по ресурсам, т.е. реальный ноль - хоть $3 за 6 осей

Вот решение близко к идеальному. https://geektimes.ru/post/286324/

Сообщение отредактировал Jenya7 - Oct 29 2017, 12:27

Нет, CORDIC использовали условно-бесплатный для аппроксимации траектории между базовых точек. На самом деле это был жуткий колхоз, т.к сначала предполагалось использовать станок в режиме нарезания резьбы метчиками ( синхронная с вращением шпинделя подача по Z оси) но конструкторы промахнулись по моменту привода шпинделя). Тогда появилась идея с фрезерованием резьбы, но используемые контроллеры при интерполяции делали граненные отверстия, куда винты не вкручивались. И тогда была слеплена приспособа на ПЛИС которая в режиме step-dir рулила приводами в "ручном режиме" в цикле фрезерования резьбы, при этом грубая траектория прогружалась в виде таблицы снаружи, а ПЛИС занималась интерполяцией траектории и синхронизацией всех осей.
Я к тому, что это весьма специфический случай был и межконтроллерное взаимодействие ( каждая ось привода имела свой сервоконтроллер промышленный и отдельный контроллер оптической линейки) не справилось с задачей т пришлось лепить костыли. Если бы там был EtherCAT, то возможно бы и успели, но был обычный profibus.
Тут вся проблема, как делить петлю обратной связи относительно интерфейса и успеет ли она в риалтайме. Как пример картинка.

PS. http://www.iftomm2015.tw/IFToMM2015CD/PDF/OS13-011.pdf
Вот такое потяните в одиночку?

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


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


обычный profibus, это который медный на уарте ? ну ой, взяли бы хотя бы голый уарт, сильно урезавшись в хотелках, можно было организовать обмен, иначе никак
сразу ethercat - другая крайность, эзернета было бы достаточно, хотя да, это должен был быть точно не обычный эзернет, обычный легко может случиться медленнее чем profibus


да всё что угодно, буде время и деньги

Сообщение отредактировал Огурцов - Oct 29 2017, 14:20