Сегодня утром отвалился дисплей - горит белым, ни какой инфы на дисплее нет. Курс на потребители идет как обычно, т.е. проблема только с дисплеем.
В 8 утра всё было ок, за исключением блеклых полос, которые были и ранее.
В 8.40 уже был белый.
Хотел через WEB морду глянуть, но не смог найти куда подключен ГК, жду когда скинут Installation и/или Service manual..
Сетевой кабель подключен в LAN1 и уходит в неизвестном направлении.
Покопал сервис мануал, там ничего нет по вопросу.
По стандартной схеме можно сделать полное отключение от сети, дождаться полной остановки и разрядки всех конденсаторов, но это не на промысле, да и что то мне подсказывает, что этот тот случай - не трож *овно, пусть себе работает, т.к. с выходными данными проблем нет, а ГС уже не первой свежести.
ЗИПа необходимого также нет, проблема может быть не просто в сбое условного “чипа“, но и в ЦП и тд и тп, столь глубокие подробности в сервис мануале не расписаны.
В общем самый оптимальный вариант оставить как есть до МРТО.
Узнаю у Канари, но думаю, что вопрос с дисплеем останется до МРТО, если курс идёт, и проблема только в отображении - это не критично
По подключению локально - чего тебе мешает с ноута подключиться?
пробуй с ноута, сделай ноуту статику в подсети 192.168.0.0/24
и используй вот это
Заводские данные для входа в Service Mode:
Адрес: http://192.168.0.203:3000
Логин: ran
Пароль: ran
В сервис мануале немного другие данные
Кабель воткнут в сокет LAN1, индикация на сокете горит, но уже выяснил что это все фигня и нашел второй конец кабеля. Подключится никто не мешает на данный момент.
В итоге сервис мануал соврал и доступ был по http://192.168.40.203:3000
Прилагаю Incident Log
applicationLog.txt (9.9 KB)
Расшифровка:
Записи от 2026-05-13 15:33:37:
EL22: Power-On Counter (Status)
CL05: Voltage Cut-Off (Warning)
Анализ: В 15:33:37 прибор зафиксировал кратковременный провал по напряжению питания или полное переключение/микроперерыв в питании (ошибка снялась сама через ~8 секунд, в 15:33:45).
Причина: Просадка напряжения на судовой шине, срабатывание переключателя сетевых входов, либо проблемы с терминальной платой/блоком питания гирокомпаса.
Записи от 2026-06-09 и 2026-07-08:
SPEED DATA timeout
LATITUDE DATA timeout
Анализ: Гирокомпас ненадолго терял данные о скорости (от лага) и широте (от GPS/GPS-навигатора). Оба раза таймаут длился около 2–3 минут, после чего связь восстанавливалась (Falling error).
Причина: Кратковременный сбой судовой сети NMEA / CanBus, перезагрузка внешнего навигационного прибора (лаг/GPS) или плохой контакт в интерфейсных линиях.
Последствия: При отсутствии данных по скорости и широте гирокомпас временно снижает точность (не считывает автоматическую поправку на скоростную и широтно-скоростную девиацию).
Записи от 2026-07-06 и 2026-07-19:
CheckThreads: Thread timed out: AlarmManager::Worker...
Raising sum-error "Sensor Error" / Falling sum-error...
Анализ: Внутренний сторожевой таймер (Watchdog) приложения зафиксировал, что поток менеджер тревог (AlarmManager) заблокировался или затормозил более чем на секунду/11 секунд. Из-за этого прибор кратковременно выбросил общую ошибку Sensor Error и тут же ее сбросил (через 0.5 секунды).
Причина: Скорее всего, связано с высокой нагрузкой процессора процессом логирования или блокировкой доступа к фалам/Hardware (см. пункт 4).
Это самая частая группа ошибок в предоставленном логе, повторяющаяся раз в несколько дней/недель (2026-05-15, 05-24, 05-30, 06-18, 06-19, 06-21, 07-07, 07-26, 08-07).
Ошибка №1 (Sysfs / Display_Worker):
Exception caught in SimpleTimer Display_Worker
[boost::errinfo_errno_*] = 9, "Bad file descriptor"
Path: /home/applic/HW/leds/display_mode/trigger
Описание: Фоновый поток управления индикацией/экраном пытается записать значение в файловую систему Linux (sysfs), но файл либо закрыт, либо отсутствует, либо к нему нет доступа в этот момент.
Ошибка №2 (ADC Read / SystemMonitor):
[boost::errinfo_errno_*] = 16, "Device or resource busy"
Описание: Монитор системы пытался прочитать данные с АЦП (плата измерения аналоговых сигналов/напряжений), но драйвер вернул “ресурс занят”.
Анализ: Это известные минорные софтовые ошибки ПО (firmware) STD 22 NX (версия прошивки E00.06). Они не приводят к фатальному крашу всей системы, так как перехватываются блоком catch, но забивают Incident Log.
Работоспособность системы: В целом гирокомпас работает, критических системных отказов гиросферы или полного зависания OC (Kernel Panic) в данном отрезке лога нет.
Питание: Проверьте надежность подключений питания к гирокомпасу (особенно при переключениях ГРЩ/АВР), а также статус судовых АКБ 24V (если есть резервирование).
NMEA Сеть: Обратите внимание на стабильность работы лага и GPS. Если ошибки SPEED DATA timeout происходят регулярно — проверьте кабели и параметры порта NMEA.
ПО (ПО Raytheon/Anschütz): Ошибки Bad file descriptor и readRaw вызваны недоработками в версии прошивки E00.06. Если данные ошибки вызывают беспокойство у сервисного инженера или классификационного общества, рекомендуется обновить прошивку STD 22 NX до более свежей версии (где исправлены ошибки обращения к sysfs).
А в Error Log просто перечислены все ошибки подряд от 00 до 29 со счетчиком 
Вывод: Ждём-с МРТО =)))
