cnc-club.ru

sertix писал(а):В DDLMV1 интерполятора скорее всего нет, так как он не является DSP контроллером. Интерполятор в данном случае находится в Mach

Гм.
adopt FPGA(field programmable gate array) ,software use real time multitasking control and hardware interpolation enable that has high stability when stepping motor running

На странице производителя.

Кто Mach глубоко ковырял ? Он на чем построен на сервоциклах или на брезенхеме(третий вариант если есть)?
Или он более высокоуровневую информацию выдает, а интерполяцию на аддон сбрасывает ?

Могу сказать что на паралельном порту даже в полушаге работало куда лучше. Могу предположить что таки аддон интерполирует.

AlexSVC писал(а):Кто Mach глубоко ковырял ? Он на чем построен на сервоциклах или на брезенхеме(третий вариант если есть)?

Посылает плагину уже подготовленную траекторию в виде координат в конце каждого сервоцикла (вроде бы по умолчанию длительностью 2 мс).

AlexSVC, да вы по моему не совсем в теме что есть аддон, а что интерполятор! Вот вам для домашнего чтения про интерполяцию http://interlaser.ru/diskretnost-i-interpolyciy-v-chpu. А аддон всего лишь передает в порт USB то, что должно было быть передано в LPT!

sertix писал(а):AlexSVC, да вы по моему не совсем в теме что есть аддон, а что интерполятор! Вот вам для домашнего чтения про интерполяцию http://interlaser.ru/diskretnost-i-interpolyciy-v-chpu. А аддон всего лишь передает в порт USB то, что должно было быть передано в LPT!

sertix, к чему все это?
И как можно передать в USB сигнал с частотой в несколько десятков килогерц?

USB 2.0 до 480мбит/сек.

sertix писал(а):USB 2.0 до 480мбит/сек.

Ну, замечательно, а дальше что?
Как передать многоканальный сигнал на частоте в несколько десятков килогерц?
Для этого не нужна высокая пропускная способность - даже если не сжимать данные - достаточно 100 кБ/с.
А если сжимать - то еще раз в 10 меньше.

Вопрос в другом - как передать по USB хотя бы 1 бит информации менее чем за 10 мкс?

Михаил, я с вами спорить не буду по поводу "как передать по USB хотя бы 1 бит информации менее чем за 10 мкс?", я не на столько подкован, но объясните мне как работают контроллеры в связке USB+Plugin+Mach, зачем этим контроллерам нужен Mach?

michael-yurov писал(а):Для этого не нужна высокая пропускная способность - даже если не сжимать данные - достаточно 100 кБ/с.
А если сжимать - то еще раз в 10 меньше.

Вопрос в другом - как передать по USB хотя бы 1 бит информации менее чем за 10 мкс?

И это вопрошает тот, кто сделал свою интерфейсную плату? Вы же знаете такое слово как "буфер"? Обычно заливается "покадрово"(для USB один кадр равен 1 миллисекунде) и на стороне "платы" распаковывается. "Плагин" обычно кеширует до полусекунды "пути"(хотя, в принципе - хватит и 10 кадров запаса для стабильного обмена).

sertix писал(а):USB 2.0 до 480мбит/сек.

Мегабиты и килогерцы - совершенно разные вещи!

sertix писал(а):Михаил, я с вами спорить не буду по поводу "как передать по USB хотя бы 1 бит информации менее чем за 10 мкс?", я не на столько подкован, но объясните мне как работают контроллеры в связке USB+Plugin+Mach, зачем этим контроллерам нужен Mach?

Mach рассчитывает движение с учетом заданных скоростей, ускорений, допустимых величин сглаживания траектории и прочего, прочего.
Во время расчета все это дело разбивается на кусочки по 2 мс, а уже потом данные (координаты всех осей (в импульсах/шагах, а не миллиметрах) разбитые на 2 мс) передаются плагину, который уже передает данные в контроллер (пачками).
Данные передаются с некоторым запасом (примерно 1 с) для предотвращения проблем вызванных нестабильностью передачи данных.
Из за этого получается, что станок реагирует на действия пользователя с некоторой задержкой. Например, мы нажали паузу. Mach3 рассчитал плавную остановку, но, к сожалению, рассчитал он ее с учетом того, что в буфере контроллера уже есть данные на 1 секунду работы станка, и, соответственно, замедляться он начнет не раньше, чем выработает данные из буфера.
С одной стороны данный подход сильно упрощает логику работы контроллера, а с другой - создает весьма неприятные сложности.
Например, как управлять станком вручную, если он выполняет все команды с существенной задержкой? Приходится искать обходные пути - учить контроллер работать самостоятельно, и передавать в него просто информацию о "нажатых клавишах".
Но тогда возникает новая проблема - если контроллер сам куда-то там передвинул станок - нужно тогда и координаты с программой синхронизировать. Приходится и это реализовывать, как очередную заплатку.
А потом возникают проблемы при выполнении скриптов, возникают проблемы, если буфер не опустошился, а мы двигаем станок в ручную, возникает проблема с управлением от штурвала (РГИ), возникает проблема невозможности обратной связи (например, для токарной обработки для синхронизации со скоростью вращения шпинделя / главного привода) ну и подобные проблемы.
В общем - контроллеры для Mach3 - та еще развлекуха. Как для разработчика, так и для пользователей. И виной тому - дурная голова разработчика Mach3.

Так что если если топикстартеру удастся сделать удобную и не глючную систему ЧПУ - это было бы круто.
Другой вопрос - что она не будет универсальной (так же, как KMotionCNC, NCStudio, PlanetCNC, EdingCNC и т.д.).

