Ну наконец-то что-то похожее на конструктив. Мои замечания.
-минимум 6 осей (3 линейны + 3 поворотные)
-модуль кинематика для создания непрерывной многоосевой обработки + RTCP;
-интерфейс к ПК из перечисленных только Ethernet, USB не пойдет по помехозащищенности;
-вся обработка должна производиться в RT модуле, G-код по возможности там-же. Это позволить сделать контроллер полностью автономным;
а ПК только для управление/визуализации. Плюс с одного ПК можно обслуживать множество RT-модулей;
-возможность подключение внешнего пульта управления непосредственно к RT-модулю;
-ШИМ выход управления скоростью шпинделя;
-несколько дополнительных цифровых входов/выходов которыми можно управлять из G-кода (берем пример с EMC2).

Этим условием проект не убивается, а делается нормальная система,
которой смогут использовать не только хоббисты.

Про проблемы с MACH-ем, уже много писалось выше.

Замечания приняты и оформлены.

Вопрос о методике совметной разработки ТЗ, остается открытым и очень актуальным.

Далее, новое, я пока выделяю символом "+"
Измененное - "+/-"
То, что под вопросом - "?".

ТЗ:

* Три одновременно интерполируемые оси.

Прим. - здесь, предлагают -минимум 6 осей (3 линейны + 3 поворотные)
Вопрос - надо ли столько? и не сильно ли это усложнит проект и требования к аппаратуре?

* Точность 0,001 мм
* Диапазон перемещений +/- 10 метров.
* Поддержка стандартного G-кода
* Поддержка управления STEP/DIR (либо CW/CCW).
* Частота генерации шагов - до 2-ух МГц
* Предпросмотр кадров (технология Look-ahead) глубиной 50-100 кадров
* В качестве GUI используется PC-компьютер.
* Вся NC-математика делается во внешнем RT-контроллере.
* Требования к компьютеру для GUI - надо сразу закладывать, мин. под "Семерку"


Процессор RT-модуля:

• *Разрядность – 32.
• *Наличие блока FPU (float point модуль).
• ?Тип процессора – DSP, ARM или что то другое. Этот вопрос пока обсуждается.
• ?Частота процессора, думаю, мин 100 МГц.

? ПП – двухслойка (по возможности, - четырех-слойка)
* Интерфейс с GUI-компьютером - Ethernet.


+ несколько дополнительных цифровых входов/выходов которыми можно управлять из G-кода (берем пример с EMC2).
+ ШИМ выход управления скоростью шпинделя;
+ возможность подключение внешнего пульта управления непосредственно к RT-модулю;


Под вопросом:
Здесь, предлагают реализовать такое - модуль кинематика для создания непрерывной многоосевой обработки + RTCP;

просмотрел предложенный материал,
Вещи полезные, но достаточно сложная пространственная математика, не сильно ли это уложнит проект?
Все-таки тема 5D не из дешевых, и кому надо 5D, возьмет сразу готовую 5D-плату. Думаю, если человек занимается 5D-станками,
то экономить каких-то пару сотен зеленых он не станет, поэтому, считаю, что нет смысла вставлять 5D-расчеты в проект.



Еще какие нюансы? Дополняйте.

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

Про COM - забудьте.

Когда вы в последний раз видели на новом компе COM-порт, а?


Да был у компьютера нормальный порт, и в отличие от USB никогда не глючил.

Но был, уважаемый anatolvk, был!

Ну не так все пессимистично!
И был и есть. и это единственное простое решение, ради которого стоит поискать соответствующую плату.
ЮСБ не глючный, а просто не предназначен для этих задач, т.к. по своей природе пакетный, кстати езернет тоже не далеко ушел, хотя и более подходящий.
А с КОМ все прекрасно выходит, правда на скорости 921600.

