Delphi и фискален принтер

В последната пълна документация (с описание на командите)
на FP550, която имам (версия 4.10) също няма Abs.

Това мнение е било редактирано от Dido на 11-08-2011, 15:55

Направих проект на github с COM компонент за native управление на фискални принтери и каси на Датекс, Елтрейд, Тремол и Дейзи. Тежко беше, мизериите безброй, но вече е готово за споделяне.

В проекта има скомпилиран DLL (който трябва да се регистрира с regsvr32), има merge module за инсталации, source-ът е на VB6, sample-а е на C#, документацията е оскъдна все още.

cheers,
</wqw>

Супер, евала и т.н.

П.П.
Опитах се да конвертна до С#, амЪ не става само с туловете. Много се различава VB6 от VB.NET.

Последното обновление на OPOS драйвера на Tremol има и драйвер POS for .Net. В България едва ли някой използва PosForNet, но и няма как при положение, че никой производител не е предлагал съответния драйвер.

Това мнение е било редактирано от SMITH на 22-08-2011, 15:15

@SMITH: Според мен OPOS драйвера на Tremol е under-tested, най-вероятно защото никой не го ползва. Освен това последно като гледах не беше open source като другите им изпълнения. Да направят един sample проект, който ползва OPOS-а, за да може да се тества от други devs на безбройните комбинации модели+firmware.

Генералният проблем с OPOS за фискални устройства е, че спецификацията е тясна. Например не съм сигурен че могат да се печатат фактури като от бензиностанция и пр. екстри. (Програмиране лого, оператори, поделения?)

Последно, да не работиш в Tremol? Като този "виновник" за OPOS-а?

cheers,
</wqw>

Обработка на грешките получени от принтера в 6-те байта на FP-550:

Този код го ползвам почти 10 години, но от време на време при
Z-отчет вдига 7-8 грешки наведнъж.
Не мога да разбера причината.
Вие как обработвате статус байтовете?

Това мнение е било редактирано от Dido на 31-10-2011, 12:54

Сигурен ли се, че не е timeout? Обикновено Z-отчета отнема много време, особено ако печатарката е келява.

Аз ако timeout-на, въобще не проверявам статуса, а връщам управлението на UI мълчаливо. Ако някой тръгне да печата нещо през това време ще стане мяу и най-вероятно ще му върне device busy или подобна.

cheers,
</wqw>

Да Z-отчета отнема доста време, но нали за това са
SYN (16h) байтовете уж, които трябва да връща принтера
при операции отнемащи повече време /според документацията/.

Аз чета отговора байт по байт с цикъл и всички байтове,
преди началото на пакетираното съобщение ги игнорирам,
а като ми прати 16h му давам нови 500ms timeout.
За това почнах да се съмнявам в обработката на статуса.

Или има и друг вариант, нещо да не му смятам вярно timeout /с GetTickCount/,
и да му пращам отново съобщение преди да е завършило първото и тогава
мисля имаше същото поведение.


Това мнение е било редактирано от Dido на 31-10-2011, 23:37

Прав си за SYN, би трябвало да не timeout-ва на read.

Ти проверяваш ли структурата на response-а? В смисъл започва с 1, завършва с 3, checksum, message length, etc. преди да третираш 6-те байта статус? Честно казано, не съм виждал подобно поведение (омазан статус), но наблюденията са ми предимно от 550-ки.

cheers,
</wqw>

BCC кода на отговора не го проверявам, мой пропуск.
Вземам от 01 до 05 вкл /без BCC чек сумата и 03/ и го приемам за чиста монета.

Случай от миналата седмица:
След като регистрирам всички продажби с команда 31h,
проверявам междинна сума с команда 33h и получената
междинна сума я подавам на изчисляване на сбор 35h.
Какво се е получило - върнах контролната лента и
при продажба от един ред на стойност 4.05 лв,
принтера ми е върнал междинна сума 20004.05 и
ресто 20000 лв.
Това се е случило до сега само един път за 10 години, като
на ден имам по около 250-300 продажби.
Може би е грешка на принтера, или ако бях проверил BCC кода
щях да го хвана.
И в случай на грешен BCC код, може би трябва да се прати
съобщение със същата рамка <SEQ> и да се чете отново,
принтера би трябвало само да върне отново отговор, без да прави нищо.

P.S. Това всичко е за FP550.

Това мнение е било редактирано от Dido на 01-11-2011, 11:42