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

Поддерживаться будет, или разработка прекращена?

Штрих ФР-К

Не могу сейчас сам посмотреть, потому спрошу, в драйвере функции режима НИ есть? Работа с ЭКЛЗ?

ККМ для игр больше нет, на фискальном я играться не буду.

Перепрошивку платы и ФП еще никто не отменял :)

В общем кому пригодится - используйте.

Спасибо, потыкаем :3

спасибо!

как вспомню штриховские фискальники, так блевать тянет - вечно с ними какие-то проблемы были, то ли дело феликсы - поставил и забыл до замены эклз. наверное только с мини-к проблем не было... эх, настальжи...

>А разработано было по заказу какой-либо организации, использующей данные регистраторы?

Используем. По должностным обязанностям я не программист. Заказ был? небыло.

>Поддерживаться будет, или разработка прекращена?

Аппарата не котором можно поиграться сейчас нет. Там все просто как ботинок. Если есть вопросы я отвечу. Если найдете баг попробую исправить. Дадите аппарат исправлю. Сам заинтересован в надежности и работоспособности, так-как у меня таки аппараты (только фискализированы все).

>Не могу сейчас сам посмотреть, потому спрошу, в драйвере функции режима НИ есть? Работа с ЭКЛЗ?

Реализованы только те функции, которые были нужны именно мне. ЭКЛЗ не реализованы. Но там все просто допишите на основе имеющегося. Там есть абстрактная команда и формирователь пакета. Меняйте формирователь и вуаля.

А я работал в «Штрих-М» с самого ее зарождения, когда там было всего шесть-семь человек — ее организаторов. Потом ушел, так как торгово-кассовая темя меня тяготила. :)

Разрабатывалось за неделю, «на коленке», с использованием COM-сниффера, поэтому код местами может выглядеть не очень красиво (главное, что работает).

Пардон, объясни, зачем использовался COM-сниффер, если протокол опубликован самим разработчиком?

http://support.shtrih-m.ru/data/shtrih-fr-k/prot_v1_03.pdf

http://support.shtrih-m.ru/data/shtrih-fr-k/prot_v1_04.pdf

>Пардон, объясни, зачем использовался COM-сниффер, если протокол опубликован самим разработчиком?

А вот не совпадали там детали кое какие. Сами команды соответствуют, но вот после каждой виндовый драйвер еще целую кучу вещей шлет. И каждый раз например модель выясняет.

И вот получалась ситуация когда легче в виндовом драйвере послать команду, отснифать а потом сравнить со своей.

2Zubok Мне вот интересно зачем именно так организовали протокол, неужели нельзя было сделать односторонний. В виде

компьютер подает запрос

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

Компьютер позает запрос на результат последней команды, если заняты, то отвечаем, что заняты. Если не заняты, то отдаем результат

Если надо Компьютер опять подает запрос на результат.

Тоесть режим передачи и приема данных как-бы симплексный. А то у меня ответы иногда терялись и вообще к концу эпопеи я просто забил на рассчеты и начал тупо ставить таймауты. Ибо на компьютере А одни таймауты были, на компьютере Б другие.

>А вот не совпадали там детали кое какие. Сами команды соответствуют, но вот после каждой виндовый драйвер еще целую кучу вещей шлет. И каждый раз например модель выясняет.

То есть в «Штрихе» все так и осталось, как было? 13 лет назад ничего тольком не документировали, а сейчас научились документировать, но имеют гнусную привычку вносить горячие правки и оставлять пользователя в неведении? Верю на слово, что так. Во всяком случае, так дела и обстояли, пока я там работал. К слову, я эту ситуацию мечтал исправить, но у меня просто времени не хватало, так как я железом занимался больше. :) Драйвера тоже писал для Элвесов, Штрихов и Memo Plus.

И вот получалась ситуация когда легче в виндовом драйвере послать команду, отснифать а потом сравнить со своей.

