Сканеры штрих кодов linux

LTSP/BarcodeScanners

Содержание

Сканеры штрих-кода [ править ]

В данной статье рассматривается случай, когда пользовательские программы (например, 1C) работают на MS Terminal Server, к которому по протоколу RDP подключаются оснащённые сканерами штрих-кода рабочие станции под управлением Linux (например, тощие клиенты).

Варианты подключения сканера ШК [ править ]

В настоящее время для подключения к компьютеру могут использоваться следующие интерфейсы:

• клавиатурный разъём: сканер подключается в «разрыв» клавиатурного интерфейса DIN или PS/2. При этом с точки зрения софта он ничем от этой самой клавиатуры не отличается, а следовательно, не представляет для нас никакого интереса. Клавиатура — она и в африке клавиатура.
• Bluetooth. Не сильно распространен. Не имел возможности потестировать, но думаю, с таким вариантом можно обращаться, как с последовательным устройством.
• RS-232. Обычный ком-порт.
• USB.

на двух последних вариантах остановимся поподробнее.

Подключение по RS-232. [ править ]

• относительная простота и безвариантность подключения — весь вывод с устройства мы сразу видим на /dev/ttyS?, никаких драйверов не надо.
• про такой вариант подключения догадываются и поддерживают его многие пользовательские программы.

• Сканер, последовательный порт и программы, возможно, придётся понастраивать. Скорость, четность, стоп-биты.
• Сканер потребует отдельного питания.
• никакого plug-n-play’я.
• в новых компьютерах может уже никакого ком-порта не оказаться.

Как уже было сказано, при правильной настройке сканера и последовательного порта мы сразу получим содержимое наших скан-кодов на устройстве /dev/ttyS? . ttyS0, скорее всего, вряд ли у вас больше одного ком-порта в системе. Скажем же cat /dev/ttyS0 , и попищим вволю сканером. Ну, а как напищимся, подумаем, как передать эти циферки программе на Windows-сервере. Самый простой путь — использовать возможности протокола RDP по подключению локальных устройств клиента (man rdesktop).

Подключимся к Windows-серверу командой

Данное заклинание подключило наше устройство /dev/ttyS0 к COM1-порту в данной сессии пользователя на Windows-сервере. Причем, у каждой такой сессии будет свой собственный COM1-порт. На стороне Windows увидеть этот перенаправленный порт можно командой change port , а тестово полюбоваться выводом со сканера — программой HyperTerminal . Всё, теперь остаётся настроить свою пользовательскую программу на использование COM1 и наслаждаться.

Однако, жизнь более скорбная штука и не всё в ней так просто и безоблачно. То, что ваш сканер будет работать в HyperTerminal’е, вовсе не означает, что он будет работать и в вашей программе, которая может быть старая, глюкавая, странная и капризная. Существует, например, труднорешаемая ошибка, возникающая при сочетании особенности работы программы с COM-портом и особенности реализации RDP-проброса устройств в rdesktop, когда программа получает вывод от сканера только после того, как что-нибудь напечатать на клавиатуре или пошевелить мышкой. (см. раз, см. два), которая, вдобавок, может проявляться не под администратором, а под простым пользователем. В таком случае может помочь проброс ком-порта вне протокола RDP; на стороне линукса для этого можно использовать программу ser2net , которая ловит всё с последовательного порта и отдаёт это по TCP. А на стороне сервера присылаемое можно получать бесплатной утилитой Tibbo Virtual Serial Port, которая создаёт в системе новый виртуальный COM-порт. Однако, он уже не уникальный для одной сессии, и придётся как-то самим обеспечивать уникальность связки порт-клиент, кроме того, хуже ситуация с переносом сессии на другого клиента и безопасностью.

Подключение по USB. [ править ]

• сканер может питаться от компьютера;
• имеем некоторый plug-n-play — возможность обрабатывать события подключения/отключения сканера, если нам это надо
• никакой настройки сканера кроме типа эмулируемого устройства — воткнул и оно работает

