cnc-club.ru

Скачаю LinuxCNC 2.8.0 Debian 7 Wheezy RTAI

это не влияет. Важно железо.
У меня на 245 АМД джиттер был 20-60. в среднем держался на 25к. мать ga-970. Работал, проблем не было. Иногда были сообщения о превышении джиттера, но реально проблем в работе станка не было.
При чем я пробовал свой X6 1055t на ga-880 - результат был как и на 245.

А подогнали какой-то интел тех же годов (мать + проц) - выше 10к не бывает. Ничего не менял по софту.

В очередной раз вышел из строя б.у. винт.. на смену ему был вытащен из ноута новый, но не самый надёжный (судя по результату поиска и чтения отзывов), винт Тошиба на 500Гб. Почему-то в упор плата GA-J1800n D2H не хотела стартовать с уже установленной системы... В итоге опять водрузил дебиан 9.9 + linuxcnc 2.9 + RT ядро. Выполнил действия по вышеприведённой на форум ссылки ... Оставлю часов на 5-6. .посмотрим, что поменяется.. Работать будет с месой 7i96.

Приобрел бу мини компьютер на базе mini-itx Atom D525. Установил Debian stretch 2.7.15 запустив latency test просто ужаснулся от цифр
max jitter servo thread показывал более 30 милионов , поигрался с настройками биоса, в загрузчике изолировал одно ядро, Latency стал меньше но все равно большой Биос в данном случае какой то урезанный нет возможности отключения режима энергосбережения 1CE а только выбор между 1s b 3s.
Перед покупкой прочитал данную ветку и специально искал данную материнскую плату. Вопрос можно ли еще как то снизить latency или низкие показания справедливы для старых дистрибутивов и на более свежих уже не актуальны?

成龙79 писал(а): ↑ Установил Debian stretch

А на дебиан виззи какие показатели?

成龙79 писал(а): ↑ Приобрел бу мини компьютер на базе mini-itx Atom D525. Установил Debian stretch 2.7.15 запустив latency test просто ужаснулся от цифр
max jitter servo thread показывал более 30 милионов , поигрался с настройками биоса, в загрузчике изолировал одно ядро, Latency стал меньше но все равно большой

В моём случае сильный вклад в джиттер вносил диск, причём даже SSD.
Когда поигрался с tmpfs, удалось получить приемлемые результаты.

А ещё, бывало, isolcpus прописывал без update-grub.
Причём, джиттер всё равно становился лучше. Чудеса!

Плата на базе J4005.
И ещё одна на целероне G540.

А вы когда isolcpus прописываете, потос latency-test на втором ядре запускаете?

成龙79 писал(а): ↑ Приобрел бу мини компьютер на базе mini-itx Atom D525. Установил Debian stretch 2.7.15 запустив latency test просто ужаснулся от цифр
max jitter servo thread показывал более 30 милионов , поигрался с настройками биоса, в загрузчике изолировал одно ядро, Latency стал меньше но все равно большой

Debian Wheezy покажет лучше джиттер.

rage писал(а): А вы когда isolcpus прописываете, потос latency-test на втором ядре запускаете?

Вопрос не понял, на плате 4х ядерный процессор пробовал изолировать по очереди с 0-1-2-3 результат одинаков +-. Если я правильно понимаю изолированное ядро отдается под реал тайм и на него не распространяются второстепенные задачи но по мнению компьютера более важные

alex_sar писал(а): ↑ Debian Wheezy покажет лучше джиттер

xenon-alien писал(а): ↑ А на дебиан виззи какие показатели?

На Wheezy результат гораздо лучше базовый период стартовал с двумя шестернями
7-8 тысяч через час 24000 через два три часа 44000

dimedved писал(а): ↑ В моём случае сильный вклад в джиттер вносил диск, причём даже SSD

Попробую заменить диск

成龙79 писал(а): ↑ Вопрос не понял, на плате 4х ядерный процессор пробовал изолировать по очереди с 0-1-2-3 результат одинаков +-. Если я правильно понимаю изолированное ядро отдается под реал тайм и на него не распространяются второстепенные задачи но по мнению компьютера более важные