Я такой фигней там страдал, когад только фирма образовалась. Основа работы тогда — это болгарские аппараты Элвес и Штрих. Протокол был закрытым, документации болгары не давали. В итоге я весь протокол проснифил и написал драйвера. Реверс — это галимая вещь, на самом деле. Всегда бежишь в хвосте паровоза, и не сегодня, так завтра все опять поломают. Так и будешь всю жизнь выяснять, что поменяли. Лучше, конечно, в случае несовпадения с документацией писать производителю и требовать, чтобы отразили в документации все изменения. Очень настойчиво это делать.

>2Zubok Мне вот интересно зачем именно так организовали протокол, неужели нельзя было сделать односторонний. В виде

Я, к сожалению, не знаю, что сейчас там с протоколами. Все протоколы болгарских касс были знакоориентированные, похожие на подмножество протокола BSC (древнющий IBM-овский протокол), но сильно упрощенные и видоизменнные. А в весах тогда вообще такой протокол учудили, что мне в одной корейской компании, которая с нами тогда сотрудничество хотела заиметь, высказали, что они по этому поводу думают. Хорошо, что не я его проектировал. :) Я хотел все сделать по уму. Ведь были уже стандартные протоколы знакоориентирвоанные. Тот же BSC (у нас даже старый ГОСТ зеркальный имеется). Там все моменты уже были продуманы: отказ, последовательность SYN, подтверждение, повторы, процедура соединения, процедура разъединения и пр. Японские аппараты, которые мне попадались, использовали Z-Modem вообще. Вариантов много, на самом деле.

Лучше не думай про это. Сделали как сделали. Многие разработчики даже слов-то таких не знают. Делают, как наляпается. Если хочешь что-то изменить — рвись туда с предложениями через форум (минимум) или иди туда работать (максимум). :)

>Если хочешь что-то изменить — рвись туда с предложениями через форум (минимум) или иди туда работать (максимум)

Не, не хочу. Это было разовое мероприятие. В принципе Linux потерял как embedded решение именно потому, что ККМ имеют в поставке Win драйвера.

Я очень сильно удивился когда понял, что для термопринтера этикеток вообще требуется какой либо драйвер. Они похоже курили что-то ESC последовательности Epson удовлетворяли еще в 80-х годах, а термопринтер особенный. В 1С народ его вешает через какаю-то компоненту.