Если используется схема управления типа Step/Dir с уровнями TTL, как в LPT, то лучше всего контроллеры двигателей располагать в непосредственной близости от блока управления. Не более 30 см.
Иначе пользователь может иметь серьезные проблемы с наводками, даже гальваническая развязка порой не спасает, если используется китайский шпиндель с китайским-же преобразователем частоты.
Для распределенной системы нужно либо делать сигналы управления дифференциальными, либо использовать что-то типа CAN шины для сообщениями между узлами. Но я так понимаю это не входит в концепцию ТС. Да и это уже не RT плата будет, а RT система.
Насчет Ethernet, то это сложно только в первый раз, потом по накатанной пойдет :) Слава богу стеков TCP/IP уже куча всяких бесплатных. Но к примеру тот-же CAN тоже можно использовать, вон в тепловозах используют и ничего, работает. А это место "пошумнее" будет, чем любой станок. Вот только проблема - в компах CAN не предусмотрен, к сожалению.

Естественно, по другому никак RS422.

Осмелюсь утверждать, что латентность системы не очень важна, если не управлять двигателями прямо с лпт порта.
Все известные системы чпу работают с определенным временным интервалом - сервоциклом. Это касается как ЕМС так и МАЧ.
Обе эти системы в общем случае понятия не имеют, что у них там на выходе прицеплено (шаговик, серва или еще чего).
Базовый интерпретатор Г кода занимается только одним (в плане управления) - расчитывает скорость координаты на период сервоцикла.
И говорит, что на этом сервоцикле скорость по каждой координате такая-то.
Сервоцикл для большинства систем равен 1мс.
Исходя из этого латентность и реалтаймовость должна с уверенностью попадать именно в эту милисекунду.
А все остальные заморочки важны только если дергать пинами порта, для управления приводом.

Насчет сервоцикла и 1 мс это я согласен. Но и это время все-таки нужно выдерживать, причем довольно точно. Если конечно не делать буфер на несколько десятков отсчетов( т.е. отсчетов координат с периодом следования равным сервоциклу), чтобы хоть как-то бороться с задержками, которые неминуемо возникают при работу ядра ОС, особенно дисковой подсистемы. Но такой буфер несет в себе свои минусы и не несете никаких гарантий, что он не будет переполнен рано или поздно

мне вот интересно - а какое количество народа использует серву а какое шаговик?
большое подозрение что на серву едва наберется 1/3.
так что нечего рот широко разивать - откусите сначала кусочек поменьше - сделайте контролер для шаговых.
а то тема просто по старому обычаю заглохнет ибо то что тут озвучено просто ненужно большинству...

Ethernet нормальный, только ну его нафиг, лучше модуль WI-FI. Так технологичней.
Вообще ненадо тратить время на это. Этим занимаются лидеры в своей области.
Даю прогноз ничего путнего не выйдет, чем есть сейчас. И точка.

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

Это совершенно не пессимизм, это называется громким словом - "ПРОГРЕСС!".



Согласен, USB - нормальная штука, но только не для станочных целей.
Если Ethernet допускает длину кабеля до 100 метров!, то по спецификации на USB - максимум три метра, и при этом спецификация запрещает всякие там удлинители.
Совершенно очевидно, что USB - это сугубо бытовой интерфейс.

Про пакетность, - не очень понятно.
Передача между GUI и NC-платой у всех идет в пакетах, а по другому и невозможно.
Если так рассуждать, то протоколы использующие COM-порт, тоже все пакетные


Может вы имели ввиду, последовательную передачу данных, а не параллельную?
Если да, то это абсолютно нормальное явление, сегодня, параллельных шин в ПК практически уже не осталось.
Т.е. последовательная шина, это абсолютно нормальное явление.



Вот по этому-то, вся NC-математика и должна быть только в NC-плате, иначе будут косяки.



Думаю, что здесь вы промахнулись раз эдак в десять.
1/30 и то, это в лучшем случае.
Собственно по этому аналоговое управление сервоприводами и не рассматривается,
в озвученном ТЗ есть только STEP/DIR-интерфейс.



Ну-ну
Дайте ссылочку, хотя бы на одного производителя, который так делает.
Вы никогда не заменяли кабель на Wi-Fi?


Однозначно - в нашем случае, либо медь, либо оптика, и ни каких там радиоканалов (еще этого геморроя нам не хватало)
Технологичней, в нашем случае не значит лучше
Станок и мобильник (и т.п.) это разные вещи, и не надо смешивать всё в одну кучу.






Такая критика деструктивна (перечитайте внимательно сообщение №1).

USB и в промышленных системах применяется активно, в той же армянской MSHAK CNC компьютерный станочный пульт связан с контроллером движения от ДЕЛЬТЫ по USB - расстояние до 30м. Да и здеся: http://www.planet-cnc.com

