[Firer 0]

Приветствую специалистов!

Столкнулся первый раз, прошу подсказок.

Опыт проектирования электронных плат управления более 5 лет, но столкнулся с проблемой ЭМС серьезно только сейчас:

Электрошкаф. Металлический корпус ширина 2м, высота 2м глубина около 80см.

В разных частях корпуса стоят:

- насос 220в (мощность менее 1кВт)

- датчики концевики разные

- пара разъемов Dallas iButton

- с десяток ЭМ клапанов =24в

- пара датчиков давления 5..20мА

Электрика 220в устанавливается в отдельном металл. ящике внутри изделия. К ней подводится 220в. Внутри УЗО, автоматы.

В другом ящике металл.(самое интересное) устанавливается:

- бесперебойник обычный бытовой около 500Вт

- блоки питания импульсные 24в, 12в (каждый 200Вт) - наподобие Meanwell

- плата процессорная (спроектирована мною) ядро STM32F217.

 

В отдельном ящике к которому идет кабель около 2м установлены:

- Дисплей OLED алфавитно-цифровой 4 строки 20 символов

- клавиатура матрица 4*4

 

На реальном оборудовании в течение суток все зависает по неизвесным причинам в случайное время на разных точках. (если без ватчдога в прошивке - или перезагружается если с ватчдогом).

Хочу докопаться до истины.

Доп.инфо:

 

плата процессорная - питание на процессор формируется так:

сначала Buck LM2673 до 5в. Затем линейный стабилизатор до 3.3в.

 

плата разведена с землями и сверху и снизу. Но трассы земель с одного разъема внешних устройств на другой могут проходить через землю процессора, т.е. две земли не отделены четко.

 

1. Соединение общего провода (- блоков питания) с шасси корпуса сделал в блоке рядом с блоком питания. Несколько уменьшило частоту зависания.

2. Дисплей и клавиатуру вешал на короткие кабели прямо рядом с платой. Проблема зависаний не исчезла. Это как понимаю наиболее проблемные линии так как напрямую от процессора наружу идут.

 

Куда копать еще?

 

 

[Microwatt 2]

Вы уверены, что зависания из-за питания?

ПО может само по себе зависания вызвать. Сопряжение с датчиками неудачно сделано. И еще могут быть причины помимо питания.

[=AK= 18]

Хочу докопаться до истины.

Не там копаете. В таких случаях, как ваш, питание ни при чем, хотя все начинают копать именно питание. Понятное дело, что ключи легче искать под фонарем, а не там, в темноте, где вы их потеряли.

 

Куда копать еще?

 

Ознакомьтесь: http://caxapa.ru/lib/emc_immunity.html. После ознакомления проанализируйте источники и пути прохождения помех, отделите чистую землю от грязной, поставьте барьеры. При необходимости - перекомпонуйте устройство или переразведите свою плату.

[novchok 0]

Я бы для начала отрубил от модуля все кабели вообще, в том числе и питание, и повесил бы его на автономный аккумулятор.

И положил бы это на стол на сутки. Без дисплея, клавы и остального. Только светодиодик показывает что он пашет. Ну или по изолированному порту какую нибудь диагностику выдает, например температуру чипа. Приложил палец, температура изменилась,

в терминалке посмотрел, значит живой.

Если завис, значит софт.

Затем вот это дело засунул в шкаф. Если зависает, значит помехи настолько сильные, а схема настолько слабая, что наведенные помехи выбивают проц. Тогда полная переразводка платы без вопросов.

Если не зависает, подключил одно устройство. На сутки. И опять зависает или нет.

И так по одному устройству. Все на собственном аккумуляторе.

Если при подключении очередного устройства стало виснуть, значит защита по ESD.

Если на аккумуляторе все кроме питания подключено и он не зависает, значит проблема в питании от сети.

Ну там еще много если. Плохо что редко зависает. Самый тяжелый случай. Долго искать придется.

Изменено 5 января, 2013 пользователем novchok

[bav 0]

плата разведена с землями и сверху и снизу. Но трассы земель с одного разъема внешних устройств на другой могут проходить через землю процессора, т.е. две земли не отделены четко.

это плохо

общие советы:

1. как писал novchok сделайте лог и посмотрите в какой момент происходит зависание (при включении реле, насоса и т.п.)

2. нарисуйте схему соединений и проанализируйте как "ходят" токи. может, у Вас несколько контуров образовалось

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

4. ...

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

 

[AlexandrY 3]

Я бы для начала отрубил от модуля все кабели вообще, в том числе и питание, и повесил бы его на автономный аккумулятор.

... значит живой.

Если завис, значит софт...

 

Это называется подозревать разработчика в ограниченных умственных способностях ;)

 

Где вы видели чтобы платы отправлялись на реальный объект без этапа работы на столе?

И какая разница работает он на столе от аккумлятора либо от сетевого источника питания(считаем исправного) если к нему не подключены другие кабеля?

