cnc-club.ru

Bender писал(а):Есть ещё четырех-канальная микросхема преобразования ШИМ в напряжение LTC2645. Чтобы было всё линейно.!

Вот только выход у неё однополярный и проблема получения двуполярного напряжения -10..+10V остаётся стоять в полный рост...

MX_Master писал(а):Можно, канеш, юзать один пин ШИМ. Взяв за правило, что скважность 0-50% = -10В..0, а 50-100% = 0..+10В. Но что-то в этом способе мне не понравилось. Возможно, тот факт, что при любой скорости (даже 0) аппаратный таймер (вывод ШИМ) никогда не отдыхает.

Самый простой и логичный способ. Отдыхать таймеру ни к чему.
Наиболее существенный минус этого способа - то, что ноль будет существенно плавать вместе с питанием цифровой части МК. Но есть способы компенсировать это плавание.

UAVpilot писал(а):Нет, просто логику (2И, НЕ) и аналоговую часть из YAPSC.

Примерно так?

Примерно так.
Только зачем там резисторы по 10к в таком хитром включении? И зачем верхний конденсатор подключил не к земле как в оригинале, а к +5В?

UAVpilot писал(а):Только зачем там резисторы по 10к в таком хитром включении?

Это борьба с симулятором

UAVpilot писал(а):И зачем верхний конденсатор подключил не к земле как в оригинале, а к +5В?

Ашипка поправлена. Теперь всё так
Но симулятор эту схему из примитивов симулирует очень странно. Либо это я опять что-то не докрутил, либо симулятор хочет чего-то другого от схемы
Логическая часть (слева на схеме) отдельно ваще не симулируется. Хотя точь такая же логика в симуляторе протеуса заводится на ура.

Аналоговые и цифровые схемы стоит симулировать по отдельности в соотв. режиме симулятора...

Вопрос номер один. Случаем, не завалялся ли у кого на полке такой Ethernet Mach3 контроллер? Можем попробовать прикрутить его к LinuxCNC в качестве простой альтернативы моему варианту контроллера. Но, как я и говорил ранее, в этом китайском контроллере возможна только софт генерация шагов (200 КГц максимум). Второй вопрос. Будет ли такой китайский контроллер востребован пользователями LinuxCNC? Учитывая его параметры и цену.

Валяется такой) что то не подружился с драйверами совсем, дикие пропуски были, разбираться не стал, отложил на скучные времена (возможно по таймингам, фронтам/спадам не сошлись или ещё чего, такое чувство, что каша на выходе, но осциллографом не смотрел выход)

По мне так, если прошивку пошаманить, то он как готовая демо-плата неплох за свою цену беглым взглядом по плате - стандартно всё разведено, dc/dc, ethernet, разъемы все распаяны, и корпус с нанесенной распиновкой за недорого в общем)

Контроллер под LinuxCNC будет востребован . 200 кгц - это не мало .

vmarkiv писал(а):Контроллер под LinuxCNC будет востребован . 200 кгц - это не мало .

Ну хорошо, тогда попробовать можно.

hmnijp писал(а):Валяется такой) отложил на скучные времена

Отлично, значит, будем проверять на тебе

Но для начала надо мальца просечь поляну по выводу шагов. Китайцы довольно сильно промахнулись относительно аппаратных таймеров. Надо найти наилучший способ софт вывода согласно имеющейся разводке контроллера. Причём, сделать так, чтобы МК от возложенных задач не помер У меня есть пара макеток с STM32F407VET6 на борту. От F207 (что на контроллерах) они не шибко отличаются. Можно смело проводить тесты, занизив частоту МК до 120 МГц. На время тестов, кстати, LinuxCNC можем не трогать. Для проверки сделаю по быстрому веб морду с JOG кнопками для каждой оси и парой настроек.

Чем помочь?

vmarkiv писал(а):Чем помочь?

Пока ничего не надо.

Схему подключения МК нам хороший человек уже нарисовал - http://www.cnc-club.ru/forum/viewtopic. ... 0&#p377943. Cофт выводом шагов я особо не занимался. Поэтому методом научного тыка попробую подобрать для процессора самый лёгкий способ ногодрыга. Дело в том, что кроме ногодрыга, проц каждую миллисекунду будет общаться с LinuxCNC. Желательно, чтобы эти два процесса как можно меньше мешали друг другу. Если дело успешно выгорит, проверим промежуточный результат с веб мордой на тех, у кого этот контроллер есть. Для проверки желательно иметь на руках китайский программатор stlink v2 (2-3$).

На схеме по ссылке не разобрал что за микруха стоит на вывод шагов.Я использую с диф выходом типа max485.У меня расчет шагов внутри прерывания.Ethernet не использую ,у меня работа автономная.Но у него тоже прерывания или прямой доступ.Так что задержки конечно небольшие будут ,но не критичные.

У меня в автономном контроллере 3 канала с максимальной частотой шагов 131072 Гц (больше не требовалось). Тактовая частота МК (STM32F072) - 48 МГц. Расчет и вывод - по таймерному прерыванию. На входе - значение частоты в формате с фиксированной запятой, на выходе - последовательность STEP. На расчет и вывод 1 канала тратится 35-50 тактов (без использования ассемблера).
Остальные расчеты - скорость, ускорение, направление, датчики - по второму прерыванию, тоже таймерному, но более низкого приоритета и с периодом 1024 Гц.
Полагаю, реализовать 6 каналов по 200 кГц при тактировании МК 120 МГц можно будет без особого труда.
Но для меня, например, "темным местом" была бы реализация обмена по Ethernet в реалтайме.

Контроллер под LinuxCNC будет востребован . 200 кгц - это не мало !!!

sidor094 писал(а):На схеме по ссылке не разобрал что за микруха стоит на вывод шагов.

конвертер уровней 3.3-5V

Сергей Саныч писал(а):Расчет и вывод - по таймерному прерыванию.

Да, именно этим способом я и хотел попробовать.

Сергей Саныч писал(а):Но для меня, например, "темным местом" была бы реализация обмена по Ethernet в реалтайме.

Отправка и получение UDP сообщений вполне укладываются в миллисекундный сервопериод. Можно, канеш, ещё быстрее, но для этого нужно отказаться ото всех LwIP. И слать всё чистыми Ethernet пакетами по МАК адресу, без IP маршрутизации. Я испробовал оба способа, лично мне нравится голый Ethernet Правда, на нём веб-морду (tcp/ip) cделать намного сложнее, чем с помощью готового IP стека (LwIP). Так что в начале (для тестов) мы будем юзать LwIP + TCP + UDP, а в финальном варианте перейдём на чистый Ethernet

MX_Master писал(а):Отправка и получение UDP сообщений вполне укладываются в миллисекундный сервопериод.

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

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

MX_Master писал(а):Все процессы юзера и даже само ядро будет ждать пока мы работаем с конкретным драйвером.

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

Опыт плат mesa показывает, что усё успевается. Я потом, кстати, сделаю замеры по времени. На настольных платах и на orangepi.