Если вы попадаете с приемлемой точностью в период управления шагами на максимальной частоте 25кгц, то почему возникает вопрос о попадании в 1 мс?



Да не нужно никакую математику, кроме ПИД и Синтезатора частоты выносить в контроллер!
Вся математика укладывается в CPLD на 512 логических элементов типа ALTERA MAXII.



Для хобби наверняка и намного меньше, а для промышленного переверните дробь наоборот.
Дело в том, что для того, что я предлагаю, нет никакой разницы чем управлять сервой, шаговиком, шпинделем, кнопками, лампочками или еще чем более экзотическим.
Суть идеи состоит в создании распределенного контроллера, управляемого по последовательному каналу, все части которого связаны в сеть.
Получается простая масштабируемость. Хотите все блоки запихните в одну плату, хотите привяжите географически к приводам, кнопкам ...
Причем все это будет работать как с ЕМС так и с МАЧ и в обеих случаях как с шаговиками, так и с сервоприводом.



Возможно Вы и правы.
Просто у меня есть проработки этого контроллера сделанные просто на досуге, по специфике я занимаюсь разработками в другой области.
Однако идея очень , на мой взгляд, интересная.
Конечно, из сказанного не совсем понятно о чем я. Если интересно, могу подробнее.
Вот здесь я немного об этом писал http://www.cnc-club.ru/forum/viewtopic.php?f=15&t=790
Ник Impartial.

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

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

вот к примеру готовый http://www.dynomotion.com/KFLOP.html , конечно ща будет флейм УСБ гуано и все такое. но оно сделано и работает.

Да все правильно, только плата, указанная в ссылке стоить будет не по хобби.

А намеков на софт нет потому, что с ним как раз и нет проблем - это однозначно либо ЕМС либо МАЧ.
Для ЕМС надо написать только ХАЛ настройки, а для МАЧ - плагин. И все!
А для повторения - проще не придумаешь. По большому счету самым сложным будет изготовление платы
И по запчастям можете сами посчитать сколько стоит ПЛДшка, передатчик 422 и драйвер двигателя. Ну еще блок питания.
Ну и грубо умножьте все это на количество осей.

Написать и отладить систему, аналогичную ЕМС, даже выдернув из нее исходники RS274, задача нетривиальная, и учитывая, что не будет серьезной поддержки, практически гиблая.

MSHAK?
Хотел зайти на их сайт, ан нетушки! Уже нет их сайта (www.mshak.am)
Да и фирмы наверняка нет такой (по крайней мере я не нашел её в Инете)


Так, что 30м у фирмы, которая уже давно закрылась - это не показатель

Да и сильно я сомневаюсь по этому поводу.
Во всех спецификациях на USB написано - ну максимум 5м и то, это при супе-пупер кабеле.


Может у ДЕЛЬТЫ и Ультра-Супер-Пупер кабель, но тогда стоимость 30м такого кабеля, думаю раз в 30 больше,
чем стоимость нужной нам дополнительной обвязки для использования Ethernet-а.


Да и вообще, с обычными USB-кабелями из компьютерных магазинов бывают проблемы,
и не со станками в цеху, а с обычными принтерами, в тепличных офисных условиях!!!


Текст из указанной ссылки:

Сейчас как раз заезжал к нам сервис-инженер - я его еще раз спросил по теме. Он сказал, что отличить глючный от безглючного кабеля практически невозможно по внешнему виду/надписям, более того одна партия кабелей одной фирмы может работать нормально, а другая - нет (высказал предположение, что проблема заключается в материалах из которых кабель делают). Нам он решил проблему просто - привез кабеля нескольких производителей - протестил на принтере, тот кабель, который подошел - оставил и затем привез нам нужное к-во кабелей этой партии. Если нужен только один кабель ... ну, сыграть в чет-нечет . Или договориться со знакомым из фирмы...

С Ethernet-кабелями такого не бывает, обжали тебе, за десять копеек, кабель в любом компьютерном магазине, и вот вам счастье!!!


Так, что, по поводу USB, делайте выводы сами.



Ну почему сразу гуано?
Просто USB для других задач и вот вам весь секрет.

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

