Приветствую специалистов!
Столкнулся первый раз, прошу подсказок.
Опыт проектирования электронных плат управления более 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. Дисплей и клавиатуру вешал на короткие кабели прямо рядом с платой. Проблема зависаний не исчезла. Это как понимаю наиболее проблемные линии так как напрямую от процессора наружу идут.

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

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

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



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

Я бы для начала отрубил от модуля все кабели вообще, в том числе и питание, и повесил бы его на автономный аккумулятор.
И положил бы это на стол на сутки. Без дисплея, клавы и остального. Только светодиодик показывает что он пашет. Ну или по изолированному порту какую нибудь диагностику выдает, например температуру чипа. Приложил палец, температура изменилась,
в терминалке посмотрел, значит живой.
Если завис, значит софт.
Затем вот это дело засунул в шкаф. Если зависает, значит помехи настолько сильные, а схема настолько слабая, что наведенные помехи выбивают проц. Тогда полная переразводка платы без вопросов.
Если не зависает, подключил одно устройство. На сутки. И опять зависает или нет.
И так по одному устройству. Все на собственном аккумуляторе.
Если при подключении очередного устройства стало виснуть, значит защита по ESD.
Если на аккумуляторе все кроме питания подключено и он не зависает, значит проблема в питании от сети.
Ну там еще много если. Плохо что редко зависает. Самый тяжелый случай. Долго искать придется.

Сообщение отредактировал novchok - Jan 5 2013, 10:59

это плохо
общие советы:
1. как писал novchok сделайте лог и посмотрите в какой момент происходит зависание (при включении реле, насоса и т.п.)
2. нарисуйте схему соединений и проанализируйте как "ходят" токи. может, у Вас несколько контуров образовалось
3. возьмите источник наносекундных импульсов и проведите тестирование. так быстрее найдете слабые места
4. ...
советов много. лучше выложите схему соединений и разводки шкафа. так будет виднее для всех куда копать.

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

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

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

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

Сообщение отредактировал novchok - Jan 5 2013, 11:51

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

Уважаемые профессионалы, благодарю за подсказки!!
Подозревать в ограниченных умственных способностях - это именно взгляд со стороны, иногда зарабатываешься и что-то забываешь.
Но не в моем случае. Забыл сообщить.
Плата с дисплеем, клавиатурой и частью датчиков работает на столе 3 дня (дольше не оставлял) все четко - лаб.блок питания и вне корпуса.
Софт написан на FreeRTOS сегодня получил 5-суточный лог отладки - никакие задачи стек не переполняют, т.е. я с вероятностью 99% отсек - это не проблема ПО.
Уже месяц как проделывались разные тесты.
В том числе - отключение по очереди каждого разъема и оставление на прогон.
Без разъемов все работает, с одним подключенным разъемом каждым работает, но при подключенных 2-3 из этих же начинает подвисать.
Подвисание происходит не в какой-то конкретный момент например включения какого-то клапана - давно бы отловил. Зависает даже просто так!
АК - похоже вы правы, не под фонарем. Вашу ссылку про EMC_immunity прочитал 1-го января и стал осознавать.
Не выкладывал схемы потому что не хотел грузить всех здесь лишней информацией - и так своих проектов наверняка хватает.
Переразвести плату сейчас проблемно т.к. сотню первых придется выбросить.
Почему скажете первую не протестировал? Смешно. Первую протестировал. И на первом образце аппарата она отлично работала. Первый образец аппарата просто не покрашен был
Т.е. стараюсь найти решение без переразводки платы.
Проброска толстых проводов поверх всех разъемов может помочь?
В принципе все земли периферии из разъемов могу вытащить и соединить сразу на клемму блока питания или платы (где питание приходит).

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

Прилагаю разводу платы. Пожалуйста критикуйте. "Переделать все заново" - это я и сам теперь могу сказать. С возможностью эту плату как-то перетрясти.
XT8 - ввод питания (+12, +24в)
XT18 - датчики 5..20мА
XT19 - концевики
XT16 - iButton
XT15 - ЭМ клапаны =24в
XT2 - ЖКИ/OLED
XT5 - на силовую плату (там реле электромагнитные)
Это все из текущих подключений.

И фото прилагаю. Видно щиток с платой. Под ней стоят блоки питания.
Сверху ящик с клавиатурой дисплеем.
Снизу - насос.

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

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

Сообщение отредактировал novchok - Jan 5 2013, 19:44

Здесь ситуация трагичная.
У меня был похожий случай недавно.
Смысл в том что плату проектировали одни, а разводку проводов в ящике другие и абсолютно произвольно как им было удобно.
И вообщем проложили шлейф к клавиатуре тоже как в вашем случае достаточно длинный и вплотную прикрепили его конструкционному металлу.
А на плате монтажные отверстия тоже не были присоединены к земле. Ну плата не ресетилась, но сигналы ложного дребезга кнопок шли непрерывно при включенном двигателе.

А вообще ошибки на плате грубейшие.
Главная это отсутствие верхнего и нижнего полигонов под микроконтроллером.
Поэтому источников сбоев скорее всего несколько и это должно вносить путаницу.
Т.е. ни одна единичная мера не принесет полного избавления от проблем.

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

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


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

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

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

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

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


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

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

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

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

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

Монтажники ящиков были хорошо научены проводить шины CAN. И знали что там надо использовать обязательно витую пару, и это гуд.
И у них было прикуплено в запас таких проводов.
И вот настал момент вывести из ящика интерфейс RS232.
И конечно без вопросов применили для этого кабель от CAN. Т.е. в одной паре и TX и RX.
И оно ничего, протестировали, все нормально, а на обоих концах стояли нагрузки. Но как-то раз нагрузку на дальнем конце не подключили.
И стали случаться странные глухие зависоны всей системы управления.

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

В системе работала RTOS.
Через RS232 выводился лог и диагностика как раз чтобы отлавливать редкие баги.
Поскольку задача ловли багов очень важная, то ей был присвоен высший приоритет.
Но в витой паре на RS232 возникла эховая петля из-за наводки TX на RX. Задача на RS232 включилась на полную мощность (эха там никто не предполагал) и вытеснила все остальные задачи в системе.
С виду выглядело как полный зависон системы.

Кррруто!

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

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

Если точнее, то было так:
Перед пуском агрегата проводился апгрейд его ПО. После апгрейда иногда проводилась, а иногда нет диагностика через RS232.
На другом конце того "неправильного" кабеля иногда подключалась, а иногда нет HMI панель.
Но диагностика проводилась локально с отсоединением длинного "неправильного" кабеля.
В течении диагностики мог быть включен режим специального реалтайм лога, который на один введенный символ из большого набора выводил кучу информации в интерактивном режиме. Т.е. имел место несимметричный по объему обмен информации туда и обратно.

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

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