← На главную

Работа со сканером штрих-кода в терминальной сессии (RDP) часто сопровождается неприятным эффектом: при быстром последовательном сканировании нескольких товаров данные начинают поступать в 1С с нарастающей задержкой. Если первый код обрабатывается мгновенно, то пятый или десятый может «повиснуть» на несколько секунд. Рассмотрим причины этого явления и разберем по шагам, как настроить систему для максимально быстрого отклика.

Проблема очереди событий и технологии драйвера

Прежде всего, проанализируем ситуацию: почему в обычном терминале (например, Putty или HyperTerminal) на сервере данные «летают», а в 1С возникают задержки? Основная причина кроется в механизме обработки внешних событий. Стандартная компонента ScanOPOS.dll, особенно старых версий, работает по технологии COM. Когда данные передаются через проброшенный COM-порт в RDP, они дробятся на пакеты. Если 1С занята обработкой интерфейса или предыдущего кода, события встают в очередь Windows.

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

Решение 1: Настройка таймаута в драйвере 1С

Одной из главных причин задержки между вызовами события является параметр Таймаут. Драйвер ждет определенное время после получения последнего символа, чтобы убедиться, что передача штрих-кода завершена, и только потом генерирует внешнее событие в 1С.

Рассмотрим порядок действий для исправления:

1. Проверим версию установленного драйвера. В версиях типа 8.0.15.1 поле таймаута может быть заблокировано или отсутствовать.
2. Рекомендуем обновить компоненту до версии 9.x или 10.x (обычно поставляется с современными конфигурациями, такими как УТ 11.4 или Розница 2.3). В новых версиях, реализованных на технологии NativeApi, работа с потоком данных оптимизирована.
3. В настройках оборудования в 1С установим параметр Таймаут (или ТаймаутCOM) в значение 0 или минимально возможное (например, 5-10 мс). Это заставит драйвер мгновенно передавать данные в программу.

Решение 2: Использование альтернативного драйвера (АТОЛ)

Многие специалисты по автоматизации считают «золотым стандартом» для обычных форм драйверы компании АТОЛ старых версий (до того, как они стали платными). Разберем, почему это эффективно.

Драйверы АТОЛ DTO6 (версия 6.20.x) обладают очень гибкой настройкой чувствительности и суффиксов. Если стандартная компонента 1С «тормозит», попробуем следующий алгоритм:

1. Установим пакет драйверов торгового оборудования АТОЛ 6-й версии.
2. В настройках 1С выберем обработку обслуживания, поддерживающую АТОЛ (например, ATOLBarcodeScan_v2.epf).
3. В параметрах порта выставим корректную скорость (обычно 9600) и, самое главное, проверим Поиск оборудования. Если в окне поиска коды отображаются мгновенно, значит, проблема была именно в программной прослойке 1С.

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

Решение 3: Оптимизация настроек COM-порта и FIFO

Иногда задержка возникает еще на уровне операционной системы до того, как данные попали в 1С. Это связано с буферизацией данных в виртуальном COM-порте. Проанализируем настройки порта на локальном компьютере (где физически подключен сканер):

1. Зайдем в Диспетчер устройств -> Порты (COM и LPT).
2. Откроем свойства порта, на котором висит сканер.
3. Перейдем во вкладку Параметры порта -> Дополнительно.
4. Найдем настройки буферов FIFO. По умолчанию они установлены на максимум. Попробуем сдвинуть ползунки «Буфер приема» и «Буфер передачи» в крайнее левое положение (на 1).

Это заставит систему не ждать заполнения пакета, а отправлять каждый байт в RDP-канал немедленно. Также попробуем изменить номер порта. Если сканер сидит на COM1 или COM3, иногда возникают конфликты с системными ресурсами. Переназначение на COM7 или COM9 часто решает проблему «залипания» событий.

Решение 4: Настройка суффиксов (прерывание посылки)

Драйвер 1С должен точно знать, где заканчивается один штрих-код и начинается другой. Если суффикс не настроен, драйвер ждет окончания времени ожидания (таймаута). Посмотрим на пример правильной настройки:

Большинство сканеров по умолчанию выдают только цифры. Нам нужно запрограммировать сканер (с помощью инструкции из коробки), чтобы он добавлял символ CR (код 13) или LF (код 10) в конце каждого кода.

В самой 1С в настройках параметров сканера обязательно укажем:

Суффикс = 13 (или '#13')

Когда 1С видит этот символ, она моментально закрывает прием данных и инициирует процедуру ВнешнееСобытие, не дожидаясь лишних миллисекунд.

Решение 5: Системные настройки RDP и реестра

Если вышеописанные методы не помогли, причина может быть в низком приоритете трафика устройств ввода в протоколе RDP. Выполним следующие настройки на сервере:

1. Откроем редактор групповых политик (gpedit.msc).
2. Перейдем в раздел: Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Службы удаленных рабочих столов -> Среда удаленных сеансов.
3. Включим политику «Приоритет трафика для устройств ввода».
4. Дополнительно проверим работу антивируса на сервере. Попробуем добавить процесс 1cv8.exe в исключения, так как антивирусные экраны могут перехватывать и анализировать каждый пакет, приходящий через виртуальные порты, что создает микрозадержки, суммирующиеся при быстром сканировании.

Подводя итог, скажем: в 90% случаев проблема решается либо обнулением таймаута в настройках компоненты, либо переходом на NativeApi драйвер. Использование старого доброго АТОЛа остается «планом Б», который работает практически всегда, когда штатные средства 1С дают сбой в сложных терминальных средах.