В процессе работы с торговым оборудованием в среде 1С:Предприятие пользователи часто сталкиваются с проблемой существенных задержек при выводе чека на печать. Особенно критичной ситуация становится, когда программа «зависает» еще на этапе предварительного просмотра документа. Проанализируем типичную ситуацию: при печати из документа РеализацияТоваровУслуг (РтиУ) система замирает на 30–40 секунд, причем детальная отладка показывает, что «узким местом» является вызов метода ОбъектДрайвера.ПолучитьПараметрыККТАсинх. При этом обычные операции через тест драйвера (например, снятие X-отчета) проходят мгновенно.
Рассмотрим подробно причины возникновения такой проблемы и разберем по шагам методы её решения, основываясь на опыте эксплуатации ККТ семейства «Штрих-М» и «Ритейл».
Современные версии 1С:Бухгалтерия и других конфигураций на базе БПО (Библиотеки подключаемого оборудования) используют асинхронные вызовы для взаимодействия с драйвером ККТ. Метод ПолучитьПараметрыККТАсинх предназначен для того, чтобы программа могла запросить состояние кассы (наличие бумаги, статус смены, связь с ОФД) без блокировки основного интерфейса. Однако, если драйвер или интерфейс связи (USB-COM) работает некорректно, ожидание ответа превращается в «мертвое» зависание клиента 1С.
Выясним причину, почему это происходит именно в 1С, а не в тесте драйвера. Тест драйвера чаще всего использует прямые синхронные вызовы через COM-объект, в то время как 1С работает через дополнительную прослойку — Native API компонент. Посмотрим на основные способы исправления этой ситуации.
Большинство касс «Ритейл-01ФМ» подключаются к компьютеру через USB-кабель с использованием эмуляции COM-порта. Это самый распространенный, но и самый нестабильный способ связи. Проанализируем настройки виртуального порта.
Если задержки сохраняются, рассмотрим переход на протокол RNDIS. В этом режиме касса определяется как сетевая карта, и обмен данными идет по протоколу TCP/IP. Это радикально повышает стабильность и скорость работы асинхронных методов ПолучитьПараметрыККТАсинх, так как исключаются ошибки эмуляции последовательного порта.
Существует известная особенность взаимодействия компонентов 1С с драйверами торгового оборудования разной разрядности. Проанализируем ситуацию, когда установлена 64-битная платформа 1С, а драйвер ККТ используется 32-битный (или наоборот). Несмотря на наличие механизмов совместимости, вызов асинхронных методов может приводить к задержкам из-за маршалинга данных между процессами.
Попробуем привести систему к единому стандарту:
Часто причиной «фризов» становится чрезмерная активность самого драйвера по записи логов. Выясним, как это влияет на производительность. При каждом вызове ПолучитьПараметрыККТ драйвер записывает в текстовый файл подробную информацию о запросе и ответе. Если файл лога (обычно ShtrihMkkt.log или drvfr.log) разросся до нескольких гигабайт, операционной системе требуется время на позиционирование в конце файла для записи новой строки.
Выполним следующие действия:
%AppData% или из программной папки драйвера.Разберем ситуацию, когда Windows в целях экономии энергии «усыпляет» USB-порт. Когда 1С инициирует предварительную печать чека, системе требуется время, чтобы «разбудить» контроллер порта и инициализировать соединение с ККТ. Это может занимать от 2 до 10 секунд.
Чтобы исключить этот фактор, проделаем следующее:
Если внутренние процессы ККТ перегружены, ответ на запрос параметров будет задерживаться. Проанализируем состояние очереди документов в ОФД. Если в кассе накопилось много неотправленных чеков, её процессор будет приоритетно пытаться установить связь с сервером оператора данных, отодвигая на второй план запросы от 1С.
Также стоит проверить Таблицу №10 «Сетевые интерфейсы» в настройках ККТ. Ошибки в адресах DNS или некорректно настроенный шлюз могут заставлять прошивку кассы ждать таймаута при инициализации сетевого стека, что напрямую отражается на скорости работы функции ПолучитьПараметрыККТАсинх.
Для понимания того, где именно происходит затык, можно использовать замер производительности, но, как замечено в проблеме, асинхронные вызовы часто «проглатываются» стандартным замером. В таком случае мы можем добавить собственные отметки времени в коде (если конфигурация позволяет внесение изменений в модули БПО):
НачалоТаймера = ТекущаяУниверсальнаяДатаВМиллисекундах();
Результат = Ждать ОбъектДрайвера.ПолучитьПараметрыККТАсинх(ПараметрыПодключения);
КонецТаймера = ТекущаяУниверсальнаяДатаВМиллисекундах();
Задержка = (КонецТаймера - НачалоТаймера) / 1000;
Если Задержка > 1 Тогда
ЗаписьЖурналаРегистрации("ККТ.МедленнаяРабота",
УровеньЖурналаРегистрации.Предупреждение, , ,
"Метод ПолучитьПараметрыККТАсинх выполнялся " + Задержка + " сек.");
КонецЕсли;
Такой подход позволит точно подтвердить, что проблема лежит на стороне компоненты или драйвера, а не в алгоритмах построения самого чека в 1С.
Подводя итог, можно сказать, что зависание при предварительном просмотре чека чаще всего является следствием проблем транспортного уровня между 1С и «железом». Наиболее эффективным решением для моделей «Ритейл-01ФМ» является переход на подключение через RNDIS и отключение расширенного логирования в драйвере. Это минимизирует время отклика системы и делает работу кассира комфортной.