Что дальше ?

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

miniEMC2 - что к чему.

Итак, почему именно Linux и EMC2? Начнем с того, что сделать сколько-нибудь приличный интерпретатор G-кода с нуля - задача не из простых и автор вряд-ли бы взялся за это в качестве хобби. Однако все-таки хотелось реализовать все попроще и дешевле. Ему даже удалось втиснуть урезанный EMC2 в простенький ARM7 без всякой ОС ( спасибо зарубежным товарищам, подробнее смотрите здесь ), но все-таки это его не устроило по разным причинам. И в первую очередь из-за того, что производительности и памяти хватало как раз впритык. Впрочем, это было уже более двух лет назад, возможно сейчас можно продолжить изыскания используя, например, последние Cortex-M3 от ST.  Но автору пришла мысль все-таки использовать полноценный EMC2 и более мощный процессор, ну и Linux конечно. Выбор остановился на mini2440 в виду ее широкой распространенности и небольшой цены. Первые эксперименты со сборкой EMC2 под эту платформу показали, что в режиме эмуляции реал-тайм производительности хватает с запасом ( это для EMC2 2.2.0, с версией 2.4.0 он уже не справился). Имеется ввиду, что работал только интерпретатор и интерполятор, HAL отключалась, GUI отсутствовала...работал только через TkEMC на ПК.  Далее встал вопрос - как же реализовать режим реального времени, чтобы  генерировать шаги с необходимой скоростью и точностью ? Решение пришло неожиданно. Просматривая исходный код ядра от gta02 автор обнаружил там интересный трюк, а именно обработчик FIQ от таймера. Fast Interrupt ( FIQ ) сродни обычным прерываниям, однако их скорость реакции несколько выше. И что самое главное, эти самые FIQ не имеют никакой инфраструктуры в Linux. IRQ обернуты в специальные обработчики и демультиплексоры и в любой части кода ядра их можно запретить. FIQ наоборот нигде не используются, не запрещаются и они не прерываются ни одним из обычных IRQ. Таким образом они вполне подходили на роль псевдо-системы жесткого реального времени. Замеренная скорость реакции была около 1-3 микросекунды, что было достаточно для начала экспериментов. Но это только часть проблемы, вторая часть заключалась в том, что надо обеспечить еще и менее жесткий реал тайм для вычисления траектории движения. Тут как раз все оказалось сложнее и долгое время не удавалось найти решение. Пока наконец разработчики Xenomai не добавили поддержку нашего процессора. Тесты показали время отклика процесса, использующего Xenomai, порядка 100 микросекунд при серьезной нагрузке на подсистему ввода/вывода. Это было очень неплохо и в результате была создана следующая структура EMC2 для mini2440:

Функциональная схема miniEMC2

Motion controller и IO controller это стандартные части EMC2, после них идет работа непосредственно с оборудованием. IO controller работает в User space, т.к. время реакции для него не очень критично. Motion controller это уже часть HAL ( в терминах EMC2) и должен работать в реальном времени, т.к. он генерирует поток координат для перемещения с периодом сервоцикла. Его обычно выбирают равным 1ms, т.е. точность попадания в этот цикл около +/-10% ( 100uS =10% от 1ms ). Этого все еще недостаточно для наших целей, поэтому пришлось ввести очередь координат. Но сначала давайте рассмотрим новый, нестандартный HAL компонент, который носит название miniemcdrv.so Это компонент специально предназначен для работы на нашей платформе. Он совместно с FIQ-обработчиком выполняет функции, которые на обычных ПК делают модули Stepgen вместе с Parport. Т.е. в задачи  miniemcdrv.so входит прием потока координат от Motion controller, формирование значений для синтезаторов частоты, PI-регулятор позиции.  Кроме того он обеспечивает опрос дискретных входов контроллера  ( GPIO ). Его основной цикл вызывается с периодом сервоцикла, т.е. через 1 ms. На самом деле период сервоцилка выбран чуть меньше, чем 1mS - это связано с "очередью координат".  Выходные данные miniemcdrv.so помещаются в специальную область разделяемой памяти и оттуда они доступны обработчику FIQ.  Последний вызывается с периодом 10uS обеспечивая тем самым максимальную скорость шагов на уровне 50 кГц. Внутри обработчика происходит непосредственно синтез частоты и управление всеми цифровыми выходами. Так-же он предоставляет текущую позицию для каждой координаты(т.е. число уже сделанных шагов), которая учитывается в PI регуляторе позиции miniemcdrv.so.

Теперь об "очереди координат" или точнее об очереди заданий для синтезаторов частоты. Собственно это такой буфер, в котором хранятся вычисленные и готовые к выполнению значения для генератора частоты. Если при возникнут непредвиденные задержки на уровне User space, то FIQ будет иметь какое-то количество работы выбирая данные из этого буфера. Это позволяет нам справиться c относительно большим временем реакции Xenomai. Этот буфер заполняется в miniemcdrv.so  до того, как успевает опустошаться в обработчике FIQ из-за чуть меньшей длительности сервоцикла. Когда буфер заполнен, miniemcdrv.so сигнализирует Motion controller временно приостановить вычисление координат.  

