cnc-club.ru

MX_Master писал(а):хороший вопрос, над которым предлагаю подумать в поисковиках самостоятельно

вот например https://github.com/synthetos/g2/blob/ed ... tepper.cpp
написано что 4.3 us в критической секции, и даже если это на 1 мотор, то для 3 это будет все равно больше 50КГц. или это не тоже самое?

4.3 мкс отнимает конкретный кусочек кода. В апельсиновом сопроцессоре такой же кусочек будет выполняться намного быстрее. Просто потому что у сопроцессора 450 МГц, а у кортекса M3 в среднем 72 МГц. Но я, честно говоря, не сильно понимаю зачем в МК телебонькать пины софтом, в то время как на борту есть аппаратные генераторы.

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

MX_Master писал(а):Откатываться никуда не надо Установщик устроен так, что отдельные компоненты можно переустанавливать парой команд за 6 секунд.

Пожалуйста, напиши мне эти команды, как будет доступна ускоренная часть.

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

Тест на 4-х часовой УП (рельеф) успешно пройден. Данный тест проводился для точного замера позиции в шагах. Считалось всё внешним счётчиком на STM32. В тесте было 3 оси, 1 шаг был равен 1-му микрону. В начале УП был вписан G код G64 P0.001 Q0.001. После выполнения УП и возврата в ноль, позиция осей плавает на +/-1 шаг. Что допустимо для преобразования чисел с плавающей точкой в целые.

Завтра соберу стенд из 57-ых шаговиков и TB6600. Проверю как оно работает в натуре. Если всё окажется пристойным, завтра же обновлю установщик новым драйвером и прошивкой.

Небольшой тест драйв нового драйвера и прошивки. Под рукой был только БП на 12V, поэтому раскрутить моторчики до сверх скоростей не получилось Есть БП на 48V, но что-то я стремаюсь столько подавать на этих малышей (TB6600). Вощем, пришлось убавить скоростя. Зато микрошаг 1/32 радовал своей тишиной. И поверьте мне на слово, частота вывода может быть намного выше 200 КГц. Просто, такой обычный драйвер как TB6600 не может её переварить.

https://www.youtube.com/watch?v=-N7UBLOjsFo

Более детальный тест на вибрацию (щупал руками) показал, что в драйвер надо добавить нормализацию вывода по ускорению. Планировщик LinuxCNC, несмотря на значение ускорения, иногда может дать приказ на вывод шагов в 1.5-2 раза больше, чем в предыдущем сервопериоде. Этот момент чётко чувствуется руками на шаговике.

MX_Master писал(а):Планировщик LinuxCNC, несмотря на значение ускорения, иногда может дать приказ на вывод шагов в 1.5-2 раза больше, чем в предыдущем сервопериоде.

Проверь разницу между заданием и фидбэком в соседних сервоциклах...

UAVpilot писал(а):Проверь разницу между заданием и фидбэком в соседних сервоциклах...

Проверять, скорее всего, не придётся. Наверняка, разница будет (время от времени). И, кажется, я знаю почему... Раньше в драйвере была корректировка времени каждого задания. А ща я её отключил

Дело в том, что программный вывод сопроцессора работает не точно. Он чуток запаздывает. При каждом шаге - где-то на 200-300 нсек. Проверено практическим путём. А я в драйвере делаю расчёты точно. Вощем, с каждого шага по задержке. И в какой-то момент их сумма вырастет до сервопериода (или больше). Мини буфер заданий переполнится, новое задание добавить будет нельзя. Фидбек при этом разойдётся с текущей позицией, а планировщик поддаст газу в следующем задании

Пошёл исправлять..

Т.е. получается что драйвер не согласовывает время между планировщиком и генератором который работает в сопроцессоре?

Уже согласовывает Провожу тесты..

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

Самая длинная правка общей памяти занимает порядка 2-3 мкс. И на больших частотах эти пинки отчётливо видны. Даю зуб на отсеченье, эти пинки можно будет руками ощутить прямо на шаговике. Вопрос - что можно предпринять для "уменьшения" данного скачка частоты?

Извините, если вопрос не в тему...
Никто не замечал проблем со стартом OrangePi при быстром передергивании питания, подаваемого через "гребенку"?
Суть: от ATX блока питания запитана макетка, на которой стоит OrangePi, куда подается +5В прямо от ATX блока питания. В OrangePi прошивка Android (но пока не будем на этом акцентировать внимание). Если снять питание, потом в течение нескольких секунд вернуть обратно, то чаще всего OrangePi, видимо, не может нормально инициализироваться - HDMI не работает (и наверное все прочее). А если выдержать хорошую паузу - запускается нормально.