Да, еще у USB еще есть одно гадкое свойство -
если USB-связь оборвалась, то она уже никогда не восстановится самостоятельно (нужна перезагрузка системы!!! ).

Да вот в том, то вся и проблема, что на современных ПК периодически не попадает даже в 1мс!!!
Да! Да! Здесь нет ошибки именно 1 мс, а то и более!

Через некоторое время, эти современные компьютеры будут уже Б/У, а те, которые сейчас уже Б/У,
через некоторое время будут уже на свалке. Если сейчас, можно подобрать подходящий комп из Б/У,
то через некоторое время такие платы будут вообще бесплатными - это плюс,
но есть и минус - эти материнки надо будет собирать где-то на свалке. Кого-кого?, но лично меня это не вдохновляет.
Собственно, это один из основных мотивов запуска этого проекта.


С начала этого топика обсуждались эти вопросы (но это было не по теме текущего топика).
Если хотите продолжить обсуждение по этому поводу,
то пожалуйста прочтите сообщение №32, ч2.




Про МАЧ забудьте (по той-же причине), да и вообще работает он не в RT-среде!!! отсюда и основные траблы.
EMC - еще пока можно использовать, все-таки, там есть RT-операционка (RTAI)
и она пока еще что-то вытягивает.
PS/
А перенос кода из EMC уже начат в нескольких проектах .

Мне вот нравятся продукты Delcam.

Это вы о чем?

Я вот маркую тут над системой позиционирования. Станок скажем 2*3 шаг грубый и быстрый, а система позиционирования имеет точность 0.1 мм. Нужно сделать контроллер для такой системы. Сочетание точности и скорости.

Для хобби и малого бизнеса хватает LinuxCNC за глаза.

см. сообщение №32 (ч.2)

Парни, а существуют ли какие-либо [международные] стандарты по теме всего этого? Может быть, проще начать со стандартов? Тогда будет проще увязать всё это в единый комплекс.

По поводу выбора процессора -- любой, который работает в режиме реального времени и умеет делать вещественные вычисления. А относительно RT-платы писюк будет работать как периферийное устройство хранения кода и приблизительной отрисовки этого самого кода. :)

ТЗ здесь уже вменяемо.

Если уж что-то делать, то надо делать хорошо, с запасом на будущее, чтобы потом не переделывать. Как знать, вдруг этот проект станет дико популярным во всём мире?

По-хорошему проект надо бы разбить на логические модули (в рамках единого стандарта) и разграничить взаимодействие модулей по "слоям", подобно сетевой модели OSI. Тогда возможно получить и универсальное ПО, и унифицированные платы. И разрабам будет проще.

NB! Можно сделать всё гораздо проще: вместо заморочек с реальным временем на отдельной плате организовать N кусков оперативной памяти (где N - количество осей) с общей синхронизацией, в которые будет заливаться (и добавляться динамически в буфер) готовый битовый код для исполнительных устройств. Вся математика просчитывается заранее на любом писюке и пофиг на RT.

Таким образом, на плату достаточно установить RT-проц только с целочисленными вычислениями (только байты гонять), ОЗУ и буфер (вспомогательное ОЗУ) на 5 секунд битового кода для движков. ОЗУ на каждую ось можно делать из двух банков: пока один исполняется, в другой заливаются данные из писюка. Прорисовка этого же битового кода производится средствами писюка, всё равно разницу в микроны или даже десятые между реальным изделием и картинкой мы не увидим. А уж заливать этот битовый поток можно любым двунаправленным интерфейсом по любым протоколам, в том числе с гарантированной доставкой пакетов и контролем целостности данных.

В итоге мы получаем максимально дешёвую плату (реализующей принцип перфоленты), любое количество осей и максимально гибкий софт.

Фигушки: либо медленно, либо дорого. Ситуация здесь точно такая, как с интерпретатором и компилятором в программировании. Лучше конечный (битовый) код готовить заранее, тогда будет и быстро, и дёшево.

а ещё комп для подготовки битового кода.

а смысл (кроме кнопки "Стоп")?

Вообщем-то стандартов почти нет, разве, что стандарт на формат G-кода - RS274D (и его национальные аналоги - DIN 66025, ГОСТ 20999-83, и т.п.),
а всё остальное, к сожалению, в вольной трактовке

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

