roboforum.ru

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

Replies from the RepRap machine to the host computer

All communication is in printable ASCII characters. Messages sent back to the host computer are terminated by a newline and look like this:
xx [line number to resend] [T:93.2 B:22.9] [C: X:9.2 Y:125.4 Z:3.7 E:1902.5] [Some debugging or other information may be here]
xx can be one of:
ok
rs
!!
ok means that no error has been detected.
rs means resend, and is followed by the line number to resend.
!! means that a hardware fault has been detected. The RepRap machine will shut down immediately after it has sent this message.
The T: and B: values are the temperature of the currently-selected extruder and the bed respectively, and are only sent in response to M105. If such temperatures don't exist (for example for an extruder that works at room temperature and doesn't have a sensor) then a value below absolute zero (-273oC) is returned.
C: means that coordinates follow. Those are the X: Y: etc values. These are only sent in response to M114 and M117.
The RepRap machine may also send lines that look like this:
// This is some debugging or other information on a line on its own. It may be sent at any time.
Such lines will always be preceded by //.
The most common response is simply:
ok
When the machine boots up it sends the string
start
once to the host before sending anything else. This should not be replaced or augmented by version numbers and the like. M115 (see above) requests those.
All this means that every line sent by RepRap to the host computer except the start line has a two-character prefix (one of ok, rs, !! or //). The machine should never send a line without such a prefix.

Добавлено спустя 16 секунд:
http://www.reprap.org/wiki/G-code

Добавлено спустя 1 минуту 29 секунд:

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

Кстати, да. 20мс минимум.... Но это надо смотреть - много это или мало.

Кстати, серва поймет и 10 и 5 мс между импульсами

Добавлено спустя 3 минуты 53 секунды:
Problem to solve
Each line of G-code sent from the host to the controller is answered with an ok before the next line can be sent without locking communcations up. This makes operations very slow, as the usual USB-TTL converters and probably also the host's operating system drivers come with substantial latency, often 10 milliseconds.
For more details on this proposal, and some suggested solutions, and comments please see GCODE_buffer_multiline_proposal
Ребята, проблема решена! Надо использовать мой стол - 8см за две минуты! Можно кино за это время скачать в хорошем качестве, не то, что сотню строк

Кстати, на самом деле степ-дир - вполне себе интерфейс. Как-то делали упаковщик типа флоу-пак для влажных салфеток, задача в чем-то похожая на станок ЧПУ или принтер - надо, чтобы 5 сервоприводов (толкатель продукта, сама упаковочная пленка, нож, который прорезает в ней дырку, стикер прозрачный, который ее заклеивает и нож, который режет на выходе ленту на отдельные пачки), вращаясь с разными вообще говоря скоростями, а ножи так и вообще нелинейно, приводили свои механизмы в движение строго синхронно и все действия над лентой (дырка, стикер, заталкивание продукта, поперечный рез) происходили в нужных ее местах в соответствии с рисунком на ленте.
Так вот, примененные там сервопривода Дельта единственным входным интерфейсом по позиции признают именно импульсный (в 3 вариантах: квадратура, степ-дир и импульсы вперед-назад). Мы пользовали как раз степ-дир. Контроллер - атмега128 . А уже внутри серво берет этот степ-дир, масштабирует его, сравнивает со своим 160000-импульсным энкодером на валу и ПИДами рулит своим мотором. В общем, в такой системе главное, чтобы быстродействие серво было существенно выше рабочих скоростей и ускорений самой траектории движения - тогда все нормально в траекторию попадет.

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

как так ? на ваших сях месяц работы? да мона на асме 2 раза за месяц сделать )

Duhas писал(а):как так ? на ваших сях месяц работы? да мона на асме 2 раза за месяц сделать )

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

Для нормальных скоростей даже периода в 5 мс не хватит. При скорости в 300 мм/с это 1,5 мм пройденного расстояния.

Хотя сервы 300 мм могут и не дать, конечно.

А openservo не умеет, случаем, нужные вещи делать? Или почти нужные. Там есть загадочный MotionProfile. Возможно, проекции Гкода на оси удобно разложатся на сплайны Эрмита.

а у нас кружок любителей слоупочных чпу

300 мм/с это слишком быстро, я ориентируюсь максимум на 10 мм/с

Читал про слоупоков, наткнулся вот на что: http://lurkmore.to/%D0%A4%D0%B0%D1%82%D ... 0%BE%D0%BA

Ае?

Добавлено спустя 2 часа 58 минут 30 секунд:
чо-то туплю весь вечер и не могу понять как распарсить буфер
буфер вот такой: uint8_t RxBuffer_SW[BufferSize]
в него складывается все, что прилетает в юсарт, т.е. строки с командами. Надо каждую строку взять и выцепить из нее команды... Как?

Добавлено спустя 4 минуты 29 секунд:
Т.е. есть буфер.
Поискали конец строки
Взяли от начала до конца строки - получили одну строку
Дальше ищем параметры. Например команды вида g-code: "X451 Y678\r\n". Поискали, например Z - его нет. Поискали X - есть. После икса ищем пробел. Нашли. Берем все от Х до пробел - пишем в переменную. Дальше Y, то же самое.
Потом копируем строку, которая начинается после "\r\n" в буфер, т.е. фактически дискардим первую отпарсенную часть. Так что ли? Чо-то все какое-то адски долгое, не?

Добавлено спустя 2 минуты 26 секунд:
Сечас в буфер все складывается способом, описанным в AN3109 от ST. Т.е. включен ДМА с кольцевым обходом, складывает все в эмулируемый FIFO. Программа периодически из FIFO перетаскивает данные в свой буфер, с ним работаем.

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

Добавлено спустя 11 минут 44 секунды:
для ардуины пример есть =)
принимаем сроку, ищим первый символ координаты и фигачим в массив последующие цифры пока не наткнёмся на пробел.

Код: Выделить всё • Развернуть

void process_string(char instruction[], int size)

distanceX = (int)(search_string('X', instruction, size);
distanceY = (int)(search_string('Y', instruction, size);
distanceZ = (int)(search_string('Z', instruction, size);

double search_string(char key, char instruction[], int string_size)
{
  char temp[10] = "";
  
  for (int i=0; i<string_size; i++)
    {
      if (instruction[i] == key)
      {
        i++;      
        int k = 0;
        while (instruction[i] != (' '|NULL))
        {
          temp[k] = instruction[i];
          i++; k++;
        }
        return strtod(temp, NULL);
      }
    }  
  return 0;
}

там короче http://forums.reprap.org/read.php?12,9459

Добавлено спустя 1 минуту 22 секунды:
нет, с масками пожалуй не очень удачная идея...

Самый крутой и методичный парсер - правильно написанный конечный автомат

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

да да, мы уже поняли, конечный автомат, можно не повторять =)

Я просто не в курсе, что такое конечный автомат. =) Если оно - ок.

Код: Выделить всё • Развернуть

          beginning = strchr(RxBuffer_SW, 'X');
          end = strchr(RxBuffer_SW, ' ');
          strncpy(strX, ++beginning, end-beginning);

          beginning = strchr(RxBuffer_SW, 'Y');
          end = strchr(RxBuffer_SW, '\r');
          strncpy(strY, ++beginning, end-beginning);

          strcpy(RxBuffer_SW, end+1);
          RxCounter_SW = 0;

          intY = atoi(strY);
          intX = atoi(strX);

Чо-то вот навскидку наваял...

Ммммммммммммм?

Добавлено спустя 1 час 28 минут 33 секунды:
Блина, оно медленное, но оно точное! Я ожидал "занос 1м" - а оно работает!