КИП, КИПиА, Автоматизация: KIPiA.SU: Не там искали…

Не там искали…


Как часто неисправность оказывается не там, где искали. Для примера приведу два случая.

Токарный станок с Числовым Программным Управлением (ЧПУ). Имеет три привода: привод шпинделя (Главный привод), привод суппорта (перемещение вдоль оси станка - по документации – по оси Z) и привод каретки (поперёк станка - по оси X). Управляет всеми этими приводами, а заодно и всей автоматикой, Устройство Числового Программного Управления (УЧПУ), выполненного на основе очень известной «Электроника-60). Надо отдать должное – станок здорово выручает. Но однажды произошёл сбой – резец «чуть-чуть» проехал заданную координату – деталь испорчена.

Начинаем логически мыслить. Каждый привод имеет свой датчик. Сбой произошёл по оси Z – значит неисправность в канале Z. Начиная от датчика и заканчивая решением УЧПУ.

Дополнительная информация – УЧПУ сбой не обнаружило. Делаем профилактику датчика и разъёмным соединениям. Поскольку дефект случайный, надо сделать тестовый режим многократного повторения одной и той же операции. Программируем, гоняем только по оси Z, остальные приводы не включаем, чтобы не мешали. 4 часа – сбоев нет. Ну, значит где-то был неконтакт. Включаем – станок работает. Но через два часа – опять сбой. Сколько было потрачено времени на поиски неисправности! Гоняем по Z тестовой программой – сбоев нет. Как только включаем в работу – сбой. Всё. Сами – никак. Нашли в Интернете прекрасный Форум приводчиков. Консилиум в основном сошёлся на неисправности датчика. Поскольку своих умных мыслей больше нет, тупо делаем заново профилактику канала датчика Z, а заодно X и главного привода. Нам повезло, иначе мне не о чем было бы писать. Неисправность действительно оказалась в датчике, но не Z, а главного привода (Шпинделя). Во время этой глобальной профилактики в датчиках Z и X ничего не обнаружили. А вот в датчике шпинделя...! Ось датчика шпинделя соединяется с валом шпинделя через гибкое соединение типа кардана. Со стороны датчика – тонкая пружинистая пластина с двумя диаметрально расположенными отверстиями. Со стороны вала – два пальчика. Одно из отверстий было деформировано так, что, вероятно, иногда пальчики проскакивали (соединение пробуксовывало). Заменили пластину. Гоняли на разных скоростях (ну теперь, конечно же при работе всех трёх приводов) – сбоев не было. Это и был дефект. Ошибка (ГРАБЛИ)! в том, что гоняли только координату Z без вращения шпинделя, т.е. без неисправного элемента. Так, конечно, дефект вряд ли найдёшь. На прогоне (без вращения шпинделя) – ошибок нет, во время работы (шпиндель и соединение с датчиком работает) – сбой. Специалисты, думаю, посмеются. Ну и правильно и хорошо – смех прибавляет здоровья. А вот тем, кто вынужден в силу разных обстоятельств заниматься не своим делом – надеюсь наука.

А вот второй пример может и специалистов предостеречь от ошибок.

Простое устройство. Два релейных цифровых сигнала. Длительность одного (около 30 сек) надо измерять и подсчитывать его передние фронты. Через установленное количество этих фронтов выполнять пару-тройку несложных операций. Результаты замеров и своих действий сохранять для передачи в компьютер по интерфейсу RS485. По второму сигналу (период около 30 минут) сбрасывать всю эту статистику и начинать всё с нуля. Для микроконтроллера это не задача, а так, задачка. Один нюанс: питание контроллера 5В, а исполнительных элементов – 24В. Да это тоже не проблема! Их столько всяких разных! Выбрали из них нужной мощности, а для компактности – ключевой на два выходных напряжения на 5 и 24. Вот ну кто бы возражал против такого выбора? Приборчик получился компактный, на столе отладили – и в цех. В цехе надо было установить таких устройств с десяток. Вот тут и началось! Пара штук работает как на столе, пара ночью работает без сбоев – днём изредка сбоит, другая пара сильно сбоит, а один вообще бешеный – сбоит всегда. На поиск неисправности потратили времени больше, чем на её разработку. Перелопатили программу контроллера, программу компьютера, заменили аналоговую фильтрацию сигналов на цифровую, перетряхнули интерфейс, боролись с помехами, дополнили обе программы дополнительными диагностическими программами (кстати, это и помогло выявить дефект). Получалось, что контроллер по ему только понятным причинам срабатывал как по команде “Reset” – перезагружался. Хотите верьте, хотите нет – осталось только заменить источник питания. Для пробы поставили два раздельных источника питания на 5 и 24. По сети они, конечно, объединялись, но 5В работали только на контроллер. Обалдеть! Как бабушка нашептала, как барабашка слинял. Полтергейст кончился! Оказалось, что эти ключевые источники питания как-то странно себя ведут – импульсная нагрузке по цепи 24В влияла на цепь 5В – вот контроллер и перезагружался. А поскольку это происходило случайно – вычислить оказалось сложно. Вот тебе и ключевой, вот тебе и компактный! По крайней мере для себя я сделал вывод: питание контроллера – только от индивидуального источника питания. Как поступать в каждом конкретном случае – вам решать, но Грабли я показал.


Инженер-электронщик Агафонов Михаил Павлович


Предлагаем обсудить статью на нашем форуме


P.S.S. Данная статья является интеллектуальной собственностью сайта KIPiA.SU. При перепечатке обязательна прямая ссылка.





Наша рассылка:
НОВОСТИ ПРИБОРОСТРОЕНИЯ
Ваше имя:
Ваш email:


 

Page created in 0.00590 seconds Powered by LastoBlog