Уже представил себе цех, от станков витые пары идут в свич, в серверной сервер управляет этим стадом станков. Всё оборудование стандартно, из нестандартного только наша плата с разъёмом RJ45 на входе. Если плата станет популярной, то она также станет стандартным оборудованием. А для хоббистов или полной автономии станка (с автономным графическим пультом) платы вообще можно делать под разъёмы PCI или PCI-Express.

Таким образом, мы уходим от проблем RT, SMI/прерываний и прочих неудобств x86-архитектуры, используя эту же архитектуру для вычислений и транспортирования битового кода.

Поскольку плата по сути является "проигрывателем" битового кода, очень просто восстанавливать обработку детали после пропажи питания в цеху или при поломке режущего инструмента -- после восстановления работоспособности повторяются последние рабочие 15 секунд битового кода (столько в буфере пропало и в обоих банках ОЗУ): поскольку компьютер на ИБП и периодически получает запросы на порции данных, несложно организовать отслеживание последнего рабочего состояния станка.

Для опен-сорса такая платка очень гибка и дешева, поскольку вся физика просчитывается программно -- а это предоставляет широкие возможности для приспосабливания ПО к любой платформе (хоть на Java пиши или на виртуальных машинах запускай) и к любому оборудованию (включая космическое ).

Сегодня, ситуация в корне изменилась. Есть быстро и дешево


Например это - ADSP-21261 - 900MFLOPS peak performance!!! И это при цене менее 10 баксов







О чем вы говорите?

900MFLOPS - вам что мало?
Этого хватит и на анализ G-кода, и на формирование траектории, и на генерацию STEP-импульсов, и еще на много чего.
И не надо разделять NC-код на две платформы.


А GUI - это должно быть - только GUI!


А что вам не нравится идея работы планшетника в качестве GUI?
Мне лично очень нравится, нет лишних коробок, все предельно компактно и функционально.
Если NC-математику жестко завязывать с ПК, то про такую идею придется забыть,
т.к. на планшетнике, такие вычисления не логично делать.

Ага, и приплюсуйте к этим 10 баксам ещё разработку платформы (пишем ОС и ПО под этот ADSP-21261) -- это по сути повторное изобретение ПК -- теперь на другой платформе.

Это всё уже есть в том же EMC, отлажено и работает -- зачем изобретать велосипед?

Идея планшетника нравится. Существующие планшетники -- хоть x86, хоть ARM -- без проблем нарисуют Вам что угодно -- зачем изобретать велосипед?

Запихните всё это в PC-card и будет Вам предельно компактно.

А какая разница, на чём готовить код? Если отказаться от идеи RT-вычислений и принять идею проигрывателя бинарного кода, то конечный пользователь купит стандартный вычислитель (планшет, ноутбук, ПК -- не важно), просто вставит в него плату (подключит к коробочке) -- и будет иметь полноценное RT. Ведь всё равно при проектировании изделия без САПР на стандартной платформе не обойтись, так зачем же усложнять жизнь ещё одной платформой?

Единственный смысл городить огород -- это привязать к себе юзверя и делать на этом деньги. Тогда да, никаких стандартов, никакого опен сорса и завязываем юзверя аппаратно на себя.

А если не городить огород, то можно дописать модуль к EMC, который будет забирать готовый битовый код в файл, скармливать этот файл плате-проигрывателю и эмулировать для EMC поведение "реального железа" (с запаздыванием в 1 секунду, например).

А в чем собственно проблема ребятушки?

Я написал USB программатор под виндой который программирует AVR на скорости 3мгц(SPI)
и EEPROM через I2C (400 кгц и выше), при этом никаких ошибок и прочих траблов, я вообще об этом не думаю. Надеюсь представляете на какой скорости залетают прошивки в чипы. )
А почему все так сладко да гладко? Да потому что FT микросхема имеет свой тактовый генератор и буфера FIFO. Обмен идет пакетами 64кб (фреймами). Винда занимается формированием этого пакета и отправкой.
Итог: имеем на одной микросхеме FT232 выход 8 линий на скорости 3мгц. Если надо 16 линий , FT2232D.
Нужно написать только GCode>FT232 конвертер программу и вперед.

