"Конь в Вакууме" - это аппаратно - программный комплекс, умеющий работать как со всеми существующими, так и с перспективными интерфейсами и выполнять уже существующие и ещё нет задания.
Собственно, нужно сделать контроллер для станка и программу для контроллера.
В интерфейсе LPT есть 12 пинов, работающих на выход. Обычно управление станком с компьютера осуществляется сигналами шаг-направление и есть 6 осей, которые могут рабтать одновременно, или практически одновременно. На вход могут работать 5 пинов. Задача состоит в том, что бы расширить возможности станка путём последователиной передачи данных через LPT в контролер.
Из 12-и пин выхода LPT, 6 пинов остаются работать в режиме "шаг". 4 пина задают адрес, 1-данные, 1-синхро импульс. Из 16-и адресов 6 задают смену направления оси, 1 начало и конец введения адреса, 1 предназначен для введения адреса, 1-команда " адрес + 1" с записью данных в ячейку памяти по каналу данных; 1 адрес - обнуление отсчёта "адрес + 1"
Все данные изначально записываются в ячейки в 1-битном формате. Одна ячейка может быть предназначена для включения опроса концевика, включения/выключения реле, установления деления шага/кратности шагов для ускоренного режима серводвигателя. В случае когда 1-го бита не хватает, используется несколько с соседними адресами.
Для разработки программы предполагается найти исходники чего-либо или заказать дополнения в программу разработчикам мач4. При этом вроде как раньше можно было купить исходники Mach 3, а в линуксе (для линукс ЦНЦ) вообще исходники должны быть открытыми.
Выбор порта LPT, не в пользу остальных, обусловлен двумя факторами: высокой скоростью работы (на практике) и его простотой, пониманием его устройства. Со временем можно добавить возможность работы через USB 2-3, ethernet.

Наверное вам сюда

Зачем так усложнять, если есть USB?

Возможно и не стоит усложнять.
При вращении стандартного шагового двигателя 200 имп/об в полушаговом режиме со скоростью 50 об/с частота импульсов составит 50*200*2=20 000 имп/с.
Вопрос: USB выдаст стабильно 20 000 имп/с по 6-и осям одновременно? Обеспечит ли USB обработку 1000 ячеек памяти по 1-му биту? На сколько стабильно это будет работать? Может там обратную связь получится сделать и обрабатывать её в реальном времени? Как это в железе реализовать? Есть плата rs485, может через неё можно управление станком сделать?

1) Вообще-то, импульсы микроконтроллер выдавать должен, а USB нужно только для его общения с ПК.
2) Где вы видели шаговик, который умеет 50*200=10000 шагов в секунду? Пределом, который я встречал (на потере мощности в 50%) было 600-800 шагов в секунду! Даже при делении шага на 16 это достаточно мало, чтобы одновременно можно было 3-5 шаговиками с одного МК управлять. Справится даже копеечный STM8S003. Хоть я больше STM32 уважаю, но и для STM8 делал управлялку шаговиками.
В случае станка помех может быть очень много, поэтому — да, там предпочтительней RS-485 или CAN для связи с компутером. Ну или сразу компутер в станок пихать, благо, какие-нибудь убогие "малинки" стоят рублей 600!

1. Компьютер нужен для обеспечения линейной/круговой интерполяции одновременно по 3-м осям. Пример- нарезание конусной резьбы. Если это будет делать контроллер, он будет почти полностью дублировать функции компьютера. На практике такие устройства стоят порядка 100-200 тыс. руб. Типа НЦ201-НЦ400

посмотрите платы управления для 3D принтеров, порядок цен от 2 до 10 тыр, линейная и круговая интерполяция по 2 осям + подача по еще 2 осям + стабилизация температуры двух нагревателей.

2. Расчёт 20 000 шагов в секунду сделан для обозначения предельных параметров системы. Были американские программы, которые не выдавали достаточной частоты, и на этом фоне Mach начал заметно выигрывать. Возможно, в станке будут стоять серводвигатели, и они будут управляться так же сигналом шаг/направление. Может быть с разными коэффициентами - 100, 1000, 10 000 имп/оборот.

