Задержки при закрытии чека с маркировкой (2) : Маркировка

И у ОИСМ 1.5 секунды? Не знал. Думал что у РР только ограничение в 1.5 сек

Ага. И у Спарка-130 тоже.
С другими не работал, только Спарк, АТОЛ, Штрих...
Но, думаю - у всех так, это общий принцип.

Не уверен... Могу путать.
Я у себя такого не делал.
Как-то не было необходимости.

Опять же из практики по атолам.
Делаю запрос марки в ОИСМ. Далее нужно опрашивать драйвер с целью получения ответа. Смысл опрашивать мгновенно? Там же задержка какая-то на ответ нужна. Ну поставил 20 мс. А если ответ придëт на 21й мсекунде , то я ушëл на вторую интеррацию - имеем задержку 40 мс.
Опять же по опыту из общепита - когда gtin передаëшь вместо марки, то атол делает вид, что опрашивает оисм, а сам ничего не посылает. notsendtoserver=.t. Не помню точно. В таком случае визуально позиции в 2 раза быстрее добавляются в чек, но это в обоих случаях меньше 1 сек на каждую позицию

Олег, у Вас когда чек тормозит на нëм [м+] есть? Или только [м]?

Короче, если всë делается в конце, и [м+] в чеке есть везде, то быстрее в таком случае нельзя. Значит, ускорится только можно размазывая задержки между сканированиями в уже открытом чеке.
А вот если всë делается в конце и есть [м], то тут, если чек долго обрабатывается налицо нелады с ОИСМ. Можно ускорится прибивая вручную проверки ОИСМ

Хм... В АТОЛе не помню, делал давно...
А точнее, даже и не делал под ФФД-1.2, под АТОЛ делал маркировку под ФФД-1.05 еще, они так и работают... Пока не переходили, говорил, но, они там на грани закрытия...
А у остальных моих, у кого АТОЛы, программа student-а, УКМWIN работает, я точно не знаю, что там внутри...
Но, в Штрихе, как я понял, команда проверки сама отрабатывает и устанавливает свойства объекта, если отработала, таймаут там общий:
Рез = ФискальныйРегистратор.FNCheckItemBarcode2();
СзРезПроверки = СоздатьОбъект("СписокЗначений");
Если Рез = 0 Тогда
СзРезПроверки.ДобавитьЗначение(1, "ПровВыполнена");
СзРезПроверки.ДобавитьЗначение(ФискальныйРегистратор.CheckItemLocalResult, "РезЛокПров");
СзРезПроверки.ДобавитьЗначение(ФискальныйРегистратор.CheckItemLocalError, "ПричинаНеПроизвЛокПров");
СзРезПроверки.ДобавитьЗначение(ФискальныйРегистратор.MarkingType2, "РаспТипМарки");
СзРезПроверки.ДобавитьЗначение(ФискальныйРегистратор.KMServerErrorCode, "РасшОшОнлПров");
СзРезПроверки.ДобавитьЗначение(ФискальныйРегистратор.KMServerCheckingStatus, "РезОнЛайнПров");
Иначе
Если ОбработкаОшибок() = 0 Тогда
Иначе
КонецЕсли;
СзРезПроверки.ДобавитьЗначение(0, "ПровВыполнена");
КонецЕсли;

Может там и можно как-то установить отдельный таймаут на проверку, надо почитать... Мне как-то ни к чему было... Порпробовал на стенде отключить сеть от Штриха, такое ощущение, что примерно те-же полторы-две секунды задумывается на проверке ОИСМ... Не критично, для моей задачи, это не продукты с очередями, это запчасти - из маркировки колесья только, да и те редко, в основном под заказ. Поэтому, эти таймауты мне пофик.

А когда уже чек набран, печатается мгновенно, не зависимо от наличия/отсутствия сети. Если уведомления не удалось сразу отправить, ФН их копит, и отправит в фоне, как только связь появится.

Ускорение, с обработкой в конце, как я его вижу:
Запрашиваем через РР коды. Я не помню - можно ли там сразу пачку одним запросом? По-моему можно. Ждëм ответ. Если ответ приходит, то открываем чек, добавляем все коды в ОИСМ, без реальной отправки на сервер, жертвуя [м+], регистрируем позиции, закрываем.
Если РР в начале даëт отлуп - разбираемся с маркой.
Если РР не даëт ответа за 1.5 сек - дальше зыбкая дорожка. Я бы в этом случае скоростью пожертвовал, и подождал бы [м+], хотя можно и забить

Совершенно точно можно.
Там POST запрос с телом в виде JSON. Туда можно много марок напихать, вродо до 1000, но, может и меньше, надо документацию поднимать, но точно не одну.