Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Система команд сервоконтроллера
Форум разработчиков электроники ELECTRONIX.ru > Силовая Электроника - Power Electronics > Электрические машины, Электропривод и Управление
Страницы: 1, 2, 3, 4
dpss
Цитата(_Pasha @ Feb 17 2009, 12:47) *
Ну, допустим, как снизить частоту обновления, понятно всем: использовать макроязык с интерполяторами. Зачем апдейтить координату еще и с дисперсией времени доставки, когда можно ее хоть кусочно-линейно хоть сплайном интерполировать. А кто знает уже готовые устоявшиеся решения?

А как при таком управлении делать табличные корректировки положения, управлять приводами ведущий-ведомый ?
arisov
Мне кажется «в дебри улезли». Изначально планировалось полулюбительский контроллер. Таких контроллеров по 100-150$ много уже кто выпускает. Даже российский есть http://www.ellab.ru/russian/razrabotki/sva...rka_001_rus.htm. С приобретением особых проблем нет. Любители ЧПУ народ консервативный и будут покупать или изготавливать (ServoOpen) только многократно проверенные конструкции. И надо ещё видео на рабочем станке ЧПУ показать, а то так не поверят. Испытания желательно производить на станке с ЧПУ. _Pasha у Вас он есть? Испытания на столе никого не убедят в работоспособности. Я просто с этим уже столкнулся.
Сначала надо попробовать с «мощным» двигателем (хотя бы 110В, 10А) - возможно что и разговоры о протоколах не понадобятся – можно будет здесь «увязнуть». И если уж такой движок будет «послушным», то и от 24В подавно.

Если Вы действительно хотите сделать что-то полезное для любителей и которое пользовалось бы спросом, то я думаю преобразователь USB в Step/Dir было бы самое то. Например http://www.usbcnc.com/index_products.html или http://www.cnc4pc.com/Store/osc/product_in...products_id=185, только цену конечно не 180-320$.
За открытый проект или 50$ многие сказали бы спасибо. И на своих станочках начали бы ещё усерднее бороться с мировым кризисом. smile3009.gif
К тому для этого никакого оборудования не надо.
А вообще то лучше конечно сначала пообщаться с теми кому это предназначено и из "первых рук" узнать что им надо. http://www.cnczone.ru/forums/index.php?&act=idx
http://forum.rcdesign.ru/f41
khach
Коллеги, а кто нибудь может ответить на вопрос, как в интеллектуальном интерфейсе синхронизировать движение по двум осям? Если в системе step-dir эта задача висит на контроллере, то в сервоприводе у меня оси разезжаются внутри косого отрезка, хотя на концах отрезка- все нормально. Приходиться длины отрезков уменьшать, привод дергается, получается управление как на шаговиках, а не "плавно врезался и поехал фрезой под постоянной нагрузкой"
_Pasha
Цитата(dpss @ Feb 17 2009, 13:17) *
А как при таком управлении делать табличные корректировки положения, управлять приводами ведущий-ведомый ?

CODE
Макроязык управления сервоконтроллером.
1. Концепция
Для снижения нагрузки на канал связи локального управляющего контроллера
и одновременно для обеспечения возможности активно воздействовать на все параметры
управляющего серво-алгоритма предлагается макроязык, позволяющий описывать поведение параметров во времени с использованием предопределенного набора известных методов интерполяции, а также задавать управление в реальном времени от различных входов

2. Набор параметров управления

2.1. Управляющие параметры
- Координата S либо X,Y,Z в случае, если определены функции сервоконтроллера по перемещению вдоль конкретной оси.
- Скорость V либо VX, VY, VZ
- Момент T либо TX, TY, TZ
- Прямой нормированный канал ШИМ U, либо UX,UY,UZ
- Интервалы времени du - в микросекундах, dm-миллисекунды ds-секунды dt-время в формате с плавающей точкой либо dt=<число><суффикс u|m|s>

2.2. Входы управления или источники команд
- Одиночная команда. Например S=1120,dt=1.09Е-2 или тоже самое S=1120,du=10900
- Интерполятор, например S= cspline(-11.24,-3.003,6.573,0) dt=1.09E-2
S= pwl((115,1120u),(220,2400u),(1120,10900u))

- Частота по входу, например S=freq(x1), где
x1 - символическое имя дискретного входа,

- Период по входу, напр. S= per(x1,K)
- Напряжение по входу например S=an(x3)
Денормирующие коэффициенты хранятся в настройках