Как несложно догадаться, такая схема создает один недостаток, иногда весьма существенный: текущее положение двигателя всегда отстает от вычисленного на время, равном N*1ms. Где N - размер буфера. По умолчанию этот размер равен 32, т.е. задержка равна 32 mS. Это значение может быть уменьшено до 2. Если вы не планируете запись на SD или USB карту по FTP во время работы станка, то размер буфера можно смело устанавливать в 8 и менее. Если-же вы хотите большей защищенности вашей системы, то лучше его не менять. Когда чреват слишком большой размер буфера? Автор знает только одну сложность: позиционирование по конечным выключателям, т.е. когда станок продолжает движение в течение времени N*1ms, даже если сработал концевик. Если для вас крайне критично, чтобы 0 располагался именно там, где это задумано, то вам не стоит использовать это устройство. Если же допускается некоторый уход от заданной концевиком позиции, то думается что более проблем возникнуть не должно.
     Автор надеется, что немного прояснил особенности архитектуры системы. Теперь несколько слов о том, почему нет дисплея и тачскрина. Автор более всего хотел реализовать полностью автономное устройство, но увы все эксперименты провалились.  Сначала он работал с 3.5" экраном и реализовал небольшой GUI на QT2.3, но эксперименты на реальном оборудовании показали все неуместность столь крошечного дисплея с тачскрином и стилусом на производстве. В результате было решено использовать 7" дисплей. Но результаты оказались еще хуже. Из-за того, что он имел большое разрешение, отнималось порядка 30% пропускной способности у памяти. Плюс к тому контроллер тачскрина у чипа S3C2440 явно не рассчитан на такой большой дисплей. Выражалось это в том, что он ловил ложные срабатывания, порой показывал нажатие  совсем не в том месте, где это требовалось. Автор приобрел дополнительные тачскрины от для проверки - результат был тот-же. Ну и все вместе это давало ужасную картину едва шевелящегося GUI, который при этом еще и работает как попало.  Если учесть, что стоимость такого экрана порядка 90$, то стало понятно что игра не стоит свеч. Было решено просто расширить функциональность прибора, позволив пользователю управлять им через WEB интерфес с любого устройства. Если удастся добиться устойчивой работы WI-FI, то ситуации с подключением значительно упростится. Например, самый дешевый китайский планшетный ПК уже стоит меньше, чем 7"  экран для mini2440.
Ну и напоследок, для нормальной работы mini2440 с контроллерами ШД крайне желательна плата согласования уровней. Автор планирует разработать нечто подобное, если в том будет необходимость у заинтересованных лиц.

