Работаю над проектом, связанный с восстановлением/модернизацией старого, но надёжного принтера Samsung ML-1250(добавил Wi-Fi). Разбираюсь, как работает его сервисный интерфейс DCU, предназначенный для диагностики и самотестирования.
Что уже удалось:
Подключился к порту DCU (разъём, 4-pin) с помощью логического анализатора.
Выяснил, что принтер сам передаёт статусы через последовательный синхронный интерфейс:
DATA и CLK, 8-бит, MSB-first, тактирование по falling edge CLK.
Декодируется как Parallel Decoder в PulseView: word size 8, big endian, falling edge.
Получаем коды состояния (0x61, 0x72, 0x50, и т.д.) — всё читается корректно.
Что хочу сделать:
В инструкции сказано, что если при старте принтера нажать Down + Shift + Stop на панели DCU, то принтер войдёт в Self Diagnostic Mode (code 78).
Но эти кнопки находятся не на принтере, а на внешней DCU-панели, которая подключается к порту DCU принетера
Это значит, что панель DCU должна передавать команды по шине в самом начале старта — и принтер их должен распознать. Хочу это воссоздать с помощью Arduino или ESP32, но пока неизвестен формат команд, соответствующих этим "нажатиям кнопок".
Что ищу:
У кого есть оригинальная DCU-панель для ML-1250 (или совместимая) — нужен дамп шины.
Снять трассировку шины (DATA/CLK) логическим анализатором при:
Включении питания и входе в Self Diagnostic Mode.
Выборе и запуске команд например:
06 — включение соленоида.
08 — тест сенсоров подачи и выхода бумаги.
09 — тест датчика открытия крышки.
10 — тест фьюзера.
Прислать хотя бы примеры байтов, которые DCU передаёт при этих действиях — чтобы понять структуру и протокол команд.
Или, возможно, у кого-то уже есть готовая самодельная DCU на Arduino — буду признательны за схемы, код, документацию.
Любые догадки/трассировки/опыт по реализации подобных сервисных панелей (даже от других моделей Samsung) — тоже подойдут, возможно, используется общий принцип.
Если у кого-то есть возможность снять трассировку с реальной DCU — это сильно бы продвинуло проект. Или, может быть, кто-то уже разбирался с этим интерфейсом и знает, какие байты нужно слать принтеру в первые секунды старта?
Заранее спасибо!
Спойлер
На большинстве устройств оргтехники (принтеров, МФУ, копиров и т.д.) на плате управления (форматтере) предусмотрены внутренние сервисные интерфейсы.
Их задача — обеспечить отладку и диагностику на этапе производства и в сервисном обслуживании.
Через такие интерфейсы устройство может:
выдавать коды ошибок и статусов в режиме низкоуровневого доступа (минуя дисплей или панель),
принимать управляющие команды от сервисной панели (например, запуск самотестов, активация узлов),
входить в диагностические режимы (self-test, debug, режим калибровки и пр.).
Обычно эти интерфейсы:
построены на простых протоколах вроде UART, SPI, I²C или их вариациях;
физически реализованы как скрытые пины, тестпойнты или разъёмы на самой плате;
не документированы публично, что требует обратной инженерии.
Суть подхода — зафиксировать сигналы, понять структуру протокола и, при необходимости, эмулировать поведение оригинальной сервисной панели с помощью Arduino, ESP32 и т.п.
Такой способ работает не только для одной конкретной модели. Подобные сервисные интерфейсы (схожие по логике, хоть и разные по реализации) встречаются у:
HP, Canon, Ricoh, Kyocera, Samsung, Brother и других производителей;
и часто продолжают использоваться даже в устройствах, формально снятых с поддержки — особенно там, где USB не даёт всей информации о сбоях.
Таким образом, задача — не просто “оживить старое”, а создать гибкий способ взаимодействия с техникой, в которой нет другого доступа к внутренним процессам.
Их задача — обеспечить отладку и диагностику на этапе производства и в сервисном обслуживании.
Через такие интерфейсы устройство может:
выдавать коды ошибок и статусов в режиме низкоуровневого доступа (минуя дисплей или панель),
принимать управляющие команды от сервисной панели (например, запуск самотестов, активация узлов),
входить в диагностические режимы (self-test, debug, режим калибровки и пр.).
Обычно эти интерфейсы:
построены на простых протоколах вроде UART, SPI, I²C или их вариациях;
физически реализованы как скрытые пины, тестпойнты или разъёмы на самой плате;
не документированы публично, что требует обратной инженерии.
Суть подхода — зафиксировать сигналы, понять структуру протокола и, при необходимости, эмулировать поведение оригинальной сервисной панели с помощью Arduino, ESP32 и т.п.
Такой способ работает не только для одной конкретной модели. Подобные сервисные интерфейсы (схожие по логике, хоть и разные по реализации) встречаются у:
HP, Canon, Ricoh, Kyocera, Samsung, Brother и других производителей;
и часто продолжают использоваться даже в устройствах, формально снятых с поддержки — особенно там, где USB не даёт всей информации о сбоях.
Таким образом, задача — не просто “оживить старое”, а создать гибкий способ взаимодействия с техникой, в которой нет другого доступа к внутренним процессам.
