Там я LPT вижу и что-то еще, связанное с TCP?
___________
OFF: у меня тут уже полночь почти пришла. Завтра на учебу и работу рано. Хочется, конечно, поучавствовать, но надо спать идти. Не хочу спать на парте перед лектором)
Завтра днем посмотрю, что получится из обсуждения.
Всем успехов!

Можно выбирать тип интерфейса (протокола) LPT или TCP Modbus, например. Производители оборудования (сервоконтроллеров) обычно дополняют Mach различными плагинами для согласования.

Можем скооперироваться. У меня как-раз тут рояль завалялся - недорогой мост Modbus Over Serial Line <-> Modbus Over TCP. Можем с модбаса переточить на что-нибудь другое.

_Pasha а это будет коммерческая разработка или OpenServo?

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

Это уже не любительский получается. А в любительских задание ускорения, времени выполнения перемещений и т.д. выполняется в управляющей программе обработки, обратная связь – единственный сигнал ServoError объединяющий несколько ошибок (рассогласование позиции, большие и долгие перегрузки по току и т.п.) подается снова в управляющую программу. В управляющей программе при поступлении этого сигнала (по отдельному входу) происходит экстренная остановка.
Любителям всех этих наворотов, как я понял не надо. Им даже концевиков ограничения хода не надо, т.к. они тоже предусмотрены в некоторых программах.
Любителям надо НЕДОРОГОЙ, надёжный сервоконтроллер с максимальной частотой (энкодер) 100-150кГц, напряжением питания серводвигателя – до 150В, мощностью – до 1кВт. С регулируемой защитой по току. И как я уже писал желательно с интерфейсом согласования USB, т.к. многие сейчас переходят на ноутбуки (один комп – несколько станков).

А мне кажется, что "нечто over TCP" с физикой в виде Ethernet будет самое оно - объединяй в одной сети сколько надо приводов, а по помехоустойчивости и дальности эзернет на голову выше USB.

Конечно было бы ещё лучше, просто выше писали о сложностях при этом.

Покопался в доках, можно почитать, как стандартизуют ПО для ПЛК.
Программирование ПЛК: языки МЭК 61131-3 и возможные альтернативы.
Некоторые конторы указывают на соответствие своих языков пр. сервоконтроллеров этому стандарту.

В каждый контроллер смысла засовывать Ethernet в полулюбительском варианте конечно нет. Но оконцовывать контроллер интерфейсом USB тоже не есть гуд - врядли ему будет хорошо работаться в "горячей" (с точки зрения ЭМС) зоне. А выполнив физику в виде 485го интерфейса и дополнительный мост в TCP - это, как мне кажется, будет самая пися золотая. Мост могу организовать. Весьма дешево. И решится вопрос с зависанием FT232 (к сожалению, вынужден констатировать, что один из моих знакомых, занимающийся модулями телеуправления, хотя и имеет в ассортименте выпускаемой продукции конверторы 485-USB, применять их не рекомендует. Хотя у него профессиональные разработчики, но справиться с зависаниями фтэшки не смогли)

* гуд!
* RS-274D на уровне приводов избыточен и неудобен
* I2C совсем неподходит, RS232 просто не подходит - есть прекрасные RS485/RS422 или CAN. После долгих мучений с выбором я остановился на RS422, как наиболее отвечающему всем ограничениям
* терминалка с одной стороны хорошо, но с другой - сильно ограниченный и незащищенный способ обмена с девайсом. Но нет ничего проще, чем написать свою терминалку, с формированием команд в пакетах
* скорость 9600, дефолтовая для конфигурирования, и выше, для работы. Я остановился на 1 MBit - на столе вроде бы работает
* задирать сервоциклы я (бы) не стал, иначе и arm не хватит, а хотелось бы остановиться на народном avr
* интерфейс со стороны компа USB/ETHERNET/RS232/LPT - в порядке убывания
* Масh3 нужен далеко не всем
* Modbus слишком неудобный протокол. Под Масh3 лучше бы иметь свой протокол и свой плагин
* навороты любителям не нужны, это точно, но любители могут подрасти
* в интерфейсах начинал описание своего протокола Slp, но никто не поддержал. Если все же интересно, то в процессе разработки уже появились некоторые изменения
* все имхо

Тему ниасилил ввиду большого объема. К тому же FT232 ни разу не того. PL2303 немножко юзал. А FTшки на слуху отдельно от матюков не употребляются.

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


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


Громоздко несколько. Надо подумать...

Конечно, интересно! Только ссылку киньте, пожалуйста, а то за Вашими деяниями как-то не слежу. Пока не было интереса. По поводу выбора RS-422 vs RS-485, прошу Вас высказаться подробнее, почему именно 422 рулит?


Спасибо за взвешенные цифры.

По-моему слишком архаичен.

До создания своего собственного физического интерфейса и системы команд привода предлагаю рассмотреть и обсудить уже существующие решения , которые используют большие компании. По моему проще приспособится к готовому стандарту чем изобретать свой собственный велосипед. Возможно это будет несколько дороже и сложнее , но у такого варианта есть и преимущества. Ваш привод (и другая перефирия) будет совместим с оборудованием которое выпускает большая фирма, можно использовать готовый "верхний" софт , который пишет , отлавливает баги и сопровождает не один - два человека а целая коорпорация. Какими свойствами должен обладать кандидат?
Относительно низкая стоимость реализации физического интерфейса.
Гальваническая развязка.
Легкая масштабируемость и переконфигурация.
Защита от помех, сбоев и зависаний.
Автоопределение типов устройств (у каждого должен быть свой паспорт).
Высокая скорость.
Доступная и полная информация описывающая интерфейс, примеры и готовые решения.
Доступный (возможно после некоторого "лечения"), удобный и часто обновляемый "верхний" софт.

Для начала предлагаю рассмотреть EtherCAT, Sercos, PROFINET.

Ну вы тут наобсуждали. Аж волосья встают от ужасов. А для чего нужен этот сервоконтроллер и что он из себя представляет как-то забыли упомянуть, надо именно от этого и плясать. Вы бы сначала посмотрели как сделано в других готовых системах. Прежде чем изобретать чего-то. G-код к серво вообще никакого отношения не имеет, это другой уровень. Его даже вспоминать тут неуместно. Если не устраивает древний +/-10в или step-dir смотрите цифровые уже существующие решения EtherCAT, Sercos. И как у ведущих ЧПУ-строителей сделано. Ваш самодельный интерфейс ни с чем не совместимый вряд ли кому-то будет нужен, вы же не Siemens чтобы протолкнуть свой интерфейс. Выше уже была мудрая идея - приспособиться к существующему стандарту.

IMHO EtherCAT весьма перспективно. Но это не для простых "серво". Для простых достаточно и step-dir.