cnc-club.ru

Первые тесты на orangepi-pc2


RTT|  00:06:40  (user, 1000 us period, priority 98, CPU2)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|      0.284|      0.464|      7.198|       0|     0|      0.230|     59.404
RTD|      0.312|      0.481|      6.132|       0|     0|      0.230|     59.404
RTD|      0.271|      0.473|     12.356|       0|     0|      0.230|     59.404
RTD|      0.290|      0.462|      6.665|       0|     0|      0.230|     59.404
RTD|      0.275|      0.454|      4.224|       0|     0|      0.230|     59.404
RTD|      0.281|      0.468|      6.574|       0|     0|      0.230|     59.404
RTD|      0.316|      0.477|      8.257|       0|     0|      0.230|     59.404
RTD|      0.295|      0.461|      8.524|       0|     0|      0.230|     59.404
RTD|      0.288|      0.459|      6.458|       0|     0|      0.230|     59.404
RTD|      0.295|      0.470|      6.349|       0|     0|      0.230|     59.404
RTD|      0.311|      0.481|      6.575|       0|     0|      0.230|     59.404
RTD|      0.297|      0.466|      5.633|       0|     0|      0.230|     59.404
RTD|      0.323|      0.480|      6.858|       0|     0|      0.230|     59.404
RTD|      0.312|      0.478|      5.917|       0|     0|      0.230|     59.404
RTD|      0.312|      0.464|      5.725|       0|     0|      0.230|     59.404
RTD|      0.312|      0.468|      6.909|       0|     0|      0.230|     59.404
RTD|      0.274|      0.476|      6.009|       0|     0|      0.230|     59.404
RTD|      0.317|      0.480|      4.556|       0|     0|      0.230|     59.404
RTD|      0.312|      0.465|      6.709|       0|     0|      0.230|     59.404
RTD|      0.292|      0.463|      6.768|       0|     0|      0.230|     59.404
RTD|      0.271|      0.462|      6.576|       0|     0|      0.230|     59.404

RTT|  00:11:13  (kernel, 1000 us period, priority 98, CPU2)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|      0.555|      0.709|     14.342|       0|     0|      0.504|     26.432
RTD|      0.545|      0.690|     14.004|       0|     0|      0.504|     26.432
RTD|      0.550|      0.705|      5.334|       0|     0|      0.504|     26.432
RTD|      0.554|      0.709|     14.872|       0|     0|      0.504|     26.432
RTD|      0.548|      0.702|     15.451|       0|     0|      0.504|     26.432
RTD|      0.590|      0.710|      5.323|       0|     0|      0.504|     26.432
RTD|      0.573|      0.720|     13.069|       0|     0|      0.504|     26.432
RTD|      0.586|      0.707|     13.231|       0|     0|      0.504|     26.432
RTD|      0.565|      0.705|      4.228|       0|     0|      0.504|     26.432
RTD|      0.577|      0.726|     14.474|       0|     0|      0.504|     26.432
RTD|      0.549|      0.698|     12.720|       0|     0|      0.504|     26.432
RTD|      0.545|      0.714|      5.717|       0|     0|      0.504|     26.432
RTD|      0.545|      0.709|     11.296|       0|     0|      0.504|     26.432
RTD|      0.577|      0.699|     18.958|       0|     0|      0.504|     26.432
RTD|      0.570|      0.717|      9.163|       0|     0|      0.504|     26.432
RTD|      0.565|      0.689|     13.451|       0|     0|      0.504|     26.432
RTD|      0.551|      0.697|      4.197|       0|     0|      0.504|     26.432
RTD|      0.588|      0.715|     13.110|       0|     0|      0.504|     26.432
RTD|      0.549|      0.687|     13.023|       0|     0|      0.504|     26.432
RTD|      0.551|      0.704|      5.478|       0|     0|      0.504|     26.432
RTD|      0.563|      0.722|     12.557|       0|     0|      0.504|     26.432

RTT|  00:09:07  (irq, 1000 us period, CPU2)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|      0.669|      0.708|      1.284|       0|     0|      0.628|     15.281
RTD|      0.669|      0.711|      1.592|       0|     0|      0.628|     15.281
RTD|      0.670|      0.712|      1.734|       0|     0|      0.628|     15.281
RTD|      0.670|      0.712|      1.293|       0|     0|      0.628|     15.281
RTD|      0.669|      0.711|      1.560|       0|     0|      0.628|     15.281
RTD|      0.669|      0.711|      1.201|       0|     0|      0.628|     15.281
RTD|      0.669|      0.710|      1.593|       0|     0|      0.628|     15.281
RTD|      0.669|      0.711|      1.277|       0|     0|      0.628|     15.281
RTD|      0.669|      0.709|      1.585|       0|     0|      0.628|     15.281
RTD|      0.669|      0.712|      1.560|       0|     0|      0.628|     15.281
RTD|      0.663|      0.710|      1.577|       0|     0|      0.628|     15.281
RTD|      0.669|      0.709|      1.552|       0|     0|      0.628|     15.281
RTD|      0.669|      0.710|      1.986|       0|     0|      0.628|     15.281
RTD|      0.669|      0.710|      1.627|       0|     0|      0.628|     15.281
RTD|      0.670|      0.712|      1.603|       0|     0|      0.628|     15.281
RTD|      0.669|      0.711|      1.619|       0|     0|      0.628|     15.281
RTD|      0.670|      0.710|      1.595|       0|     0|      0.628|     15.281
RTD|      0.669|      0.710|      1.320|       0|     0|      0.628|     15.281
RTD|      0.669|      0.710|      1.253|       0|     0|      0.628|     15.281
RTD|      0.669|      0.710|      1.312|       0|     0|      0.628|     15.281
RTD|      0.629|      0.704|      1.287|       0|     0|      0.628|     15.281

