Я дописывал АРМ кассира, разработанный нами самими для наших супермаркетов, чтобы он поддерживал ШТРИХ-МИНИ-ФР-К.

При этом не использовал ваш драйвер, а писал на С обмен с com-портом в соответствии с инструкцией "Протокол работы ФР v.1.5".

При программировании столкнулся с тем, что в системе команд отсутствуют команды печати чеков и нефискальных документов целиком, то есть одной командой. В фискальных регистраторах других производителей такие команды есть, хотя и не всегда они удобны. Например, в ПРИМ-08ТК ограничение на 40 строк по 40 символов, для нас недостаточно. Преимущества -- печать чека идет залпом, без разгона/остановки ленты на каждой строке, а также, на мой взгляд, большая отказоустойчивость.

Я задал вам вопрос через вашего дилера, переслал протокол обмена.

Евгений Холкин рекомендовал настроить фискальный регистратор на печать чека по закрытию. Я это сделал. Действительно, в таком режиме он принимает команды, буферизирует их, а по закрытию чека залпом печатает.

Но ... одно из требований владельцев супермаркетов -- представительный вид чека. На практике это выливается в конкретные вещи:
1) отбивка информации (дополнительные строки с линиями)
2) полное описание товара до 100 символов с правильным переносом по строкам
3) печать кода товара, единицы измерения
4) печать особых слов благодарности покупателю
5) и еще пара-тройка требований
Проще говоря, между открытием чека, строк с оплатами и закрытием чека, мне нужно печатать текст.

Я его печатаю. Но в режиме печати по закрытию он не печатается! Печатаются открытие, закрытие, обрывки названий товаров, которые я отправляю командой продажи. А команды печати строки пропадают.

В итоге я вынужден был отказаться от печати чека по закрытию.

Что можете порекомендовать?

Поле 20 "Сохранять строки в буфере чека" таблицы 1 "Тип и режим кассы" установлено в 1?

В Таблице 1 поле 20 установлено в 0.

Я правильно понял: если установить 20 в 1 и 21 в 1, команды "печать строки" будут выполняться?

===

Прочитал внимательно присланное руководство. Вопросы отпали.
Спасибо.

Должно быть именно так.

Отработал два дня -- все работает отлично.

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

И еще вопрос - что происходит у вас при переполнении буфера? Я надеюсь, ничего не пропадет? А то как-то не хотелось бы следить за этим на уровне ПО ПК.

Выслал Вам последнюю прошивку процессора системной платы. В ней улучшен алгоритм печати. Перепрошить процессор может ЦТО.

А вот если буфер переполниться остальные строки просто не будут напечатаны, т. к. не попадут в буфер.

Тогда мне хотелось бы получить описание, как определить заполнение буфера.

Разверну вопрос, видимо так на него трудно ответить.

1) Какой лимит объема буфера? Лимит измеряется:
а) в байтах
б) в печатаемых строчках
в) в командах

2) Каковы правила запоминания?
2.1) если в байтах -- как зависит занимаемый объем от команд "открытие чека", "печать строки", "продажа", "закрытие чека"?
2.2) если в строчках -- считаются ли строчкой строки с количеством, ценой и суммой по команде "продажа", строки открытия чека, строки его закрытия
2.3) если в командах -- считаются ли в лимит сами команды открытия и закрытия чека

3) А не планируете ли вы сделать буфер так, как обычно делают кэш -- то есть при исчерпании печатать что есть в буфере, и продолжать с пустым? Или вы окончательно приняли решение возложить это на драйвер, чтобы он дробил длинные чеки или временно переводил для них ФР в режим печати по команде?

Я не просто так спрашиваю. У нас в одном магазине активно пошла торговля семенами, и недавно был установлен новый рекорд длины чека -- 250 строк. Когда возникнет ситуация, что чек слишком длинен и не может быть напечатан полностью, я не хочу давать ответ, что я этого не предусмотрел, или что вы мне не дали нужной информации. Я хочу, чтобы этой ситуации не было.[/b]

Буфер ограничен 300 любыми командами для формирования чека.

Спасибо.
==========
Следующий вопрос по тойже теме (или лучше новую начать?):
Я заметил, что чек заканчивает печататься позже, чем ПК получает ответ на команду закрытия чека. Это очень странно, но это так.

Без сомнения, это означает, что в результате я не могу быть уверенным, что полученный по команде закрытия чека ответ окончательный. Может кончится бумага, может произойти сбой принтера, да мало ли что еще. Уверен, что на практике так и происходит время от времени. У меня произошла пара сбоев, при которых у меня подозрение именно на такой случай. Чек не напечатан, в ЭКЛЗ его нет, в ФП тоже, в буфере есть, ответ на закрытие чека получен положительный, но чек открыт. Уверенности нет, а только подозрение, так как лог я не вел -- теперь включил.

