Как в 1С организовать прием данных от оборудования через TCP/UDP порт в реальном времени?

Интеграция 1С с промышленным и торговым оборудованием (весы, камеры машинного зрения, датчики) часто ставит перед разработчиком нестандартную задачу. Типичная ситуация: устройство принимает команды настройки через современный REST API, но результаты работы (например, текущий вес или распознанный код) транслирует непрерывным потоком данных (Broadcast или TCP-stream) на определенный сетевой порт. В этой статье мы подробно разберем, почему 1С не может «слушать» порт напрямую и какими способами можно решить эту задачу.

Анализ проблемы: почему 1С не веб-сервер

Прежде всего, проанализируем ситуацию с точки зрения архитектуры платформы. 1С:Предприятие не является сетевым сервером в классическом понимании. Она может выступать клиентом (отправлять HTTP-запросы) или публиковать свои HTTP-сервисы, но эти сервисы работают под управлением веб-сервера (IIS или Apache). Если оборудование просто открывает TCP-сокет и начинает «лить» туда байты данных, 1С не сможет их перехватить стандартными средствами встроенного языка.

Для решения задачи нам необходимо создать механизм, который будет постоянно активен («слушать» порт) и сможет инициировать передачу данных в 1С в момент их появления. Рассмотрим основные архитектурные варианты решения этой задачи.

Вариант 1: Использование промежуточного приложения (Шлюза)

Это один из самых надежных способов, который выбрал автор темы. Мы создаем небольшое приложение на языке, поддерживающем многопоточность (например, C#, Python или Go). Разберем по шагам, как работает эта схема:

1. Приложение-шлюз запускается как системная служба.
2. Оно открывает TCP/UDP порт и ожидает поступления данных от устройства.
3. При получении данных приложение может либо сохранить их в промежуточную БД/файл, либо само выступить в роли HTTP-сервера.
4. 1С обращается к этому шлюзу по мере необходимости или получает данные через механизм внешних событий.

Пример логики на стороне 1С для получения данных из такого шлюза через HTTPСоединение:

&НаКлиенте
Процедура ПолучитьДанныеОтШлюза()
    Соединение = Новый HTTPСоединение("127.0.0.1", 8880);
    Запрос = Новый HTTPЗапрос("/get_weight");
    Ответ = Соединение.Получить(Запрос);
    Если Ответ.КодСостояния = 200 Тогда
        ТекущийВес = Ответ.ПолучитьТелоКакСтроку();
        // Обработка полученного веса
    КонецЕсли;
КонецПроцедуры

Вариант 2: Использование Native API внешних компонент

Если мы хотим избежать написания отдельного приложения, рассмотрим вариант использования внешних компонент (ВК). Правильно написанная Native компонента может работать в отдельном потоке операционной системы, не блокируя основной интерфейс 1С.

Выясним причину, почему это удобно: когда в порт приходят данные, компонента генерирует «Внешнее событие». 1С перехватывает его в специальном обработчике. Это позволяет реализовать событийную модель работы.

Пример обработки события в модуле формы:

&НаКлиенте
Процедура ВнешнееСобытие(Источник, Событие, Данные)
    Если Источник = "TCP_Listener" И Событие = "DataReceived" Тогда
        // Данные содержат строку, пришедшую в порт
        ОбработатьПотокДанных(Данные);
    КонецЕсли;
КонецПроцедуры

Важный момент: при использовании UDP или широковещательных (Broadcast) запросов, компонента должна уметь фильтровать пакеты по IP-адресу отправителя, чтобы не собирать «мусор» из сети.

Вариант 3: Технология WebSockets через поле HTML-документа

Это «хитрый» способ, который позволяет обойти ограничения платформы без регистрации внешних компонент в системе. Разберем этот механизм:

1. На форму 1С добавляется реквизит с типом Строка, который отображается как Поле HTML документа.
2. В это поле загружается минимальный HTML-код с JavaScript-скриптом.
3. JavaScript внутри браузерного движка открывает WebSocket соединение с устройством (если оно его поддерживает) или со шлюзом.
4. При поступлении данных JS вызывает метод 1С через команду window.external.MessageFromJS() (для тонкого клиента).

Этот метод хорош тем, что работает в рамках стандартного интерфейса и не требует прав администратора для установки стороннего ПО.

Вариант 4: Использование Node-RED как универсального посредника

В промышленной автоматизации часто применяют инструмент Node-RED. Проанализируем ситуацию, когда нам нужно быстро объединить несколько разных устройств. Node-RED позволяет визуально настроить поток (flow):

TCP In Node -> Function (Parsing) -> HTTP Request (в сторону 1С)

В этом случае 1С публикует стандартный HTTP-сервис, а Node-RED, слушая порт весов или камеры, «пушит» данные в 1С сразу после их появления. Это избавляет 1С от необходимости постоянно опрашивать устройство (polling).

Вариант 5: Виртуальные COM-порты (VSP)

Многие старые драйверы 1С и БСП (Библиотека стандартных подсистем) отлично умеют работать с последовательными портами. Если устройство шлет данные по TCP, мы можем использовать специальное ПО (например, HW VSP), которое создает в системе виртуальный COM-порт, привязанный к IP-адресу и порту устройства.

Для 1С это будет выглядеть как обычное подключение торгового оборудования:

1. Устанавливаем драйвер виртуального порта.
2. В 1С настраиваем «Весы» или «Сканер» на работу с COM3 (например).
3. Используем стандартные методы ПодключитьОборудование().

Технические нюансы реализации Native API

При написании собственной компоненты (например, на C++ или Delphi) нужно учитывать следующие требования:

• Многопоточность: Слушатель порта должен запускаться в методе AsyncEvent компоненты, чтобы не «вешать» поток отрисовки 1С.
• Буферизация: Данные из порта могут приходить частями. Компонента должна накапливать байты до тех пор, пока не встретит символ окончания кадра (например, CR/LF), и только потом генерировать событие.
• Кодировки: Часто оборудование шлет данные в ASCII или UTF-8 без BOM. Обязательно проверяйте корректность преобразования в Unicode, который использует 1С.

Подведем итог: выбор метода зависит от критичности данных. Для весов в магазине достаточно периодического опроса (polling) через HTTP-шлюз. Для высокоскоростной камеры на конвейере, как в примере из темы, необходима событийная модель через Native API или прямая трансляция данных в HTTP-сервис 1С через промышленный брокер сообщений.