Проблема зависание 2Gi/MC

[serg-el]

Цитата

Сообщение от coverart

При имеющейся схеме шкафа она нафикЪ не нужна. Ну или назовите НафикЪ.

При наличии бирок на кабелях в коробе под шкафом (вроде проглядывается белый) - да, не надо.

[Den]

Цитата

Сообщение от djaval

Эпопея продолжается.

Сегодня перепроливал свою программу, и после заливки контроллер вошёл в ступор. Посмотрите видео. Во-первых, контроллер не реагирует на кнопки перехода в меню и листания экранов. Во-вторых, при входе в системное меню, начинается полная чехарда. При этом, на сами нажатия кнопок прибор реагирует - обратите внимание, нижний светодиод 2Gi у меня заведён на любое нажатие любой кнопки. Показания датчиков, которые видны, обновляются. Но получается, что программа выполняется как-то не полностью, т.к. не работают переходы по экранам. При этом, я был подключен в режиме отладки и видел, что все EEPROM уставки выдают нули, поэтому там куча алармов.
Этот контроллер был прошит ядром 3.26. А на моём экземпляре тоже была такая фигня, когда он был 3.26. Меня наводит на мысль, что косяк именно в этом.
Я, с вашего позволения, его пролил в 3.25, будем смотреть.
Руслан, попробуйте мой контроллер пролить в 3.26. Я вам его отдал с 3.25 ядром.
Дело в том, что я уверен почти на 100%, что помех на этом объекте нет. А в то, что к зависанию может приводить моя пользовательская FBD-программа - я в это не верю (а возможно ли в принципе так составить FBD-схему, что контроллеру станет плохо?...).

Видео http://sharem.rusfolder.net/files/44074518

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

[djaval]

Отправил.

[Arsie]

Цитата

Сообщение от djaval

:rofl
Ну а если серьёзно, пока ничего?

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

Т.е. всё работает штатно.

[Ruslangsm]

Цитата

Сообщение от djaval

Отправил.

логи получили, но есть вопросы:

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

2. когда проблема с показаниями была, авария системная была или нет, и что выбирали если была?
-"пусто"
-"нет связи с MC"- подтверждено
-"нет связи с MC"- запретить до перезагрузки FBD

[djaval]

Цитата:

Сообщение от Ruslangsm

логи получили, но есть вопросы:

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

2. когда проблема с показаниями была, авария системная была или нет, и что выбирали если была?
-"пусто"
-"нет связи с MC"- подтверждено
-"нет связи с MC"- запретить до перезагрузки FBD

1. Проблема за последнее время была:
7.08 в 23:00
12.08 в 17:30
12.08 в 19:40
15.08 в 4:00
Каждый раз в это время в логах появляется огромное количество записей:

Aug 15 04:08:09 alarmd: rcvd alarm: r МC Нет связи с МС

При этом, системного аларма не возникает. В СМарт-журнал тоже на эту тему ничего не пишется, хотя у меня предусмотрена запись аларма по сигналу блока MC(Link). На скриншоте видно, что если бы был аларм MC, то сделалась бы запись в SMart-журнал. Там правда задержка 5 секунд, но судя по логам авария MC в некоторых случаях была явно дольше, чем 5 секунд.
Ну и каждый раз железно помогала перезагрузка по питанию, после перезагрузки система оживала.

И что значит вот это?

Aug  8 02:44:11 kernel: [   71.724908] hrtimer: interrupt too slow, forcing clock min delta to 35550 ns
Aug 12 00:57:04 alarmd: rcvd alarm: r МC Нет связи с МС
Aug 12 00:57:04 alarmd: rcvd alarm: r МC Нет связи с МС

Jul 31 17:15:39 mbs: МС is found on 0 pos. id=   2 sn=4522
Jul 31 17:15:39 mbs: Addin brd req
Jul 31 17:15:39 mbs: MP6 0
Jul 31 17:15:39 alarmd: rcvd alarm: r МС Ошибка ID МС
Jul 31 17:15:39 mbs: MP6 0
Jul 31 17:15:39 mbs: MP7 0
Jul 31 17:15:39 mbs: MP7 0
Jul 31 17:15:39 mbs: MP7 0
Jul 31 17:15:39 mbs: МР1 not responding... skipping
Jul 31 17:15:39 alarmd: rcvd alarm: s МР1 Нет связи с МР
Jul 31 17:15:39 alarmd: alarm parse: 0 0
Jul 31 17:15:39 alarmd: alarm parse: 1 0
Jul 31 17:15:39 alarmd: alarm is: 2

