"Конь в Вакууме" - это аппаратно - программный комплекс, умеющий работать как со всеми существующими, так и с перспективными интерфейсами и выполнять уже существующие и ещё нет задания.
Собственно, нужно сделать контроллер для станка и программу для контроллера.
В интерфейсе 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 отлично справится и ничего не будет. Если иногда и будет отрубаться — ну и что? Программно пересоединитсья — и все! Детали это не навредит, т.к. микроконтроллер просто не успеет за время пересоединения отработать заданную до этого программу!!!

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

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

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

Сообщение отредактировал controller_m30 - Feb 4 2017, 22:22

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

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

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

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

Сообщение отредактировал Леонид Григорьевич - Feb 5 2017, 16:00

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

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

Если это о моём предложении, то лучше всего - взять готовую отладочную плату, на которой установлена 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, и в местных инет-магазинах тоже.

Сообщение отредактировал controller_m30 - Feb 5 2017, 18:44

По всем параметрам это то, что я хотел; с ячейками и можно подключить по 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 давно реализуем в рамках ПЛИС без использования всяких софтовых контроллеров.

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

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

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