Именно это он и хочет реализовать прилагая свои усилия.

ncPod Motion Controller
www.ncpod.oemtech.com/
Характеристики:
USB 2.0 Com Interface
6 Axis Step/Direction Output
5 General Purpose Outputs
1 PWM Output for Spindle Speed Control
6 Home Inputs
6 General Purpose Inputs
Status LEDs
Up to 75000 Steps/Second
Individual MTA Connectors for each axis (+5v, Gnd, Step, Dir) and Output (Gnd, +5v)
Small Size (2.75 x 3.00 inches).
Complete Part Files stored on inexpensive Secure Digital media
Part is completed even if Host computer loses communiactions
Capable of supporting any combination of Constant Vector Velocity, Continuous Motion
Contouring, or High Speed Machining trajectories

ADSP, я привел для примера, чтобы вы понимали, что времена уже изменились.
А так, вообще-то, подобное есть у многих (Motorolla, Texas Instruments, Renesas и др.)
ОС под это всё есть готовое (там даже есть Linux!!!).
А разработка платформы, собственно и есть цель этого топика

Ну и чудненько, осталось перенести его на "правильную" платформу, и можно даже в среде Линукса, и сразу на RT-аппаратуре!!!


Про PC-card для платншетника, не очень понял .



Зачем так усложнять архитектуру?
Всё планируется предельно просто и предельно открыто.






Повторяю, опенсорцевость в этом проекте - одно из основных требований.
И как вы себе представляете в опенсорцевом проекте привязать к себе юзверя?
Опенсорцевость подразумевается как софтварной части, так и аппаратной.





Вот как раз это и называется - "городить огород"

"Моя твоя не понимай..."
Вы хотите создать ещё одну "экосистему" в дополнение к существующим ("ещё один проект")? Объясните, пожалуйста, ещё раз, как Вы видите работу Вашего программно-аппаратного комплекса начиная с момента, когда потребитель уже создал модель изделия в САПР и получил G-код (а то вчера ночью мозги вспухли, читая много текста от начала темы).

кто вам говорит что мач3 ДОЛЖЕН работать в реалтайме? от него тока требуется интерфейс юзера и траектория. реалтайм делает внешний контролер за 50уе.

да и большие сомнения что кто то бесплатно напишет софт лучше чем мач3 на любой платформе НЕ х86. все что требуется - написать маленький плагин по выводу траектории фрезы.

И я ему о том же толкую, чтобы вынести из писюка только RT-часть.

в варианте с внешним РТ-контролером можно взять любую материнку неважно где - хоть в магазине хоть на свалке.

а мотивы в нашем мире достаточно просты - материальный достаток.

Кстати вопрос на засыпку. а нельзя как то использовать уже готовые возможности мач3 или его плагинов для вывода траектории? Ведь на родном сайте есть готовые плагины под платы других производителей.

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

Нет ничего нового в этом мире...
http://www.cnczone.ru/forums/index.php?s=&...post&p=2695
Только что-то никто не загорелся попробовать сделать.
Простая схема, дешевая память для буфера - все доступно.
Но "не круто", что ли?
Видимо, поэтому все норовят в контроллер запихать интерпретатор G-кода, визуализацию, Linux, убить на это кучу сил и времени... И выйдет сильно ухудшенный вариант EMC2 на PC.

И, главное, не поленитесь прочитать последний пост темы, на которую дал ссылку. :)

ну суть не в крутости. а в удобстве.
я вот не знаю одного. если комп для мач3 будет жутко нереалтаймовым не начнет ли он сам пропускать вывод в порт?
а то давно чешутся руки поставить на станок ноутбук/планшетник с сенсорным экраном из разряда 800-1000мгц.
тогда суть буфера имеет смысл.

Основная проблема МАЧ-а - его закрытость, отсюда и проблемы со всякими примочками под него.
Посмотрел все USB-сглаживатели шагов на мач-суппорте.
И прослеживается интересная вешь - так оказывается, что они все в Beta-версии .

А те которые в релизе, все построены как раз по полноценной схеме с автономной NC-платой,
где сам МАЧ является только GUI-интерфейсом!
Не верите? Так сами просмотрите мачсуппорт.
Эти моменты, также подтверждает правильность изначально выбранного пути в данной ветке!
А путь с вешним USB-проигрывателем шагов, это явно тупиковый путь.