dmesg

Код: Выделить всё

[    0.000000] IRQ pipeline enabled
...
[    1.196028] IRQ pipeline: high-priority EVL stage added.
...
[    1.199786] EVL: core started [DEBUG]

Очень даже неплохо.

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

Я на личном примере убедился. В паре миллиметров от этого минипк можно поставить бюджетную макетку с STM32. И всё, проблемы с latency больше нет

MX_Master писал(а): ↑ В паре миллиметров от этого минипк можно поставить бюджетную макетку с STM32

Михаил, а связь с STM32 по какому интерфейсу? ethernet? spi?

Вот что показывает cyclictest:

Код: Выделить всё

leo@orangepipc2:~$ sudo cyclictest -c 1 -t4 -p 98
WARN: cyclictest was not built with the numa option
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 0.06 0.08 0.08 1/124 7647           

T: 0 ( 7387) P:98 I:1000 C: 158554 Min:      7 Act:    8 Avg:   18 Max:  9947544
T: 1 ( 7388) P:98 I:1500 C: 105764 Min:      8 Act:    8 Avg:   21 Max:  994678
T: 2 ( 7389) P:98 I:2000 C:  78887 Min:      8 Act:   11 Avg:   37 Max: 100023333			???!!!!!???
T: 3 ( 7390) P:98 I:2500 C:  63468 Min:      8 Act:    8 Avg:   28 Max:  9954277
^C

leo@orangepipc2:~$ sudo cyclictest -x -t4 -p 98
WARN: cyclictest was not built with the numa option
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 0.00 0.02 0.02 1/123 7677          

T: 0 ( 7650) P:98 I:1000 C:1132062 Min:      9 Act:   10 Avg:   12 Max:     848
T: 1 ( 7651) P:98 I:1500 C: 754707 Min:     10 Act:   11 Avg:   12 Max:     471
T: 2 ( 7652) P:98 I:2000 C: 566030 Min:     10 Act:   11 Avg:   13 Max:     602
T: 3 ( 7653) P:98 I:2500 C: 452824 Min:     10 Act:   11 Avg:   12 Max:     558

going писал(а): ↑ ethernet? spi?

В двух миллиметрах - SPI, а в двух метрах - Ethernet. Я сначала пошёл по пути с SPI. Ничего лишнего, скорость, простота кода. Но вовремя опомнился. Дело в том, что минипк даёт просадку универсальности. Стоит только открыть GUI посложней и всё, тушим свет, расходимся. Если нет аппаратного видео, которое тянет все хотелки, то и малые значения Latency будут не в радость.

MX_Master писал(а): В двух миллиметрах - SPI, а в двух метрах - Ethernet

Это означает, что мы должны иметь на этих интерфейсах гарантированное время отклика (передачи - приёма пакета данных).
Или задержка в передаче пакета не может быть больше чем ХХ.ХХХ (наносекунд\миллисекунд) сколько?

Сейчас я тестирую соединяясь с платой по ssh (ethernet). Заметил глазом задержку при передаче данных.
Я точно знаю, что каждая строчка в тесте выводится\печатается один раз в секунду.
Но изредка, вывод подвисает, а потом сразу печатается две или три строчки.

1 - Маршрутизация. 2 - TCP/UDP. 3 - Ethernet драйвер тоже не мгновенный. 4 - код отправки/получения пакета занимает время. 5 - аппаратная отправка/получение.

Я убирал первые два (raw Ethernet), тогда последние занимали менее 50 мкс. Плюс в МК крутится свой сервоцикл, которому всё равно, когда приходят пакеты.

Для SPI этот список вдвое меньше. Но привязка к минипк обязательна, настольные компы в пролёте.

MX_Master писал(а): Плюс в МК крутится свой сервоцикл, которому всё равно, когда приходят пакеты.

Даже если пакеты будут приходить с задержкой ~1 сек?

Я хочу оценить, какую максимальную задержку мы можем позволить.

Если в МК есть "сторожевой пёсик" и он не меньше этой секунды, то МК будет молотить поставленные задачи не меньше этой секунды. Но секунда - это слишком большой обрыв связи, по всем параметрам. Конечно, всё зависит и от реализации задач внутри МК. Если степген в МК сам рулит ускорениями и следит за концевиками, то при обрыве связи оборудование не пострадает, даже без "сторожа". А если степген в МК - это обычный частотный генератор, то 1 секунда без связи может увезти станок в закат