2.3. Вывод состояния сервоконтроллера - выходные параметры
- координата
- скорость
- момент
- прямой нормированный канал тока

2.4. Средства мониторинга выходных параметров
- прямой лог
- лог с интерполяцией
- лог о выходе за заданные пределы
- лог ошибки, например между заданным S и фактическим

2.5. Простые настроечные параметры в EEPROM - через символические имена
например Kp_speed = 16384 - коэфф пропорциональности в ПИ-звене контура
регулирования скорости

Сразу говорю - просьба не пинать за этот поток сознания. Интересует, существуют ли где-то похожие концепции.


Цитата(arisov @ Feb 17 2009, 14:15) *
Испытания желательно производить на станке с ЧПУ. _Pasha у Вас он есть?

Ну, у меня есть хорошо "промаринованный" заказчик, который ловит каждое мое слово, а я, в свою очередь, стараюсь не наглеть и держаться на уровне. А у заказчика - станок. smile.gif
arisov
Цитата(khach @ Feb 17 2009, 14:28) *
...привод дергается, получается управление как на шаговиках, а не "плавно врезался и поехал фрезой под постоянной нагрузкой"

Что делать не подскажу, но такое дёргание в Mach происходит когда вместо G1 (линейная интерполяция) выполняется G0 (ускоренное перемещение) при одинаковых заданных скоростях.
_Pasha
Цитата(khach @ Feb 17 2009, 14:28) *
Коллеги, а кто нибудь может ответить на вопрос, как в интеллектуальном интерфейсе синхронизировать движение по двум осям?

В идеале - перекрестной связью по датчику положения. В реале - sad.gif кисло
khach
Цитата(_Pasha @ Feb 17 2009, 14:38) *
В идеале - перекрестной связью по датчику положения. В реале - sad.gif кисло

Это как, доп раземы на драйверы сервомоашинок от енокдеров другой оси? А кто тогда математикой заведует?
Я уже не говорю, что заказчики "обнаглели" и присылают G-код с хеликоидальной интерполяцией или пытаются использовать
зуборезные пальчиковые фрезы- это когда отверстие и фрезеруется и резьба режется одной и той же фрезой и нужно согласованное
с вращением шпинделя движение детали по двум осям :-)
_Pasha
Цитата(khach @ Feb 17 2009, 15:47) *
Это как, доп раземы на драйверы сервомоашинок от енокдеров другой оси? А кто тогда математикой заведует?

Если есть проблемы - надо PLC дополнительный ставить. А перекрестная связь - это же теоретически 100% действенный метод.
ЗЫ мне кажется, средствами самого сервака трудно будет определить кто ведущий, а кто ведомый.
evgeny_ch
Цитата(haker_fox @ Feb 17 2009, 13:10) *
А я воспринял Ваше сообщение, как иронию. Или неправильно воспринял?
Вполне серьезно.
Вот энкодер с оптовыходом.
Rst7
Цитата
Сразу говорю - просьба не пинать за этот поток сознания.


Как по мне, то пинать совершенно не за что.

Я вообще считаю, что надо как можно больше мозга уносить ближе к исполнительным механизмам. Во-первых - снижается нагрузка на канал связи. Во-вторых - намного проще обеспечить действительно реалтайм работу - ну о каком вменяемом реалтайме может идти речь, если весь моск суть программа на большом брате работающем под виндой/никсами? А гарантированное время доставки? Как по мне - это сугубо говнопиар. А если пакет потеряется? Как-то мне никогда в описаниях протоколов не попадалась фраза "время доставки меньше T гарантируется с вероятностью X". А именно такая формулировка и должна присутствовать. Может, конечно, не туда смотрел, посему с удовольствием разую глаза по вашей фразе "А это ты внимательно курил?" и приложенной ссылке.

Однако, для такого управления необходимо помимо команд задания алгоритма движения необходимо еще предусмотреть выбор алгоритма на случай аварийной ситуации - например, серьезная авария при заклинивании механизма может быть обработана банальным обесточиванием, а вот, например, ситуация неприхода привода в точку финиша? Или большое отклонение от заданной траектории?

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