Aug 15 07:58:21 kernel: [   31.767043] USB Mass Storage support registered.
Aug 15 07:58:24 alarmd: rcvd alarm: r МC Нет связи с МС
Aug 15 07:58:26 kernel: [   35.449765] Driver 'sd' needs updating - please use bus_type methods
Aug 15 07:58:27 alarmd: rcvd alarm: r МC Нет связи с МС
Aug 15 07:58:28 kernel: [   37.569816] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver

2. Системную аварию живьём не видел ни разу. Если она была, но потом пропала, запись сохраняется в Системных авариях или нет?

3. Шлейф MC я в субботу вынул из короба из расправил. Но визуально он целый, загибов, заломов нет, в коробе он не пережимался, а пролегал свободно.

[Arsie]

Цитата

Сообщение от djaval

Каждый раз в это время в логах появляется огромное количество записей:

Aug 15 04:08:09 alarmd: rcvd alarm: r МC Нет связи с МС

Что-то очень похоже на шлейф.

[djaval]

Цитата:

Сообщение от Arsie

Что-то очень похоже на шлейф.

А что с ним может быть, со шлейфом?

[Arsie]

Цитата

Сообщение от djaval

А что с ним может быть, со шлейфом?

Множественные попытки восстановить соединение, иногда это удаётся.

Переломлен где-то, похоже.

[Ruslangsm]

Цитата

Сообщение от djaval

1. Шлейф MC я в субботу вынул из короба и расправил. .

если я правильно понял у вас сейчас шлейф вынут из короба и система запущена

зависания показаний наблюдались за эти 4 дня?

[djaval]

Цитата:

Сообщение от Arsie

Переломлен где-то, похоже.

Да я внимательно осмотрел его, никаких повреждений

[Arsie]

Цитата

Сообщение от djaval

Да я внимательно осмотрел его, никаких повреждений

Толку-то. Жила может переломиться и внутри оболочки.

Есть и другой вариант. Если у 2Gi или у МС кварц "уплыл" более, чем на 30% по частоте. Для кварцевых резонаторов это событие по вероятности где-то между авиакатастрофой и падением метеорита. А меньшее расхождение 2G/2Gi компенсируют подстройкой порта.

Также есть вариант, что что-то начинает "фонить" на частоте связи 2Gi с МС.

[djaval]

Добрый день.
Вчера в 13ч опять сбойнуло. Логи прилагаю.
На этот раз впервые удалось увидеть Аварию MC в журнале.

Теперь появилась перегрузка AOut, хотя аналоговые выходы в проекте вообще не использованы.

Aug 19 16:35:25 alarmd: rcvd alarm: s МC Нет связи с МС
Aug 19 16:35:25 alarmd: alarm parse: 1 0
Aug 19 16:35:25 alarmd: alarm is: 2
Aug 19 16:35:38 alarmd: rcvd alarm: r МC Нет связи с МС
Aug 19 16:35:38 alarmd: alarm parse: 0 0
Aug 19 16:35:38 alarmd: alarm is: 0
Aug 19 16:35:38 alarmd: rcvd alarm: r МC Перегрузка AOut

Также стала появляться ошибка MR, чего раньше вроде бы не было.

Aug 15 07:44:33 mbs: МР1 is found on 1 pos. id= 810 sn=337528
Aug 15 07:44:33 mbs: Addin brd req
Aug 15 07:44:33 alarmd: rcvd alarm: r МР1 Ошибка ID МР

Если посмотреть логи, Ошибка ID возникает каждый раз после поиска MC.
Неужели, оба шлейфа MC и MR неисправны? Что ещё может быть??
Чё-то замучился я уже с этими зависаниями бороться...
Конкретный экземпляр MC не причём, похоже? Т.к. сейчас-то там стоит подменный комплект.