3. Перечисленные контроллеры буду изучать. Сомнения в быстродействии системы на USB связано ещё с тем фактом, что прошивка контроллеров через порт LPT проходит в 2 раза быстрее, чем по USB. По этому было бы хорошо обеспечить возможность работы как по USB, так и по LPT. Начать лучше с LPT.
Вопрос по rs485 наверное придётся выделить в отдельную тему. Пока нет программы для работы станка через rs485 и ответных устройств, таких как серводвигатели rs485, реле rs485, концевики rs485. В природе возможно это есть, нужно искать. Или создавать.

4. Можно подробнее про "малинки" по 600 р?

Плата от 3d принтера даёт ограниченные возможности. Суть вопроса о создании контроллера с расшимяемыми возможностями. Например, плата с двумя rs485 обеспечивает обмен информацией с 254 устройствами, из них 64 физических.

Был станок, который работал через rs232 (com порт). Работать он начал после устранения всех контакторов и замены на тиристоры.

Это еще что за фантастика? USB даже в режиме CDC обеспечивает как минимум мегабит в секунду! А уж если полноценный FS поднять, так совсем хорошо будет. А LPT — жутко тормозящий интерфейс.
Не говоря уже о том, что параллельные порты уже давно вымирают. Все меньше шансов встретить материнку с аппаратным LPT.

Ничего сложного. И совсем недорого будет по железу.

aliexpress, ebay

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

Ну у меня станина уже готова и посадочные места под двигатели и ШВП
http://www.16b16t1.ru
С прошивкой контроллера тормозит программатор, сделанный на таком же контроллере. Время уходит на преобразование сигналов. Я не думаю, что у меня получится лучше устройство сделать и оно такой эффект не выдаст.
Есть супер-интерфейс EtherCAT. 10 КГц частота тактирования сервы по 100 осям. Но мне все таки кажется реальные сделать устройство на базе LPT, потому что проще LPT нет ничего. А по ресурсам - 6 одновременно работающих осей хватает за глаза. С частотой шагов тоже справляется, даже под Winds.
Про малинки так и не понял, это нетбуки малинового цвета или что искать нужно?

"Малинки" ­— это "raspberry pi" и им подобные армовские одноплатники. Довольно компактные и недорогие. В самый раз, чтобы внутрь прибора засунуть — наружу только ethernet разъем торчит (а то и вообще по wifi). Запускаешь браузер, выходишь на веб-морду и дергаешь что нужно.

Сделали-бы сначала на том что есть и отлажено, а потом-бы мечтали.
http://purelogic.ru/

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

Ну, вообще-то LPT вовсе не тормозящий, особенно в сравнении с USB LS и даже FS. И особенно для задач, где важно время отклика удаленной системы (пример - любой JTAG адаптер или, скажем, SPI программатор, в общем, любая задача с BitBang'ом). Время чтения или записи регистра данных LPT - порядка длительности цикла ISA-шины, а это порядка 1 мкс в худшем случае. Считая время формирования реакции на запись в подключенном устройстве =0 (чтобы получить крайнюю оценку), имеем время отклика
tResponse = 2 * 1us = 2 us,
что дает оценку теоретического предела частоты воздействий
fControl = 1 / 2us = 0.5 MHz.

Теперь учтем время реакции управляемого объекта - пусть это будет еще 2 мкс (что, согласитесь, весьма расслабленно для современной электроники). В результате имеем:
tResponse = 2 us + 2 us = 4 us
fControl = 1/tResponse = 1/(4E-6) = 250 kHz

А что у нас в USB системе? Воздействия/отклики USB device привязаны к хождению по USB их фреймов, период следования которых для LS/FS 1 ms. В результате имеем :
tResponse = 1ms + 1 ms = 2 ms
fControl = 1 / 2 ms = 500 Hz
И в любом случае частота считывания параметра, на который мы воздействуем, будет не лучше 1000 Hz (=1/1ms).

Вывод: если подключать через USB - надо хотя бы часть функционала, ту, которая требует быстрого отклика на воздействие, переносить на устройство, локализовывать. С LPT (если он есть еще под рукой :-), конечно) - можно попробовать чем-то поуправлять, вычисляя все необходимое на PC.


