При подключении к Citrix по ЛВС (маппинг COM-порта) Штрих-ФР-Ф версии 3 работает без нареканий (тест драйвера 1.2.8.101 или 1.4.0.45), а при подключении к сети с помощью модема (другой COM-порт) оба теста драйвера ФР не видят, причём, сравнивая логи, можно понять, что обмен данными идёт, но конкретный запрос состояния в ФР так и не отправляется.
Как можно настроить параметры связи для работы в таком режиме?

В данной конфигурации Штрих-ФР-Ф нами не тестировался. Этот вопрос скорее надо задать производителям Citrix. Попробуйте обновить ПО Citrix.

... а может быть и производителям Windows ... т.к. подключение - средствами ОС. М.б. Винда при включении Dial-Up Networking меняет драйвера (всех!) COM-портов? Но тогда интересно то, что ИНОГДА при запуске теста драйвера сразу после подключения к серверу ответ от ФР проходит и нормально интерпретируется, но - только один раз. Однако, спасибо, за совет.

Начитался Вашей документации ... и вот что получается (на сервере Citrix на скорости 50kb/s):

при первом подключении всё проходит успешно:
26.04.2005 13:39:02.759 -> 05
ФР готов принять команду:
26.04.2005 13:39:02.900 <- 15
команда ПК:
26.04.2005 13:39:03.025 -> 02 05 11 1E 00 00 00 0A
ответ ФР:
26.04.2005 13:39:03.165 <- 06
26.04.2005 13:39:03.431 <- 02
26.04.2005 13:39:03.712 <- 30
26.04.2005 13:39:03.712 <- 11 00 1E 41 31 D3 11 16 03 02 02 4D 00 D1 03 04 00 00 31 31 1F 00 11 09 01 1A 04 05 0D 26 2F 05 EF A4 00 00 00 00 34 08 00 10 FF FF FF FF FF FF
26.04.2005 13:39:03.712 <- 78
и ответ в сторону ФР уходит:
26.04.2005 13:39:03.853 -> 06
но при начале следующей (любой) команды:
26.04.2005 13:39:23.259 -> 05
как будто ФР не воспринял последний ответ ПК и повторяет свой ответ заново:
26.04.2005 13:39:23.399 <- 06
26.04.2005 13:39:23.681 <- 02
26.04.2005 13:39:23.806 <- 30
26.04.2005 13:39:23.806 <- 11 00 1E 41 31 D3 11 16 03 02 02 4D 00 D1 03 04 00 00 31 31 1F 00 11 09 01 1A 04 05 0D 26 2F 05 EF A4 00 00 00 00 34 08 00 10 FF FF FF FF FF FF
26.04.2005 13:39:23.806 <- 78
а ПК ему снова подтверждение:
26.04.2005 13:39:23.946 -> 06
и снова попытка команды:
26.04.2005 13:39:24.071 -> 05
а ФР зациклился ...
26.04.2005 13:39:24.212 <- 06
26.04.2005 13:39:24.478 <- 02
26.04.2005 13:39:24.618 <- 30
26.04.2005 13:39:24.618 <- 11 00 1E 41 31 D3 11 16 03 02 02 4D 00 D1 03 04 00 00 31 31 1F 00 11 09 01 1A 04 05 0D 26 2F 05 EF A4 00 00 00 00 34 08 00 10 FF FF FF FF FF FF
26.04.2005 13:39:24.618 <- 78
как будто в этом месте при ожидании подтверждения (судя по диаграмме приложения 2) истекает тайм-аут ожидания подтверждения до получения подтверждения от ПК:
26.04.2005 13:39:24.743 -> 06
...
судя по документации "Тайм-аут ожидания подтверждения устанавливается в 2 раза большим тайм-аута приема байта", лог получен при тайм-ауте приема байта 5000 мс, что (и без двух раз) гораздо больше 13:39:24.743 - 13:39:24.618 = 125 мс

Сдвигает всё это с места любая команда с локально запущенного теста драйвера, у которого разницы во времени м/у ответом и подтверждением нет:
26.04.2005 13:49:24.925 <- 4B
26.04.2005 13:49:24.925 -> 06
после этого можно снова подключаться к серверу и получить в тесте драйвера нормальный ответ, но только один раз

Хотелось бы получить от разработчиков комментарий по этому поводу...

Добрый день.

Вы правы, истекает таймаут приема байта у фискального
регистратора при ожидании подтверждения на посланный ответ.
Нужно увеличить таймаут приема байта ФР.
Это можно сделать в тесте драйвера на закладке
"Параметры связи" при помощи кнопок "Получить параметры"
и "Установить параметры". Установите таймаут в 1 секунду.

но я устанавливал этот тайм-аут аж в 5 секунд, это даже больше, чем Вы рекомендуете

конечно, можно предположить, что символ ACK (0x6) теряется в драйверах транспорта (TCP/IP его точно использует, возможно и DUN что-то добавляет), но ... согласно семиуровневой модели систем связи всё, что выше транспорта - для пользователя д.б. прозрачно, в подтверждение этому:

26.04.2005 16:26:48.066 -> 05
26.04.2005 16:26:48.222 <- 15
26.04.2005 16:26:48.347 -> 02 06 15 1E 00 00 00 00 0D
26.04.2005 16:26:53.535 <- 06
26.04.2005 16:26:53.972 <- 02
26.04.2005 16:26:54.113 <- 04
26.04.2005 16:26:54.113 <- 15 00 01 A3
26.04.2005 16:26:54.113 <- B3
26.04.2005 16:26:54.253 -> 06

