Продолжение темы "Разработка нового контроллера".

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

Это продолжение первой части.

Тестеры и разработчики читаются тут, остальные не пишут: ТУТ ТОЛЬКО ЧИТАТЬ, ЕСЛИ ТЫ НЕ ЗАЯВЛЕННЫЙ ТЕСТЕР!

unsigned char all[2]; //буфер для приема данных с ПК
Этот буфер лишний в программе, так-как программа сама уже сгенерировала буфер, по приему которого вызываеться прерывание: // USART Receiver interrupt service routine
Сейчас размер этого буфера 100 байт: #define RX_BUFFER_SIZE 100, а нам нужно всего 5 байт, если посылка будет примерно такого вида ~255~~a01~~a02~~a03~~a04~
Тоесть нужно сделать так:
#define RX_BUFFER_SIZE 5
и в основном цикле пользоваться этим буфером:
проверка на 255 = rx_buffer[0];
1 ось = rx_buffer[1];
2 ось = rx_buffer[2];
3 ось = rx_buffer[3];
4 ось = rx_buffer[4];

Я не согласен с замечанием andrik. такой подход совершенно не учитывает возможные нарушения и сбои на линии связи. К примеру, что делать, если в 255 будет находиться не в rx_buffer[0], а в rx_buffer[3]?

В этом смысле код от Pavel155 более помехозащищенный, но и в нем не все гладко. К примеру, не контролируется тот факт, что принята ВСЯ посылка от компа. Т.е. наличие в буфере приема байтов (символов) "AB" совсем не гарантирует, что и последующие данные тоже уже в приемном буфере

Я когда писал код для приборки, перед каждым типом данных у меня стоял идентификатор, например F~a01~S~a02~("F" топливо, "S" скорость). Никакого буфера я совсем не использовал. Анализ и присвоение данных переменным я выполнял непосредственно в прерывании по приему байта. Данные были 8 и 16 битные. Тестировал долго - сбоев не было совсем, осей не помню сколько, но не меньше 6-ти.
Вот мое видео если кто не видел http://youtu.be/GPZldX_BYUg

Ale
А как по твоему мнению сделать правильнее?


(Добавление)
AlexVr
Твое сообщение здесь http://mal4x.ru/viewtopic.php?p=4739#4739.

Ale писал(а):К примеру, что делать, если в 255 будет находиться не в rx_buffer[0], а в rx_buffer[3]?

Такие варианты вoзмoжны как-раз в кoде Павла, так-как в нем каждый принятый байт засoвываеться в unsigned char all[2]; без всяких прoверoк. Кoдвижен любезнo сoздал целую функцию для успешнoгo приема нужнoгo кoличества байт, и oна oтличнo рабoтает в реальных устрoйствах.

такой подход совершенно не учитывает возможные нарушения и сбои на линии связи

Какая вероятность этих сбоев ?
ИМХО: при наших расстояниях кабелей и возможностях МК их недолжно вообще быть.

Кoдвижен любезнo сoздал целую функцию для успешнoгo приема нужнoгo кoличества байт, и oна oтличнo рабoтает в реальных устрoйствах.

Вынужден Вас огорчить. Ничего Кодвижен не придумывал. То, что Вы предлагаете - будет работать только в ИДЕАЛЬНЫХ условиях, а именно - ни одного сбоя на линии связи, определенная последовательность включения устройств и программ, и.т.д. Стоит подключить или ресетнуть контроллер вовремя приема посылки, последовательность расположения байт в приемном буфере вполне может измениться. Ведь фактически Кодевижен делает следующее:
1 - пишет принятый байт во входной буфер по определенному указателю
2 - инкрементирует указатель
3 - если указатель превышает размер буфера - обнуляет его (переводя на начало буфера)

Никаких проверок, вообще ничего. И если, не дай БО, во время сбоя/включения/ресета контроллер пропустит первый байт посылки, вы так и будете его до бесконечности искать rx_buffer[0], а он преспокойно будет всегда попадать в другое место буфера.

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


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

Как работает софт на компе? Посылает ли он через ОПРЕДЕЛЕННЫЕ пользователем интервалы времени текущие ПОЛОЖЕНИЯ осей?
Т.е. если я задал, предположим, интервал в 10 мс, означает ли это, что софт с частотой 100Гц будет высылать мне на контроллер посылки с положениями всех осей. И если ось не перемещалась, то будут посылаться посылки с одинаковыми значениями?

