Кажется...тема умерла.


2 slog: согласен по всем пунктам

Меня пугает даже не упавшая, а максимальная скорость UARTа в Меге. Я уже делал серво с интерфейсом на 12 мегабит. Этого в притык хватило для управления 4-мя осями. И без всяких сложно-наворочанных протоколов. Еще и протокол и так примитивный оптимизировать под максимальную скорость пришлось. Но для простого позиционирования одной оси большая скорость обмена конечно не нужна.

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

Делаю шаг назад, и вот почему:


ASCII - в процессе разработки, но сразу скажу, что там с игнорированием регистра, поскольку делать из юзеров неврастеников неприлично.
Умерла тема? Не дождетесь!

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



ЗЫ: посоветуйте, надо ли в рамках бинарного потока сигналить об аварии или достаточно сделать это в текстовом виде?

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



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

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

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

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

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

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

- не защищен

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

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

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

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

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

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

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



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

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



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

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

 



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

Добавил (текстовый режим):



Еще. Например, выполняется команда, а нам неймется в текстовом режиме 

обратиться к девайсу



Таким образом, других сообщений от слейва не надо, кроме {"OK","BUSY","ERROR"}

На какую комбинацию клавиш лучше  ввести  экстренный стоп?

^C, че за вопрос

^C - это скока? Помню ^Z=26, а это - забыл

И вот еще мысль:

Пусть нам надо переместиться по одной оси, но взять текущую координату с другой и че-то там с ней сделать

Хочу еще попробовать навернуть конструкции типа X.S, т.е. обращение к другому девайсу 



Выполнение этого уже требует разговора двух девайсов. Не вижу сложностей:



В общем-то, логика не нарушается, потому что мастер по-прежнему инициирует обмен

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

=3



Ох сдается мне, что для таких вещей лучше CAN. Девайсы флудят своим состоянием в шину, а кому надо - настраивает свои фильтры на интересующий ID - и гребет всегда свежие данные.

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

В BIN-е фантазии кончаются, начинается скорость. Как только скорость оставляет желать и начинают хихикать сторонники 12мегабит, имеется еще более тупой и адекватный интерфейс - step/dir/an


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

Надо бы Вам ко мне в гости зайти. Я покажу, как делается комфортно для юзера

Продолжу про оптику.
Упоминаемый уже Бекхоф, с интерфейсом Lightbus, он же Sercos,
переходит на CoDeSys. Почитал немного из форума.
Картинка из каталога.