Emc Под Friendlyarm, EMC под FriendlyARM Опции

[halkru]

Кто то пытался запустить ЕМС под FriendlyARM?
Полгода назад отдали комплект в Питер, какой-то институт, парень не смог ... говорит не поднимается реал тайм на этой архитектуре..
По нашему замыслу получился бы неплохой наладонный пульт управления..

[halkru]

Будут серьезные предложения найдем еще комплект для "добивания вопроса"...

[starik99]

Будут серьезные предложения найдем еще комплект для "добивания вопроса"...

вы не с того конца зашли... Тут будет многоходовка :)
1. Нужно перевести ЕМС на xenomai (все еще на Х86)
2. Поднять xenomai на вашей борде (а правильнее все-таки на чем-нибудь класса Бигля) -- xenomai, в отличие от RTAI поддерживается в том числе и на ARMе.
3. Поднимать ЕМС на этой борде.

[Евгений]

А зачем?

[at90]

А зачем?

Ну типа недорогой автономный контроллер!

[valorsp]

на форуме linuxcnc.org ктото поднимал уже данную тему, все уперлось в переписывания части работы с портом из lpt в gpio но вроде как вполне реально? есть пара этих самых mini 2440 если кто что соберет в плане софта могу попробовать запустить. минька стоит на ебее от 80 долларов с 3 дюймовым экраном и гдето от 120 с 7 дюймовым

Сообщение отредактировал valorsp - 21.12.2010, 20:50

[halkru]

Эту тему поднимали многие... но решения на сегодня нет. GPIO - это вторично.. надо поднять реал тайм и с ЕМС определить латенси для оценки производительности и дальнейшей перспективы этого направления, вполне возможно 400мгц не вытянет.

[Евгений]

Ну типа недорогой автономный контроллер!

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

Кроме того по моим оценкам Axis по любому не запуститься, маловато все таки 400 Мгц то для GUI

[valorsp]

френдлиарм на с 7 дюймовым дисплеем (тачскрин) стоит 200 $
на томже linuxcnc.org в темах написано что сам linux с rtai было скомпилировано и проведен latency test и результаты были довольно приличные, 400 мегагерц для арм архетектуры примерно тоже самое что 1300 для х86 по производительности.

Сообщение отредактировал valorsp - 18.1.2011, 17:57

[serg_io]

френдлиарм на с 7 дюймовым дисплеем (тачскрин) стоит 200 $
на томже linuxcnc.org в темах написано что сам linux с rtai было скомпилировано и проведен latency test и результаты были довольно приличные, 400 мегагерц для арм архетектуры примерно тоже самое что 1300 для х86 по производительности.

Занимаюсь подобным "рукоделием" в свободное от работы время. Изучив вопрос, понял что портировать RTAI самому довольно проблематично, поэтому искал другой выход. Сначала собрал EMC 2.2.0 в Simulation mode просто посмотреть что из этого выйдет. Все консольное собралось, все что GUI естественно нет и не было такой цели. На mini2440 запустилось (в user space конечно), та часть, которая реалтаймовая, отъедает 15-20% ресурсов ЦПУ, и это с частотой цикла 1 ms. Поэтому пытаться портировать RTAI и выжать что-то из стандартного Stepgen с гораздо меньшим периодом цикла мне показалось бессмысленным. Долго искал путь, продумывал варианты внешних stepgen на SPI шину. Но в конце концов нашел более оригинальное решение с использованием FIQ от Таймера и на нем сделал DSS для генерации шагов - максимальная частота выходит 50 кГц. В общем и целом работает, но есть несколько нюансов: 1) Поскольку планировщик траектории работает в User space и никто не гарантирует что он будет вызван ровно через 1ms, то пришлось организовывать FIFO для координат. А это значит задержку примерно на 32ms, что в общем-то не проблема но есть нюансы - например пролет позиции при позиционировании по концевикам. Хотя при небольших скоростях это не особо критично, имхо. 2) Во время работы по программе нельзя писать на SD или на USB stick( например через FTP) - драйвера сих девайсов намертво убивают мой псевдо-реалтайм на FIFO. Что в общем тоже не очень большое ограничение, главное запретить юзеру делать это в неподходящее время.
Подводя итог, можно сказать что идея в общем и целом реализуема, но много чего нужно сделать.

Вот делали видео

PS: GUI делаю свое, на QT.