Альтернативой может служить способ передачи событий. Т.е. передавать данные только тогда, когда положение оси изменилось.

(Добавление)
И в догонку - а не посылает ли софт еще какую нибудь инфу? типа скорости перемещения оси в заданное положение? Пока, по описаниям на форуме, получается, что только положение передается. А может ли передаваться всякая скорость, ускорение (именно по осям, а не болида целиком)?

Ale писал(а):И если, не дай БО, во время сбоя/включения/ресета контроллер пропустит первый байт посылки, вы так и будете его до бесконечности искать rx_buffer[0], а он преспокойно будет всегда попадать в другое место буфера.

Наверно мы друг друга не поняли, но тот вариант который я предлагаю уже пол года работает в 5D кинотеатре в неидеальных условиях и ни одного сбоя.

Ale писал(а):Как работает софт на компе? Посылает ли он через ОПРЕДЕЛЕННЫЕ пользователем интервалы времени текущие ПОЛОЖЕНИЯ осей?
Т.е. если я задал, предположим, интервал в 10 мс, означает ли это, что софт с частотой 100Гц будет высылать мне на контроллер посылки с положениями всех осей. И если ось не перемещалась, то будут посылаться посылки с одинаковыми значениями?

Абсолютно верно. По другому не умеет. У хсим есть SDK для разработки плагинов для внешних интерфейсов и при большом желании можно написать свой.

Ale писал(а):И в догонку - а не посылает ли софт еще какую нибудь инфу? типа скорости перемещения оси в заданное положение? Пока, по описаниям на форуме, получается, что только положение передается. А может ли передаваться всякая скорость, ускорение (именно по осям, а не болида целиком)?

Нет насколько я понимаю.

Наверно мы друг друга не поняли, но тот вариант который я предлагаю уже пол года работает в 5D кинотеатре в неидеальных условиях и ни одного сбоя.

Вполне возможно. Я просто делился своим опытом ))

Так вот, про регулирование, ПИД и прочее. Думал, сделаю революцию, но потом внимательнее почитал код, присланный Pavel155. И понял, что революции не получится

Что такое есть ПИД (ИМХО) - это непрерывное вычисление нового значения регулятора для оптимально-быстрого достижения устройством заданного значения (уфф).

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

Есть только одно предложение от меня в добавление к коду Павла - не производить регулировку (отключать двигатель) после достижения заданной точки, что может предотвратить всякие раскачивания вокруг нуля.

Как-то так

(Добавление)
Заранее прошу извинить, если я "открыл Америку"

(Добавление)
И еще, в догонку. Данный метод НЕ ПРЕДПОЛАГАЕТ ТОЧНОГО ПОЗИЦИОНИРОВАНИЯ оси на заданное программой значение. Действительно, с приходом каждого нового значения (и только тогда) мы вычисляем новую СКОРОСТЬ перемещения оси и задаем ее двигателю. Двигатель поехал и... все, больше мы его ни о чем не спрашиваем до следующего прихода данных от компьютера. С одной стороны, тут кроется опасность, что при неверно заданном коэффициенте "KP" мы будем либо переезжать, либо не доезжать до заданной позиции. Но это, ИМХО, не имеет особого значения. Нам ведь нужны ощущения, а не точность. А для ощущений важен закон перемещения оси а вовсе не точность ее установки в заданное положение.

А теперь посмотрите на код Павла. Там нет ПИД регулирования.

Там его и не будет, т.к. по статье, которую давал Null, написано, что для электроприводов достаточно П. Это для меня на данном этапе.

не производить регулировку (отключать двигатель) после достижения заданной точки, что может предотвратить всякие раскачивания вокруг нуля.

немного не понял как это выглядит. Я если не отключу двигатель, он пролетит точку.

(Добавление)

unsigned char all[2]; //буфер для приема данных с ПК

идея создать буфер был найден на каком-то форуме, для того, чтобы получить из 2-х 8-bit один 16-bit

Я вообще считаю, что в данном случае нам НЕ НУЖЕН линейный датчик обратной связи, кроме концевиков. О.. вот она, РЕВОЛЮЦИЯ.