Пошел покурить про Mach3... Очень порадовало описанице на форуме biggrin.gif
Цитата
Програмное обеспечение с сайта производителя.
Без таблеток и кряков.
Ограничения производителя 1000сторк G-кода и 25000гц частота.
ВНИМАНИЕ!!!
При использовании MACH оптимизируйте операционную систему согласно рекомендаций,погасите все ненужные сервисы,иначе реал -тайм в виндах проблематичен.
После установки программы ОБЯЗАТЕЛЬНО перезагрузите компьютер.
Перед первым запуском запустите Driver Test.exe (по умолчанию в папке C:\Mach3\Driver Test.exe)
НЕ ИСПОЛЬЗУЙТЕ компьютер станка для задач кроме управления станком.
При отсутствии другого компьютера-разделите жесткий диск и поставьте ОТДЕЛЬНУЮ операционную систему ТОЛЬКО для задач управления станком.

Последние релизы программ на сайте производителя:


Болд мой smile.gif Только вот фраза неправильная - "иначе реалтайм в виндах проблематичен". Правильная фраза "В любом случае реалтайм в виндах невозможен!"
Iptash
Цитата(khach @ Feb 17 2009, 14:47) *
Это как, доп раземы на драйверы сервомоашинок от енокдеров другой оси? А кто тогда математикой заведует?
Я уже не говорю, что заказчики "обнаглели" и присылают G-код с хеликоидальной интерполяцией или пытаются использовать
зуборезные пальчиковые фрезы- это когда отверстие и фрезеруется и резьба режется одной и той же фрезой и нужно согласованное
с вращением шпинделя движение детали по двум осям :-)

Это надо, что-бы у каждего привода выхода датчиков положения соединялись как с ЧПУ так и между собой, и ЧПУ распределяет кто
ведущий кто ведомый. Например при нарезки резьбы, ведущий привод шпинделя, поэтому привод допустим Z считывает импульсы датчика "S " и синхронизуется с масштабом которая ЧПУ прописала (что будет соответсвовать какому-то шагу), также и допустим
линейная интерполяция ведущий допустим "Z" , а ведомый "X" (здесь ведущий будет тот, у кого по расчетам будет наибольшая скорость).
Огурцов
Mach, конечно, хорошо. Но в дефолтовом виде таки плохо. Windows и realtime - слишком противоположные слова. Еще раз - нужен свой плагин, который и (по)мог бы победить болезни windows. В других вариантах я бы и не рассматривал Mach, как программу для управления станком или ботом.


Цитата(_Pasha @ Feb 17 2009, 12:34) *
Сразу говорю - просьба не пинать за этот поток сознания. Интересует, существуют ли где-то похожие концепции.

А это откуда ? Еще есть ? На первый взгляд вроде бы логично. Наверно можно детализировать.
haker_fox
Что-то это меня настораживает:
Цитата
The Home of Mach3 and LazyCam

Artsoft has been in the CNC business since 2001. In this time, the Mach series of CNC software has evolved into the best available PC-based CNC software on the market. Not only is it extremely affordable to the hobbyist and industry alike, it is pioneering in it's features and continuing development. There are over 10000 users of Mach who swear by its ease of use, great features, and outstanding support.



Software Requirements

Keeping with our home hobbyist roots, the minimum software requirements to run Mach are very reasonable. Below are the specifications for running Mach3 stably.
Mach3 Minimum Requirements:

* Windows 2000/XP Operating System
* 1Ghz CPU
* 512MB RAM
* Non-integrated Video Card with 32MB RAM
* Basic Computer Skills (ability to copy/rename files, browse directories, etc)
* Desktop PC if using the Mach3 Driver (Laptops are not supported because the power saving features of the chipsets disrupt the pulse stream)

Взято отсюда.
Получается, что Mach3 софтварно реализует ЧПУ на базе компьютера? С учетом требований к реалтайтму, возникает вопрос, а на сколько все это надежно?
Да и системные требования впечателяют, хотя и не сверхбольшие. Или это нормально и я отстал (не догнал) от жизни?
Просто в моем представлении ЧПУ это специализированная платформа (ну пусть IBM PC) с соответствующей ОС. А компьютер, пусть даже и под виндой, выполняет только функцию терминала - удобного рабочего места для оператора, наладчика. Но не как не выполняет функции непосредственного управления оборудованием.
_Pasha
Цитата(Rst7 @ Feb 17 2009, 17:18) *
Как по мне, то пинать совершенно не за что.
Есть за что: явный перекос потока данных. От сервака с АВР в реалтайме да еще и режиме мониторинга требовать обрабатывать поставляемые данные - это что-то особеннаго smile.gif Надо додумать. Оправдывает только то, что написано буквально "на кончиках пальцев" - что вижу, то и пою.

Цитата
ситуация неприхода привода в точку финиша? Или большое отклонение от заданной траектории?
Это по-большей части головная боль контроллера верхнего уровня, надо только гарантировать доставку лога от сервака.