Так что делайте выводы товарищи!

PS/

И чего вы прицепились этому МАЧ-о?
Да, он разрисованный и разукрашенный, но это ли главное в NC-системе?


Из более-менее нормальных чисто программных NC-систем, есть только одна - EMC2 (она-же LinuxCNC)

Её плюсы (по сравнению с Мачо):

• 
  Реализована на базе RTOS (это самый большой плюс)
• EMC2 работает гораздо стабильнее чем Мачо.
• Поудобнее и поэргономичнее интерфейс
• Более конфигурируемая.
• Открытая архитектура
• Открытый исходный код (это тоже огромное преимущество).
• Поддерживается сообществом, а не одним человеком.
• и т.д.

Основная проблема EMC2 (да и МАЧ-а) это то, что код исполняется не на RT-платформе.
Но об этом, мы уже достаточно много говорили выше.

По хорошему, надо чтобы интерпретатор (Мач или EMC) выводил в файл а не в порт.
Вариант записи с порта далеко не лучший.
При записи DIR/STEP в файл для последующего "проигрывания", "реалтайм" вообще не нужен.

да все равно. пусть будет емс2. главное - простота и повторяемость разработки.

МАЧ это конвертер PC в контроллер для станка. Тут и так понятно что при таком подходе проблемы будут. Чисто софтом не осилить эти задачи. Программно-аппаратно надо решать. Вот приставка к PC + софт классный. Я бы купил не думая. Как будет подрубаться к PC роли не играет, но приоритет отдаю WIFI или другой радиоканал.
Вопрос еще на какой кошелек ориентироваться.
100, 500, 1000, 5000 евро это будет стоить?

контролер к РС не должен превышать 50уе в деталях. 100уе это уже предел.
смысла в вай-фай нет так как РС это интерфейс юзера и далеко от контролера стоять не будет. хотя если нужно гальваническая развязка то я бы выбрал оптику медик или опторазвязку.

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

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

Согласен.
Действительно, МАЧ - это попытка реализации RT-задачи на ПК.
Делается такое исключительно из-за того, что нет доступной по цене аппаратной части для реализации NC-задачи.
А в этом проекте мы то и пытаемся устранить этот существенный пробел




А чем не устраивают чипы от AD, которые я для примера приводил немного выше?
Их производительность выше чем у Atom-а, а цена ниже!
И со средствами разработки и отладки - все в полном порядке!
(Я пока не отстаиваю AD, т.к. пока вопрос выбора проца открыт, я его привел только для примера)



Где-то выше писал - плата по комплектухе - до 100 баксов, это в теории, в реальности, со всеми там налогами, поборами, подготовками производства
и прочими "непредвиденными расходами" уверен что уложимся до двух сотен.

Есть сообщество разработчиков Колибри OS, так вот умещается она на дискетку и имеет GUI, открытый
исходный код можно ковырять сколько нужно, монолитное ядро, требуется для ее работы 8мб оперы. Написана на FASM. Советую написать под нее софт для ЧПУ станка и сделать аппаратную примочку. Вот это
будет мега сила. Единственно решение которое я вижу реальным.
А приставку на ADSP или еще на чем мне всеравно.

Ассемблер, это конечно круто, но вы себе представляете уровень сложности проекта на ассемблере?
И на сколько это сложнее и дольше чем на ЯВУ?
Да, и никто не будет писать этот проект на ассемблере.

Почему никто не будет проект у вас ОПЕНСОРСНЫЙ потихонечку все напишется годами. Колибри же написали.
Хотите ускороить процесс разработки?
Сделайте плату сопряжения с PC(Windows) с интерфейсом на выбор (WIFI, USB, Ethernet) и соотвествующие библиотеки для нее.
Софт будет написан быстрее, чем вы это себе представляете.

DSP с Atom не сравнивайте совсем разные назначения.
DSP в основном ориентированы на обработку сигналов в реальном времени в составе чего то.
Все дело в том что вы изначально задумали вычисления делать не на PC, это неправильно.
Правильно просто сделать примочку на какомнить камне хоть кипарис хоть арм хоть авр кому как нравится. Главное было кому разрабатывать и писать прошивку.