Обычно сервоцикл 0.001с составляет при работе с платами mesa по Ethernet. Вроде это считается норм. Станок в случае ошибки связи до заката не уезжает).

Для проверки, попробуй выдернуть Ethernet кабель на полном ходу станка. Если станок остановится резко, значит, в прошивке месы простой частотный генератор + "сторожевой пёсик".

У меня был сбой связи, я это уже проверил самопроизвольно). Почему то raspberry pi4 иногда ругается на ошибку связи, ну это бывает практически сразу после вкл EMC. Повторный запуск вроде решает эту проблему.... Пока причины не понял.

antoxa-kylibin писал(а): Обычно сервоцикл 0.001с

Хорошо. Будем держать эту цифру в уме. И я не имел ввиду разрыв связи, а только задержку в отправке пакета.
В ядре EVL реализована поддержка отправки пакетов UDP на внеполосной стадии, т.е. обходя общую очередь.
Я хочу это протестировать.

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

going писал(а): ↑ Даже если пакеты будут приходить с задержкой ~1 сек?

Я хочу оценить, какую максимальную задержку мы можем позволить.

При использовании Ethernet происходит уже не жёсткая генерация (например как LPT), а управление с помощью PID.

То есть мы отправляем на контроллер (ethernet) данные с PID (скоростью на которой нужно двигаться).
Далее получаем текущее положение и отправляем его в PID далее корректируется скорость... итд...

Задержка может быть и 1 секунда. Здесь вопрос как жёстко мы будем контролировать положение и какие ускорения будем использовать. И соответственно какая ошибка(положения) допустима..

MX_Master писал(а): ↑22 май 2022, 14:21 Для проверки, попробуй выдернуть Ethernet кабель на полном ходу станка. Если станок остановится резко, значит, в прошивке месы простой частотный генератор + "сторожевой пёсик".

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

wldev писал(а): ↑ Изучал драйвер-компонент месы.
У них на стороне LCNC есть свой степген, который не даст выйти за пределы скорости и ускорению двигателя. И только потом он передаёт частоту на которой нужно передвигаться. То есть сама меса это генератор+счётчик...
То есть если выдернуть шнур то всё должно встать колом, после срабатывания сторожевого...

В таком подходе есть положительный и отрицательный нюанс. Положительный - простота реализации. Отрицательный - задержка реакции на простые входящие сигналы. Я эту задержку наглядно заметил, когда перекинул чтение сигналов концевиков с основного цикла на сервоцикл. Пришлось сбавить скорость поиска дома. Не знаю как в прошивке месы, но, желательно, чтобы МК мог обработать сигналы с концевиков сам. И ещё до отправки этих данных остановить соответствующие генераторы сигналов.

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

Скорость реакции нажатия на кнопки может быть незаметна глазу аж до 10мс. А я говорил про сравнение реакции в 1мс и 50мкс. Такие тонкости только электронике под силу различить.

а вообще что дает более короткий сервопериод? Ну понятно что частота опроса контроллера компом увеличивается, но по сути какое это преимущество дает на выхлопе?

cnc-club.ru

Xenomai + LinuxCNC, EVL + LinuxCNC из исходников

Re: Xenomai + LinuxCNC, EVL + LinuxCNC из исходников

Re: Xenomai + LinuxCNC, EVL + LinuxCNC из исходников

Re: Xenomai + LinuxCNC, EVL + LinuxCNC из исходников

Re: Xenomai + LinuxCNC, EVL + LinuxCNC из исходников

Re: Xenomai + LinuxCNC, EVL + LinuxCNC из исходников

Re: Xenomai + LinuxCNC, EVL + LinuxCNC из исходников

Re: Xenomai + LinuxCNC, EVL + LinuxCNC из исходников

Re: Xenomai + LinuxCNC, EVL + LinuxCNC из исходников

Re: Xenomai + LinuxCNC, EVL + LinuxCNC из исходников

Re: Xenomai + LinuxCNC, EVL + LinuxCNC из исходников

Re: Xenomai + LinuxCNC, EVL + LinuxCNC из исходников

Re: Xenomai + LinuxCNC, EVL + LinuxCNC из исходников

Re: Xenomai + LinuxCNC, EVL + LinuxCNC из исходников

Re: Xenomai + LinuxCNC, EVL + LinuxCNC из исходников

Re: Xenomai + LinuxCNC, EVL + LinuxCNC из исходников

Re: Xenomai + LinuxCNC, EVL + LinuxCNC из исходников

Re: Xenomai + LinuxCNC, EVL + LinuxCNC из исходников

Re: Xenomai + LinuxCNC, EVL + LinuxCNC из исходников

Re: Xenomai + LinuxCNC, EVL + LinuxCNC из исходников

Re: Xenomai + LinuxCNC, EVL + LinuxCNC из исходников