Доброго времени суток! "Заболел" я созданием мелкого сервоконтроллера. Очень хочется поговорить о системе команд, поскольку то, что я наблюдаю в openservo, elm-chan и в аппликухах microchip, не нравится. Думаю, может лучше подмножество G-кода огранизовать? Кто из сервостроителей имеет свое мнение на сей счет? Только не надо Siemens и т.п. цитировать - немножко уровень полулюбительский должен остаться. В идеале хочется, чтобы в конце обсуждения появился некий маленький "стандартик" на систему команд и применяемые интерфейсы и протоколы. Или организую RS-274D, если это никому не интересно. 

Вы имеете в виду эти странные Dir & Step? Если речь о них, то я тоже не могу их назвать удобными, т.к. никакой полезной инфой с сервой не обменяешься. Ни конфиги принять/передать, ничего.

Беглое знакомство с G-кодом говорит, что он скорее предназначен для программирования уже готовой системы, например станка. А серва это лишь периферия ЧПУшного оборудования. Кстати, подобная проблема обсуждалась в моей ветке по приводу, вот только плохо помню, где она. Но там пришли к выводу, что можно (и я реализовал, кроме I2С) сделать два интерфейса: RS-232 и I2C. Первый для сервисного обслуживания, т.е. для работы "на столе" потестировать, настроить, что не исключает подключение по нему и к системе более выского ранга. Второй - как раз ориентирован для работы в системе. Над протоколом I2C, к сожалению пока еще все не думал, так вышло( Но как основу хотел покопать протокол на www.openservo.com . Там тоже серва по I2C управляется.

Всеми четырьмя лапами за!!!) Все равно это прорабатывать придеться в будущем. Почему бы не заняться сейчас?!

Ну что Вы, интерес есть!

Что касается меня, то я придерживаюсь пока двух интерфейсов, как написал выше.
Интерфейс для RS-232 создан по образу одного из микрочиповских аппноутов. Т.е. примерно это я ввожу в терминалке:

Где доллар - приглашение командной строки сервы.
m - задать вручную значение PWM.
250 - непосредственное значение. Все подтверждается ENTERом. Редактирование не возможно. Т.к. программа сервы это не поддерживает.
Все остальные команды в подобном стиле. Например * позвояет посмотреть все текущие настройки сервы (параметры ПИДа, заданной скорости и тд). В общем, все пока примитивненько. Но общими силами может быть и получится что-то? Очень надеюсь на это!!!

Паша, респект!

В станках G-код преобразуется (скажем постпроцессором) в команды контроллера.
Долго и нудно описывать, назову группы.
Калибровка привода.
Отображение состояния.
Включение/выкл. функций.
Сброс, запись, чтение, сохранение, ожидание.
Тестовые.
Знач. параметров двигателя, энкодера, регуляторов.
Величина и тип перемещения.
Ввод программы, загр. прогр. в EEPROM, старт программы.
И пр. мелочи.

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


Т.е напрямую G-код на контроллер сервака никогда не поступит? "В команды контроллера" - слишком расплывчатое определение. Интересно, насколько это стандартизовано.

А зачем всё это? Для полулюбительского уровня мне кажется уже достаточно G-code. Другое дело – интерфейс. Для самодельщиков-ЧПУшников актуально будет управление через USB или ТСР, т.к. LPT «отходит». И ориентироваться надо, на мой взгляд, на самую популярную программу Масh3.

Нет смысла передавать G-код в контроллер, это снизит быстродействие.
Хост (PLC, например) транслирует G-код в команды контроллеров (!) привода.
Насчет стандартов не знаю, я же бывший.

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

А команды:

Меняются версии, контроллеры, вместо простенького пульта компьютер... протокол изменять надобности нет.


Да-да-да. Есть такое подозрение Только хоцца и объять необъятное и определить нужный людям уровень универсальности.

Вопрос риторический, ответа не имеет... Ведь и elm-chan когда-то создавался...

TCP, пожалуй, тяжеловато да и монстрообразно для привода. Хотя при современном спектер недорогих армов вполне. Но речь идет об интерфейсе не системы ЧПУ, где эти интерфесы как раз, а о серве. Где можно применить дешевый AVR или PIC, но поднять USB или TCP на их бортах дело тяжелое, да и зачем?

Есть еще RS-232. И дешевые конвертилки RS-232<->USB. Поэтому (ИМХО) RS-232 забывать не стоит)

А какой смысл применения своих команд, если это никакой прогой не будет поддерживаться? Возможно это пригодиться только единицам.

TCP не надо: поголовно никто ставить не будет, а в качестве опции - вот, мосты всяческие ETHERNET<->RS-485. А потом, возможно, придется двигаться в сторону RTP (все равно рано или поздно к этому придут) - это уж точно ни в какой  АВР не влезет

Дешёвые конвертилки на FT232 почему «отваливаются» с сервоконтроллером, при чём не только у меня.
http://kazus.ru/forum/topics/14286.html

И здесь http://forum.rcdesign.ru/f41/thread40981-5.html#post1037070 начиная с сообщения №165

А как быть с физическим интерфейсом? Или он не будет особой роли играть, главное команды? Этот уровень, я тоже сейчас до шел до этого, нужно пытаться делать совместимым с чем-нибудь стандартным, но не особо навороченным, возможно со своими подмножествами.

Как все-таки по поводу Rs-232 для подключения к кому, чтобы можно было из терминалки с приводом пообщаться? Ведь не всегда под рукой будет спецсофт, да стойка ЧПУ, а вот комп с примитивным терминалом обычно есть... (ИМХО). Да и для матлаба такой интерфейс, наверно больше подходит. Я вот сейчас пытаюсь в матлаб со своего привода данные гнать, для моделирования... RS-232 в этом деле как раз кстати: простота, куча примеров в инете... и тп.

