cnc-club.ru

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

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

Кстати появится еще вопрос что делать по возвращении из обработки прерывания.

1. На обработку прерывания уйдет какое-то время. Как его оценить.
2. Что делать, если данные поменялись? Заново запускать планировщик траектории?

На самом деле, появляется гораздо большее число вопросов К счастью, ответ на них несложен - натурный эксперимент. Ещё раз напомню его цель - повысить стабильность главного таймера emc2, к которому относится константа BASE_PERIOD. Сейчас он запускается по сигналу от аппаратного таймера компьютера (который на аналоге чипа 8254), перехваченному надстройкой realtime linux. Поскольку на этом же аппаратном таймере много чего висит, его показания оказываются нестабильны, если я правильно ситуацию понимаю. Предположим, latency-test показал латентность в 17000 (17 мкс) при BASE_PERIOD равном 25000. Это очень неплохой результат, но он означает, что по каким-то причинам один из тактов таймера может затянуться до 42000 нс (42 мкс), а другой (не обязательно следующий) выполниться за 8000 нс (8 мкс). С другой стороны, насколько я понял, сама emc2 отслеживает ситуацию, когда сигнал на начало следующего цикла приходит раньше, чем закончился предыдущий (попробуйте, например, задать слишком малое значение BASE_PERIOD, соответствующее заведомо недостижимому быстродействию, например 3000) система экстренно прекращается с рекомендацией подкорректировать BASE_PERIOD. То есть фактически в вышеприведенном примере все вычисления успевают выполниться за 8 мкс, иначе система зафиксировала бы сбой, а этого не происходит. Остается только грешить на точность таймера, который задаёт моменты срабатывания циклов. Поживём - увидим...

ИМХО если base_period=25мкс, а latency=17мкс, то тик таймера может быть от 25 до 42мкс. т.е. он может только увеличится, но не уменьшится.

Я все никак не могу понять такую вещь:
1. Если у нас n двигателей, то создается n realtime threads для вычисления задержек.
2. Как эти потоки не мешают друг другу если они все realtime?
3. Почему бы не обойтись всего одним потоком на все двигатели?

Моё ИМХО категорически не согласно с Вашим Сначала объясню теоретически - если тики таймера могли бы только растягиваться на величину латентности, то все генераторы частоты в emc2 безбожно сбоили бы в сторону снижения частоты, потому что, например, в секунде просто бы не помещалось нужное количество "растолстевших" тиков. На практике, с частотой генерации всё в порядке, имеет место быть только "плавание" фронтов - jitter. Практическое доказательство - latency-test это обычный скрипт, использующий простенький реалтаймовый компонент timedelta. Исправьте в нём строчки типа:
net bl timedelta.0.max => lat.bl на
net bl timedelta.0.min => lat.bl

на своём тестовом компьютере я вижу такой результат:
10521 16014 24645
то есть мин. тик 10 мкс, макс. отклонение 16 мкс, текущий интервал 24 мкс.

1. Нет, thread'ов всего два, независимо от количества двигателей - base и servo. Thread, как правильно Вами было замечено в первых постах, это такой же реалтаймовский Компонент, как и все прочие, включая арифметические функции, генераторы сигналов, и генераторы управляющих сигналов на двигатели. Эти thread'ы нужны только для хранения списка функций всех присоединённых к соответствующему потоку Компонентов, которые большую часть своей жизни спят. Любой thread большинство своего времени тоже спит, потом по сигналу от таймера realtime linux (на точность которого мы и клевещем ) просыпается, поочередно вызывает функции обновления всех присоединённых компонентов (в том числе и управляющих двигателями), они поочереди просыпаются, вычисляют что им там надо вычислить и снова засыпают.
2. Таким образом, потоки не мешают друг другу, потому что realtime поток только один. Компоненты не мешают друг другу, поскольку пока один компонент работает (вычисляет), другие просто спят
3. Поток и так один, а если обслуживать все двигатели одним Компонентом, то это будет противоречить самой идее HAL, а она действительно хороша.

Мне казалось, что я где-то прочитал, что максимальное количество потоков - 8 штук. И этим обусловлено максимальное количество осей - тоже 8 шт.

Да, на счет длительности интервала я был неправ.