Как мне построить алгоритм отработки таких ситуаций?
Мой вариант -- ПК ожидает (количесто команд)*const миллисекунд (сколько обычно надо на печать чека), потом запрашивает состояние ККМ, и если оно не стандартное (например, ожидание команды продолжения печати или открытый чек) -- аннулировать чек и послать его заново.

У вас не возникало идеи давать ответ на команду закрытия чека по факту закрытия чека?

Привожу выдержку из руководства программитса на драйвер.

"1. Существует различие в том, как драйвер реагирует на выполнение методов, связанных и не
связанных с операциями печати. В случае вызова какого-либо метода, связанного с выполнением
операций печати, выдача драйвером ответа OK говорит лишь о том, что в данных, выводимых на
печать, нет ошибок, но, однако, не означает, что во время печати не возникнет какой-нибудь
ошибки (например, обрыв бумаги). В свою очередь, при вызове остальных методов, ответ
драйвера OK символизирует успешное выполнение метода.
2. Имеется две стратегии поведения при выполнении команд печати.
Первая стратегия заключается в следующем. По началу печати ККМ переходит в подрежим 4
«Фаза печати операции» (например, при закрытии чека) и не принимает от хоста дальнейших
команд, связанных с печатью (например, команды новой регистрации продажи). Состояние ККМ
можно отслеживать, подавая через определённые интервалы времени команду «Запрос
состояния». Если очередной запрос состояния вернул подрежим ККМ 0 «Бумага есть», то можно
посылать следующую команду печати. Возможна ситуация, когда из подрежима 4 «Фаза печати
операции» ККМ переходит в подрежим 2 «Активное отсутствие бумаги» (закончилась бумага).
Тогда необходимо выдать об этом сообщение оператору ККМ с требованием заправить новый
рулон бумаги и продолжить запрашивать состояние ККМ до тех пор, пока она не окажется в
подрежиме 3 «После активного отсутствия бумаги» (в ККМ был заправлен новый рулон бумаги).
После этого следует подать команду «Продолжение печати», которая повторяет печать
прерванного чека, и опять продолжить запрашивать состояние, пока очередной запрос не вернёт
подрежим ККМ 0 «Бумага есть». Теперь ККМ готова принять очередную команду печати. Таким
образом, мы как бы дожидаемся окончания фазы печати, анализируя состояние ККМ командой
«Запрос состояния». У этой стратегии имеется недостаток, так как команда «Запрос состояния»
выполняется довольно медленно: вместо команды «Запрос состояния» можно пользоваться
командой «Короткий запрос состояния», которая выполняется гораздо быстрее.
Вторая стратегия подразумевает анализ состояния ККМ по ошибкам, возвращаемым ККМ. Сразу
после подачи операции печати (например, команды закрытия чека) подаётся следующая команда
печати (например, команда регистрации продажи). Если ККМ возвращает ошибку 50h «Идёт
печать предыдущей команды», то она находится в подрежиме 4 «Фаза печати операции».
Повторяем команду печати и анализируем ошибку до тех пор, пока её значение не станет равным
0 «Ошибок нет». Возможна ситуация, когда значение ошибки, возвращаемой на попытку
выполнить очередную команду печати во время выполнения предыдущей, равно 72h «Команда не
поддерживается в данном подрежиме», что означает, что ККМ находится в подрежиме 2
«Активное отсутствие бумаги». В этом случае необходимо выдать оператору ККМ сообщение, что
необходимо вставить новый рулон бумаги, и продолжать посылать команду печати и
анализировать возвращаемую ошибку. Значение ошибки станет равным 58h «Ожидание команды
продолжения печати», когда оператор заменит бумагу и ККМ перейдёт в подрежим 3 «После
активного отсутствия бумаги». После этого можно продолжить посылать команду печати,
анализировать ошибку, пока её значение не станет равным 0 «Ошибки нет»."

Спасибо за подробный ответ.

Реализовал алгоритм с опросом ФР после закрытия чека, чтобы выяснить, закрыл он его или нет. Спрашиваю командой 0х11.

Ошибки, возникавшие раз в день посыпались лавиной:
теперь я после закрытия чека через секунду запрашиваю состояние командой 0x11, получаю ошибку "не достаточное питание", после чего ФР впадает в состояние "ФР ФП отсутствует". На панели горит красный индикатор, выводится из этого состояния выключением и включением. Если ФР не опрашивать, то проблемы не возникает ... но тогда опятьже я не знаю, действительно закрылся чек по команде "закрытие чека" или нет!

Временно поставил время перед опросом ФР после закрытия чека 5000 мс. Но в этом случае не очень понятно, чем он лучше матричного. Кроме того, бывают чеки, которые печатаются дольше.

Что делать?

Необходимо прошить ФР прошивкой, которую я вам выслал на e-mail. И еще http://81.19.73.35/index.cfm?uid=CA9765 ... docid=1637