Если уж с терминальной программой «отваливается», то чё уж тогда говорить о непосредственном управлении.

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


Так я и не предлагаю RS-232 для непосредственного управлениея Ну а "отваливание" нужно решать. Интерефейс-то из за этого игнорироваться не должен

Вот Screen из Mach.

Там я 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.

Интересно, а есть ли различие в плане интерфейса привода станка и привода робота? Хотелось бы не только на привод станка ориентироваться.


Это действительно упущение, хотя выше и предполагалось

Но надо детализировать.

Так идеи протолкнуть интерфейс вроде бы и не ставилось.
Просто EtherCAT и другие предложенные базируются на ETHERNET, как я понял. Довольно таки монстрообразно. Хотелось бы на AVR-подобные МК уложиться. С другой стороны на AVRке серьезный привод вряд ли можно сделать. Получается, что мы хотим создать что-то среднего класса.
По поводу стандартного интерфейса: можно ведь создать при необходимости переходник наш_интерфейс<->что_то_стандартное. А вот команды может быть можно и ближе к распространенным стандартным взять.

Вот здесь похожее обсуждалось http://www.cnczone.com/forums/showthread.php?t=42373

Step-dir это самый простой и надежный интерфейс, сам делаю на этом(от ЦАПа отхожу). Но это под ЧПУ реального времени. А под Windows это плохо работает
(у меня), поэтому видимо выход как раз допустим M команды типа <М96.1000> - повернуть вал двигателя на 1000 импульсов датчика. Это особенно подходит
для роботов и манипуляторов, где простой командой можно повернуть "руку" на определенный угол. А также это нужно, что-бы программировать сам привод допустим P командами и практически не нужны встроенные пульты на блоках управления. Все же не соглашусь, что в реале не нужно изменять какие ли бо параметры. Как раз таки параметры типа разгон торможение и т.п. удобнее на "ходу" регулировать и для опытного электронщика методика настройки из книги не нужна, он это на "глаз" сделает и под конкретное железо. А RS-422, я согласен, рулит. Не знаю, мое мнение на счет
МК. Все же лучше применять 16 разрядные МК, типа dsPIC30/33 да и по цене они не намного дороже, и переферия мощная и все есть.

Ой )


http://electronix.ru/forum/index.php?showt...495&hl=slp*


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

1. Как раз хочу охватить CNC и применения в манипуляторах. "Первый блин" - 24В/4А на базе L298, но это ничего не значит. Надо платформенно-независимые вещи разрабатывать.


2. А как же : изначально заложил 4-20мА и step/dir/limit_switch. 

Еще PROFIBUS очень интересен. Надо вкурить подробнее.

Вот "отец - основатель" EtherCAT. http://www.beckhoff.com/ http://www.beckhoff.ru
Есть международная ассоциация www.ethercat.org
Самый быстрый интерфейс реального времени на основе эзернета.
PLC , декодер G кода , профиль движения, интерполяторы делаются программно с использовнием TwinCAT который
сделан из CODESYS.

Блин, занесло всех в эзернет! Ну нельзя сразу его закладывать! Рано еще. 

Для кого рано? На самом деле не так страшен черт как его малюют. Зато сколько преимуществ. Одни готовые библиотеки трансформации координат чего стоят.

Я тоже так считаю. Так что же выбрать в качестве пока еще физического интерфейса?

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

Пусть будет два девайса: мост эзернет в какой-нить RS485 либо Ether->PLC->[step/dir/Analogue] Но в одном флаконе - рановато


Тогда повторяю вопрос: каким выражением (алгебраическим, ессно, а не матерным) можно отобразить требования по максимальному времени доставки сообщения и получения ответа ???

Можно ориентироваться на частоту с которой работает токовый регулятор в приводе. Частота обновления командного регистра положения 0.5 - 0.1
от частоты токового регулятора.

Мда-с... Зураб Церетели отдыхает на DIN-рейке

Временем реакции системы на самое быстрое событие, делённым на количество управляемых осей.
Тип интерфейса определяется вовсе не скоростью, пмсм. Есть ещё помехоустойчивость и пр. простые вещи.

О! Уже что-то очень ценное! Спасибо. Частота токового регулятора == длительность сервоцикла ? 

Вот, пожайлуйста, еще одна причина делать rs422, но не что-нибудь еще.


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

Нет, даже еще хуже: деленным на количество устройств в сегменте сети. Их может быть немного больше чем осей Действительно, до фига большая скорость



Ну, допустим, как снизить частоту обновления, понятно всем: использовать макроязык с интерполяторами. Зачем апдейтить координату еще и с дисперсией времени доставки, когда можно ее хоть кусочно-линейно хоть сплайном интерполировать. А кто знает уже готовые устоявшиеся решения?

Можно использовать дешевый пластик POF . Есть программа MOST перевода автомобильной электроники на этот пластик.
http://www.pofto.com/ Аваго , Инфенион, Тайко собираются выпускать дешевые приемники и передатчики под этот стандарт.

А я воспринял Ваше сообщение, как иронию. Или неправильно воспринял?

Теперь, если стремиться снизить требования к коммуникационному каналу, получается, что  рулят Techno IL и Techno ST

http://www.adastra.ru/products/overview/IEC61131/

ЗЫ: а если сервоцикл уложится в один период ШИМ? Причем это будут честные 4 кГц