Цитата
Кроме того, в каждом пакете данных необходимо иметь таймстамп в приемлемых единицах.
+1 И еще синхронизацию как-то сделать бы. Синхропакетом, что ли? Пока непонятно.
Цитата
Пошел покурить про Mach3... Очень порадовало описанице на форуме biggrin.gif



smile.gif У меня старый ноутбук, на который еле-еле влезла ХР, печатная машинка, короче. Думал: ага, пристрою вещицу. Пень 300 МГЦ/192 ОЗУ... Блин, как поставил Mach3 - компьютер чуть ли не вздулся от "реалтайма" smile.gif

Цитата(Огурцов @ Feb 17 2009, 18:47) *
А это откуда ? Еще есть ?

Из головы, дурное дело - нехитрое wink.gif
Огурцов
Цитата(_Pasha @ Feb 17 2009, 16:18) *
+1 И еще синхронизацию как-то сделать бы. Синхропакетом, что ли? Пока непонятно.

Slp_system_synchronize

Цитата(_Pasha @ Feb 17 2009, 16:18) *
Пень 300 МГЦ/192 ОЗУ... Блин, как поставил Mach3 - компьютер чуть ли не вздулся от "реалтайма"

Лол...у меня пентиум 2GHz временами зависает. Не, если кроме Mach больше ничего не пущать, то оно работает. Так что выше не просто так про отдельную и оптимизированную ось написано.

Цитата(_Pasha @ Feb 17 2009, 16:18) *
Из головы, дурное дело - нехитрое wink.gif

Неплохо. Подумывал написать нечто такое, та все некогда.
_Pasha
Цитата(Огурцов @ Feb 17 2009, 18:29) *
Slp_system_synchronize

Не, я начал вкуривать, но пока чего-то все кажется, что это избыточно. Надо еще время для осознания.
Rst7
Цитата
И еще синхронизацию как-то сделать бы. Синхропакетом, что ли? Пока непонятно.


Это не трудно. Можно реализовать что-то аля NTP.

К сожалению, винда - это тоже не атомные часы. Миллисекундные тики - они хорошо если с дискретностью 10-20мс идут. При частом вызове вот такого (а часов с меньшей дискретой в винде я не знаю)
Цитата
struct timeb ct;
double d;
ftime(&ct);
d=ct.time*1000.0+ct.millitm;

d будет иметь дискрету, названную выше.
_Pasha
Получил платы, Ё-МОЁ. Таки умудрился накосячить. Если бы у меня был начальнег, уволил бы меня нахрен. В общем, все блины - первые sad.gif

Хорошо, что не смертельно, можно и так запустить.

По теме. Есть еще вариант задания траекторий/профилей тупо в виде арифметического выражения. Влезет в m168 ?
В общем, на ум приходят все более текстовые версии протокола. Бинарные - мимо кассы, раз тут математика пойдет. А это, в свою очередь, облегчает навороты с синхронизмом, адресацией, маршрутизацией и т.п.
Rst7
Цитата
Есть еще вариант задания траекторий/профилей тупо в виде арифметического выражения.


Давайте все-же определимся, кто будет этому контроллеру команды давать? Нужен ли тому, кто будет давать эти команды такой способ их задания?

Цитата
Влезет в m168 ?


Калькулятор на +-*/() - это очень маленькая софтинка smile.gif
dpss
Как говорится "все уже придумано до нас" Десятки приводов ,тысячи портов с управлением под "Окнами" c
жестким реальным временем до 30 микросекунд на цикл http://www.beckhoff.ru/english/pdf/EtherCA...AT_Overview.pdf
_Pasha
Цитата(Rst7 @ Feb 17 2009, 19:24) *
Калькулятор на +-*/() - это очень маленькая софтинка smile.gif

Не, с синусами, логарифмами, экспонентами и степенями... А может и не надо
Rst7
Цитата
А может и не надо


+1.
Огурцов
Цитата(_Pasha @ Feb 17 2009, 16:33) *
Не, я начал вкуривать, но пока чего-то все кажется, что это избыточно. Надо еще время для осознания.

Не, это еще малая толика. Но не избыточно и не сложно. Описание, конечно, нужно, с картинками, чтобы хоть чуть-чуть понятно было.


Цитата(_Pasha @ Feb 17 2009, 17:34) *
Не, с синусами, логарифмами, экспонентами и степенями... А может и не надо

Какие синусы, таблично бы успеть...