У меня на макетке не обрабатывается сигнал ATX PowerOK, т.е. есть предположение, что происходит что-то нехорошее из-за медленного нарастания +5В. В схеме OrangePi супервизоров не вижу. Может, в этом дело?
Есть у кого-нибудь мысли?

MX_Master писал(а):Исправил вышеуказанный косяк Теперь резких рывков частоты по ходу вывода больше нет. И в целом, для программного вывода, осциллограмма выглядит очень даже хорошо Единственный мелкий скачок частоты, который действительно заметен в выводе - это задержка на правку общей памяти, когда добавляем новое задание в сопроцессор.

Самая длинная правка общей памяти занимает порядка 2-3 мкс. И на больших частотах эти пинки отчётливо видны. Даю зуб на отсеченье, эти пинки можно будет руками ощутить прямо на шаговике. Вопрос - что можно предпринять для "уменьшения" данного скачка частоты?

2020-04-28_144952.png

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

может сигналы вообще без сопроцессора выводить черед DMA напрямую на пины?

Argon-11 писал(а):Есть у кого-нибудь мысли?

У меня только одна мысль - питание должно быть правильным, стабильным и с запасом по мощности Это, всё-таки, не микроконтроллер.

avmartugin писал(а):буфер общей памяти один? если да, то можно двойной буферизацией как это сделано для DMA в контроллерах. половина буфера закончилась - переключение на другую половину - прерывание - заполнение законченной половины и т.п.

Там буфера, как такового нет. В общем куске памяти лежат все переменные, которыми пользуется сопроцессор. Когда ARM'у надо что-то в них поменять, он блокирует доступ с помощью переменной. Сопроцессор ждёт доступа в цикле (spinlock). Любой другой способ общения вызывает задержки на порядок больше чем 2-3 мкс.

avmartugin писал(а):может сигналы вообще без сопроцессора выводить черед DMA напрямую на пины?

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

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

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

Если нужен статичный ШИМ без подсчётов и в наличии весь GPIO порт, тада базару нет. А во всех остальных случаях - это геморрой

MX_Master писал(а):Вопрос - что можно предпринять для "уменьшения" данного скачка частоты?

Задержка ведь стабильна по времени? - Уменьшить длину первого импульса/периода на эту величину...

Argon-11 писал(а):У меня на макетке не обрабатывается сигнал ATX PowerOK, т.е. есть предположение, что происходит что-то нехорошее из-за медленного нарастания +5В. В схеме OrangePi супервизоров не вижу. Может, в этом дело?

Скорее из-за медленного спада. Как вариант: питание чипа успевает упасть до нуля, а например заряд конденсатора, подключенного параллельно ноге Reset не успевает разрядится - при подаче питания на чип он оживает в "неопределённом" состоянии, а сброса не происходит.

avmartugin писал(а):на хабре есть статья где пробовали генерировать шаги по DMA на старой малине, в целом у него получилось. хотя и критика в каментах была

Лучше почитайте эту тему для понимания сути, а то сейчас вы пытаетесь объяснить MX_Master'у, что большие частоты STEP никому не нужны и он это всё он зря делает...

Argon-11 писал(а):Суть: от ATX блока питания запитана макетка, на которой стоит OrangePi, куда подается +5В прямо от ATX блока питания. В OrangePi прошивка Android (но пока не будем на этом акцентировать внимание). Если снять питание, потом в течение нескольких секунд вернуть обратно, то чаще всего OrangePi, видимо, не может нормально инициализироваться - HDMI не работает (и наверное все прочее).

Снять питание на несколько секунд это как?
Физически разорвать провод от ATX блока питания или выключить блок питания, а затем его включить?
Если второе, то прошивка Android может воспринять медленный спад напряжения, как разряд батарейки и успеет
отправить "всех спать а дежурного оставить".
Т.е. при подаче напряжения, "находясь в неопределённом состоянии", от пользователя ожидаются физические действия
"нажать на кнопку", "ткнуть пальцем в тач". (По аналогии со смартфоном)

Я наблюдал такое поведение на устаревших оригинальных прошивках от производителя BananaPI

UAVpilot писал(а):

MX_Master писал(а):Вопрос - что можно предпринять для "уменьшения" данного скачка частоты?

Задержка ведь стабильна по времени? - Уменьшить длину первого импульса/периода на эту величину...

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

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