[haker_fox 61]

Вот Screen из Mach.

Там я LPT вижу и что-то еще, связанное с TCP?

___________

OFF: у меня тут уже полночь почти пришла. Завтра на учебу и работу рано. Хочется, конечно, поучавствовать, но надо спать идти. Не хочу спать на парте перед лектором)

Завтра днем посмотрю, что получится из обсуждения.

Всем успехов!

[arisov 0]

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

[Rst7 5]

TCP не надо: поголовно никто ставить не будет, а в качестве опции - вот, мосты всяческие ETHERNET<->RS-485.

 

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

[arisov 0]

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

[Duhas 0]

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

[arisov 0]

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

Любителям всех этих наворотов, как я понял не надо. Им даже концевиков ограничения хода не надо, т.к. они тоже предусмотрены в некоторых программах.

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

[Rst7 5]

И как я уже писал желательно с интерфейсом согласования USB, т.к. многие сейчас переходят на ноутбуки (один комп - несколько станков).

 

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

[arisov 0]

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

[evgeny_ch 0]

...

"В команды контроллера" - слишком расплывчатое определение. Интересно, насколько это стандартизовано.

Покопался в доках, можно почитать, как стандартизуют ПО для ПЛК.

Программирование ПЛК: языки МЭК 61131-3 и возможные альтернативы.

Некоторые конторы указывают на соответствие своих языков пр. сервоконтроллеров этому стандарту.

[Rst7 5]

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

 

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

[VCucumber 0]

* гуд!

* RS-274D на уровне приводов избыточен и неудобен

* I2C совсем неподходит, RS232 просто не подходит - есть прекрасные RS485/RS422 или CAN. После долгих мучений с выбором я остановился на RS422, как наиболее отвечающему всем ограничениям

* терминалка с одной стороны хорошо, но с другой - сильно ограниченный и незащищенный способ обмена с девайсом. Но нет ничего проще, чем написать свою терминалку, с формированием команд в пакетах

* скорость 9600, дефолтовая для конфигурирования, и выше, для работы. Я остановился на 1 MBit - на столе вроде бы работает

* задирать сервоциклы я (бы) не стал, иначе и arm не хватит, а хотелось бы остановиться на народном avr

* интерфейс со стороны компа USB/ETHERNET/RS232/LPT - в порядке убывания

* Масh3 нужен далеко не всем

* Modbus слишком неудобный протокол. Под Масh3 лучше бы иметь свой протокол и свой плагин

* навороты любителям не нужны, это точно, но любители могут подрасти

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

* все имхо

[_Pasha 0]

Дешёвые конвертилки на FT232 почему «отваливаются» с сервоконтроллером

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

 

Можем скооперироваться. У меня как-раз тут рояль завалялся

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

 

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

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

 

 языки МЭК 61131-3 Некоторые конторы указывают на соответствие своих языков пр. сервоконтроллеров этому стандарту.

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

 

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

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

 

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

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

[haker_fox 61]

Можно выбирать тип интерфейса (протокола) LPT

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

[dpss 9]

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

Относительно низкая стоимость реализации физического интерфейса.

Гальваническая развязка.

Легкая масштабируемость и переконфигурация.

Защита от помех, сбоев и зависаний.

Автоопределение типов устройств (у каждого должен быть свой паспорт).

Высокая скорость.

Доступная и полная информация описывающая интерфейс, примеры и готовые решения.

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

 

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

[slog 0]

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

 

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