Здравствуйте.
Использование аппаратного внешнего эталонного таймера чревато кучей проблем с правильной реализацией.
Однако такое решения на просторах интернета я встречал для Windows NT. В двух словах идея такая
В комп вставлена плата (PCI?,ISA? на фотке макетка была) с таймером и написан специальный драйвер. Ясное дело, что по таймеру вызывается этот драйвер Х-раз в секунду и записывает регистры контроллера движения. Там применялся внутренний ISA контроллер движений на 3 оси с микрошагом.

Теперь про RTAI jitter - мне до конца не ясна его природа. Что влияет на него больше всего?

1 При каких условиях (программных и аппаратных) джиттер минимален - т.е. отключить всякие кривые функции процессора и чипсета в ОС и БИОС выключить кривой софтмодем или сетевуху/звуковуху/видео.

2 Даст ли применение внешнего таймера уменьшение джиттера? Можно ли использовать для таймера простые устройства (порт PS/2, COM), какие ограничения? Какие прерывания желательно использовать? Какой частоты можно/нужно добиться?

3 Маленький джиттер важен для степ/дир приводов с большой частотой, если приметить что-то аналогичное PLUTO-P step - то EMC2 будет работать в режиме сервопривода, а степ/дир выдавать PLUTO-P с большей частотой чем LPT.

По идее нужно отключить все, что может вызывать системные прерывания.
В основном пишут о:

• SMI - System Maintenance Interrupt может сильно портить жизнь realtime процессам.
• не советуют использовать встроенные графические карточки.
• рекомендуют отключить все функции по сбереганию энергии, изменения частоты, входа в режим suspend и т.д.
• говорят об использовании опенсорс драйверов для видео вместо проприетарных

Можно попробовать запуститься в терминальном режиме и по-вырубать все не нужные процессы, а для управления станком использовать keystick - он работает из под консоли.
Кстати, проще всего будет запуститься в recovery mode при минимальных загруженных драйверах.
Сегодня постараюсь это попробовать и напишу изменения latency.

PS Alligator, есть ли прогресс с хардварным таймером?

Прогресса пока нет, ибо в командировке Для общего развития могу подкинуть цепочку событий, на которой основаны потоки в EMC. Самый Главный Цикл потока находится в функции thread_task (файл hal_lib.c). Она последовательно вызывает рабочие функции всех зарегистрированных для данного потока компонентов и вызывает rtapi_wait() (описана в файле rtai_rtapi.c). Эта функция важна тем, что именно она сообщает пользователю об ошибке в случае, если мы используем недопустимо малое значение BASE_PERIOD. Больше важного функционала у неё нет и она вызывает rt_task_wait_period() (файл api.c папки rtai). Эта функция вычисляет, в какое время нужно будет пробудить заснувшую thread_task, сохраняет его в каких-то глобальных переменных и вызывает rt_schedule() (описана в sched.c исходников realtime linux). Эта функция вообще вызывается где надо и где не надо по любому поводу. В ней вся логика реального времени, она определяет приоритет текущей задачи, сравнивает его с другими, вычисляет преемственность, она даже запрещает и разрешает аппаратные(!!!) прерывания в зависимости от атрибутов текущей задачи. Поскольку она решает глобальные проблемы, все данные хранятся во множестве глобальных структур данных. Дальше уже нужно плотно читать мануалы по rtai, а это уже те врата ада, в которые я не хотел бы входить

xentaur писал(а):Здравствуйте.
Использование аппаратного внешнего эталонного таймера чревато кучей проблем с правильной реализацией.

Кучей проблем чревато использование системы, которая работает по неизвестным, скрытым глубоко внутри механизмам. Я неплохо знаю устройство Windows, поэтому реализация в ней "реалтайма" для конкретной небольшой задачи (расчета осей) путём внедрения драйвера мне понятна. Кстати, та же Mach3 на Windows XP в плане джиттера выигрывает у EMC, но функционал, конечно, у неё гораздо скромнее.

Джиттер в EMC возникает ИМХО оттого, что на прерывании от аппаратного таймера компьютера висит множество служебных задач. Эти задачи в равной степени важны для функционирования всей системы, поэтому выполняются последовательно одна за другой. Всё это перемежается обработкой аппаратных прерываний. Удаляя "ненужное" железо и службы, вы фактически уменьшаете количество этих служебных задач. Но вы не властны над тем, какой по счёту в очереди стоит ваша задача, то есть emc. Если бы она всегда вызывалась первой при срабатывании аппаратного таймера, джиттер бы был несколько десятков наносекунд, а общее время исполнения всех служебных задач не изменилось бы. Просто у какой-нибудь другой задачи джиттер ухудшился бы.

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

