cnc-club.ru

SergeyK писал(а):растолкуите, я пока ещё не в курсе, что в данном случае значит "сервоцикл"?

Кратко общий принцип работы ЕМС такой (в части движения):
Интерпретатор Г кода выдает следующую точку, куда должен переместиться инструмент. Интерполятор,в зависимости от выбранной кинематики, апроксимирует эту траекторию (алгоритм кубической интерполяции сплайнами) и выдает набор точек, через которые надо пройти, чтобы достигнуть следующей заданной. Далее работает планировщик траектории который в зависимости от заданных параметров максимальной скорости и ускорения распределяет эти точки во временной плоскости. Так вот минимальный тик этого распределения и называется сервоциклом. По умолчанию он равен 1мс.
В начале сервоцикла система получает информацию о положении каждой оси, датчиков. Потом происходят все расчеты в ХАЛе (ПИД,заданные зависимости) если это внутренние компоненты. И наконец происходит выдача команд на исполнительные блоки (синтезаторы частоты,ШИМы , реле итд.)
Мне пока не ясно, происходит это в одном и том же сервоцикле, либо этот расчет делается для следующего. Если для следующего то все получается, если текущего, то о медленной передаче можно забыть. У меня работает исходя из первого предположения. Работает вроде нормально, но как оно будет при всех возможных условиях - не знаю.

А что собственно за драйвер такой специальный для EMC и с чем его едят, если не секрет?

Драйвер писал сам, в расчете на спец контроллер КОМ порта. Контроллер реализован на Verilog на CPLD ALTERA.
Скажу сразу, все это очень сырое и до конечного результата далеко.

Impartial писал(а):Мне пока не ясно, происходит это в одном и том же сервоцикле, либо этот расчет делается для следующего. Если для следующего то все получается, если текущего, то о медленной передаче можно забыть. У меня работает исходя из первого предположения. Работает вроде нормально, но как оно будет при всех возможных условиях - не знаю.

Все выполняется в порядке добавления функций к потоку (это то, что addf).
Т.е. если сначала снимаем данные с энкодера, потом расситываем значения по траектории, потом считаем параметры pid, то конечный результат будет постоянным до следующего срабатывания. Хотя, он и так будет постоянным до следующего цикла.

Т.е. если сначала снимаем данные с энкодера, потом расситываем значения по траектории, потом считаем параметры pid, то конечный результат будет постоянным до следующего срабатывания. Хотя, он и так будет постоянным до следующего цикла.

Хотелось, чтобы это было так
Но судя по исходнику сначала все таки производится считывание параметров. Если бы по твоему, то вначале должна идти запись.

Все зависит от расположения строчек addf в твоем файле hal. В каком порядке ты их расположишь, в таком они и будут работать.
Вот пример, взял hal Lexxa

....
addf hm2_5i20.0.read servo-thread
addf motion-command-handler servo-thread
addf motion-controller servo-thread
...
addf pid.0.do-pid-calcs servo-thread
addf pid.1.do-pid-calcs servo-thread
addf pid.2.do-pid-calcs servo-thread
...
addf classicladder.0.refresh servo-thread
addf near.0 servo-thread
addf hm2_5i20.0.write servo-thread
addf hm2_5i20.0.pet_watchdog servo-thread

Сначала читаем данные из mesa, потом планируем траекторию, потом вычисляем параметры ПИД, потом выполняем Ladder logic, потом делаем near, потом пишев все на выводы и все - ждем следующего цикла .

Все правильно. Логически по другому не напишешь. Есть только одно НО! Поток ОС и порядок обработки потока драйвером не одно и тоже.

порядок обработки потока драйвером?

Да, а что удивляет?

Не удивляет, просто не понял/не знаю что это .

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

Насколько я понимаю, с драйверами общаются только
addf hm2_5i20.0.read servo-thread
addf hm2_5i20.0.write servo-thread
addf hm2_5i20.0.pet_watchdog servo-thread
И пока они не выполнились выполнение дальше не идет. Хотя для меня это черный лес, в низкоуровневом программировании я

Это уровень APPLICATION драйвера, который, скорее всего, только производит идентификацию сообщений для низкоуровневой части драйвера.
Основная работа происходит именно там (обработка прерываний, обмен с периферией, DMA).

Большое спасибо. Вполне доходчиво объяснили, принцип более менее понятен. Конечно интересно было бы поработать в этом направлении, но жалко времени. Хотя, что касается лада вместе с MODBUS, тут даже для подключения концевиков скорость маловата. Только если помпу включать или что то подобное.

Nick писал(а):Да, на обратный пакет нужна еще одна мс.
И еще на каждое отдельное устройство нужно посылать отдельные пакеты.

Т.е. если подключить несколько юсб устройств( usb0, usb1 и т.д.) то для отправки 1 пакета из каждого устройства потребуется задержка в мс? Нельзя уложиться в 1мс, если слать одним юсб устройством, а принимать другим?

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

Гагарин писал(а): Просто есть мысль повтыкать в юсб хаб

На слове USB мечты о реалтайме заканчиваются. Отклик в 1 мс USB никак не гарантирует.