Те-же сканеры штрихкодов с отдельным интерфейсом, им чем разрыв клавиатуры не угодил? Я понимаю дополнительно конфигурить, но надо оставить и стандарт. Вот такая штука (http://www.thinkgeek.com/computing/keyboards-mice/8193/) у меня сейчас лежит, тоже чудо еще то. Надо демона писать. И потом эти люди удивляются, что их устройство не покупают.

>Я очень сильно удивился когда понял, что для термопринтера этикеток вообще требуется какой либо драйвер. Они похоже курили что-то ESC последовательности Epson удовлетворяли еще в 80-х годах, а термопринтер особенный. В 1С народ его вешает через какаю-то компоненту.

Сколь я помню про принтеры этикеток (а были у нас, кажется, Eltron'ы), то там были разные протоколы вплоть до тупой загрузки туда графики. Но я вплотную принтерами не занимался, если честно. У принтеров протокол был документирван произодителем. Проблем с написанием драйвера быть не должно. Вполне может быть, что даже кто-то уже и написал.

просьба отредактировать новость так, чтобы она была больше похожа на новость, а не на сообщение в личном блоге автора

Так?

пункты про:

Разрабатывалось за неделю, «на коленке», с использованием COM-сниффера, поэтому код местами может выглядеть не очень красиво (главное, что работает).

Особой сложностью было то, что ККМ как-то странно общается с компьютером: если запросить ответ раньше, чем команда была выполнена, то в качестве ответа придет ошибка о том, что идёт обработка команды, а вот ответ от команды больше вы не получите никогда. Поэтому в код добавлены тайм-ауты. ККМ для игр больше нет, на фискальном я играться не буду.

В общем, кому пригодится — используйте.

Убрал

>У принтеров протокол был документирван произодителем.

Вот только вопрос ЗАЧЕМ? ЗАЧЕМ было изобретать велосипед. Почему-б не сделать обычный Epson совместимый принтер с доп командами.

Ведь свой протокол это свои драйвера. Термопринтеры как GDI принтеры в виндовс не видны (те, что мне попадались). Тоесть бодренько садимся и для каждого пишем свои дрова.

>Ведь свой протокол это свои драйвера. Термопринтеры как GDI принтеры в виндовс не видны (те, что мне попадались). Тоесть бодренько садимся и для каждого пишем свои дрова.

Дело в скорости. Эти этикетки должны вылезать моментально. Протокол содержал всякие хитрые команды по рисованию линий, кружочков и т. д. Идеологически как Postscript, но только свои велосипеды (PS в такие принтеры никто в здравом уме пихать не быдет). Я точно помню, что печать через графику давала плохие результаты — очень долго принтер думал. А со своими командами моментально вылезал штрих-код, текст и линии. Принтеры даже сами штрих-код по коду могут рисовать. Причем там даже была хитрая вещь, по-моему (боюсь ошибиться, так как точно не помню). Можно было шаблон этикетки хранить в принетре, а по протоколу закидывать только значения полей.

Позитивно ! спасибо !

> Я точно помню, что печать через графику давала плохие результаты — очень долго принтер думал.

И это в эпоху USB 3.0 и гигагерцевых процессоров в тостерах...

А если серьёзнл - да, была когда-то такая проблема. USB нов и непонятен, а по RS232 несколько килобайт графики враз не прокачаешь. Вот и извращались, кто как мог.

Спасибо. У кого-нибудь есть опыт печати на ФР из 1С под стандартным вайном?

Примерно с этим-же сталкиваюсь при написании поддержки для Штрих-ФР в системе Openbravo POS, только на Java. Пока получилось организовать печать чеков не затрагивая фискальных функций, слишком рискованно отправлять запросы по таймауту без получения ответов. Если будет интересно про работу с другим оборудованием продаваемом Штрих-М посмотрите на сайте моего проекта http://code.google.com/p/openbravoposru/

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

Такие штуки очень легко и приятно писать на twisted.

Драйвера для ФР и их тестовая программа работают на стандартном Вайне 1.0 и 1.2 без проблем. Из 1С печатать не пробовал, но из другого софта все печатает.

На С было бы полезнее, думаю...

Отлично! Ждём драйверов для валидаторов и принтеров (или уже есть?) :)

На C оно (драйвера) есть. Но я как-то не хочу, да и не могу ставить VC под Win и компилировать это все, да еще и писать модуль для Python.

Перепиши, кто мешает?

>Ждём драйверов для валидаторов и принтеров (или уже есть?) :)

Ху из ис валидатор?

На самом деле это и не драйвер вовсе. Это библиотека для доступа к устройству. Как-то драйвер всетаки самостоятельная штукенция, с каким-то обобщенным АПИ.

Вот библиотека для наСильников https://sourceforge.net/projects/drvfr/

Опенсорц в действии

Яркий пример опенсорца в действии таким, каким он должен быть, а не кучи новых плееров с интересными обоями.[br] Добра тебе, мужчина на мотоцикле, побольше бы таких людей.

> Ху из ис валидатор?
Купюроприёмник.

>Купюроприёмник.

А надо? На самом деле у купюроприемника мозги должны быть в компьютере не хилые. Я боюсь насуют мне ксерокопий. :-) А на самом деле я сейчас общаюсь с людьми которые заняты банкоматами через которые деньги кладут на телефоны. У них все под Windows какраз по причине отсутствия дров к аппаратуре. Если нет одного оборудования, сразу ставят другое и все. А с Linux сразу вилы начинаются.

Если вы заняты в той-же области может пообщаемся. мой email в заголовке файликов есть.

> Но я как-то не хочу, да и не могу ставить VC под Win

