Проект «Драйвер ККМ Штрих-М для Linux (Debian, Ubuntu)»
Представляю драйвер для фискальных регистраторов от фирмы Штрих-М и совместимых с ними.
Драйвер написан «с нуля» на основе протокола 1.7 с использованием Qt.
Реализован основной набор функций, которых достаточно для решения вопросов автоматизации магазинов, POS-терминалов и аналогичных устройств.
Основная особенность проекта: разработка кросс-платформенного драйвера ККМ Штрих-М, который может работать в режиме сервера, производить обработку XML-команд и тем самым позволит отказаться от процедуры «проброса COM (Serial) портов». В итоге получился своеобразных XML-RPC-HTTP сервер.
Так же сервер поддерживает функции по работе через SHTTP (SSL), что позволяет организовывать безопасную работу с удаленными терминалами (например, с постаматами, терминалами оплаты и т.д., когда вся логика и учет исполняются на головном сервере).
Для целей теста высылаю тест-ключ (необходимы ИНН, заводской номер ККМ, контактные данные).
Надеюсь, моя разработка будет интересна и пригодится в Ваших проектах.
Сообществу предлагается ознакомиться с проектом, задавать вопросы, тестировать драйвер в своих системах.
есть спрос? Можно и под федору сборку сделать в перспективе (не работал с ней, увы). Могу бинарную сборку в тарболе выложить: если версии Qt будут соответствующие в системе — заработает.
спроса нет, но всё же если делаешь — надо делать под всё =) мы в RussianFedora репозитории можем добавить даже =)
Не то ли это устройство, которое подключается по LPT и позволяет печатать штрих-коды?
и тем самым позволит отказаться от процедуры «проброса COM (Serial) портов».
Проброс COM портов позволяет использовать существующее ПО.
В итоге получился своеобразных XML-RPC-HTTP сервер.
Теперь софт нужно переписывать.
Не то ли это устройство, которое подключается по LPT и позволяет печатать штрих-коды?
Вот под LPT Штрих-М’овских железок не видел за последние 10 лет.
Драйвер работает с фискальными регистраторами, кассовыми аппаратами и чековыми принтерами которые подключаются по Serial или USB.
Кстати, штрих-коды тоже можно печатать (в ближайшей сборке будет реализована данная функция).
В мире RPM-based систем стандарт — RHEL 5 (бесплатный вариант — CentOS 5). С него писался стандарт LSB, который поддерживают все популярные дистрибутивы Linux. Если бинарники скомпилированы в CentOS 5, то они потом заработают везде. Вот перечисленные в стандарте системные библиотеки, которые есть во всех дистрибутивах Linux: 1, 2. Среди них Qt 4.3. Старый компилятор гарантирует то что бинарник запустится в линуксе 2005 года и новее. Однако если Qt 4.3 слишком старый (обратная совместимость позволяет запускаться бинарнику и в последней версии Qt4, но не наоборот), то просто кладём новые библиотеки в архив с программой.
А как там в DEB-based не знаю. Однако судя по тому что Flash Player, Nero, R-Studio и Maya там тоже работают, LSB поддерживается и там.
Не то ли это устройство, которое подключается по LPT и позволяет печатать штрих-коды?
Приравнять фискальный регистратор к LPT принтеру это сильно .
> Вот под LPT Штрих-М’овских железок не видел за последние 10 лет.
Значит у меня не такой. Найду куда я его засунул — скажу точную модель.
штрих все так же вкладывает в коробку полную документацию на железо и протокол?
От части — да. Но есть случаи, когда выгоднее переписать: например, плохое качество связи с устройством. Или необходимость взаимодействия с устройством ккм в работе с web-приложением (на том же питоне и чем ещё), когда ккм и сервер — физически разные машины, да ещё и на разных ОС крутящихся.
В свое время обнаружил, что под линукс нет драйвера для штрихов, обладающего требуемым функционалом.
у штрихов DB25 разъем — «широкий COM» практикуется на аппарате. Может это сбило с толку?
Но тем не менее интересно, что же за устройство с LPT.
От части — да. Но есть случаи, когда выгоднее переписать: например, плохое качество связи с устройством.
Переписать чужой софт ? Сильно сильно.
Или необходимость взаимодействия с устройством ккм в работе с web-приложением
Используем небольшой jar апплет к примеру.
когда ккм и сервер — физически разные машины, да ещё и на разных ОС крутящихся.
В таким случаях куда выгоднее использовать что то на стороне браузера, ибо обеспечивать подключение с сервера на клиента то еще удовольствие.
В свое время обнаружил, что под линукс нет драйвера для штрихов, обладающего требуемым функционалом.
Какой функционал ? Открываешь СOM порт, шлешь аргументы и команду, ждешь ответ. Всё. Описание команд, аргументов, ответов и таблиц настройки в документации
Только интересная тенденция обнаружена — для работы с устройствами надо отловить массу неучтенных моментов в этом самом протоколе.
Например, таймауты ожидания байта в разным моделях могут отличаться от того, что написано в протоколе. Может меняться поведение ФР при аварийных ситуациях (к примеру, процедура переинициализации ФР при обрыве связи в процессе выполнения длительной по времени команды).
Так что протокол — описание «как в идеальных условиях должна себя вести железка».
Переписать чужой софт ? Сильно сильно.
И сильно. И толсто. С чужим не заставляю никого воевать. А если проект свой — то используется вполне.
В таким случаях куда выгоднее использовать что то на стороне браузера, ибо обеспечивать подключение с сервера на клиента то еще удовольствие.
Браузер в терминале оплаты порой (чаще всего) не используется.
Да, да, да. и байтики шлются, и ответы разворачиваются. Однако удобнее работать с XML чем с последовательностью байт.
С чужим не заставляю никого воевать. А если проект свой — то используется вполне.
Для своего проекта, не в последнюю очередь, нужна совместимость с уже установленным на точке софтом. А значит стабильная работа со «сплиттерами».
Браузер в терминале оплаты порой (чаще всего) не используется.
Ну во первых, имею прямо противоположный опыт. Вот рядом стоит киберплатовский терминал, работает через браузер.
Во вторых откуда тогда web-приложения взялось, если у вас браузера нет.
Однако удобнее работать с XML чем с последовательностью байт.
Удобнее, не спорю. Вот только перспективы йок. Ну написали на новом мега XML протоколе приложение, пришли в точку оплаты устанавливать свой мега-софт, а там уже работают три программы — и все через COM порт. И чего ?
Как разработка, вещь интересная, но применение крайне неудобное.
меня одного смущают слова «Драйвер написан «с нуля» с использованием Qt.»?? зачем драйверу Qt?
Сперва ты наезжаешь на разработчика со словами «Где пакеты для нашего тысячного дистрибутива линукса», затем ты его успокаиваешь «вот какие мы хорошие мы тебе поможем».
Qt наверняка использован как крассплатформенный фундамент
меня одного смущают слова «Драйвер написан «с нуля» с >использованием Qt.»
Предлагаю погуглить «драйвер ккм штрих-м» или хотя бы перейти на сайт ТСа и посмотреть скриншот
1. «драйвер» представляет из себя сервер HTTP 2. работает с SSL 3. работает с XML 4. кроссплатформ ———- использование Qt позволяет решить эти задачи логично и структурированно. Самодостаточно.
+ Qt используется в ряде других моих проектов. Поэтому для меня выбор более чем обоснован.
именно так. Тем более что есть ещё и GUI морда ко всему этому (но как составляющая часть одного АРМа).
В разделе «Как использовать» есть текст «Они коворят». Что они делают?
600 за штуку в год? Смишно да
Оно, хоть бы, без иксов умеет работать?
За указание ошибки в тексте — спасибо. Исправил. Должно быть «Они говорят. », конечно.
Что смешного? Прошу пояснить. Не увидел юмора.
Оно, хоть бы, без иксов умеет работать?
Конечно. Вот Х-ы вообще ни при чем. Требуется только QtCore + QtXML + QtNetwork. Они в зависимостях ничего Х-ового не нянут (в отличие от QtGUI, что и естесственно).
Какой функционал ? Открываешь СOM порт, шлешь аргументы и команду, ждешь ответ. Всё. Описание команд, аргументов, ответов и таблиц настройки в документации
Основная задача — максимально гарантированно распечатать чек. В случае, если ФР находится в нерабочем состоянии, то постараться привести его в рабочее (на основании флагов состояния) и таки заставить распечататься чек. Это основная задача драйвера — управление железкой не только на уровне команд, но и на уровне логики состояний.
Например: при печати произошел обрыв ленты, или произошел сбой по питанию. Необходимо проанализировать режим и подрежим, предпринять определенные меры по истранению неисправности (послать команду продолжения печати после обрыва ленты, закрыть чек, аннулировать чек и т.п. в зависимости от ситуации) и таки распечатать тот чек, что необходим.
В данном случае уже нельзя говорить о том, что «просто шлешь команду». ФР ещё должен быть готов соответствующую команду выполнять. А то получится ситуация, когда команду печати чека послали, ККМ её не выполнил, а мы и не знаем почему, да как.