Нави Тулаг – От датчика до интерфейса. Практическое руководство по созданию инженерных десктоп приложений на Python и web-технологиях (страница 2)
Нельзя отправить команду «Включить нагрев» обратно на устройство.
В Serial Monitor (Arduino IDE):
Только текст, нет графиков.
Нет сохранения данных в удобном формате (CSV/JSON).
Нельзя создать кнопки управления.
А в своём приложении — всё это возможно. И даже необходимо.
1.2. Причина №1: Доступ к оборудованию
Веб-приложения (в браузере) работают в «песочнице». Они не знают, где на диске лежит файл, не видят USB-устройства (без сложных API).
Инженерное десктоп-приложение:
Читает данные с COM-порта напрямую (через Python pyserial).
Работает с локальными базами данных (SQLite) без ограничений.
Управляет реле, моторами, источниками питания через интерфейс.
🛠️ Пример: Приложение для калибровки датчиков давления. Оно должно опросить 10 датчиков по очереди, сравнить показания с эталоном и записать коэффициенты в память устройства. В браузере это невозможно. В приложении на Python Eel — легко.
1.3. Причина №2: Визуализация в реальном времени
Инженер мыслит графиками. Таблица из 1000 чисел ничего не скажет о тренде.
Современные веб-технологии (Chart.js, Plotly) позволяют строить красивые, интерактивные графики прямо внутри десктопного приложения.
Преимущества своего UI:
Мгновенная реакция: График обновляется по мере поступления данных.
Интерактивность: Можно выделить участок, приблизить, сохранить скриншот.
Аварийная сигнализация: Цвет меняется на красный, если значение превысило порог.
1.4. Причина №3: Автономная работа
Интернет — не всегда надёжен. Цех, подвал, полевые условия… Часто сеть отсутствует вообще.
Веб-сервис зависит от соединения. Десктопное приложение:
Работает полностью локально.
Хранит данные на устройстве.
Синхронизирует их с облаком только когда появляется сеть (если нужно).
📝 Пример: Система мониторинга вибрации двигателя на удалённой насосной станции. Приложение пишет данные в локальный файл 24/7. Раз в сутки, когда появляется связь, оно отправляет отчёт на сервер.
1.5. Причина №4: Производительность и автоматизация
Рутина съедает время. Если вы каждый день запускаете тест по одному и тому же сценарию — автоматизируйте это.
Своё приложение позволяет:
Записать сценарий теста (нагреть до 50°C, ждать 5 мин, снять показания).
Запускать его одной кнопкой.
Сразу получать готовый отчёт (PDF/Excel).
1.6. Когда своё приложение — избыточно?
Честность важна. Писать ПО нужно не всегда.
Используйте готовые инструменты, если:
Нужно просто один раз снять показания (подойдёт мультиметр + блокнот).
Задача одноразовая (не стоит тратить 2 дня на код).
Есть готовое промышленное ПО (например, LabVIEW), которое уже куплено и настроено.
Но если ваш продукт — это инструмент для ежедневной работы, — своё приложение часто даёт лучший UX и экономию времени в долгосрочной перспективе.
1.7. Что мы узнали?
✅ Готовые инструменты (Excel, Serial Monitor) часто ограничены для инженерных задач.
✅ Ключевые преимущества своего ПО: доступ к железу, визуализация, автономность, автоматизация.
✅ Современные фреймворки (Eel, Electron) позволяют использовать веб-технологии для создания удобного UI.
✅ Выбор между «написать самому» и «взять готовое» — это вопрос частоты использования и сложности задачи.
📋 Практическое задание
Подумайте о трёх инструментах или процессах, которыми вы пользуетесь в работе (например: сбор данных с осциллографа, ведение журнала испытаний, управление нагревателем).
Для каждого ответьте:
2.a. Есть ли у него автоматизация?
2.b. Какие функции занимают больше всего времени вручную?
2.c. Какие из четырёх причин (доступ, визуализация, автономность, автоматизация) могли бы улучшить этот процесс?
Представьте, что вы создаёте приложение для одного из этих процессов.
Напишите 2–3 предложения: какую главную проблему решит ваше приложение?
💡 Пример: «Я создаю панель для тестирования датчиков температуры. Сейчас я записываю показания вручную в журнал. Приложение позволит автоматически собирать данные с 4 датчиков одновременно, строить график и сохранять отчёт в CSV. Это сэкономит 30 минут на каждом тесте».
В следующей главе мы сравним традиционные подходы к созданию GUI (Tkinter, PyQt) с современными веб-обёртками, чтобы вы понимали все компромиссы и выбрали правильный инструмент.
Глава 2. Обзор архитектур: традиционные GUI (Tkinter, PyQt) vs WEB-обёртки
О чём эта глава?
Вы уже поняли, зачем инженеру своё приложение. Теперь возникает главный вопрос: «На чём писать?»
Если вы знаете Python, логичным кажется использовать стандартные библиотеки для интерфейсов. Но есть нюанс: инженеру нужны не просто кнопки, а графики, логи и удобная вёрстка.
В этой главе мы сравним два подхода:
✅ Традиционные GUI (Tkinter, PyQt) — классика Python-разработки.
✅ Веб-обёртки (Eel, Electron) — современный гибрид Python + HTML/CSS.
✅ Архитектурные компромиссы — что вы получаете и что теряете в каждом случае.
✅ Почему для инженерных задач веб-технологии часто выигрывают.
Вы поймёте, почему в этой книге мы делаем ставку на связку Python + Web, и когда всё-таки стоит выбрать старый добрый Tkinter.