megagad писал(а):И это вопрошает тот, кто сделал свою интерфейсную плату? Вы же знаете такое слово как "буфер"?

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

Predator писал(а):Мегабиты и килогерцы - совершенно разные вещи!

Тут скорее проблема в синхронности передачи данных.

michael-yurov писал(а):Mach рассчитывает движение с учетом заданных скоростей, ускорений, допустимых величин сглаживания траектории и прочего, прочего.
Во время расчета все это дело разбивается на кусочки по 2 мс, а уже потом данные (координаты всех осей (в импульсах/шагах, а не миллиметрах) через каждые 2 мс) передаются плагину, который уже передает данные в контроллер.

А разве я не об этом в сильно упрощенном варианте говорил?

sertix писал(а):аддон всего лишь передает в порт USB то, что должно было быть передано в LPT!

sertix писал(а):А разве я не об этом в сильно упрощенном варианте говорил?

Об этом, но не сказал главного - что же именно передается по USB.
И упустил деталь - драйвер LPT от Mach3, который такие же данные преобразует в импульсы управления и "дергает" за пины порта.
Этот драйвер - самая важная часть в Mach3.

С этим разобрались, теперь надо разобраться где находится интерполятор.

sertix писал(а):С этим разобрались, теперь надо разобраться где находится интерполятор.

Тот который G-код разгребает?
Так он, вообще, у Mach3 из исходников EMC выдран и немного доработан (с ошибками, к сожалению).

А, не,.. это, наверное интерпретатор?

А интерполятор, это, видимо, то, что потом соединяет траекторию, разбитую на сервоциклы в последовательность управляющих импульсов - так это уже в контроллере (и в драйвере LPT).

Хорошо, а здесь тогда о чем речь http://interlaser.ru/diskretnost-i-interpolyciy-v-chpu

sertix писал(а):Хорошо, а здесь тогда о чем речь http://interlaser.ru/diskretnost-i-interpolyciy-v-chpu

Здесь они интерпретатор называют интерполятором (ошибка перевода созвучных слов).
В целом речь идет про ту часть системы ЧПУ, которая читает G-код и соображает, что же нужно делать станку.

Недавно похожая путаница была со словами дампер (тот, который ограничивает всплески напряжения, поглощая избыток) и демпфер (который поглощает вибрации ШД за счет создания электроникой вязкости в работе мотора).

michael-yurov писал(а):Там, скорее всего, по четыре выхода с каждой микросхемы, так что с каждого выхода можно снять до 17,5 мА.

Ну да, я ошибся. 3 микросхемы * 8 = 24 вывода, 5*2=10 + 4 на доп порт и того используют 14 из 24. 75*3/14 = 16.07 мА в среднем.

michael-yurov писал(а):Очень хотелось бы увидеть осциллограмму.

завтра сделаю.

michael-yurov писал(а):- Чтобы станок не шумел (чтобы шаговые моторы работали максимально тихо).
- Чтобы движение станка было максимально плавным и равномерным. Это нужно при работе тонким инструментом (иногда использую фрезы диаметром до 0,3 мм).

Я считаю, что этот момент должен взять на себя драйвер, а не контроллер, т.к. каналов и драйверов может быть много, а контроллер - один. Контроллеру высокие частоты даются не просто (сильно усложняется и дорожает аппаратная часть + требует более скоростные каналы + с ростом частоты растет чувствительность к помехам) и ладно бы если ради точности, так нет, а банально для плавности привода. Получается, что информация о движении которую генерирует контроллер для драйвера - сильно избыточна. Если этот момент переносится на драйвер, то получается как-бы многопроцессорная система (в каждом драйвере-процессор), которая путем незначительного усложнения аппаратно-программной части дает значительный выигрыш в нескольких позициях. С экономической точки зрения такая система выйдет дешевле. Это очень похоже на ваше решение с фильтром для степов, только встроенное в драйвер.

AlexSVC писал(а):Это очень похоже на ваше решение с фильтром для степов, только встроенное в драйвер.

А есть встроенное в драйвер - только работает фигово.

Кстати, мне тоже не легко дались высокие частоты Step - практически год на это потратил, однако, сделал.

michael-yurov писал(а): все это дело разбивается на кусочки по 2 мс

Похоже main control chip is AT91SAM7S64 of ATMEL series. master frequency 55MHz не правда.
master frequency не 55MHz а в лучшем случае 500КГц, завтра осциллограму сделаю и замерю джиттер. По идее 1/длительность джиттера = master frequency.

Частота сервоциклов Mach : 1/0.002 = 500 Гц...

Пару слов о сервоциклах.
Недостаток систем на сервоциклах в том, что если в сервоцикл попадает кусок с резким изменением траектории (к примеру поворот на 90гр.) и скорость движения значительна (кол-во шагов в сервоцикле больше 1) то происходит растягивание импульсов или сглаживание угла независимо ни от каких настроек (кроме частоты сервоциклов).Выходит, чем выше скорость (частота импульсов) тем сильнее сглаживается, причем не всегда одинаково, а как попадет кадр.
И еще, плавный разгон превращается не в равномерное нарастание частоты импульсов, а в скачкообразное изменение частоты пачками с частотой сервоцикла. Т.е. в случае Mach - пачками по 2 мс.
Достоинство - можно напихать сколько угодное число шагов в один сервоцикл.

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

michael-yurov писал(а):А есть встроенное в драйвер - только работает фигово.

Ну у вас же хорошо работает, а системы равнозначны (обе со степами работают). У STM-а ресурсов хватило на два канала, что мешает по одному STM-у на канал + оставшийся ресурс на обслугу драверных дел ?
А то что кто-то фигово сделал - так это не покаатель.