[djaval]

Цитата:

Сообщение от Arsie

Также есть вариант, что что-то начинает "фонить" на частоте связи 2Gi с МС.

Объясните, что в жилом доме может фонить?! Двигатели работают постоянно, запитаны прямо от сети, без частотников. Специально посмотрел, кондиционеров по близости нет. На крыше есть здоровые дымососы, но они выключены всегда!
В котельной узел учёта в GPRS-модемом. Всё, больше там нечему фонить.
Может всё-таки перегрев как-то влияет?

[Arsie]

Цитата

Сообщение от djaval

Объясните, что в жилом доме может фонить?! Двигатели работают постоянно, запитаны прямо от сети, без частотников. Специально посмотрел, кондиционеров по близости нет. На крыше есть здоровые дымососы, но они выключены всегда!
В котельной узел учёта в GPRS-модемом. Всё, больше там нечему фонить.
Может всё-таки перегрев как-то влияет?

В жилом фонде? Да что угодно. Например, стоящая за стенкой старая микроволновка с неисправной от времени защитой, физически убивает телевизор за неделю-две разогревания еды в обед. Именно физически - выгорают полупроводники даже на выключенном телеке.

Старые холодильники, при старте компрессора которых перезапускаются компьютеры и принтеры.

Лампы дневного света с потерянной герметичностью (мигают которые) фонят почище иного частотника.

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

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

А по теме: ваш комплект у нас прекрасно работает. Т.е. если температура и влияет, то всё нормализуется при снижении температуры до нормы. Вам нужно как-то обеспечить охлаждение, чтобы проверить эту версию.

[Arsie]

Цитата

Сообщение от djaval

Также стала появляться ошибка MR, чего раньше вроде бы не было.

Aug 15 07:44:33 mbs: МР1 is found on 1 pos. id= 810 sn=337528
Aug 15 07:44:33 mbs: Addin brd req
Aug 15 07:44:33 alarmd: rcvd alarm: r МР1 Ошибка ID МР

Если посмотреть логи, Ошибка ID возникает каждый раз после поиска MC.
Неужели, оба шлейфа MC и MR неисправны? Что ещё может быть??
Чё-то замучился я уже с этими зависаниями бороться...
Конкретный экземпляр MC не причём, похоже? Т.к. сейчас-то там стоит подменный комплект.

Видно, что MR определяется верно: найден MR810, на фотке у вас MR810.

Если эта ошибка не попадает в системный журнал, то всё нормально. Какая-то недоработка в драйвере.

[Arsie]

Погоняли в печке, на 70 градусах через несколько часов при подаче питания наблюдается тупняк (тик растягивается до 170 мсек), к работе МС и МР замечаний нет.

Но 70 градусов... Побойтесь бога

[djaval]

Ну при 70 уже можно пироги запекать )) Пластик наверно плавиться начнёт...

22го MC отвалился почти на весь день. Но системной аварии не возникает, соответственно на пульт дежурного никакого сигнала не проходит, что очень и очень плохо. Почему так происходит?
Логи прилагаю.

[Arsie]

Цитата

Сообщение от djaval

Ну при 70 уже можно пироги запекать )) Пластик наверно плавиться начнёт...

22го MC отвалился почти на весь день. Но системной аварии не возникает, соответственно на пульт дежурного никакого сигнала не проходит, что очень и очень плохо. Почему так происходит?
Логи прилагаю.

Запись о разрыве связи в логе - это подтверждение факта, что запрос к МС потерялся, далее следует переустановление соединения и если несколько подряд следующих попыток связаться неудачны, то в лог записывается соотв. запись и включается системная авария.

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

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

[serg-el]

Так можно долго искать.

Вариант 1 - заменить шлейф на заведомо исправный.
Вариант 2 - один шевелит шлейф достаточно энергично, постепенно продвигаясь от одного конца к другому - второй смотрит на данные в контроллере.
Вариант 3 - заземлить и заэкранировать всё, что только возможно (экраны кабелей датчиков, заземлять только со стороны шкафа!).
Вариант 4 - проверить питание контроллера (осциллографом на предмет шумов, заменить блок питания).