Это да. С перспективной точки зрения надо смотреть на варианты с локализованной частью функционала, который может бегать на, скажем, подходящем контроллере с USB интерфейсом.

Но если ТС имеет LPT под рукой, и он ему ближе и понятнее, то первую реализацию можно и на LPT сделать. Только декомпозировать фунционал надо сразу с оглядкой на будущую локализацию процедур быстрой реакции на устройстве непосредственного управления.

LPT окончательно умер 10 лет назад, 232 готовится следом.
Нет никакого смысла гальванизировать.
Ещё через несколько лет отомрут последние динозавры, и встретить LPT можно будет только в музее.

качественно правильный вариант с точки зрения долговечности, предсказуемости и производительности - разрабатывать сразу, на старте, с использованием интерфейса PCI-Express.
Т.е. нужно взять например какую-нибудь отладочную плату с ПЛИС (Altera, Xilinx - что больше по душе) и начать с неё.
Ввод-вывод, скажем, 200-300 цифровых сигналов одновременно с низкой задержкой обработки и предсказуемости по времени исполнения требует применения именно ПЛИС.
Ну а далее, владея нструментарием, доступным в ПЛИС, вы дальше сможете не задумываясь набирать количество датчиков и исполнительных устройств исходя из принципа "а сколько надо?" вместо логики "а сколько успею?" при использовании какого-нибудь LPT или RS232/RS485.

Забыли про необходимость написания некоего драйвера, который позволит все эти оптмистичные тайминги не на голой железке, а на машине Lin/Win реализовать. Тем радиолюбителям, которые для автора явились образом для подражания, какой то драйвер кто под 32bit Win написал. Под 64bit драйвера нет, вот вся эта их поделка и не работает.

Все есть. Этот вопрос решили радикально. С исходниками.
InpOut32
InpOut32-x64

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


Вариант прикольный. Не делать отдельный корпус, а засунуть все в системный блок.
Про EtherCat: сервопривод с EtherCat стоит на 9000р дороже абсолютно такого же без EtherCat.

Я на таких полусамопальных станках с управлением от ПК с LPT в прошлом веке работал. Удовольствие еще то. Дело, конечно, Ваше, но не советую формировать управляющие воздействия напрямую из ПК.
Считаю идеологически верным подходом изготовление отдельного блока системы управления (БСУ).
Управляющую программу в БСУ заливать из ПК по USB, Ethernet или любым удобным способом. БСУ будет формировать управляющие воздействия независимо от ПК и так, как Вам нужно.


Да-да! Загубленная заготовка быстро убеждает, что дешевизна ПК-управления очень сомнительная.

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

Да, именно так.

Напоминает один из законов Мерфи "Измеряй микрометром, отмечай мелом, руби топором".
Я конечно далек от металлообработке, но измерять или симулировать нарезку резьбы с помощью осциллографа - это смело!!!

Физика стала точной наукой когда взяла в руки весы.
В нашем случае есть 3 оси, работающих одновременно и циклически: ось шпинделя, ось продольной подачи т ось поперечной подачи. На шпиндель подаётся 1000 импульсов в секунду. За это время он делает 10 оборотов. Как бы там ни было, при равномерной подаче импульсов расстояние между ними на экране осцилографа всегда будет одинаковым. При увеличении расстояния между двумя импульсами в 2 раза отклонение от заданной позиции составит 1/100 оборота.
По продольной оси за то же время пройдёт (10 оборотов x 200 имп. на оборот в двигателе x 2, полушаговый режим x 1, шаг резьбы 2мм=шагу швп 2мм.) 4000 импульсов. При этом увеличение расстояния между двумя имп. в 2 раза приведёт к появлению неравномерности в 0,005 мм.
Загрузка по 3-й оси нужна для нагружения процессора и остального железа.
С внешним контроллером было 4 проблемы: первые две - его было невозможно мгновенно остановить и он был очень чувствителен к помехам. Вторые две - он жил своей жизнью и было только одному богу известно, что он делает. Например, когда станок сам делает натяги перед проходами, хоть и не правильно, это ещё не так страшно. Но когда он вместо сферы вытачивает непонятно что и невозможно разобраться, какие сигналы приходят на контроллер и почему он так себя ведёт, это уже геморой. Хотя я не утверждаю, что все внешние контроллеры такие.