Окей, я просто думал, что в Win и так всё работает, а это библиотека для обеспечения поддержки в Linux. Поэтому предположил, что низкоуровневая библиотека libstrokeecr.so на компилируемом языке была бы полезнее.

В купюроприёмнике есть прошивка, он сам отвечает за то, чтобы распознавать купюры. Всё что нужно сделать - реализовать управляющую логику (инициализация, получить информацию о купюре, считать показания датчика заполнения и т.п.).
Я был когда-то занят в этой области (платёжные терминалы и собственно биллинг), но сейчас уже 3 года как нет. Так, интересно просто, какая там ситуация.
Надо ли? Не знаю. Открытые драйверы помогут новым компаниям проще выходить на рынок платежных терминалов. Другое дело, что этих компаний там уже как грязи :) К тому же не понятно, что случится раньше - кибер с осмп всех заховают или терминалы будут не нужны, ибо у всех интернет и нетбанкинг.

> Перепиши, кто мешает?

Да никто, в общем-то, но нам пока не требуется - большинство кассовых регистраторов, с которыми мы работаем, от Datecs. :)

>Окей, я просто думал, что в Win и так всё работает, а это библиотека для обеспечения поддержки в Linux.

На самом деле я подумывал о том, чтоб сделать действительно 1 демон который умеет N команд, а уже к нему дрова (SANE эдакий).

Вот такая штука будет иметь смысл. В Win просто задействуем стандартные Win дрова.

Но кто это оплатит? А вот всем миром можно.

> А надо? На самом деле у купюроприемника мозги должны быть в компьютере не хилые. Я боюсь насуют мне ксерокопий. :-)

Разве? Если я не ошибаюсь, валидаторы всегда самостоятельно проверяли подлинность купюр, и отсылали код ответа какая купюра пришла (типа 10 рублей образца 98г. - код 1, 10 руб. образца 2004 г. - код 2, ну и т.д. Мне кажется, ещё разные коды могут быть смотря каким местом/стороной купюру засунешь.)

Вообще-то неглубоко знаком с этой кухней, но не припомню чтоб валидаторы что-то посылали на хост для распознания купюр (да и скорость посл. порта это не позволит).

Зато хорошо помню, что при добавлении новых денежных знаков в прошивку валидатора добавляли новую купюру, и их банально перепрошивали. Причём для этой операции привозили валидатор в офис.

Хотя было бы забавно самому писать распознавание.
Заявка: прошу выделить 5 тыс. руб. (одной купюрой) для обучения персептрона. Возврат не гарантируется :)

>Разве? Если я не ошибаюсь, валидаторы всегда самостоятельно проверяли подлинность купюр, и отсылали код ответа какая купюра пришла (типа 10 рублей образца 98г. - код 1, 10 руб. образца 2004 г. - код 2, ну и т.д. Мне кажется, ещё разные коды могут быть смотря каким местом/стороной купюру засунешь.)

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

Это прям уровень OCR какой-то

А как обходились с фискальным режимом? Для меня, в свое время, это было непреодолимым препятствием, поскольку ФР был зарегистрирован в НИ. Запишешь там какую-нить операцию, а потом попробуй отмыиться.

СПАСИБО!!!

на http://www.kkmcom.ru/forum/index.php?action=post;board=39.0 сообщил о Вашей работе. Думаю тестеры либы соро появятся...

103 ФЗ тому виной. Надеюсь это поможет внедрения Линукса в платежные терминалы. PS И до ЛОРа дошло эхо фискализации терминалов и услышал я снова знакомые до боли словечки :-(

Хорошая новость, теперь кассиры в сапёра и косынку играть не будут :)

блин, где раньше оно было.

Аналогично, http://kiosks.ru/yaf/Default.aspx?g=posts&m=309263

>а по RS232 несколько килобайт графики враз не прокачаешь
ну что ты врёшь

> а по RS232 несколько килобайт графики враз не прокачаешь.

Этого чертова JBIG черно-белого можно было качать много даже тогда.

Вот мой вариант драйвера: http://code.google.com/p/kkm/ написан в 2005, выложен под GPL в 2007.