Разработка комплекса программа+железо LPT/USB для станков, Рабочее название "Конь В Вакууме" Опции

[Леонид Григорьев...]

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

[Леонид Григорьев...]

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 связано ещё с тем фактом, что прошивка контроллеров через порт LPT проходит в 2 раза быстрее, чем по USB

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

В природе возможно это есть, нужно искать. Или создавать.

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

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

aliexpress, ebay

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

[Raven]

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

Ну, вообще-то 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.

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

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

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

[zltigo]

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

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

[Raven]

...Под 64bit драйвера нет, вот вся эта их поделка и не работает.

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

[Эдди]

del

Сообщение отредактировал Эдди - Feb 3 2017, 05:39