Так оно и планируется. Только в случае с LPT (внимательно прочитайте первый пост, после слова Вакуум вся геометрия и синхронизация осей между собой оставались в компьютере. На внешний блок возлагается расширение функционала, такое как переключение работы с осями, изменение коэффициентов шагового режима (100-1000-10 000 шагов оборот) и работа с неограниченным количеством датчиков и реле.


Это уже половина того, что нужно. Когда в одной программе идёт симуляция обработки, другая программа может брать данные и передавать их на исполнение в контроллер. Если это та дырка, о которой я думаю.

Нет, это просто НОЛЬ, если надо обеспечить под Win не просто факт записи в произвольный момент, но и ГАРАНТИРОВАННЫЕ интервалы между записями в указанном Вами диапазоне.

del

Забудьте про USB в индустриальной среде.
Первое, что пришлось заменить при испытаниях на ЭМС - ноутбук с USB-485 на классический железный СОМ-порт на материнской плате PC.
USB порт просто отваливался напрочь.

По теме - вообще непонятно, о чем речь. Цель, задачи.
Действительно, конь в вакууме.
А портят заготовку и инструмент, как правило, не внешние контроллеры, а Васи, которые вместо того, чтобы к станку за несколько лямов купить ещё САПР за столько же, колхозят программу на листочке в клеточку и забивают с пульта.

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

ОК, заменяем USB на ethernet, благо полным-полно микроконтроллеров, отлично с ним работающих!
Но не параллельный порт же!

Берём CY7C68013A заливаем в неё прошивку и получаем любого из динозавров хоть LPT хоть IDE хоть .... Со своим API конечно.


Лучше тогда уж RS-485 или CAN если думать о помехоустойчивости.
А может даже что-нить wireless.

Вообще, я не понимаю этого беспокойства: если это фрезерный станок, то что-то не представляю себе, что прямо рядом кто-то будет сваркой фигачить или еще какие-нибудь наводки бешеные гнать!
USB отлично справится и ничего не будет. Если иногда и будет отрубаться — ну и что? Программно пересоединитсья — и все! Детали это не навредит, т.к. микроконтроллер просто не успеет за время пересоединения отработать заданную до этого программу!!!

Компромиссное предложение, между прямым управлением через LPT или управлением через микроконтроллер + какой-либо из интерфейсов.

Предложение такое: LPT + FPGA.
5 проводков LPT порта для первоначальной загрузки прошивки FPGA, а остальные - для обмена данными с схемой контроля шаговиков, собранной внутри этой самой FPGA.
К FPGA приделать собственный кварц, для внутреннего тактирования всех времянок. На пины общего назначения, связанные с LPT, вывести любой удобный для себя интерфейс, для опроса текущего состояния. Добавить туда сигнал экстренной остановки, и т.д.
В схеме внутри FPGA сформировать примитивы резки: прямых на заданное число шагов, резку по загруженному в SRAM шаблону, и т.п.
Касательно памяти для шаблона. Например, даже в самой "слабенькой" FPGA серии Cyclone I, EP1C3T100 - есть 6144 байт SRAM для данных. Чем "сильнее" микросхема, тем в ней SRAM объёмнее.

FPGA позволит управлять шаговиками в реальном времени, с опорой на нормальный тактовый сигнал. И при этом рапортовать о состоянии процесса управления без малейших задержек.
Также FPGA можно сколько угодно раз загружать новыми конфигурациями внутренней схемы, для разных вариантов управления.

Это и есть то, что нужно было. Где можно достать эту систему?
В развитие темы: было предложение через PCI - E вывести сигнал на контроллеры (сервоприводы, концевики и т.д.) и втыкать их в систему неограниченное количество. Картина получается примерно такая: дешёвый контроллер работает на частоте 16 МГц. Частота шины должна составлять 1/16 = 1 МГц.
Оптимальный вариант использования шины:
Сигнал делится по 10 байт (80 бит). Первый байт - стартовый (11111111) для синхронизации всех устройств в системе. Далее следует 3 байта для управления шаговыми двигателями и сервоприводами сигналами "шаг вперед - шаг назад", по 2 бита на 1 двигатель. Таким образом, 12 двигателей управляются в режиме реального времени, без дополнительных переключений между осями. Далее следует 1 бит для запроса прерывания ведомым устройством, 15 бит адреса, 14 бит данных и 18 бит пауза для обратной связи.

Чем не устраивает готовая система которую я предложил?

Без кварца здесь конечно тоже не обойдётся, но он и так стоит в любом устройстве, работающем с последовательной шиной. Хотя, изначально шина PCI или PCI-E обладает какой-то частотой. Её не кварцем получают? Может быть там синхро-импульс с мать. платы проходит?

Ответ чем не устраивает...
Будем пробовать. Пока есть сомнения, что это будет работать, в частности в нарезании резьбы.
Мне больше симпатизирует вариант без внешнего контроллера с буферизацией, что бы система работала в режиме реального времени. А то что там винда на ней крутитца или линукс - там процессор с 4 ядрами по 4 ГГц. Не дорогой, от AMD.

Это работает, и буферизация там есть, эзернет, сделано как надо. Такая разработка требует массу времени и денег.

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

Если это о моём предложении, то лучше всего - взять готовую отладочную плату, на которой установлена FPGA, и минимальная обвязка, достаточная для работы.
Например вот такая, без наворотов, плата (картинка 1) - содержит всю нужную обвязку для данного применения. Есть кварц, стабилизаторы питания, разъёмы для загрузки конфигурации схемы (те что по 10 pin), и 4 "гребёнки" по 28 pin для сопряжения с внешними устройствами. Т.е. ножек, с помощью которых можно расширить LPT-порт более чем достаточно.
Имеется ещё и микросхема памяти, из которой FPGA может автоматически загружать конфигурацию при включении.

Для микросхем этого производителя (Altera) есть среда разработки Quartus II.
Практически вся разработка может делаться только мышкой. Самый простой способ: из микросхем стандартной логики собирается схема, компилируется в файл для прошивки FPGA, загружается и испытывается.
Имеется временной графический анализатор, в котором можно посмотреть временные диаграммы работы схемы. Т.е. что будет на выходе и с какими задержками, в зависимости от того что подаётся на вход.

На второй картинке, триггер типа 555ТМ2 (74HC74), а ниже - временная диаграмма работы этой схемы, с точностью до 10 ns. На вход подан меандр, а на выходах будет получен вот такой сигнал.
Можно и что-то гораздо более навороченное анализировать, и смотреть как оно себя ведёт в зависимости от входных сигналов.

PS. Данная конкретная платка называется "ALTERA FPGA CycloneII EP2C5T144 Mini Development Board". Продаётся и на AliExpress, и в местных инет-магазинах тоже.

По всем параметрам это то, что я хотел; с ячейками и можно подключить по LPT.
https://m.habrahabr.ru/post/274829/
По поводу всей критики - принимается если станок будет в реальном времени работать и резьбу резать. Хоть по Blutus.

Это для себя/хобби, или попытка в серию поставить? Т.к. готовых красивых решений уже масса, и конкурировать с ними будет не просто... В частности есть куча плат MESA для LinuxCNC, в частности у меня отлично работает MESA 7i92 - интерфейс ethernet, соответственно гальванически отвязана от ПК, кабель любой разумной длины и нет проблем с помехами, есть варианты и PCI и PCI-E. Для Mach тоже куча всего есть... Даже если хочется делать свое - посмотрите как сделано у них.
А от LPT все потихоньку уходят, т.к. там и джиттер при генерации шагов, из-за отсутствия реалтайма нормального, и низкая частота шагов и т.д. и т.п.

LPT - тупиковый путь. И генерация шагов силами компьютера - тоже тупиковый путь. Компьютер должен строить траекторию (с учетом допустимых скоростей/ускорений и особенностей механики станка) и передавать в контроллер результат - сколько шагов на каком временном промежутке (или с какой частотой) сгенерировать для каждой оси, а контроллер генерирует шаги по полученным заданиям и обрабатывает входы от датчиков. По желанию контроллеру можно добавлять наворотов - например, обратную связь от оптической линейки для коррекции перемещения осей, процедуры хомления (обнуление осей по высокоточным концевикам), отработку сигналов аварии от драйверов моторов и т.п.
Тогда и контроллер получится сравнительно несложным и недорогим, и можно будет уйти от всех недостатков софтовой генерации шагов.
USB для станка не пойдет - слишком незащищен от помех. В идеале надо использовать какой-то промышленный стандарт связи - CAN, RS485 и т.п. В идеале - с гальванической развязкой. Ethernet тоже неплохо работает.

Автор непоколебим

Разработка своего контроллера на ПЛИС с обменом с ПК и прочими примудростями займет не меньше полугода-года. Не знаю есть ли у ТС такое время и столько запала..

Обмен с ПК и прочие высокоуровневые вещи можно сделать на микроконтроллере. Можно и генерацию шагов сделать на нем же, хотя гораздо более эффективным будет отдать эту задачу ПЛИС, с этим согласен
За PCI-E он же вроде почти готов взяться, а там проблем, мне кажется, будет побольше При том, что проблема LPT никуда не уходят - все та же непредсказуемость во временных интервалах между порциями вывода, все-таки ни Windows ни Linux не являются ОСРВ. А шаговики очень не любят неравномерность между шагами, и реагируют на нее весьма нервно - от повышенной шумности вплоть до полного срыва вращения

Ну тот же UART давно реализуем в рамках ПЛИС без использования всяких софтовых контроллеров.

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

Да я не спорю, в рамках ПЛИС реализуется практически любой интерфейс, но разбираться с протокольной частью проще все-же контроллером

Это в данном случае и есть главная проблема Тут только по верхнему софту задача далеко не на пару недель.

ТС похоже уже сдался и наши измышления ему не интересны.

Нет, я думаю он паяет проводки на PCI-E. Их там ох как много...

Новая тема называется "Управление станком по шине PCI"
Вводные: мы имеем платформу 4 ядра по 4 ГГц AMD.
Компьютер моделирует процесс работы станка в соответствии с программой, в G-кодах. Для каждой из задействованных в работе осей высчитывается положение, с частотой 1 МГц, ни больше ни меньше.
На плате имеется выход ШИМ для 20 Н-мостов и последовательная шина, совместимая с rs485, а также входы на 10 TTL датчиков. На шаговый двигатель ставится датчик обратной связи TTL. Обмотки управляются через 2 Н-моста. По последовательной шине идёт зацикленный сигнал с частотой 1 МГц следующего вида: стартовый байт 11111111, два байта адреса, два байта данных, 4 бит пауза - резерв для запроса прерывания ведомым устройством, два байта обратной связи, 4 бит пауза, затем по кругу.
Цена вопроса полсотни тысяч рублей. sayt1000@ya.ru

Хм. Но там тоже нужна FPGA По другому к той шине не подключиться (насколько мне известно). Только затраты на такое применение FPGA будут ещё бОльшие.

А чем вариант с LPT вдруг не понравился? Мне кажется, там можно рулить движками с большой точностью.
Или нужна совместимость с программами типа Mach 3 и т.д.?

Есть и DSP с шиной и мосты отдельно.

Да дело не в том какой порт взять. Заводит "наивность" : возьмем и будемуправлять из ПК без всяких причиндал и будет вселенское счастье.
ТС возжелал практически в реальном времени управлять работой станка из ПК, не учитывая что интерфейсы (RS232, LPT, да и тот же PCI-e) работают под управлением операционки, а в ней еще крутится его эфемерная программка.
Рулить с большой точностью, можно, но не всегда в реальном масштабе времени. И опять же, есть подозрение, что у ТС в качестве исполнительного узла шаговый мотор (или группа) не охваченный(ные) обратной связью. Вот он и делает "четкий" формирователь управления с наблюдением на экране осциллографа, вместо того что бы отладить "механику" и имеющийся блок внешнего управления.