Судите сами: Допустим, мы достаточно точно подобрали коэффициент, и можем с большой точностью задавать скорость перемещения оси. Тогда, умножив скорость на время мы получим дистанцию. А теперь представьте, что текущее "положение" оси мы храним только в памяти МК... ммм. нет, проще будет алгоритм по шагам расписать

1 - включили и калибруемся от концевика до концевика. Т.е. с постоянной скоростью доезжаем до низа, затем до верха и по времени и скорости прикидываем расстояние. Возвращаемся в центр (та же скорость, но половина времени) - это будет позиция "0" Будем хранить позицию в глобальной переменной POSITION

2 - с приходом данных от компа вычисляем новое (будущее) положение оси, находим необходимую дистанцию перемещения, делим ее на время (уж время то мы знаем, поскольку сами настраиваем интервал передачи данных от компа к контроллеру). И получаем скорость, которую надо задать двигателю, что бы он к приходу следующих данных приехал ПРИБЛИЗИТЕЛЬНО в нужное место. А в переменной POSITION сохраняем новую позицию оси, КАК БУДТО мы реально ее достигнем к концу заданного интервала времени.

3 - с приходом очередных данных от компа вычисляем новую дистанцию перемещения не на основании РЕАЛЬНОЙ позиции, а на основании ИДЕАЛЬНОЙ, которую мы храним в переменной POSIТION.

4 - и так далее.

Давайте в цифрах. Допустим комп нам пришлет следующую последовательность положния оси : 100, 120, 50, 80, 100.
Допустим, интервал между посылками - 50мс.
Допустим, переменная POSITION = 0

Пришла первая посылка - 100. Вычисляем дистанцию D = (100 - POSITION) = 100. Вычисляем скорость, которую надо задать двигателю, что бы он за 50 мс прошел 100мм дистанции. S = abs(KP*D), где KP - наша калибровка. Задаем двигателю эту скорость и вычисляем POSUTION = POSITION + D.

Пришла вторая посылка - 120. D= (120 - POSITION) = 20, S=abs(KP*D), POSITION=PISITION+D

Пришла третья посылка - 50. D=(50-POSITION) = -70 (реверс), S=abs(KP*D)

... и так далее. Так вот, даже если мы ошиблись в коэффициенте калибровки KP, даже если интервалы в 50 мс выдерживаются не точно, реальное перемещение оси будет очень похоже на то, которое сим пытается нам задать. Пусть мы в реале получим не 100,120,50,80... а 102,119,55,78 - ну и фиг с ним, ИМХО.

Вот теперь вроде всё

а как вероятность накопления ошибки ?
например: Контролер получил скорость, но физически ее не выполнил (изменился момент двигателя, моргнул свет и т.п.).

Там его и не будет, т.к. по статье, которую давал Null, написано, что для электроприводов достаточно П. Это для меня на данном этапе.

Павел, позвольте не согласиться. Это не П регулирование. Регулирование подразумевает вычисление и коррекцию управляющего воздействия через равные промежутки времени для достижения регулируемым устройством заданного значения. А у вас в программе для каждого заданного значения оси вычисляется всего ОДНО значение ШИМ, которое сохраняется до прихода СЛЕДУЮЩЕГО значения оси от компа. Вот регулированием это стало, если бы вы по таймеру каждый раз корректировали значение ШИМ исходя из текущего положения и заданного значения. А у Вас - ПРЯМОЕ задание скорости вращения двигателя, вычисленное для каждого нового положения оси.

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

немного не понял как это выглядит. Я если не отключу двигатель, он пролетит точку.

Так Вы с приходом новых данных от компа задаете НОВУЮ скорость двигателю. И если данные не меняются, то Вы как раз и отключите движок. Проблема только в конце, когда сим отключается, а движок продолжает отрабатывать ПОСЛЕДНЮЮ уставку с заданной скоростью. Ну тут два решения - одно обязательное - концевики. А второе - тумблер, отключающий все перемещения

(Добавление)

а как вероятность накопления ошибки ?
например: Контролер получил скорость, но физически ее не выполнил (изменился момент двигателя, моргнул свет и т.п.).

Ну вот... Тем же оружием. Я про ошибки интерфейса, а мне - про ошибки силовой части.

Да, конечно, вероятность есть, и не маленькая. Но, главное, что бы ошибки не в ОДНУ сторону копились. А уж вероятность такой ситуации, мне кажется, довольно мала. Ну и, конечно, на крайний случай - концевики. Это условие обязательное