Возможная неисправность данных шлейфов заключается в том, что разъём не припаян к проводу, а запрессован. При наличии влажности, сильно дёрнули, недобили при запрессовке - и всё - то есть контакт, то нет.

Ох, сколько намучились с этими шлейфами в эпоху Spectrum.

[Arsie]

Цитата:

Сообщение от Arsie

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

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

Это как версия. Температура воздуха у вас, по вашему же описанию, запредельная. Да и два комплекта ведут себя одинаково, а приехавший от вас комплект работает стабильно. "Чёт падазрительна" (с)

[Arsie]

Цитата

Сообщение от serg-el

Возможная неисправность данных шлейфов заключается в том, что разъём не припаян к проводу, а запрессован. При наличии влажности, сильно дёрнули, недобили при запрессовке - и всё - то есть контакт, то нет.

Ох, сколько намучились с этими шлейфами в эпоху Spectrum.

Мы шлейфы током проверяем, там недожатость сразу заметна

А вот дёрнуть, и особенно - дёрнуть сильно разогретый, это да.

[djaval]

Цитата:

Сообщение от Arsie

при активировании аналоговых выходов МС нагружает питание и тем самым, через ёмкостную связь "ловит" ложный сигнал перезапуска. Тем самым обрывая обмен с контроллером. И так по циклу.

Аналоговые выходы в моём случае не задействованы. А перегруз AOUT кстати как-то всё равно попадался в логах.

[djaval]

Цитата

Сообщение от serg-el

Вариант 3 - заземлить и заэкранировать всё, что только возможно (экраны кабелей датчиков, заземлять только со стороны шкафа!).

Экраны "заминусованы", а минус заземлён )) Мож в этом косяк?...

[djaval]

Цитата:

Сообщение от Arsie

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

В том то и проблема, что связь теряется, данные на AIN и DIN перестают обновляться, а аварии нет.

[serg-el]

Цитата

Сообщение от djaval

Экраны "заминусованы", а минус заземлён )) Мож в этом косяк?...

Схему в студию.
На первый взгляд неправильное решение - при утечке по экрану датчика путь тока будет > экран > модуль МС > питание модуля МС > питание контроллера > заземление.

Ещё раз повторяю - заземление экранов датчиков выполняется ТОЛЬКО в одной точке - на заземление в шкафу! Все остальные схемы чреваты блуждающими токами, и непредсказуемой работой оборудования!

[djaval]

Цитата

Сообщение от serg-el

Схему в студию.
На первый взгляд неправильное решение - при утечке по экрану датчика путь тока будет > экран > модуль МС > питание модуля МС > питание контроллера > заземление.

Ещё раз повторяю - заземление экранов датчиков выполняется ТОЛЬКО в одной точке - на заземление в шкафу! Все остальные схемы чреваты блуждающими токами, и непредсказуемой работой оборудования!

В схеме такие подробности, к сожалению, отсутствуют.
В пятницу переделал заземление. Минус отсоединил от земли, а экраны пересадил на землю. Посмотрим, поможет ли...

Со вторника в контроллер залит облегчённый вариант проекта, с реальным тиком 3. Хочу проверить, влияет ли проект на зависание.
Всю неделю жалоб не было, хотя судя по логам, которые я снял в пятницу, проблема всё равно есть. Но теперь изменился характер. Теперь валится МR (который в облегчённом проекте вообще не задействован.)
Вот например:

Aug 24 20:02:44 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 24 20:41:37 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 24 21:34:04 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 24 22:24:38 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 25 00:08:50 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 25 01:54:56 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 25 05:54:35 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 25 07:47:51 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 25 07:50:42 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 25 08:32:13 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 25 14:07:26 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 25 15:29:25 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 25 17:55:39 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 25 20:00:08 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 25 22:36:30 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 26 00:42:29 alarmd: rcvd alarm: r МC Нет связи с МС
Aug 26 00:42:29 mbs: tune0 4
Aug 26 00:42:29 mbs: MC  64
Aug 26 00:42:29 mbs: МС is found on 0 pos. id=   2 sn=4522
Aug 26 00:42:29 alarmd: rcvd alarm: r МС Ошибка ID МС
Aug 26 00:42:29 mbs: Addin brd req
Aug 26 01:22:04 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 26 03:24:01 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 26 07:56:14 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 26 08:22:36 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 26 09:31:25 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 26 10:08:06 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 26 10:43:59 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 26 11:28:49 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 26 11:39:55 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 26 18:22:09 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 26 18:53:56 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 26 19:27:36 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 26 20:42:48 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 26 21:28:23 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 26 21:54:47 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 27 00:18:06 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 27 00:38:42 alarmd: rcvd alarm: r МC Нет связи с МС
Aug 27 00:38:42 mbs: tune0 4
Aug 27 00:38:42 mbs: MC  64
Aug 27 00:38:42 mbs: МС is found on 0 pos. id=   2 sn=4522
Aug 27 00:38:42 mbs: Addin brd req
Aug 27 00:38:42 alarmd: rcvd alarm: r МС Ошибка ID МС
Aug 27 07:42:44 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 27 10:08:38 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 27 11:37:33 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 27 12:37:43 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 27 13:01:28 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 27 14:50:58 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 27 16:22:46 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 27 18:21:54 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 27 21:14:25 alarmd: rcvd alarm: r МC Нет связи с МС
Aug 27 21:14:26 mbs: tune0 4
Aug 27 21:14:26 mbs: MC  64
Aug 27 21:14:26 mbs: МС is found on 0 pos. id=   2 sn=4522
Aug 27 21:14:26 mbs: Addin brd req
Aug 27 21:14:26 alarmd: rcvd alarm: r МС Ошибка ID МС
Aug 27 21:42:24 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 28 01:18:55 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 28 02:06:20 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 28 03:07:41 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 28 03:08:58 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 28 04:42:33 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 28 06:33:05 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 28 08:50:01 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 28 11:12:45 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 28 11:58:05 alarmd: rcvd alarm: r МР1 Нет связи с МР
Aug 28 13:27:30 alarmd: rcvd alarm: r МC Нет связи с МС

[Arsie]

Цитата

Сообщение от djaval

Со вторника в контроллер залит облегчённый вариант проекта, с реальным тиком 3. Хочу проверить, влияет ли проект на зависание.
Всю неделю жалоб не было, хотя судя по логам, которые я снял в пятницу, проблема всё равно есть. Но теперь изменился характер. Теперь валится МR (который в облегчённом проекте вообще не задействован.)

Это не валится, это ошибки чтения периодические. Ситуация допустимая.

А вообще прослеживается некоторая закономерность. Оба внешних интерфейса у вас то ли ловят помехи, то ли ещё что с ними творится.

Оба интерфейса опторазвязаны, но по обоим модули получают питание. Модет быть действительно где-то токи блуждающие?..

[djaval]

Приветствую!
Пока работает без сбоев, почти третью неделю. Тьфу-тьфу-тьфу

Что было сделано:
а) Сделан и загружен в контроллер новый проект, в который перенесено часть кода из старого проекта, а часть изменено. (Самой муторной работой было перенести интерфейс SMArt...)
б) Переделано заземление, как писали выше.

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

Господа разработчики, а не может ли быть такого, что старый проект был каким-то образом запорчен в процессе его редактирования и не могло ли это влиять? Потому что ситуации вылетания SMLogix с ошибкой иногда были (особенно в SMArtе), и возможно после какой-то из них я не откатился на бэкап, а продолжил редактировать и сохранять.

P.S.
А что значит эта запись в логе?
Jan 1 00:00:23 kernel: [ 13.253878] Display copy took 289 mks
Jan 1 00:00:23 kernel: [ 13.503151] Display copy took 625 mks
А эта?
Sep 1 20:04:23 dis: SLEEPING!!!

[serg-el]

Цитата

Сообщение от djaval

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

Если есть осциллограф, можно посмотреть между землёй и откинутыми экранами датчиков и приводов. Будет понятно откуда наводки идут.
Если осциллографа нет, то можно и вольтметром переменного напряжения, но характер (источник) наводки определить сложнее.