Impartial

По моему опыту виснут все инверторы и с 485, и с КАН и, даже, эзернет (EtherCAT). Смотря как проложена линия. Причем помеха лезет не со стороны кабелей с ШИМом а со стороны силового питания. Попробуйте напрямую, вне жгутов, подключиться.

Очень просто. Ставите самокат на горку и создаете момент который удерживает самокат на месте. КПД двигателя равен нолю. Вся энергия подаваемая в двигатель преобразуется в тепло.

Пропорционален. Но зависит не только от тока, а и от взаимного расположения полюсов ротора и статора.

Нужно управлять не током а моментом. Это не совсем одно и тоже; Посчитайте, для начала, сколько энергии нужно рассеять.

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

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

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

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

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

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

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

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

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

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

Спасибо.