Система команд сервоконтроллера, обсудим? Опции

[_Pasha]

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

[Rst7]

Протокол 8-E-2

Эээ, я не очень понял, данные передаются по инициативе контроллера? Или запрашиваются мастером?

надо ли в рамках бинарного потока сигналить об аварии или достаточно сделать это в текстовом виде?

Хотя бы флаг аварии надо передать. А расшифровку можно уже и потихоньку текстом забрать.

Но есть ли смысл реализовывать текстовый протокол вообще? Как по мне, так и не очень...

[_Pasha]

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

1. Мастер - инициатор обмена. Следовательно запрашиваются мастером

2. Какой нибудь MAGIC... вот: использовать несимметричность signed char, т.е в отдаваемом приращении 0x80 -ето туши свет

3. Вы его еще не видели  
PS текстовый - в первую очередь для возможности управлять, причем всем сегментом сети, из терминала. Отсюда некоторые особенности:

Код

1. Единица обработки команды - строка, заканч. 0x0d или 0x0a - настраивается
2. Команды широковещательные, адресные и может быть приватные сообщения между слейвами
3. широковещательные, адресные - идут от компа, читай - от юзера, поэтому для проверки правильности делаем эхо обратно
4. приваты - в конце добавляется CRC8, пусть слейвы между собой разбираются :)
*****Как это выглядит *****
команда назначения имени и адресу
assign x=0x04
девайс отвечает
@x: assign x=0x04 OK
Дальше что-то пишем ему
x: S+=20
@x: S+=20 OK

[Огурцов]

Если таки речь не про профибас: Текстовый режим плох по многим причинам. Сходу:
- не защищен (если не собираетесь заставить юзера руками считать crc)
- избыточен, раза в два примерно (а канал и так довольно узкий)
- требует для дешифрации больших ресурсов в слейве (особенно если давать командам осмысленные имена)

[_Pasha]

- не защищен

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

Из предыдущего моего поста: x: S+=20 после получения команды можно сделать сразу эхо, а можно после выполнения

- избыточен, раза в два примерно 

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

- требует для дешифрации больших ресурсов в слейве 
"На лету" ничего делаться не будет в текстовом режиме. Получил - сверился- выполнил - отчитался.
В бинарном режиме, по получении MAGIC 0x80, сигнализирующем об аварии, хост останавливает процесс элементарно - переходом в текст. Остальные - услышали MAGIC и стали, а для "особо понятливых" - сработает тайм-аут "потеря связи" по прекращению бинарного потока (планируеццо 3,5 символа) Кстати, тайм-аут в символах на полудуплексе ваще удобно делать - Dummy writes при выключенном драйвере 485

ЗЫ какой из меня парсер сообщений!

Следующая "умная мысль". Структура строки

Код

[#<идентификатор потока>] [<имя устройства>:] [<команда1> [;<команда1>]]

идентификатор потока: число 1-99

имя устройства: идентификатор

команда1: семейство команд модификации регистров S,V,M,T

Идент. потока нужен для задания синхронного начала исполнения команд. 

По именам регистров: регистр момента предлагаю назвать M,а не T(torque) потому что иначе нечем назвать время



Еще вопрос из другой оперы: кто как считает ресурс/наработку сервака?

Имхо есть смысл считать отдельно:

Код

1. Моточасы, т.е. общее время в работе силовухи

2. Счетчик общего пробега

3. Время нахождения в режиме с ускорением

 



По поводу бинарного протокола: +статистика: общее число принятых пакетов, число подтвердженных.