Цитата(dpss @ Feb 17 2009, 17:30) *
Десятки приводов ,тысячи портов с управлением под "Окнами" c
жестким реальным временем до 30 микросекунд на цикл

Mach3 и побыстрее может. Ядро способно работать на 100kHz, при том, что реально прерывания вызваются еще в два раза чаще.
Однако все упирается в цену ошибки. Пока он грызет фанеру вопрос с зависаниями не актуален, если запущена обработка чегой-нибудь более ценного, чем фанера с пенопластом, то тут уж задумаешься.
slog
Вам бы сначала определится что за сервоконтроллер изобретаете.
Какие функции у этого сервоконтроллера? Это что, гибрид сервоусилителя и motion controller?
Куда подключены датчики обратной связи?
Кто синхронизирует оси?
Кто интерпретирует G-код?
Какая программа будет им управлять?
Не напишите же вы софт для ЧПУ и роботов. От этого и надо плясать. А большинство любительских программ используют step-dir и не нужна там никакая система команд и протокол.


Цитата(dpss @ Feb 17 2009, 19:30) *
Как говорится "все уже придумано до нас" Десятки приводов ,тысячи портов с управлением под "Окнами" c
жестким реальным временем до 30 микросекунд на цикл http://www.beckhoff.ru/english/pdf/EtherCA...AT_Overview.pdf

Есть ли в свободном доступе документация по логической части EtherCAT? Дастаточная чтобы его можно было использовать в своих контроллерах.
_Pasha
Цитата(slog @ Feb 18 2009, 09:27) *
Вам бы сначала определится что за сервоконтроллер изобретаете.


Объясняю более внятно.


1. Цель: получить "гибрид сервоусилителя и motion controller"

2. Заложены 6 свободно программируемых дискретных входов по IEC61131-2 http://www.prolog-plc.ru/beck/docum/AN_SC1X3_IO.pdf которые закороткой одного стабилитрона можно превратить обратно TTL  

Из этих входов  2/3 идут на квадратурный энкодер, Step, Dir, Limit_Switch

3. Аналоговый вход 4..20 мА

4. RS-485 с растяжками и джампером на RC-termination 

Протокол уже строю по принципу Hayes-модема: с одной стороны богатая текстовая командная строка, затем переход к варианту MODBUS-RTU или скорострельный поток данных  непосредственно для командных регистров положения/скорости/момента.

Теперь про бинарный поток данных

Избежать "экзотики", видимо, не получится. Замечу еще полезное свойство: командные регистры не могут  измениться мгновенно, поэтому для низкоуровневого потока данных достаточно передавать приращения с гарантией их доставки, например инвалидацией после приема блока данных (адресат отправляет обратно CRC блока), отправитель решает, повторять ли передачу. В пакет входит Timestamp с "зерном" в 100 мкс  разрядности 16 бит, потому что реально никто больше 1 секунды молчать не будет.
_Pasha
Так. В процесса курения инфы кое-что меняется. В общем, придется-таки заняться PROFIBUS, потому что там есть все ответы на вопросы по физическому и канальному уровням, а также "домашние заготовки" в части управления движением. Предлагаю просмотреть чтиво во вложении и вот это http://www.profibus.com/celummdb/doc/PROFI...scr_e_Aug07.pdf
slog
Если ты сможешь реализовать PROFIBUS без специальных чипов от сименса, которые занимаются этим аппаратно, то зачем тебе к этой задаче какой-то лишний довесок в виде мелкого любительского сервоконтроллера.


PROFIBUS, несмотря на то что там простой RS-485 очень "жирный" протокольчик. Особенно если с уклоном в серво. Теоретически, если осилить, можно замахнуться и на совместимость с ЧПУ от Siemens. Это круто, но практически, это сложновато будет.
_Pasha
Нажмите для просмотра прикрепленного файла

Это что, сложно ???
ЗЫ: Не забывайте, что PROFIDRIVE не некая вещь в себе, а уже содержит заточенную под моторный девайс систему параметров, которая на 99.9% совпадает с реализуемой в данный момент.
dpss
Цитата(_Pasha @ Feb 18 2009, 13:06) *
Так. В процесса курения инфы кое-что меняется. В общем, придется-таки заняться PROFIBUS, потому что там есть все ответы на вопросы по физическому и канальному уровням, а также "домашние заготовки" в части управления движением. Предлагаю просмотреть чтиво во вложении и вот это http://www.profibus.com/celummdb/doc/PROFI...scr_e_Aug07.pdf