• большая-большая проблема передать этот usb на сервер и пользовательской программе.

Подключение сканера по USB отличается большим количеством вариантов типов изображаемых сканером устройств. Тут и HID-устройство (USB-клавиатура, проще говоря), и эмуляция последовательного порта (если железка поддерживает), и многочисленные проприетарные устройства (типа IBM Hand-Held USB и USB OPOS Hand-Held), которые для нас неинтересны — под Виндусом всё это живёт со своими драйверами, а под Линукс их нет.

Проще всего было бы передать на сервер «сырое» USB, чтобы виндусячьи драйвера сами разбирались, что там к чему, но увы, протокол RDP такого не предусматривает. Эту функциональность могут предоставить сторонние утилиты, бесплатных из которых я пока не обнаружил. Например, Fabulatech USB for Remote Desktop. Для линукса компилится модуль ядра и патчится rdesktop, а для Виндуса ставится драйвер с программой-монитором. В тестах работает неплохо, каждая сессия получает свои собственные USB-устройства, но всё это бесполезно без толстого бюджета из-за сильной небесплатности программы. Ну что же, может быть, когда-нибудь напишут Windows-часть для распространяемой по GPL usbip.

Если сканер поддерживается любым из usbserial-модулей, (см., например), то с ним можно обращаться как при подключении по RS-232 (см. выше), сюда же можно отнести подключение сканера всякими экзотическими rs232 usb кабелями.

Остаётся HID Keyboard Emulation. С одной стороны, оно столь же простое и малоценное, как и подключение в разрыв клавиатуры, но с другой стороны, у нас имеется чрезвычайно интересная возможность «вычленить» ввод с этой «клавиатуры». Это позволяет реализовать программа hid-barcode-scanner из одноименного пакета. Она умеет отключать указанное HID-устройство от общей консоли и перенаправлять его на свой стандартный вывод. На сервер этот вывод можно отсылать банальным netcat ‘ом, а там ловить вышеупомянутым TibboVSP , настроенным в режиме сервера (рекомендую UDP). Потестируйте получившийся COM-порт в HyperTerminal ‘е; мне для нормальной работы понадобилась конструкция вроде

Было бы совершенно замечательно иметь доступ к разработчикам нашей пользовательской программы. Тогда можно было бы обойтись без прослойки в виде TibboVSP и виртуального ком-порта: программу можно было бы научить напрямую слушать UDP-порт, и всё полученное там трактовать, как ввод со сканера ШК. Вопросы безопасности при этом остаются нерассмотренными.

Так же за рамками статьи остались вопросы:

• проброска ввода со сканера ШК для программ в wine (в т.ч., и на терминальном сервере)

Источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

• Главная
• 1С:Предприятие 8. Поддержка торгового оборудования в Linux (Debian/Ubuntu)

1С:Предприятие 8. Поддержка торгового оборудования в Linux (Debian/Ubuntu)

Последние годы фирма 1С серьезно подошла к обеспечению кроссплатформенности своих продуктов. Появление «родного» клиента для Linux открыло новые возможности к применению этой ОС в рабочем процессе. Сегодня уже ничто не мешает развернуть на базе Linux рабочее место менеджера по продажам или расчетчика заработной платы, но вот с автоматизированными рабочими местами до сих пор все было не очень радужно. В тоже время есть все основания полагать, что в скором будущем ситуация изменится, подробнее в нашей статье.

Начнем с объективных предпосылок использовать Linux на автоматизированных рабочих местах (АРМ). Это не только снижение затрат на ПО, хотя в небольших внедрениях отказ от приобретения даже «домашних» редакций ОС Windows способно принести ощутимую экономию, но и снижение затрат на последующее сопровождение.

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

Что касается «сложности» администрирования и освоения Linux-систем персоналом, то любая система или прикладное ПО сложнее пасьянса требует от администратора определенных технических знаний. При этом для пользователей порог вхождения оказывается достаточно низким, так как они продолжают работать с привычным набором программ: 1С, браузер, офисный пакет, а принцип работы в большинстве графических оболочек ничем существенно не отличается от работы с проводником Windows.