Скажу что, если плата хорошо ловит электромагнитные наводки, то и аккумулятор не поможет если он габаритный и к нему идут провода более 10 см длиной.

Возня с аккумулятором дело только запутает.

 

Первым шагом должна быть пропайка на плате звездой напрямик толстым проводом земель на разъемах внешних кабелей (даже гальваноизолированных) с землей разъема питания.

[novchok 0]

Это называется подозревать разработчика в ограниченных умственных способностях ;)

Человек спросил, я ответил, как бы делал я. Насчет длинных проводов, ошибочка вышла. Надо написать "подключить аккумулятор короткими проводами, а лучше встроить его в корпус с микропроцессором под общий корпус".

Если уж дело имеем с наводками, провода должны быть максимально толстые, лучше с палец толщиной :) И максимально короткими, лучше короче поперечного сечения :)

Изменено 5 января, 2013 пользователем novchok

[=AK= 18]

Надо написать "подключить аккумулятор короткими проводами, а лучше встроить его в корпус с микропроцессором под общий корпус".

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

[Firer 0]

Уважаемые профессионалы, благодарю за подсказки!!

Подозревать в ограниченных умственных способностях - это именно взгляд со стороны, иногда зарабатываешься и что-то забываешь.

Но не в моем случае. Забыл сообщить.

Плата с дисплеем, клавиатурой и частью датчиков работает на столе 3 дня (дольше не оставлял) все четко - лаб.блок питания и вне корпуса.

Софт написан на FreeRTOS сегодня получил 5-суточный лог отладки - никакие задачи стек не переполняют, т.е. я с вероятностью 99% отсек - это не проблема ПО.

Уже месяц как проделывались разные тесты.

В том числе - отключение по очереди каждого разъема и оставление на прогон.

Без разъемов все работает, с одним подключенным разъемом каждым работает, но при подключенных 2-3 из этих же начинает подвисать.

Подвисание происходит не в какой-то конкретный момент например включения какого-то клапана - давно бы отловил. Зависает даже просто так!

АК - похоже вы правы, не под фонарем. Вашу ссылку про EMC_immunity прочитал 1-го января и стал осознавать.

Не выкладывал схемы потому что не хотел грузить всех здесь лишней информацией - и так своих проектов наверняка хватает.

Переразвести плату сейчас проблемно т.к. сотню первых придется выбросить.

Почему скажете первую не протестировал? Смешно. Первую протестировал. И на первом образце аппарата она отлично работала. Первый образец аппарата просто не покрашен был :)

Т.е. стараюсь найти решение без переразводки платы.

Проброска толстых проводов поверх всех разъемов может помочь?

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

 

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

 

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

XT8 - ввод питания (+12, +24в)

XT18 - датчики 5..20мА

XT19 - концевики

XT16 - iButton

XT15 - ЭМ клапаны =24в

XT2 - ЖКИ/OLED

XT5 - на силовую плату (там реле электромагнитные)

Это все из текущих подключений.

 

И фото прилагаю. Видно щиток с платой. Под ней стоят блоки питания.

Сверху ящик с клавиатурой дисплеем.

Снизу - насос.

 

Спасибо за любые комментарии!!

emc_problem_pcb.pdf

[novchok 0]

Интересная платка.

Изменено 5 января, 2013 пользователем novchok

[AlexandrY 3]

Почему скажете первую не протестировал? Смешно. Первую протестировал. И на первом образце аппарата она отлично работала. Первый образец аппарата просто не покрашен был :)

Т.е. стараюсь найти решение без переразводки платы.

Проброска толстых проводов поверх всех разъемов может помочь?

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

 

Здесь ситуация трагичная.

У меня был похожий случай недавно.

Смысл в том что плату проектировали одни, а разводку проводов в ящике другие и абсолютно произвольно как им было удобно.

И вообщем проложили шлейф к клавиатуре тоже как в вашем случае достаточно длинный и вплотную прикрепили его конструкционному металлу.

А на плате монтажные отверстия тоже не были присоединены к земле. Ну плата не ресетилась, но сигналы ложного дребезга кнопок шли непрерывно при включенном двигателе.

 

А вообще ошибки на плате грубейшие.

Главная это отсутствие верхнего и нижнего полигонов под микроконтроллером.

Поэтому источников сбоев скорее всего несколько и это должно вносить путаницу.

Т.е. ни одна единичная мера не принесет полного избавления от проблем.

 

Вот как выглядит моя плата на STM32F2xx:

 

 

[=AK= 18]

Т.е. стараюсь найти решение без переразводки платы.

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

 

Проброска толстых проводов поверх всех разъемов может помочь?

В какой-то степени, но вряд ли это будет панацеей.

 

Вынужден еще раз повторить: проанализируйте источники и пути прохождения помех, отделите чистую землю от грязной, поставьте барьеры. Это можно сделать без переразводки платы. И за вас это никто не сделает, потому что документов нужной степени детализации на форум вы не выложите, да и вообще, по документам это не всегда легко сделать, надо живьем смотреть.

 