PROFIBUS старая медленная шина. В новых проектах ее редко используют.
slog
Цитата(_Pasha @ Feb 18 2009, 13:33) *
Это что, сложно ???

Смотря для кого. Что делать с манчестером на 12мегабитах уже решили?
Как устроены "PROFIchip" внутри посмотрели? http://www.profichip.com/products/
Если не испугались, то ничего сложного.

И действительно, 12 мегабит для серво это сейчас медленно.
_Pasha
Цитата(slog @ Feb 18 2009, 15:00) *
Смотря для кого. Что делать с манчестером на 12мегабитах уже решили?

Стоп-стоп. Давайте не будем мешать в кучу физический уровень 1 OSI и весь Profibus, который использует уровни 1,2 и 7

То, что Вы назвали - это MBP. Кстати, почему-то написано
Цитата
MBP is synchronous transmission with a defined transmission rate of 31.25 Kbit/s and Manchester coding



Цитата
MBP transmission technology is usually limited to a specific segment (field devices in hazardous areas) of a plant, which are then linked to a RS485 segment via a segment coupler or links (Fig. ). Segment couplers are signal converters that modulate the RS485 signals to the MBP signal level and vice versa.


Т.е. говоря по-русски Profibus, реализованный на манчестере и Profibus, реализованный на RS-485 или Profibus, реализованный на оптике. Надеюсь, понятно объяснил.

Итого, на борту несчастной меги168 имеем UART и микросхему ST485 - это уровень 1 OSI

Уровень 2 OSI- пока собираю инфу. Как-то все ненаглядно sad.gif Развеселая картинка, что приводил выше - это относится к нему

Уровень 7 - уже параметры и некоторые рекомендации по улучшению синхронности.

12Мбит может и мало, но это уже восходит к возможностям сервака и энкодера, а они -то как раз скромненькие.
slog
Манчестер там всегда. Не зависимо от физического уровня. Который кроме RS-485 может быть и по оптике. И несколько фиксированных скоростей с 9.6к до 12мбит. И автоопределение скорости. Мега программно потянет только самые маленькие скорости. А для серво 12мбит надо.
_Pasha
Цитата(slog @ Feb 18 2009, 16:02) *
Мега программно потянет только самые маленькие скорости.
Флаги поддерживаемых скоростей - содержатся в GSD, типо паспорте устройства - это я уже асилил. Поэтому для собственно поддержки Profibus не имеет значения, что мега не успеет на 12Мбит. Это уже относится только к ТТХ системы в целом, а из-за того, что контроллер не поддерживает какие-либо скорости, сеть не развалится.
Цитата
Манчестер там всегда.

Где?! Не вижу. Ткнете носом, где это написано?
dpss
Цитата(slog @ Feb 18 2009, 15:02) *
Манчестер там всегда. Не зависимо от физического уровня. Который кроме RS-485 может быть и по оптике. И несколько фиксированных скоростей с 9.6к до 12мбит. И автоопределение скорости. Мега программно потянет только самые маленькие скорости. А для серво 12мбит надо.

Если не удастся достать специализированный чип , то проще сделать на какой- нибудь дешевой Альтере . Кстати есть готовая корка под EtherCAT.
Если получится ее найти с ключиком , то считайте что у вас есть вся система. С их софтом проблема уже кажется решена. :-)
http://www.beckhoff.com/download/Document/...1810_ET1815.pdf
Rst7
Цитата
поэтому для низкоуровневого потока данных достаточно передавать приращения с гарантией их доставки, например инвалидацией после приема блока данных (адресат отправляет обратно CRC блока), отправитель решает, повторять ли передачу.


Так не делают. Для понимания рассмотрите случай, если девайс не услышал пакет подтверждения.

На самом деле надо просто пронумеровать пакеты (или байты) и ввести подтверждение по номерам. Аля TCP. Если обмен организован в стиле "только запрос-ответ", то достаточно пронумеровать по модулю 2. Т.е. для номера достаточно одного бита.