здесь тест драйвера честно показывает скорость 4800 и тайм-аут 2100, так что ACK (0x6) в сторону ФР проходит (иначе бы не было ответа с номером команды 15, ведь так ? ) и в сторону ПК проходит (иначе ПО не смогло бы этот ответ прочитать), но дальше имеем то же самое ...

26.04.2005 16:27:26.331 -> 05
26.04.2005 16:27:26.456 <- 06
26.04.2005 16:27:26.768 <- 02
26.04.2005 16:27:26.893 <- 04
26.04.2005 16:27:26.893 <- 15 00 01 A3
26.04.2005 16:27:26.893 <- B3
26.04.2005 16:27:27.034 -> 06

"Тайм-аут ожидания подтверждения устанавливается в 2 раза большим тайм-аута приема байта" - железно ? А то я попробую урезать езернет или usb-модем, чтобы исключить влияние другого com-порта ?

Интересная ситуация. Возникают вопросы:

1. Вы уверены что таймаут приема байта ФР = 5000 мс ?
Можете показать лог на команду запроса параметров связи ?

2. Не могли бы вы запустить программу Port Monitor
на компьютере к которому физически подключен ФР.
Может это прояснит ситуацию.

Взять программу Port Monitor ожно на сайте: www.sysinternals.com
Для получения лога нужно использовать параметры:

1. Edit\Max output Bytes = 1000
2. Options\Show Hex = 1
3. Options\Clock Time = 0

за кадром осталось общение с разработчиками по e-mail ... резюмирую:

работа с Штрих-ФР-Ф:
ПО ФР:
Версия: A.1
Сборка: 4563
Дата: 22.03.2002
ПО ФП:
Версия: 1.1
Сборка: 31
Дата: 17.09.2001
сравнение с эталонными версиями - успешно

есть 2 таймаута приема байта : один в драйвере, один в ФР, таймаут приема байта ФР в ПО (PortMonitor, например) не виден, но его можно прочитать и записать (в единственном месте) при помощи кнопок "Получить параметры" и "Установить параметры" на закладке "Параметры связи" теста драйвера, команды чтения и записи (15H и 14H) этого таймаута выполняются успешно, изменения отражаются в ОЗУ ФР

однако с таймаутом ожидания подтверждения (ACK=0x06), который "устанавливается в 2 раза большим тайм-аута приема байта" не всё гладко

было проведено 2 типа показательных экспериментов:

1 - вместо Штриха - программа на ноутбуке, зацепленном ч/з нуль-моодем к локальному ПК, показывала всё, что приходит от удалённого (запущенного на сервере Citrix) теста драйвера при скорости подключения к сети 50 кбит/с - байт подтверждения ACK реально приходит из локального com-порта, то есть - Citrix транслирует всё прозрачно, но естественно - с задержкой
значит - задержка более (таймаута) ожидания подтверждения ФР

2 - вместо теста драйвера - программа на локальном ПК, отправляющая в Штрих байты с задержкой показала, что подтверждение в ФР проходит при задержке ACK от ПК после последнего принятого байта от ФР примерно как абсолютное значение байта таймаута :
таймаут 2100 мс - 0xA3=163 - порог ~ 170 мс
максимальный таймаут 105000 мс - 0xFF=256 - порог ~ 250 мс
значит - порог (таймаута) ожидания подтверждения ФР не в 2 раза больше тайм-аута приема байта

Я не уверен во влиянии на тему именно таймаута ожидания подтверждения ФР, поэтому в резюме поставил это слово в скобки - (таймаут).

Я не даю гарантий на 100% валидность 2-го эксперимента, в ФР судя по документации могут срабатывать 4 разных таймаута (поэтому, вероятно, адекватной реакции ФР при задержках между байтами более 1 секунды при таймауте аж в 105 секунд я и не увидел), кроме этого результат - по двум значениям, а проверять все значения - долго и неохота ... однако порог ожидания подтверждения ФР при максимальном таймауте я считаю экспериментально проверенным

ИТОГО - работать с примапленным com-портом ч/з Citrix (да вероятно и ч/з другой терминальный сервис) на скоростях, которые не могут обеспечить трансляцию ответной реакции ПО в указанный выше тип Штрих-ФР-Ф менее чем за 250 мс - невозможно

в моём случае - 50 кб/с, то есть - практически любой dial-up
если вдруг начальство сподобится на выделенку - напишу про скорость, начиная с которой пошло ...

Добрый день.

Штрих-ФР-Ф версии 3 действительно имеет таймаут 0..255 мс.
В четвертой версии Штрих-ФР-Ф таймаут приема байта нелинейный .
Диапазон допустимых значений [0–255] распадается на три диапазона :
1. В диапазоне [0–150] каждая единица соответствует 1 мс , т . . данным
диапазоном задаются значения тайм - от 0 до 150 мс ;
2. В диапазоне [151–249] каждая единица соответствует 150 мс , т . .
данным диапазоном задаются значения тайм - от 300 мс до 15 сек ;
3. В диапазоне [250–255] каждая единица соответствует 15 сек , т . .
данным диапазоном задаются значения тайм - от 30 сек до 105 сек .
По умолчанию все порты настроены на параметры : скорость 4800 бод с
тайм - 100 мс .

Для того, чтобы Штрих-ФР-Ф работал - вам нужно перешить версию
3 на версию 4. Приношу извинения за запоздалый ответ.