Я немного не так понял, если выставить isolcups=1 (1 - это маска) система будет использовать первое ядро, и система запускает все процессы на 1-ом ядре. Это можно проверить посмотрев и посчитав список процессов запущенных на ядрах. У меня после выставления isolcups=1 (на 2-х ядреном проце) распределение ~170 процессов на 1 ядре и около 10 на втором.
Соответсвенно просто так запуская latency-test оно по умолчанию запустится на 1 ядре, на котором и так уже дофига процессов.

В общем isolcups это не какая то магия, которую "включил" и латенси разко упал.

Если не прав, прошу гуру линукса меня поправить. Я тольку начинаю осознавать глубину всех глубин

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

Оставлю свои показания.
Материнская плата EPoX EP-9NPA3J
Проц: AMD Athlon 64 3000+
Видеокарта NVIDIA GeForce FX 5200 128Mb
ОЗУ: 4Гб
SSD 120Gb

В итоге без всяких нагрузок, сугубо запущен test: Явно для работы станка этого будет не достаточно. ..


Существуют ли сейчас норм варианты в продаже? собираюсь подключать Eth контроллер.
слышал что ASRock Q1900M дает неплохие показатели. Правда ли это?

smart4on писал(а): ↑ собираюсь подключать Eth контроллер

если так, то не пофиг какой будет латенси, не?

rage писал(а): ↑09 фев 2021, 20:53

smart4on писал(а): ↑ собираюсь подключать Eth контроллер

если так, то не пофиг какой будет латенси, не?

Профан в этом деле, поправьте если не так.

В моем понимании латенси будет влиять на суммарное время обработки УП. Т.к. к каждой команде на перемещение (step и dir) будет добавляться значение латенси. В моем случае получается 30мкс...
Контроллер просто исключит задержки со своей стороны.

В вики видел следующий расчет:

smart4on писал(а): ↑ В моем понимании латенси будет влиять на суммарное время обработки УП. Т.к. к каждой команде на перемещение (step и dir) будет добавляться значение латенси. В моем случае получается 30мкс...
Контроллер просто исключит задержки со своей стороны.

Это не так. Если предыдущий сервоцикл длился, скажем, 1050 мкс, то следующий будет 950 мкс. Чтобы не выбиваться из общего RT графика. Чем меньше значение Latency, тем меньше перепады по времени между соседними циклами. И всё.

Для Ethernet контроллера эти перепады в 50-100 мкс погоды не делают. И управлять таким контроллером можно практически с любого современного утюга.

smart4on писал(а): ↑ Правда не понятно почему 16к шагов...? 1с = 1.000.000мкс => 1млн/31=32258 если поделить значение на 2 получим что написано в вики

Во первых: Эти расчеты относятся к программной генерации импульсов шага и выдаче их через LPT.
Во вторых: Авторы текста в Вики исходили из того, что для генерации одного импульса нужно два обращения к порту - одно выставляет потенциал на выводе, второе - сбрасывает. И соответственно, два цикла BASE_PERIOD.
На самом деле в LCNC есть возможность генерировать оба обращения за один цикл BASE_PERIOD.
Но в случае Ethernet-контроллера можно вообще обойтись без базовой частоты, оставив только SERVO_PERIOD 1мс.

Сергей Саныч писал(а): ↑ Но в случае Ethernet-контроллера можно вообще обойтись без базовой частоты, оставив только SERVO_PERIOD 1мс.

В случае отдельного контроллера с любым интерфейсом.
Например у Mesa они ещё бывают с PCI, LPT, SPI.

USB ?

MX_Master писал(а): ↑ USB ?

Плата есть, но в LinuxCNC не поддерживается.

Получается для использования ethernet плат все что меньше 1000000 это достаточно?

взял сборку на j1900 , в биосе отключил вообще все что было с тригерами, при нагрузке с часик тремя шестеренками и видео по вафле с ютюбчика, около 250000 серво