Вряд ли это оно, но в Linux есть простенькая утилита, которая меняет приоритеты процессов.
nice - запустить команду с заданным приоритетом
renice - изменить приоритет процесса или группы процессов.
Приоритет имеет значения от -20 до 19 где -20 наивысший, 19 - самый медленный. Устанавливать приоритет меньше 0 может только root. Хотя, по идее, основные модули EMC2 и так должны стартовать с максимальным приоритетом.

Провел испытания Latency test под консолью получил Max Jitter 8000 ns и 1600 ns при различных приоритетах процесса!
Это при том, что под гномом я получал Max Jitter 25 000 нс.

Учитывая, что EMC2 можно запускать удаленно (TkEMC может управлять EMC2 запущенным на удаленной машине по ethernet) такой вариант нужно взять на заметку!

2 root:
Поздравляю с очередной победой на пути становления EMC понятной и доступной системой и 777 сообщением Кстати, не рассматривали вариант откомпилить под PuppyLinux? Есть подозрение, что латентность ещё улучшиться, очень уж Ubuntu жирная система...

Хммм раньше я думал, что Puppy - это тоже убунта. Оказалось нет. В википедии есть чумовая картинка с "генеологическим" деревом Linuxов http://upload.wikimedia.org/wikipedia/c ... dt1009.svg . Я 15 минут искал там Puppy, когда не нашел, начал искать на каком дистрибутиве он основан. Тоже не нашел. Тогда начал искать по году. Оказалось действительно собственный дистрибутив .

По латентности, врядли будет лучше чем в консоле, но наверняка лучше чем под Gnome. Можно еще попробовать запустить под Xubuntu, в ней по идее тоже должно быть быстрее.
Или, чтобы не компилировать, посмотреть какой-нибудь дистрибутив из потомков Ububtu или Debian.

Спасибо за поздравления, нужно будет это отметить .

Ухты, оказывается в той SVG из википедии все названия дистрибутивов это ссылки на их сайты и на них можно просто кликать! Вот народ постарался!

На самом деле весьма заманчивая идея. Были даже прецеденты. Один назывался coolCNC - live cd c предустановленным emc общим размером в 50 Мб. Делали немцы, развитие заглохло. Версия emc такая древняя, что ещё Стаханов имел шансы успеть на ней поработать Но моторчики гоняет исправно. Вот здесь http://wiki.linuxcnc.org/emcinfo.pl?Emc_Puppy описывается процесс сборки из исходников puppy и emc. К сожалению, человек сделать сделал, а дописать не дописал Сказал to be continued, гад...

Кстати, DSL (Damn Small Linux) сделан на основе Debian, возможно на него обычная сборка EMC2 встанет.

А на основе Puppy была сборка от Евгения из MagicCNC вот ссылка http://www.cnczone.ru/forums/index.php?showtopic=1074. Правда я так и не понял собрали ли они все до конца или нет.
Я раньше сильно ждал их сборку, т.к. у меня на десктопе из-за видео карты не работал Axis и ECM2 вылетал с ошибкой, для версий идущих с Ubuntu 8.04 и выше. EMC2 работал только тот который шел вместе с Ubuntu 6.06, что для меня казалось слишком старым. Но потом я открыл для себя TkEMC и забыл об этой проблеме .

Есть еще возможность к улучшению. Об этом написано в самом начале integrators manual. При выборе base period не обязательно его ставить равным сумме максимального времени сигнала контроллеру и latency. За счет выбора разных steplen и dirhold можно устанавливать количество периодов на один сигнал.

Например, если минимальная длительность сигнала смены направления 20мкс перед фактической сменой, минимальное время сигнала к шагу 2мкс, растояние между шагами 2 мкс и latency 17мкс, то можно установить dirhold на 2 а base period = (4мкс на шаг + 17 мкс latency) = 21мкс. Это значит, что на выполнение смены направления будет расходоваться 2 base period.

Хотя не совсем понятно, в integrator's manual написано, что в самом плохом случае, один base period может достигнуть 21-latency = 4 мкс а для установки направления ам нужно 20, поэтому возьмем два периода и можем быть уверенны, что их длинна будет больше 20мкс. По идее длинна двух периодов в рассмотренном случае может быть от 8мкс до 38*2=79 мкс... но вероятность этого мала...