[Евгений]

PS: GUI делаю свое, на QT.

Это супер, и желательно что бы оно было совместимо со стандарной версией а не тока на АРМ ;-)
Вот за это пол мира спасибо скажет :)

[mycnc]

Будут серьезные предложения найдем еще комплект для "добивания вопроса"...

Не хотите FriendlyArm + myCNC-UP3 ?
Удорожание на usd300.
Наш GUI на Линуксе. Под ARM должен портироваться без вопросов.
Быстродействие не важно, так как интерполяцией занимается контроллер.

[CNC_User]

Не хотите FriendlyArm + myCNC-UP3 ?

Это интересно! Только не очень понятно, для чего тогда тут нужен FriendlyArm?
Логичнее подключать ваше устройство сразу к PC, а не через какое-то, в данном случае, пятое колесо , ведь для нормальной работы, всеравно, без PC не обойтись, я правильно понимаю?
Плата с USB интерфейсом, это конечно баловство, а вот с Ethernet, это самое оно!

А сколько стоит с Ethernet-интерфейсом, и какие параметры?

[mycnc]

Если не нужен GUI, то можно запускать вообще автономно.
Если GUI нужен, то он есть под Windows, Linux (x86), MacOS

GUI не требует реал=тайма и может быть запущен на разнообразном железе.

Предложение было на тему собрать GUI под Linux для ARM и запустить на этой железяке.
Похоже - интереса не вызвало.

По поводу цен - есть сайт, личка и тд

[CNC_User]

Если не нужен GUI, то можно запускать вообще автономно.

Я даже не представляю себе работы без интерфейса.

Мне кажется, что работа без интерфейса совершенно лишена смысла, т.к. компьютер все равно у всех есть (а на чем тогда делают макеты, а?) и почему, бы его не задействовать для GUI?

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

GUI нужен однозначно!

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

[ponyatov]

а не рассматривался порт EMC2 под eCos (вместо линукса) в 2х вариантах: i386 комп или ARM9 железка на выбор ?

[CNC_User]

Под что-то другое, весь EMC2 портировать это скорее всего - нереально, да и кто потом это всё будет тестировать, поддерживать, координировать?
А вот портировать RT-подсистему под ARM+Linux, и затем прицепить туда EMC-код (в Линуксе штатно есть поддержка ARM-процессоров), и затем передать это всё разработчикам EMC2, которые доведут это всё до ума и обеспечат поддержку - это вполне реальный путь.
По поводу, что портирование - это реальный путь - да это реальный путь, но только, неизвестно какая длина этого пути (это могут сказать Linux-программисты), может быть это тоже нереальный путь (см. об этом в начале этой темы).

Думаю, что такие мысли были и у создателей EMC2, ведь они сами сталкивались со всеми проблемами архитектуры x86 (и даже с гораздо большим кол-во проблем, о которых мы и не догадываемся), и думаю, что у них давно были мысли перенести свой проект на что-то более подходящее (возможно и на ARM, или на что-то другое), и несмотря на то, что проект финансируется из бюджета США!!!, никаких подвижек не наблюдается. Думаю, что даже 20-50 фанатов-альтруистов с этого и подобных форумов, которые в состоянии коллективно проделать такую работу, также не потянут эту задачу. Хотя, если развести какой-нибудь бюджетный фонд на финансирование такой задачи, и подкинуть её какому-нибудь КБ, то всяко может быть...

[Евгений]

Думаю, что такие мысли были и у создателей EMC2, ведь они сами сталкивались со всеми проблемами архитектуры x86 (и даже с гораздо большим кол-во проблем, о которых мы и не догадываемся), и думаю, что у них давно были мысли перенести свой проект на что-то более подходящее (возможно и на ARM, или на что-то другое), и несмотря на то, что проект финансируется из бюджета США!!!, никаких подвижек не наблюдается. Думаю, что даже 20-50 фанатов-альтруистов с этого и подобных форумов, которые в состоянии коллективно проделать такую работу, также не потянут эту задачу. Хотя, если развести какой-нибудь бюджетный фонд на финансирование такой задачи, и подкинуть её какому-нибудь КБ, то всяко может быть...

