LTSP/BarcodeScanners

Материал из ALT Linux Wiki
< LTSP
Версия от 19:06, 18 мая 2009; Prividen (обсуждение | вклад) (Создана новая страница размером ==Сканеры штрих-кода== В данной статье рассматривается случай, когда пользо...)
(разн.) ← Предыдущая версия | Текущая версия (разн.) | Следующая версия → (разн.)

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

В данной статье рассматривается случай, когда пользовательские программы (например, 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-серверу командой rdesktop -r comport:COM1=/dev/ttyS0. Данное заклинание подключило наше устройство /dev/ttyS0 к COM1-порту в данной сессии пользователя на Windows-сервере. Причем, у каждой такой сессии будет свой собственный COM1-порт. На стороне Windows увидеть этот перенаправленный порт можно командой change port, а тестово полюбоваться выводом со сканера - программой HyperTerminal. Всё, теперь остаётся настроить свою пользовательскую программу на использование COM1 и наслаждаться.

Однако, жизнь более скорбная штука и не всё в ней так просто и безоблачно. То, что ваш сканер будет работать в HyperTerminal'е, вовсе не означает, что он будет работать и в вашей программе, которая может быть старая, глюкавая, странная и капризная. Существует, например, труднорешаемая ошибка, возникающая при сочетании особенности работы программы с COM-портом и особенности реализации RDP-проброса устройств в rdesktop, когда программа получает вывод от сканера только после того, как что-нибудь напечатать на клавиатуре или пошевелить мышкой. (http://sourceforge.net/tracker/?func=detail&aid=1518140&group_id=24366&atid=381349, http://community.livejournal.com/ru_root/1594475.html), которая, вдобавок, может проявляться не под администратором, а под простым пользователем. В таком случае может помочь проброс ком-порта вне протокола 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'е; мне для нормальной работы понадобилась конструкция вроде hid-barcode-scanner 05e0:1200 |while read BARCODE; do echo -e "$BARCODE\r"; done |netcat -u myserver 11111

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