Моя проблема ЭМС, Вопрос к гуру! Опции

[Firer]

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

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

[Firer]

Уважаемые профессионалы, благодарю за подсказки!!
Подозревать в ограниченных умственных способностях - это именно взгляд со стороны, иногда зарабатываешься и что-то забываешь.
Но не в моем случае. Забыл сообщить.
Плата с дисплеем, клавиатурой и частью датчиков работает на столе 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 ( 608.66 килобайт ) Кол-во скачиваний: 400

 

[AlexandrY]

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

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

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

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

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

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

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

[haker_fox]

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

Кррруто!

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

[AlexandrY]

Кррруто!

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

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

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

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

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