Эээ, у мня есть подписка на спам от команды EMC, постоянно чета пишут, не думаю что проект стоит.
А вот RTAI уже давненько не обновлялся :(

[mycnc]

Я даже не представляю себе работы без интерфейса.

Масса промышленных задач, когда нужно слить программу в девайс (практически неважно как - USB, LAN, флэшка)
а затем выполнять ее в автономном режиме. Это не станок с ЧПУ, но какая-нибудь автоматическая линия - запросто!
Это не вопрос экономии - компьютер там просто не нужен.

Другой вариант - стоит гастарбайтер и режет газом фланцы диаметром 1 м. Ему нужны только кнопки старт-стоп-ресет.
Все остальное - лишнее!!! Раз в день придет кто-нибудь более мозговитый, подоткнет ноут и сольет программу на фланец метр-двадцать. И опять - кнопки старт-стоп, старт-стоп, старт-стоп

"Двадцать восемь тысяч дырок просверлил за смену я ....." (с) ДДТ

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

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

[Pointer]

Русскоязычная документация будет со временем, но пока тоже нет. Есть вопросы - спрашивайте.

Спрашиваю у вас проблэмы с переводом на русский?

[mycnc]

Спрашиваю у вас проблэмы с переводом на русский?

Просто нет свободного времени для перевода. Есть много других более интересных задач.

[serg_io]

Под что-то другое, весь EMC2 портировать это скорее всего - нереально, да и кто потом это всё будет тестировать, поддерживать, координировать?
А вот портировать RT-подсистему под ARM+Linux, и затем прицепить туда EMC-код (в Линуксе штатно есть поддержка ARM-процессоров), и затем передать это всё разработчикам EMC2, которые доведут это всё до ума и обеспечат поддержку - это вполне реальный путь.
По поводу, что портирование - это реальный путь - да это реальный путь, но только, неизвестно какая длина этого пути (это могут сказать Linux-программисты), может быть это тоже нереальный путь (см. об этом в начале этой темы).

Думаю, что такие мысли были и у создателей EMC2, ведь они сами сталкивались со всеми проблемами архитектуры x86 (и даже с гораздо большим кол-во проблем, о которых мы и не догадываемся), и думаю, что у них давно были мысли перенести свой проект на что-то более подходящее (возможно и на ARM, или на что-то другое), и несмотря на то, что проект финансируется из бюджета США!!!, никаких подвижек не наблюдается. Думаю, что даже 20-50 фанатов-альтруистов с этого и подобных форумов, которые в состоянии коллективно проделать такую работу, также не потянут эту задачу. Хотя, если развести какой-нибудь бюджетный фонд на финансирование такой задачи, и подкинуть её какому-нибудь КБ, то всяко может быть...

Совсем недавно наконец появилась полноценная поддержка Xenomai для MINI2440, т.е. появились перспективы обеспечить некоторый реалтайм на этой плате под Линукс. Однако Latency тест вчера показал время отклика в худшем случае 160 мкс, что для полноценного EMC2 со штатным генератором шагов никак не хватит. В лучшем случае планировщик траектории сможет работать в реальном времени.
Новые поколения АРМов рождаются очень быстро ( как собственно и умирают тоже ) и обеспечить полноценную поддержку в таких условиях ни одно опесурс сообщество не сможет, разве что производитель самих чипов. Но они не рассматривают Linux платформу как основу для реалтайм.

[CNC_User]

Эээ, у мня есть подписка на спам от команды EMC, постоянно чета пишут, не думаю что проект стоит.
А вот RTAI уже давненько не обновлялся :(

Так может спросить у самой команды разработчиков EMC, что они думают по этому поводу.
Лично я - против всяких революций, т.к. переход на другую архитектуру, в случае с EMC, это самая настоящая революция.
Но факты говорят о том о чем не хочется думать:
ARM-архитектура захватила почти весь рынок более-менее интеллектуальных устройств (смарт-фоны, планшетники, часть нетбуков)
За ARM плотно взялся такой гигант как "Texas Instruments" и он доведет дело до конца.
Под ARM пишет Google.
Windows 8 будет работать как на x86, так и на ARM-ах, а это уже о чем-то говорит.
см также здесь: ARM потесняет x86 даже ПК!

А с другой стороны, все равно компьютеры на ARM-ах это будут теже грабли, что и с x86, если не хуже.
В реальности получаем - "шило на мыло".


По поводу RTAI
Некоторое время назад попался крайне полезный ресурс - http://issaris.org/rtai
там база разных материнок, чипсетов и процессоров, и как каждый ведет себя в RT-режимах!!!
Недавно появилось немного свободного времени и решил подобрать комп под CNC-нужды, и зашел на эту базу, и опа, а она не работает.
Ну думал сбои у них на сервере и т.п. Зашел через неделю, две ... И стало грустно, проект остановили, а там была такая жизненно-важная информация для всех ЧПУ-хоббистов, что-то странное происходит с RTAI.

Сообщение отредактировал CNC_User - 7.6.2011, 21:14

[Евгений]

Лично я - против всяких революций, т.к. переход на другую архитектуру, в случае с EMC, это самая настоящая революция.

Ядру EMC пофиг ARM или x86, потому как весь код основан на библиотеках, которые уже разбираются с архитектурой.
НО
1. RTAI (а без него EMC не умеет) для ARM нет
2. Когда собирал EMC на другом Linux (не Ubuntu) наткнулся на зависимость от большого количества библиотек сторонних, в том числе и графических (для визарда настройки, к примеру, чуть ли не весь GNOME нужен) которые не факт что ARM понтянет.

до кучи фот фотка компьютера которые я сейчас на работу себе покупаю, правда для контроллера не пойдет, ибо нет LPT, а вообще конечно супер форм фактор :)
Это АТОМ в нетбучном варианте. Какой ARM еще нужен ;-)?

