Доброго времени суток! "Заболел" я созданием мелкого сервоконтроллера. Очень хочется поговорить о системе команд, поскольку то, что я наблюдаю в 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-код в команды контроллеров (!) привода.
Насчет стандартов не знаю, я же бывший.

Сообщение отредактировал evgeny_ch - Feb 16 2009, 15:16

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

А команды:

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


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

Вопрос риторический, ответа не имеет... Ведь и 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.