Однако до сих пор оставалось одно большое препятствие на пути применения Linux в автоматизации розницы: рабочее место кассира (РМК) и аналогичные ему АРМ предусматривает применение довольно широкого спектра торгового оборудования, с поддержкой которого в Linux наблюдались большие проблемы. Еще пару лет назад на вопрос о возможности использовать Linux на РМК мы однозначно отвечали: Нет!

Сейчас ситуация начала изменяться в лучшую сторону. Вместо разношерстного набора обработок обслуживания фирма 1С предлагает унифицированный подход к работе с торговым оборудованием в рамках БПО (библиотека подключаемого оборудования) и стремится обеспечить кроссплатформенность этого решения. Чтобы оценить, как далеко зашли ее усилия и как реально обстоят сегодня дела на этом направлении мы решили на практике проверить работу последнего релиза 1С:Розница 2.2 (2.2.4) с торговым оборудованием в среде Ubuntu 16.04 LTS.

Согласно официальным источникам, линейка релизов 1С:Розница 2.2.4.х использует БПО версии 1.2.5.10, которая является наиболее современной на текущий момент, а Ubuntu 16.04 можно рассматривать как некий эталон пользовательских Linux-систем на ближайшие несколько лет в среде базирующихся на Debian дистрибутивов.

Чтобы не растекаться мыслью по дереву рассмотрим, поддержка какого именно оборудования критична для РМК, а какого не критична, но желательна. Исходя из практического опыта, мы составили небольшую схему:

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

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

Сканер штрихкода

Сканер штрихкода наиболее простой тип торгового оборудования, большинство современных моделей работают либо в режиме клавиатуры, либо через RS-232 (COM-порт) или его эмуляцию. Обмен односторонний и весьма простой. БПО в полной мере поддерживает работу сканеров штрихкода в Linux через драйвер 1С:Сканеры штрих-кода (NativeAPI).

Каких-либо проблем в работе подключенного в режиме клавиатуры сканера Datalogic мы не обнаружили.

Считыватели магнитных карт

Новые драйвера 1С (NativeAPI) обеспечивают полноценную работу считывателей как в среде Windows, так и Linux, в том числе с поддержкой режима клавиатуры, что актуально для многих моделей программируемых клавиатур. Прежде для работы данных устройств, даже в среде Windows, требовалось применения платных драйверов от АТОЛ.

Фискальные регистраторы

Фискальный регистратор или принтер ЕНВД можно смело назвать сердцем кассового узла, однако сегодня ни одна из моделей ФР в Linux не поддерживается.

Также вам не удастся установить эмулятор фискального регистратора от 1С, что делает невозможным развертывание полноценного РМК в среде Linux. В принципе это ограничение можно обойти, распечатывая чеки на чековом принтере, но этот способ подойдет только очень небольшим магазинам на спецрежиме, где владелец сам является продавцом и ему не нужен фискальный контроль. Однако и здесь могут возникнуть сложности, отсутствие фискального режима делает невозможным «снять кассу», т.е. достоверно установить какое количество денежных средств должно находиться в ней на текущий момент.

Дисплей покупателя

1С не перестает удивлять и радовать. Появление «родного» драйвера для этого вида оборудования, да еще с неплохой поддержкой моделей способно значительно облегчить жизнь автоматизаторам вне зависимости от платформы.

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

Эквайринговые терминалы

Эквайринг был и остается одним из самых проблемных участков, так как работать приходится не только с собственной учетной системой, но и с банковским ПО, а также с его поддержкой. Мы не раз сталкивались со случаями, когда сотрудники банка заявляли нам, что вот наше ПО, вот инструкция, мы уже третий раз по ней сделали, а почему не работает мы не знаем. Учитывая многочисленные проблемы на платформе Windows мы собственно и не ожидали увидеть ничего иного:

С остальными банковскими системами ситуация ничуть не лучше. Говорить о поддержке Linux, когда даже поддержка БПО для этого типа оборудования остается где-то в «прекрасном далеко» как минимум преждевременно. Для небольших магазинов решением этой проблемы могут быть эквайринговые терминалы без подключения к ПК, но для крупных торговых предприятий такое решение будет по меньшей мере неудобно.

Весы с печатью этикеток

Как и с фискальными регистраторами поддержки данного типа оборудования для платформы Linux нет.

Однако весы не являются непреодолимым препятствием для перевода РМК на Linux, в крупных предприятиях с весами работает товаровед, который может продолжать работать на Windows, а в удаленных магазинах, при наличии нормального канала связи это можно делать из основного офиса через VPN (потребуется сетевое подключение весов). Сложности могут возникнуть в небольших магазинах, но они редко покупают весы с печатью этикеток, так как этот вид оборудования достаточно дорог.

Прочее оборудование

В общем и целом, ситуация с поддержкой Linux в БПО такова, что пока это нужно одной фирме 1С, все новые версии ее драйверов (NativeAPI) без проблем работают на этой платформе. Сторонние производители не спешат реализовывать поддержку Linux для своих драйверов, хотя, как тот же АТОЛ, вполне могут использовать эту платформу для своих решений.

С другой стороны, весовая категория фирмы 1С и охват аудитории ее продуктами может служить хорошим стимулом для начала поддержки этого семейства ОС. Так, например, мы с удивлением обнаружили поддержку Linux в драйверах принтера этикеток Godex от компании Сканкод. Правда пока поддерживается только подключение через LAN, но согласитесь, что это лучше, чем ничего.

Потом нашелся Сканкод: Драйвер для ТСД CipherLAB 8×00 (NativeApi), который также работает в среде Linux, что говорит о том, что ситуация медленно, но верно переламывается в сторону поддержки кроссплатформенности со стороны производителей оборудования.

Рабочее место кассира

Рассказывая про поддержку торгового оборудования в среде Linux мы не могли обойти стороной интерфейс РМК (рабочего места кассира). Здесь фирме 1С есть куда приложить свои усилия, шрифты на кнопках выглядят просто ужасно, в то время как к шрифтам в табличной части РМК и остальной программе никаких вопросов у нас не возникло. Кроме того, надписи на кнопках вверху и внизу РМК явно следует сделать побольше, ниже показано как это выглядит при разрешении экрана 1920×1080, которое сейчас можно встретить на мониторах с диагональю от 21″.

Выводы

Подведем небольшие итоги, для этого снова глянем на нашу схему:

Единственное серьезное препятствие — отсутствие поддержки в Linux фискальных регистраторов. Определенные сложности способен доставить эквайринг, но эти проблемы он и так регулярно доставляет вне зависимости от платформы, наконец никто не мешает использовать автономный эквайринговый терминал.

Основные устройства ввода не вызывают никаких вопросов, как и программируемые клавиатуры, о которых мы ничего не сказали выше. Единственный момент — для их программирования, как и для настройки большинства типов торгового оборудования все-таки потребуется Windows система.

Дисплей покупателя мы отметили значком повышенного внимания, так как несмотря на появление стандартного драйвера 1С к выбору данного оборудования следует подойти осмотрительно.

Весы — второй тип оборудования, который пока не позволяет однозначно рекомендовать Linux как платформу для РМК, опять-таки вся надежда здесь на производителей и решимость фирмы 1С требовать поддержки Linux в новых версиях совместимых с БПО драйверов. То, что это вполне осуществимо показывает пример фирмы Сканкод.

Да, Linux сегодня еще не готов занять свое место на автоматизированных рабочих местах, но текущие тенденции позволяют говорить о том, что это только вопрос времени. Уже сегодня реализована поддержка многих типов оборудования и видны определенные подвижки со стороны производителей. Все это разительно отличается от ситуации еще несколько лет назад, когда на вопрос поддержки торгового оборудования в Linux вообще не стоял на повестке дня.

Дополнительные материалы:

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Источник