Чем это лучше компьютера ?

    Такой резонный вопрос вполне уместен и понятен. Ответ прост: ничем не лучше и не хуже, это просто альтернатива. Если вы успешно используете MACH3 или нечто подобное, то значит вам повезло с выбором железа для вашего ПК. Автору же повезло меньше, поэтому и возникло желание сделать что-либо альтернативное. 

    В мире простых станков с ЧПУ сейчас поголовно используются обычные настольные ПК с утановленной в них картой дискретного ввода/вывода. Чаще всего это LPT порт, реже специализированные параллельные ( или даже USB ) модули ввода/вывода. LPT при этом один из самых популярных интерфейсов, поскольку присутствует во всех старых материнских платах. Для современных ПК есть PCI -платы расшиения. Схема подключения к контроллерам шаговых двигателей банально проста ( теоретически ): на каждый двигатель нужно минимум три сигнала: ШАГ, НАПРАВЛЕНИЕ и общий провод. На выходе ШАГ формируются импульсы, которые заставляют провернуться двигатель на определенный угол, который пропорционален количеству этих самых импульсов. Выход НАПРАВЛЕНИЕ соответсвтенно определяет в какую сторону двигатель вращается. Как не трудно догадаться скорость вращения вдигателя определяется частотой импульсов ШАГ. Таким образом нашему компютеру необходимо выдавать импульсы с определенной максимальной частотой и, что не менее важно, с определенной равномерность следования этих импульсов. Критерии частоты и точности являются решающими для надежной работы шаговых двигателей (ШД).

    С компьютером разобрались, теперь о программном обеспечении. В данный момент получили распространение две системы ЧПУ: MACH3 и LinuxCNC (EMC2). Поскольку MACH3 является коммерческим ПО, то не хотелось-бы здесь разводить анти-рекламу. Просто скажем, что разработчикам нужно еще хорошо поработать над своим ПО, что-бы оно действительно достойно работало в таких ответственных приложениях, как ЧПУ. EMC2 наоборот подкупает своей открытостью и возможностями, что в принципе переходит в разряд недостатков для того, кто не желает вникать в Linux глубоко. Да и пользовательский интерфейс у EMC2 еще очень сильно отстает от того-же MACH3.

    Эти системы имеют своих ярых поклонников и противников в силу двойственности нашего мира :). Хотелось лишь остановиться на основной проблеме, присущей, на мой взгляд, обеим системам. Это проблема стабильности и частоты генератора шагов. Она в общем не зависит от самой программы управления, но зависит от операционной системы и используемого железа. ОС общего применения как правило не гарантируют более менее точных временных интервалов, т.к. для обычного пользователя это не нужно. Поэтому разработчики ПО для ЧПУ используют разные методы для создания генератора шагов. MACH3 предоставляет свой собственный драйвер, который обеспечивает, по мнению разработчиков, стабильность работы генератора шагов. Разработчики EMC2 используют другой подход, а именно они используют специальную ОС  реального времени, одной из задач которой является OC Linux, а другой задачей как раз наш генератор шагов.  И это работает и довольно неплохо, но...тут нас поджидает другой сюрприз, имя которому SMI ( System Management Interrupt). По сути это такой способ обходить аппаратные проблемы чипов программным путем.  Для нас это чревато тем, что этот обработчик ошибок может быть вызван аппаратно, прервав любой другой процесс на довольно длительное время, что может нарушить работу генератора шагов. Тут есть одна лозейка - можно запретить эти SMI вообще если правильно сконфигурировать чипсет. Что и сделали разработчики RTAI, но при этом ,во первых, возникают ошибки, которые обрабатывал-бы SMI, а во-вторых ,по некоторым сведениям, запрет SMI может привести к выходу из строя железа на некоторых чипсетах. И еще одна неожиданная проблема - смена поколений чипов приводит к тому, что не все источники SMI могут быть замаскированы довольно старым и медленно развивающимся RTAI. Поэтому никто не сможет гарантировать, что там или иная комбинация компонентов ПК будет гарантировано хорошо работать в качестве стабильного генератора шагов.  К своему стыду автор не знает как проблема SMI решена ( и решена-ли) в MACH3, но есть подозрение что там все ни чуть не лучше, чем в Linux.

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

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

В следующей статье речь пойдет о том пути, который привел автора к данному решению.

Контроллер ЧПУ для любитетей и не только.

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

Цель: Перенос  Enhanced Machine Controller (http://linuxcnc.org/)  версии 2.2.0 на недорогую ARM-платформу. В качестве этой платформы будет предложена плата mini2440, как одна из недорогих плат для разработчиков, имеющая при этом неплохое оснащение.

Целевая группа проекта: в основном ориентировано на любителей мастерить станки с ЧПУ дома. Возможно блог будет интересен так-же производителям простых станков с ЧПУ.

Конечный результат:  В итоге должен получиться контроллер ЧПУ, способный выполнять пользовательскую программу (G-код) с SD-карты или USB-диска. Выходными сигналами контроллера являются импульсы ШАГ/НАПРАВЛЕНИЕ для контроллеров шаговых двигателей ( или сервоприводов работающих в этом режиме).  Наш контроллер, назовем его miniEMC2, не будет иметь своего дисплея, все управление будет осуществляться с ПК через WEB-интерфейс, либо через TkEMC. Поделючение к ПК через Ethernet, либо через WI-FI.

Основные характеристики:

• До 6 одновременно обрабатываемых осей;
• Максимальная частота импульсов шага: 40 кГц;
• Количество дискретных входов: 16;
• Количесвто дискретных выходов: 20;
• Количесвто каналов ШИМ: 2;
• Каждый выход может быть настроен как на управление двигателем (ШАГ или НАПРАВЛЕНИЕ), так и в качетсве дискретного выхода с возможностью управления из G-кода;
• Каждый вход может быть использован либо в качестве функционального входа ( концевики, кнопки), либо как вход общего применения;
• Возможность подклюения USB клавиатуры для управления перемещением по осям в ручном режиме;
• Возможность подключение пульта управления к дискретным входам;
• Возможность подключения USB flash driver для загрузки управляющей программы;
• Загрузка управляющей программы по FTP и через WEB-интерфейс;
• Полное управление и конфигурирование через WEB-интерфейс;
• Возможность использования ( с некоторыми ограничениями ) стандартного для EMC2 GUI - TkEMC ( только для Linux OS).
• WI-FI интерфейс в режиме клиент/точка доступа для управления с "планшетов" и ноутбуков ( и телефонов, возможно).

Что будет доступно желающим повторить: 

• образы загрузчика, ядра и файловой системы вместе с инструкцией по установке;
• исходных код некоторых частей проекта, а именно все, что подпадает под GPL лицензию: загрузчик, ядро Linux, модифицированный EMC2;
• Обновление ПО, если будет такая необходимость со стороны пользователей;

Более подробно обо всем в cледующих статьях.