Начните с того, что продумайте земли. Как вариант, поставьте отдельные земляные терминалы для "чистой" и "грязной" земель в каждом ящике. Очевидной "грязной землей" для каждого ящика является сам этот металлический ящик.

 

Для простоты можно положить, что каждый кабель, приходящий в каждый ящик, обязательно как-то ловит НП помеху и притаскивает в ящик, это будет недалеко от истины. Вот и продумайте, куда эта помеха побежит внутри ящика и что сшибет по дороге. Обеспечьте помехам хороший обходной путь по грязным землям, чтобы им не было резона бежать по чистой земле. А на пути к чистой земле поставьте для помех барьеры.

 

Проверьте все реле, контакторы и клапаны. Если обмотки питаются от DC - параллельно обмотке должен стоять диод. Все контакты (включая концевики), которые коммутируют обмотки, задемпфируйте искрогасящими RC-цепочками. Поставьте RC-цепочки c конденсаторами класса Х1 или Х2 в цепях питания мотора, загасите любую возможность появления искр и дуг. В том числе - проверьте, не включены ли где-либо просто гольные кондеры вместо RC-цепочек параллельно контактам. А то ведь бывают такие кулибины, которые, например, от недоумия параллельно кнопкам кондеры вешают.

 

импульсы могут проскакивать не через землю, а и через входы которые не должным образом сделаны (например прямые линии от процессора к OLED и клавиатуре).

Несомненно, могут. Если невозможно поставить барьеры на самой плате - ставьте дополнительные внешние платы с резисторными и ферритовыми барьерами.

 

Надевайте ферритовые клампы на кабели, пропускайте кабели через ферритовые кольца. Продумайте укладку кабелей, кто с кем рядом лежит. И т.п.

[AlexandrY 3]

Подвисание происходит не в какой-то конкретный момент например включения какого-то клапана - давно бы отловил. Зависает даже просто так!

 

Еще в копилку курьезов.

 

У вас я там вижу скрученными парами балуются.

 

Так вот был такой случай.

 

Монтажники ящиков были хорошо научены проводить шины CAN. И знали что там надо использовать обязательно витую пару, и это гуд.

И у них было прикуплено в запас таких проводов.

И вот настал момент вывести из ящика интерфейс RS232.

И конечно без вопросов применили для этого кабель от CAN. Т.е. в одной паре и TX и RX.

И оно ничего, протестировали, все нормально, а на обоих концах стояли нагрузки. Но как-то раз нагрузку на дальнем конце не подключили.

И стали случаться странные глухие зависоны всей системы управления.

 

А подноготная была такая.

 

В системе работала RTOS.

Через RS232 выводился лог и диагностика как раз чтобы отлавливать редкие баги.

Поскольку задача ловли багов очень важная, то ей был присвоен высший приоритет.

Но в витой паре на RS232 возникла эховая петля из-за наводки TX на RX. Задача на RS232 включилась на полную мощность (эха там никто не предполагал) и вытеснила все остальные задачи в системе.

С виду выглядело как полный зависон системы.

 

[haker_fox 61]

С виду выглядело как полный зависон системы.

Кррруто! :rolleyes:

 

Т.е. каким-то образом софт "обрабатывал" входящую информацию по каналу? Пусть даже и нештатно, например на "висячий" ISR?

 

[AlexandrY 3]

Кррруто! :rolleyes:

 

Т.е. каким-то образом софт "обрабатывал" входящую информацию по каналу? Пусть даже и нештатно, например на "висячий" ISR?

 

Вообще-то некоторые технологические моменты пропустил для упрощения.

 

Если точнее, то было так:

Перед пуском агрегата проводился апгрейд его ПО. После апгрейда иногда проводилась, а иногда нет диагностика через RS232.

На другом конце того "неправильного" кабеля иногда подключалась, а иногда нет HMI панель.

Но диагностика проводилась локально с отсоединением длинного "неправильного" кабеля.

В течении диагностики мог быть включен режим специального реалтайм лога, который на один введенный символ из большого набора выводил кучу информации в интерактивном режиме. Т.е. имел место несимметричный по объему обмен информации туда и обратно.

 

И значит должно было совпасть несколько обстоятельств: должны были включить диагностику, зайти в определенный режим, не выходя из режима выдернуть кабель (ну конец смены, кому охота лишние кнопки жать) и воткнуть штатный кабель (для порядку) на дальнем конце которого ничего не было бы подключено.

Подсистема обработки очередей на вывод в RTOS была сделана так, что при переполнении очереди на вывод

включался быстрый программный цикл ожидания очищения очереди без использования задержек RTOS,

поскольку тик операционки для отладочного протокола в реальном времени был слишком длинный (10 мс).

Соответственно очередь мгновенно переполнялась и процедура задержки в задаче RS232 занимала все ресурсы процессора и не могла быть вытеснена поскольку имела приоритет выше чем приоритет задач обработки всех внешних сигналов.

 

Вот так возникал необъяснимы глюк, редкий и с первого взгляда мало с чем коррелировавший.