Слыхали вы звон ....Сообщение от Дмитрий Артюховский
Слыхали вы звон ....
Для прецизионной точности подачи используются энкодеры ROD426, с оптическим диском - 10.000 штрихов на 1 полный оборот. Расчетно экспериментально у меня вышли - цена деления импульса: по оси Z - 7985 импульсов на 1 мм, по оси Y - 12450 импульсов на 1 мм движения резца! Вот такая точность. Станок уже работает, при быстрых движениях шпинделя (без процесса резания) координаты теряются, потому пока реализовал функцию ручной установки нуля, т.е. подвели вручную на начальную точку резец, на один дискретный вход от внешней кнопки подается сигнал, далее программа берет эту координату за нуль по всем осям и начинается процесс металлобработки, в это время скорость движения резца сравнительно не велика и уже работать можно, но до ума довести необходимо.
Быстрые движения это сколько мм в секунду?
По оси Y - около 3,5 мм/сек, по Z - около 7 мм/сек, точное время передвижения на макисмалках не отсчитывал по таймеру. Быстрые передвижения нужны только при подводе инструмента. А точность такая при резке нужна, так как станок обтачивает кончиком резца зеркала запорных араматур диаметром до 1400 мм и конечный результат после чистовой обработки на самом деле в виде зеркала и смотрится
Недельку между дел бились с согласованием уровней сигнала энкодера, добились амплитуды 24 В и прямоугольной формы - результат такой же, пропускает контроллер сигналы, даже не при 30 кГц, а при 10 как оказалось. У меня вся управляющая программа в теле основного цикла, всего строк 200 ST кода, для 400 МГц микропроцессора это ерунда так-то, не может же это влиять на счет-то.
Видимо придется уже идти в направлении движения этой ветки, подключаться в использование PRU.
Кстати, в основной программе правильно обрабатываете энкодер?
Покажете код? Ну, должно же быть преобразование из WORD'ов (которые получаются из fast encoder) в DWORD или что-то такое на стороне CoDeSys.
Может, "пропуск" из-за того, что в основной программе какая-нибудь ошибка и просто неправильно складываются показания из fast encoder'а?
В целом, попробуйте https://hardella.com/docs/pru/examples/fast-encoder/
Как-никак, будет хоть какой-то альтернативный способ посмотреть на проблему.
звиняйте за такой вид программки моей, если нарушил какие-то принципы построения кода, самоучка я. Ну вот собственно кусочек кода. Переменная Shet1: DINT - глобальная.
програмулька.jpg
Да даже визуально видно при работе программы во вкладке глобальных переменных, как себя ведет счетчик накопительный и данные какие поступают с энкодера. Все что поступило - программой просчиталось и про суммировалось. Тут явно пропуски контроллера
Быть такого не может в ПЛК110[М02]. Или программа не верно написана или ПЛК неисправен.
Ну вот у меня такая ситуация. Первый опыт общения с ПЛК и не с чем сравнивать пока. И писал же, что даже если исключить управляющую программу, наблюдаю за энкодреами в глобальных переменных, т.е. не использую никакой свой код, и там видно что идут потери, при частоте свыше 25 кГц счет уже почти отсутствует. Возможно брак, при заказе на заводе не было в наличии ПЛК110-60, ждали изготовления 3 недели.
После праздников уже продолжу эксперименты с быстрыми входами, пока станок в таком режиме запущен, влияет всего лишь на оперативность работы, за целый день дополнительно 15 минут простоя, не существенно.
Далее хочу каждый канал прогнать (с 1 по 4) в режиме быстрого счетчика, посмотрю на каких частотах начнет спотыкаться.
Уверены, что энкодер исправен ?
Ваши права
Ответить с цитированием