Алгоритм прост (в однобитном варианте) - у передающей стороны есть переменная SEQ, у принимающей - ACK. Передающая сторона в пакет вставляет свой SEQ, принимающая сторона сравнивает SEQ со своим ACK, если SEQ!=ACK - пакет отбрасывается, если SEQ==ACK - пакет принимается, увеличивается ACK на 1 (ну точнее ACK^=1). В любом случае значение ACK передается обратно в качестве подтверждения. Передающая сторона при приеме ACK!=SEQ выбрасывает переданный пакет (его подтвердили) и делает SEQ=ACK. В противном случае (ACK==SEQ) происходит перепосылка текущего пакета.
slog
Цитата(_Pasha @ Feb 18 2009, 15:20) *
Флаги поддерживаемых скоростей - содержатся в GSD, типо паспорте устройства - это я уже асилил. Поэтому для собственно поддержки Profibus не имеет значения, что мега не успеет на 12Мбит. Это уже относится только к ТТХ системы в целом, а из-за того, что контроллер не поддерживает какие-либо скорости, сеть не развалится.

Где?! Не вижу. Ткнете носом, где это написано?

Где написано не помню, информация из памяти, в доках искать лень. Если нет 12 мбит, то и делать PROFIBUS для серво не интересно. Очень сложно и медленно. Добиться совместимости с фирменными устройствами не самая простая задача. Без гарантированной совместимости с остальными в PROFIBUS нет никакого смысла. EtherCAT гораздо интереснее. Но это не для простых сервоконтроллеров на мега168. Для простых достаточно step-dir или +/-10v для работы с простым ЧПУ софтом или любого простого самопального протокола хоть на основе ModBus для работы в качестве контроллера позиционирования.

Цитата(dpss @ Feb 18 2009, 15:43) *
Если не удастся достать специализированный чип , то проще сделать на какой- нибудь дешевой Альтере .

Чипы достать теоретически можно. Но в штучных кол-вах цена у них десятки баксов за штуку, что совсем не интересно. Делать программно - не получить скорость. Есть корки для PROFIBUS под FPGA, но зачем его делать в FPGA если лучше сделать EtherCAT. Для серво это гораздо перспективнее.
Цитата(dpss @ Feb 18 2009, 15:43) *
Кстати есть готовая корка под EtherCAT. Если получится ее найти с ключиком , то считайте что у вас есть вся система. С их софтом проблема уже кажется решена. :-)
http://www.beckhoff.com/download/Document/...1810_ET1815.pdf

Это конечно хорошо, но как быть с лицензией? Сколько она стоит? Может есть достаточно информации по которой можно самостоятельно что-то сваять типа этой корки?
_Pasha
Цитата(Rst7 @ Feb 18 2009, 18:07) *
 Если обмен организован в стиле "только запрос-ответ"

А вот как раз уже и не хочется. Профибаса хачу! smile.gif А нумерация - полезно! В общем, хотелось определенности, а теперь вариантов в голове - на порядок больше. sad.gif

Протупил чуть. Профибас пылится в закромах upload/DOCs/Standarts&Specifications&Gosts/Profibus/
haker_fox
Цитата(_Pasha @ Feb 18 2009, 22:21) *
Профибаса хачу! smile.gif

Я уже тут плохо разбираюсь в вопросе. Но по профибасу, если не ошибаюсь, также контроллеры и оборудование фирмы Simiens соединяется?
Просто, как я вижу, тема далеко отклонилась от первоначальных требований laughing.gif
Цитата(_Pasha @ Feb 16 2009, 21:23) *
"Заболел" я созданием мелкого сервоконтроллера.
немножко уровень полулюбительский должен остаться.
В идеале хочется, чтобы в конце обсуждения появился некий маленький "стандартик" на систему команд и применяемые интерфейсы и протоколы.

Можно в двух словах примитивно мне объяснить прелести профибаса? Ну про совместимость со производственным оборудованием я понял. А что он еще дает? И на какой элементной базе реализовать поддержку этого протокола, а то уже FPGA мелькают сверху... И какой МК вообще будет ядром сервы? Как на счет остальных элементов привода (мост, питание, защиты, алгоритмы... и тп)? Я конечно помню, что тема для обсуждения команд, но мне, как начинающему в этой области хотелось бы остальное услышать) Не сочтите за наглость rolleyes.gif
_Pasha
Дает возможность организовать изохронный канал плюс современные фичи по повышению синхронизма между серваками. Если я буду самопально это организовывать, мой протокол окажется в Ж..в стороне от того что надо.



Посмотрел - таки да, там NRZ, но поверх обычного октета, т.е. в формате 8-bit UART. А это значит, что на передачу нам нада таблицу из 16 байт, а на прием - из 256. Так что именно это и не пугает. Пугает скорость sad.gif в два раза упавшая.
slog
Прелесть PROFIBUS только в том, что сервоконтроллер его поддерживающий будет совместим с кучей готового оборудования PLC и ЧПУ и всякого другого, в основном от Siemens. Это будет большо-о-й плюс. Но это только в том случае, если удастся сделать полностью поддержку протокола. А это без спец. чипов предназначенных для этого не очень просто. А если не будет 100% совместимости, то этот PROFIBUS вообще не нужен, слишком сложно.
Огурцов
Цитата(_Pasha @ Feb 18 2009, 15:21) *
Профибаса хачу!

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