Прикрепленные файлы

 IMAG0290.jpg ( 703,87 килобайт ) Кол-во скачиваний: 608

 

[CNC_User]

.... Какой ARM еще нужен ;-)?

Да, действительно, перевод EMC под ARM и т.п. это попытка убежать от проблем связанных с RT-механизмами на x86.
Это больше похоже на бег во сне, когда тяжело бежишь, но почему-то остаешься на одном месте .

Если один к одному перенести код EMC на другую платформу, то однозначно будут те-же грабли.

У меня такое ощущение, что EMC (в компании с Mach-ем) увлек всех нас не в том направлении, т.е. реализация RT-функциональности на
базе персоналки - тупиковый путь, другими словами, "наш паровоз вперед бежит", да он бежит, но к сожалению впереди тупик.

Скорее всего, верное направление - это внешний Real-Time модуль на каком-то распространенном недорогом контроллере, так одним махом убираются все проблемы EMC, Mach-а и т.п.
Вот этот модуль и должен разрабатываться в открытом проекте, т.к. сегодня ни для кого не проблема (даже для неэлектронщиков) собрать плату по готовому проекту, видел конторы, которые собирают платы даже в
единичном экземпляре! и за разумные деньги.

Суть:
1) Открывается отдельная тема, а вернее даже подфорум типа "Национальная система ЧПУ".
2) Коллективно формулируется задача и методы решения
4) Критиков проекта просим, чтобы их критика была конструктивна (иначе, просим проходить мимо)
5) Коллективно пишется код
6) Получаем опен-сорцевый проект аппаратной системы ЧПУ


Конечно, это всё время, но когда-то начинать все-равно придется.

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

Думаю, стоимость конечного решения будет невелика (меньше одного системника).
А если скинуться всем желающим, и заказывать оптом сразу 10-30-50 плат, то цены будут еще приятнее.

А EMC останется в качестве интерфейса.

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

И наслаждаемся полноценной работой без сбоев и глюков, и даже пыль-грязь нам уже не помеха!

PS/
Можно конечно сделать вообще автономное устройство, без компа, без монитора, прогу заливать например через флешку.
Но это заведомо ущербное решение, экономия денег минимальна (по сравнению со стоимостью даже простейшего станка).
Уровень сложности разработки обоих вариантов, думаю одинаков.
А вот удобство работы и функциональность страдают конкретно, кто работал на станке только с пультом (так называемый DSP-пульт) и на нормальной стойке, с монитором, тот понимает разницу.
Лично мне приходилось работать и на том и на этом, и разницу я почувствовал, больше ни за какие автономные пульты возвращаться не хочется (конечно, если жизнь не заставит).
Сомнительная экономия нескольких сот зеленых, ценой конкретной потери функциональности и удобства работы, это больше похоже на садо-мазо.
Русские пока еще не на столько бедны, чтобы идти на такое
Хотя для наших коллег из Афганистана или Сомали такое решение может быть придется и по душе (это я сказал абсолютно без злорадства, в какой-то степени даже жалко эти народы).