Настройка EMC2 на работу с COM(RS-232) портом

[Nick]

По сервам все примерно так, но по шаговикам период короче.

Или ты предлагаешь сделать контроллер, который будет управляться как серво, но сам сможет управлять шаговиками?

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

[Impartial]

Не короче, а точно такой же. ЕМС понятия не имеет, что у него там прицеплено серва, шаговики или еще чего. Этим занимается секция внутренних компонентов.
Согласно документу The HAL "(Hardware Abstraction Layer) Handbook" раздел 7 "Internal Components"
ЕМС может быть настроен на выдачу (на систему управления) или параметра позиции или скорости, а вот эти внутренние компоненты уже непосредственно управляют оборудованием ( там картинки есть понятные). И сделать такой контроллер несложно, еще проще на жесткой логике. Правда настраивать надо будет уже не хал, а кишки этого контроллера под конкретное оборудование.

[Nick]

Хорошо, если решение все равно принимается раз в серво-период, то какую глобальную выгоду мы получим от такого контроллера?

1. Перенос управления на USB.
...
Что еще?

[Impartial]

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

[Nick]

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

Итак, что нам нужно для реализации такой платы?

[Impartial]

Да немного надо.
Взять например такую плату "http://www.marsohod.org/index.php/howtostart/plata" и пописать чуток на верилоге или на каком нибудь еще НДЛ .
Можно вообще в квартусе нарисовать схему ничего не программируя.
Могу дать приблизительную оценку необходимого.
Контроллер RS-232 приблизительно 54 LEs.
Адресация MODBUS еще 28.
ПИД регулятор или синтезатор частоты для шаговиков 100-150 LEs.
Квадратурный енкодер и счетчик к нему 25-30.
Ну и портов ввода-вывода по желанию/необходимости.

[adif]

Вот если бы кто то сочинил схемку такого устройства (только не очень сложного ну типа как народ есть делает для мача под usb)то могбы поучавствовать в качестве тестировщика, собрал бы схему и испытал бы на станке только для шагового привода. А вот сам схемку я не осилю, тем более программировать

[Nick]

Да, я тоже со схемотехникой не дружу, зато могу помочь в программировании...

[Impartial]

Для начала надо переписать драйвер PLUTO_P для работы с /dev/ttyUSB0 вместо lpt в EPP режиме, скорректировав некоторые параметры обмена.
Сможете?

[Nick]

"Кал вопрос, сделаем".
Ссылочка на сорцы есть?
Нужно определиться с местом хранения кода. С bazaar всем удобно работать?

[Impartial]

Здесь все исходники ЕМС2 версии 2.4.4
http://sourceforge.net/projects/emc/fil ... z/download
В каталоге \emc2-2.4.4\src\hal\drivers\pluto*.* исходники того что надо доделать
Ну или рихтануть драйвер MODBUS
\emc2-2.4.4\src\hal\user_comps

[psha]

Ссылочка на сорцы есть?
Нужно определиться с местом хранения кода. С bazaar всем удобно работать?

Господа, не выдумывайте глупостей
Исходники живут здесь:
http://git.linuxcnc.org/gitweb?p=emc2.git;a=summary
ссылка для клонирования
git://git.linuxcnc.org/git/emc2.git

2.4.x версии находится в ветке v2.4_branch

[Nick]

Да, точно, что-то я туплю .

Правда не факт, что нам дадут в основную ветку пихать свой код. Особенно в момент разработки...

[psha]

Это же git, там никто никому ничего не должен.
Я вот веду свои ништяки в своем же репозитории, но регулярно обновляю его из главного.
Это не svn

[Nick]

Итак нам нужно переписать pluto_comon.h, и переписать в нем функции записи и чтения.

Также можно изменить pluto*.comp - компоненты hal, которые общаются с платой.

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

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

[psha]

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

Есть подозрение что ни одна из библиотек не подойдет. По простой причине - функции чтения и записи работает в контексте ядра.
Посему и пользоваться можно только тем, что есть в ядре. То есть никаких библиотек нет и не будет.

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

[Nick]

Разумно!

Но, опять же нужно знать какими данными мы собираемся обмениваться.
Тут возникает вопрос, насколько универсальным будет контроллер. Будем ли мы ему гнать просто сырые значения для выходов или структуру вида "выход" "тип" "значение"?

[psha]

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

Ну я просто к тому веду, что этот вопрос никак не связан с тем, чем надо пользоваться.
Собственно усбшные API не очень сильно различаются, что libusb, что ядро, а никакой специфики (например, libftdi) сюда прикручивать смысла нет.

Кстати, насколько я понимаю, на данный момент самым перспективным способом связи считается Ethernet.
Например, вроде как, Mesa собирается в этом году выпустить какую-то свою карточку на нем. По многим параметрам
он значительно лучше USB (latency, глючность), по некоторым - хуже (нужен отдельный phy, для усб куча программных библиотек для avr и компании)

[Nick]

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

[Impartial]

Наиболее просто, на мой взгляд, переделать драйвер MODBUS. Просто добавить скорость 921600 и связать его с /dev/ttyUSB0 как СОМ порт.
Контроллер получится универсальным, на все случаи жизни, а главное простым и дешевым, что очень важно для хоббийного применения.
Архитектура мне представляется такой:
Со стороны компа FTDI FT232BM, оптронная развязка RX,TX,RXEN,TXEN и ST485, DC/DC 5V/5V для питания канального приемопередатчика. Все это хозяйство будет питаться от USB.
Со стороны оконечного устройства в сети:
ST485,оптронная развязка RX,TX,RXEN,TXEN тот же DC/DC для питания канального приемопередатчика и CPLD EPM240 или FPGA CYCLONE с разведенными на разъем ножками.
Все оконечные контроллеры одинаковые по схемотехнике.
Далее по смыслу того, чем будет управлять контроллер.
Если это привод (серво, шаговик , шпиндель или еще чего), то опторазвязанные силовые ключи или специализированные микрухи управления, если концевики /реле то просто опторазвизка.
Контроллеры будут различаться только вшитой в них логикой.
А Вы говорите не очевидная мастабируемость.
Например, для управления станком на четыре оси потребуется от 3х до 6 таких контроллеров.
Это то, что касается схемотехники.
По протоколу обмена:
Протокол 9 битный, девятый бит вместо паритета является признаком адресации.
Передаем один байт с мастера со следующей информацией:
Адрес устройства, операция (запись/чтение), (адресуем максимум 128 контроллеров), далее пакет, CRC8.
Структуру пакета надо расчитать исходя из двух главных параметров: Максимальная битовая длина равна 421 бит, время 1 мс. ( жестковато получается 210 бит в каждую сторону а еще и на зазор надо оставить).
Вся информация в пакете целочисленная.
Расчет производится из следующих соображений.
1. Какое максимальное количество импульсов можно получить с енкодера за 1мс.(имеем длину счетика энкодера)
2. Какое максимальное количество импульсов надо подавать на шаговик за 1 мс для обеспечения разумной максимальной скорости перемещения осей.
3. Максимальная градация по шим.
4. Максимальное количество портов портов ввода вывода.
Хотелось бы услышать соображения практиков на эту тему.
Вот собственно и все.
На днях постараюсь нарисовать и выложить схемы всей этой канители.