Jump to content

    

Разработка комплекса программа+железо LPT/USB для станков

качественно правильный вариант с точки зрения долговечности, предсказуемости и производительности - разрабатывать сразу, на старте, с использованием интерфейса PCI-Express.

Т.е. нужно взять например какую-нибудь отладочную плату с ПЛИС (Altera, Xilinx - что больше по душе) и начать с неё.

Ввод-вывод, скажем, 200-300 цифровых сигналов одновременно с низкой задержкой обработки и предсказуемости по времени исполнения требует применения именно ПЛИС.

Ну а далее, владея нструментарием, доступным в ПЛИС, вы дальше сможете не задумываясь набирать количество датчиков и исполнительных устройств исходя из принципа "а сколько надо?" вместо логики "а сколько успею?" при использовании какого-нибудь LPT или RS232/RS485.

Share this post


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

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

 

Share this post


Link to post
Share on other sites
...Под 64bit драйвера нет, вот вся эта их поделка и не работает.

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

InpOut32

InpOut32-x64

Share this post


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

Так что может пусть МК дублирует полностью работу ПК - в таком случае шансы получить неожиданную деталь снизятся.

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

 

разрабатывать сразу, на старте, с использованием интерфейса PCI-Express.

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

Про EtherCat: сервопривод с EtherCat стоит на 9000р дороже абсолютно такого же без EtherCat.

Share this post


Link to post
Share on other sites
Выбор порта LPT, не в пользу остальных, обусловлен двумя факторами: высокой скоростью работы (на практике) и его простотой, пониманием его устройства. Со временем можно добавить возможность работы через USB

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

Считаю идеологически верным подходом изготовление отдельного блока системы управления (БСУ).

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

 

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

Так что может пусть МК дублирует полностью работу ПК - в таком случае шансы получить неожиданную деталь снизятся.

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

 

Share this post


Link to post
Share on other sites
Все есть. Этот вопрос решили радикально. С исходниками.

InpOut32

InpOut32-x64

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

Никаким решением тут не пахнет.

 

 

 

 

 

Share this post


Link to post
Share on other sites
Считаю идеологически верным подходом изготовление отдельного блока системы управления (БСУ). Управляющую программу в БСУ заливать из ПК по USB, Ethernet или любым удобным способом. БСУ будет формировать управляющие воздействия независимо от ПК и так, как Вам нужно.

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

 

 

Edited by @Ark

Share this post


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

Напоминает один из законов Мерфи "Измеряй микрометром, отмечай мелом, руби топором".

Я конечно далек от металлообработке, но измерять или симулировать нарезку резьбы с помощью осциллографа - это смело!!! :bb-offtopic:

Share this post


Link to post
Share on other sites

Физика стала точной наукой когда взяла в руки весы.

В нашем случае есть 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 шагов оборот) и работа с неограниченным количеством датчиков и реле.

 

Это просто дырка для обращения к физическому адресу

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

Share this post


Link to post
Share on other sites
Это уже половина того, что нужно....

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

Share this post


Link to post
Share on other sites

del

Edited by Эдди

Share this post


Link to post
Share on other sites
Зачем так усложнять, если есть USB?

Забудьте про USB в индустриальной среде.

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

USB порт просто отваливался напрочь.

 

По теме - вообще непонятно, о чем речь. Цель, задачи.

Действительно, конь в вакууме.

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

Share this post


Link to post
Share on other sites
Физика стала точной наукой когда взяла в руки весы.

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

Вы тут путаете. равномерно отображаемые осциллографом импульсы это еще не факт равномерного же поворота ротора двигателя.

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

Share this post


Link to post
Share on other sites
Забудьте про USB в индустриальной среде.

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

Но не параллельный порт же!

Share this post


Link to post
Share on other sites
LPT окончательно умер 10 лет назад, 232 готовится следом.

Нет никакого смысла гальванизировать.

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

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

 

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

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

А может даже что-нить wireless.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this