2 slog: согласен по всем пунктам
slog
Цитата(_Pasha @ Feb 18 2009, 18:00) *
Пугает скорость sad.gif в два раза упавшая.

Меня пугает даже не упавшая, а максимальная скорость UARTа в Меге. Я уже делал серво с интерфейсом на 12 мегабит. Этого в притык хватило для управления 4-мя осями. И без всяких сложно-наворочанных протоколов. Еще и протокол и так примитивный оптимизировать под максимальную скорость пришлось. Но для простого позиционирования одной оси большая скорость обмена конечно не нужна.
Rst7
И всеже еще раз призываю подумать над тем, какой софт или железо будет использоваться в качестве верхнего уровня для изобретаемого контроллера. Я вам гарантирую, что ответ на этот вопрос даст ответы на все остальные - и протокол, и прочее smile.gif
_Pasha
Цитата(Rst7 @ Feb 18 2009, 18:07) *
Если обмен организован в стиле "только запрос-ответ"


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

CODE
Протокол 8-E-2
Скорость по умолчанию 9600
Режимы ASCII и BIN

Режимы различаются по первому байту.

Если первый байт 0x00..0x7f то это у нас ASCII с набором команд, о котором позже.

Если же первый байт >= 0x80,то это будет такая весчь:
7 6 5 4 3 2 1 0
1 V R R A A A A

V- номер пакета по версии RST7
RR - командный регистр
00 - положения
01 - скорости
10 - момента
11 - прямой ШИМ
------------------------
AAAA - адрес устройства в сегменте сети, то бишь, короткий адрес. Адрес 0 - всегда адрес хоста. Адреса общего вызова нет, поскольку в бинарном потоке это не нужно.
------------------
Далее (это все про BIN)идет 1 байт signed приращения командного регистра, 1 байт timestamp и crc8 а-ля даллас
-----------------------------
После получения подобной команды слейв обязан ответить таким образом:
первый байт 1VRR0000 (V,R - тот же смысл, ессно)
второй - приращение фактической величины (положение/скорость/момент/ШИМ)
третий -timestamp
четвертый CRC8
-----------------------

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

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

Цитата(Rst7 @ Feb 18 2009, 20:26) *
призываю подумать над тем, какой софт или железо будет использоваться в качестве верхнего уровня


ЗЫ: посоветуйте, надо ли в рамках бинарного потока сигналить об аварии или достаточно сделать это в текстовом виде?
Rst7
Цитата
Протокол 8-E-2


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

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


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

Но есть ли смысл реализовывать текстовый протокол вообще? Как по мне, так и не очень...
_Pasha
Цитата(Rst7 @ Feb 19 2009, 08:57) *
Эээ, я не очень понял, данные передаются по инициативе контроллера? Или запрашиваются мастером?
Хотя бы флаг аварии надо передать. А расшифровку можно уже и потихоньку текстом забрать.
Но есть ли смысл реализовывать текстовый протокол вообще? Как по мне, так и не очень...

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

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

3. Вы его еще не видели smile.gif 
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 после получения команды можно сделать сразу эхо, а можно после выполнения smile.gif

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

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

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

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

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

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

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

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

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


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

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



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

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

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

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

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



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

Код
Только для адресных команд!

По умолчанию слейв возвращает полученную строку обратно

Запустить ее на исполнение можно набрав / и ввод.

Если же в конце строки будет /, то исполнение начнется сразу, после чего слейв выдаст простой отчет OK

x: S=1200; V=12; T=122m юзер пишет

@x: S=1200; V=12; T=122m OK отвечает сервак

x:/  юзер

сервак подумал, переместился и написал

@x:OK

***********************************

Или то же самое но без эха

x: S=1200;V=12; T=122m  /   юзер пишет

сервак подумал и сгорел. И никто не знает, что он там получил,

потому что если был бы ошибка, то он написал бы

@x: S=0200;V=12Ё;T= / ERROR

Мораль: не уверен - не пользуй опасные вещи.

Тем более, что испортить можно все и всегда.


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

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

Код
X: S+=120

@X: S+=120 BUSY


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

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

^C, че за вопрос
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.