Impartial

После ПИД регулятора скорости должен быть ПИД момента. Иначе линейности регулятора скорости достичь практически невозможно. Потом определяете необходимый максимальный момент на валу двигателя и максимальный момент инерции приведенный к валу двигателя. Настраиваете первым контур момента исходя из полученных моментов. Потом контур скорости. Задаете максимально допустимую скорость и ускорение. Далее на вход контура скорости ставите РАМП генератор который будет нормировать разгонно-тормозную характеристику. Это самый короткий путь к реализации.

А причем здесь тогда FOC ? С таким принципом работы датчиков векторное управление применять бессмысленно.

Мне тоже интересно как происходит обработка холлов в FOC при нулевой скорости. В определенных позициях и будет дергаться. Как точно определить позицию ротора при нулевой скорости с таким датчиком?

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

Ищу работы по переводу старых процессоров на новую элементную базу - FPGA или CPLD. Синтез осуществляется на основе блок схем , схем электрических принципиальных и содержимого ПЗУ. Синтез процессора на основе ПЗУ микропрограммного автомата. Возможна выдача описания процессора на языке "С" без сохранения временных диаграмм оригинала.

Любая попытка использовать какую либо адресацию подразумевает использование общих полей в пакете. Это противоречит идеологии реалтайма. Вообще езеркат хорошо работает только на специально спроектированном для него оборудовании мастера. При использовании обычной персоналки все его достоинства тонут в дебрях операционной системы. Попытка запустить драйвер будет приводить к синим экранам на одних компьютерах и нормальной работе на других. Есть такая любительская система управления станками ЧПУ LinuxCNC. Она с открытым исходным кодом и я много интересного узнал разбирая некоторые куски кода. Там есть исходник драйвера езерката и его нормальная работа гарантируется только на нескольких чипах. Плюс ко всему операционка с которой работает эта программа специально под нее собрана с использованием RTAI ядра и все равно джиттер на разных компьютерах, особенно современных, часто не отвечает ее требованиям.

Это максимальное количество ПДО. СДО это всего один кадр на передачу и прием. Просто мастер должен поддерживать стандарт DS 301.

Если речь идет о CanOpen то принцип выглядит так. У устройств поддерживающих этот стандарт есть всего 4 RXPDO и 4 TXPDO. Каждый из них состоит максимум из 8 байт с структурой определяемой изготовителем устройства. Принцип моста состоит в том, чтобы отзеркалить эти ПДО в приеме и передаче на соответствующие поля в пакете слейва. Все остальное сделает сам CAN интерфейс с соответствующими настройками полей COB-ID. Еще нужно обеспечить возможность настройки CANOpen устройства с помощью пакетов SDO. Но это нужно только на этапе запуска системы.

Каждый слейв имеет строго определенную внутреннюю структуру. Ни о каком изменении длины не может быть речи. Для каждого слейва есть конфигурация и конфигурационный файл. Общая длина пакета складывается у мастера на этапе конфигурации приложения и может измениться только при реконфигурации. Слейв может пропускать через себя чужие пакеты но к приложению они не имеют никакого отношения. Идентификация встроена в сам пакет. Почему смущает количество обрабатываемых в плисине потоков? Там максимальная частота 50 мгц. Одна плисина может их хоть сто штук обработать. Хватило бы ножек и триггеров внутри. Это же не микроконтроллер. В плисине все обрабатывается параллельно. Функция определения подключен дальше в цепочке слейв или нет выполняется на уровне физического драйвера. В этом процессе ни плис ни наличие данных в канале не участвуют. Это происходит на аппаратном уровне PHY. Если глубже залезть то это функция кодера\декодера 8b/10b. В этой избыточности заложены коды которыми обменивается физика для определения своего состояния.

Все зависит от конфигурации приложения. Если слейву нужны данные от других слейвов он их принимает и модифицирует без участия мастера. Мастер может (как вариант) только настраивать и синхронизировать сеть. Если слейв находится в конце цепочки то он закольцовывает через себя трафик.

Спасибо.

Порт в компе один. И нужно ведь три дырки для подключения. Нашел вот такой RB2011UIAS-RM подойдет?

Помогите советом. Нужно увидеть с помощью программы WireShark обмен между двумя устройствами. Слышал что это можно сделать подключив компьютер и устройства между которыми происходит обмен через хаб. Но найти этот хаб оказалось большой проблемой. Может возможно как то настроить какой нибудь управляемый свич. Какой нужен свич и как его настроить?

Я имел ввиду сервопривод. Нет там ничего сложного. Я первые опытные реализации укладывал в 120 триггеров первого циклона.

ЦитатаТем не менее мир АСУТП развивается именно в этом направлении. Лет 7 назад я тоже восторженно воспринимал эту концепцию. На деле оказалось наоборот. Даже яскава бросила эту затею выпускать только усилители к приводам. При том что использовался спец вычислитель а не персоналка. Может Вы и векторное управление собираетесь в компе считать? Вы предлагаете делать самопал при этом рассуждаете о сетевых стандартах. Попробуйте сначала определить объем вычислений в компе на 1 сервоцикл. А он как я понял 50мкс. На мой взгляд пустая трата времени. Плисовод не станет тратить время на копание в пакетах с непредсказуемым результатом. Если сможете поставить задачу то с этим и студент справится.