Нужно собрать и опробовать существующие средства для проброса COM-портов: http://www.ttyredirector.com/doc/quick-start-guide.htm http://www.lysator.liu.se/~astrand/projects/sercd/
Нужно описать какие средства сделаны, протестированы и какие результаты.
обстановка дел на 9 июня 2007 года. 1. В качестве сервера используется serdird. Сервер работает, и проверка работы сервреа была проведена с использованием telnet + kermit-c. 2. В качетсве клиетна используется cyclades-serial-client. в настоящий момент последняя версия не работает (во всяком случае с существующими в настоящий момент настройками) (так же отсутвует сборка последней версии в других дистрибутивах) посему планируется либо собрать ту версию которая существует в других дистрибутивах и работает, либо же продолжить занятие дополнительной настройкой последней версии.
Имелся в виду sredird? Какая "последняя версия" тестировалась? Какие версии в "других дистрибутивах"? В чём именно проблема сейчас? Какое устройство в /dev используется для "приземления" порта? Какой модуль ядра используется для этого?
пробовал serdird и cyclades-serial-client из стандартного репозитария ubuntu все работает данные передаются и приземляются на виртуальный порт /dev/ptpy из тестовой программки на delphi все ok из scener_t глухо ;-((( Логи выслал на support@etersoft.ru. Если надо выложу инструкцию как настроить, там 2 минуты на все про все.
Надо проверить ещё раз, составить раздел в документации, если что, проконсулироваться, собрать нужные пакеты.
мы так и не смогли "завести" наш сканер ШК _локально_ пробовали и разные 1с, разный вайн, и даже в винде. Тест в 1с проходит, а данные не перехватываются. Тем не менее, тест по проброшенному устройству в 1с, в вайне проходит.
Да работают локально у меня и сканеры и фискальники и дисплеи!!! с wine@etersoft 1.0.8 дрова Штрих и Атол (scanopos не использую уже давно) p.s. проброс попробую еще раз делать, т.к. давно не пробовал...
В общем ситуация на данный момент такая: Нашел еще socat + patch из ихнего git который RFC2217 к нему добавляет с linux на win (tcpcom) все ok. с linux на linux wine (scannert) все равно данные не видит. при чтении доков от cyclades нашел, что вроде там не поддержывается WAIT DCD надо смотреть исходники... В выбрал пока его, так как прост в настройке и функционала много.
Сканнер локально работает, установил sredird (она с поддержкой RFC2217), в роли клиента kermit-c запустить и установить не смог, ждем сборки от Юры, попытался также запустить с помощью cyclades-serial-client - не смог подключиться.
Серверная часть работает нормально (почти любая sredird, ser2net, socat, etc.), клиентская TCPCOM под win32 тоже (все данные нормально воспринимаются драйверами и Ширих и Атол с виртуальным портом), под linux нормального клиента так и не нашел (Вроде как управление потоком не поддерживается)... т.ч. проблема в клиенте!!!
cyclades-serial-client должен по крайней мере соединятся. пробуй cyclades-serial-cli
(In reply to comment #11) > cyclades-serial-client > должен по крайней мере соединятся. пробуй > cyclades-ser-cli Пробовал, к тому же это тоже самое что и cyclades-serial-client, только предназначено для настройки. Есть предположение что собранный С-Kermit изменит положение.
http://updates.etersoft.ru/pub/Etersoft/LINUX@Etersoft/Etersoft/i586/RPMS.etersoft/ckermit-8.0.211-alt1.i586.rpm
Клиент работает, но не корректно вот такая строчка для подключения cyclades-ser-cli -c 1 -p 7200 /dev/ttytest0 testing 1 На сервере открыт порт 7201 (7200 + 1). Соединение происходит по сокету а не по телнету.
Я не понимаю что значит "по сокету, а не по клиенту", и не вижу вывода $ cat /dev/ttytest0 при отправке чего-либо со стороны сканера.
> $ cat /dev/ttytest0 > при отправке чего-либо со стороны сканера. Пытается вывести, т.е. процесс активен, но ничего не выводит при отправке со сканера чего-либо
Интересный факт: "проброс ком-порта. Сделать сделали, данные с клиентских сканеров на сервере видны... Но гадкая 1С этот виртуальный порт есть не захотела - в упор данных со сканера не видит, события не происходит по приходу данных. Дальнейшее копание выяснило, что 1С пытается с компортом работать на железном уровне... а проброшенный - он тока данные умеет давать, никаких других сингалов не передает." взято от сюда http://www.forum.mista.ru/topic.php?id=333991
Да, уже понятно, что надо передавать DCD и прочее. Правда это не объясняет, почему у тебя со сканера данные не принимаются.
Повторил все тоже самое что удалось сделать Боре в плане локальной работы сканера с 1с. След. целью понять принцип работы сканера на Windows, после чего можно спокойно вернуться к линуксу.
Офф, на Винде локально работает замечательно, принцип работы ясен. На Линуксе локально не запустился, происходило зависание 1с при попытке настроить сканер.
Надо разобраться почему локально под wine тест сканера проходит, а данные в процессе работы не передаются в поля (например, где заночится штрих-код). После этого надо пробовать проброс, этим займусь либо я либо кто другой.
Где этот сканер находится, куда подключен?
Сканер сейчас подключен на testing.
Угу, На федоре9 rebuild из всего, что под руку попалось до рабочего ckermit-8.0.211-4.2.1.i386.rpm , далее по http://lists.altlinux.org/pipermail/community/2002-February/045781.html добился (отправлено ser2net): [root@glav ~]# kermit -0 -8 -q -J 192.168.10.101 7200 2000005440014 дополнит.кома добавлены в grab.conf 8250.nr_uarts=6 дальше по HOWTO тупик - getty в fedore заменен на mingetty, дайте правильное направление - куда дальше рыть. В итоге хочется получить данные с удаленного сканера в тесте сканера в Wine (локально работает)!
Сканер локально работает (http://bugs.etersoft.ru/show_bug.cgi?id=2233)
Проброс на винду в связке sredir + tcpcom прошел удачно, для получения более точных данных пришлось увеличивать чувствительность сканера в настройках 1с, иначи код считывается по частям. Например, значение 9784532156544 воспринимается как 9 и 784532156544, т.е. одельными кодами, но повторное считывание исправляет эту ошибку. Пробросить в линукс не удалось, 1с при подключении сканера пишет что порт занят, телнетом данных тоже не получить.
А вот это кто-нибудь пробовал ? http://www.linux.org.ru/view-message.jsp?msgid=3021442&lastmod=1219059215688 там вроде remserial с штрихом запустили...
remserial в сизифе. Андрей, пробуй!
Использовал в качестве передатчика и приемника remserial. На передачу в сеть remserial -d -p 7201 -s "9600 raw" /dev/ttyS0 получение из сети remserial -d -r testing -p 7201 -l /dev/ttyS0 /dev/ptmx проверка через cat /dev/ttyS0 прошло успешно, потери данных нет. 1с не может подключить сканер. Зависает при попытке настройки торгового оборудования в пункте выбора Обработка обслуживания - Внутренняя.
проблема может быть в права на доступ к устройству. Если через рута выставлять 777, то через некоторое время права снова становятся 620, это может быть из того что файл создается заново
У меня было что-то подобное, remserial надо запускать не из под root'а и пользователь должен быть в соответствующей группе. Можно еще создавать устройство pts в $HOME тогда с правами все ok. Но wine сканер так и не видит.
(In reply to comment #31) > У меня было что-то подобное, remserial надо > запускать не из под root'а и пользователь > должен быть в соответствующей группе. > Можно еще создавать устройство pts в $HOME > тогда с правами все ok. Но wine сканер так и не > видит. > C одной стороны порт в сеть открывается только из под рута, с другой стороны принимать отказывается со стороны пользователя. Сейчас играю с настройками в /etc/udev
1) ошибка не зависит от пожеланий про wine --update 2) http://unixforum.org/index.php?showtopic=68299&view=findpost&p=710052 можно уже что-то внятное написать?
1c не воспринимает порт от пользователя. При попытке подключить сканер в 1с выдает ошибку (-3) EscapeCommFunction failure , тест соответственно тоже не проходит.
cat .../порт информация передается. программа scantest.exe ничего не отображает.
Был создан тест, который показал, что ремсиреал не передает TIOCMGET. Это очень странно, т.к. в Винде все работало, но отличие в том что с принимающей стороны стоял TCP-Com, а не remserial. TCP-Com под вайном не удалось запустить.
Патч, написанный А.Морозовым, не помог. 1с стала также зависать при попытке настройки драйверов сканера.
Тестовая программа через проброшенный порт читает: $ ww scantest.exe | grep -v '^[0R]' fixme:comm:set_queue_size insize 4096 outsize 4096 unimplemented stub 8 : "97859518" 7 : "01487 " 8 : "97859518" 7 : "01487 " 8 : "97859518" 7 : "01487 "
scantest.exe работает на atlant, но не работает на lin-test
На lin-test scantest.exe тоже работает, только с большой задержкой. Между считыванием штрих-кода и его выводом проходит около 7 - 8 секунд. При этом с помощью cat штрих-коды выводятся сразу же.
Для проброшенного порта IOCTLs TIOCMGET и TIOCMSET всегда завершаются с ошибкой (по-видимому, не поддерживаются). Проблему можно обойти, принудительно возвращая код возврата, соответствующий успешному выполнению.
можно еще глянуть внутрь remserial и сделать чтобы все поддерживалось (если это вообще возможно). благо там программа не очень большая...
Насколько я понимаю, для псевдотерминалов не поддерживаются TIOCMGET и TIOCMSET. Может, есть какая-нибудь другая программа, которая пробрасывает порт не с помощью псевдотерминала, а создаёт специальное устройство?
Shan знает все такие программы. Можно с ним проконсультироваться
Попытался воспроизвести с новым патчем работу сканера, не получилось. У А.Морозова все работало хорошо. Видимо мне стоит дождаться новой сборки wine, в том числе и с патчами предыдущими, для локальной работы сканера. 2Boris, все ок. Уже разобрались.
> > 2Boris, все ок. Уже разобрались. > разобрались с чем??? поделитесь! remserial кроме вывода сканированного через cat <порт> более ничего не получилось - что делаю не так? с правами все норм. Поиск в гугле насторожил - http://unixforum.org/index.php?showtopic=69066 Цитата: remserial и ему подобные типа netcat НЕ ПОДДЕРЖИВАЮТ FLOW CONTROL На сегодня выход - паять удлинители для комов с сервера не очень устраивает! А, похоже, придется!
Стас Вавилин, для корректной работы remserial наложены патчи в текущей сборке wine, но по каким-то причинам считывание сканера происходит через раз. 1с все время зависает при настройке оборудования.
О чего я еще вычитал: http://www.cendio.com/support/tag/serial-redirection.html 12.2.5. Limitations and additional information -//- Applications that uses the ioctl TIOCMGET are not supported yet. -//- короче никто не хочет клиента нормального писать типа tcpcom... p.s. А какие патчи наложены на wine для remserial? Для fixme: EscapeCommFunction ? Может remserial или socat (у меня на винду с его RFC патчами нормально данные шли) допиливать, виндовый клиент работает вроде ?
> Applications that uses the ioctl TIOCMGET are not supported yet. В случае с remserial так и есть. См. комментарий #41
Проверил локальную и удаленную работу сканера в текущей сборке, использовал remserial. Тест сканер проходит, а вот данные не заполняются в номенклатуре например.
данные не заполняются в номенклатуре например. это как? может префикс или суффикс забыл поставить ?
В номенклатуре все замечательно, все заполняется. Преффиксы 13 и 10, чувствительность 30. Здесь контрольная проверка оборудования на 1с7,7 и 1с8,1 http://bugs.etersoft.ru/show_bug.cgi?id=2498 Кстати, использование в качестве принимающей стороны - не очень хорошо, т.к. утилита TCP-Com платная, но дает для теста на срок. Стоимость полной версии не радует.
Ты чем принимаешь ? TCPCom или remserial ? Можно подробнее в следующий раз писать!!! Раз 10 прочитал, чета въехать не могу...
Михаил, прошу прощения за такое кривое описание. Торопился видимо. На машине, где подключен сканер к ком-порту, запускаю $ remserial -d -p 7201 -s "9600 raw" /dev/ttyS0 Чтобы пользователь имел доступ к информации с порта, добавил его в группу tty (или какую другую, которая распространяется на этот файл) По ssh подключаюсь к удаленной машине, где есть 1с. $ ssh testing2 -Y Выполняю там $ remserial -d -r testing -p 7201 -l /dev/ttyS0 Затем запускаю 1с (ТиЗ конфигурация) в wine (!, сборка current) и настраиваю по этому описанию с сайта Атола.
(In reply to comment #54) > Затем запускаю 1с (ТиЗ конфигурация) в wine (!, > сборка current) и настраиваю по этому описанию > с сайта Атола. Конфигурация ТиС, торговля и склад
> $ remserial -d -p 7201 -s "9600 raw" /dev/ttyS0 > $ remserial -d -r testing -p 7201 -l /dev/ttyS0 Делаю тож самое (и другое), даннные отправляются, принять не могу ни с кома, ни тем более в вайн. федора9, ремсериал и из тгз, и в бине, и сизифовский > > Затем запускаю 1с (ТиЗ конфигурация) в wine (!, > сборка current) и настраиваю по этому описанию > с сайта Атола. можно узнать - версия вайна?, версия драйвера?, версия ядра? с чем то у меня не так! - помогите определить - с чем?
ААА зачем ?: Выполняю там $ remserial -d -r testing -p 7201 -l /dev/ttyS0 ^^^^^^^^^^^ помоему надо приземлять на виртуальный порт? Ты данные приземляешь на физ.устройство... Сегодня проверю у себя... p.s. remserial патчили ? Если нет, то где взять бинарник? Какая версия wine?
Извините за некраткость. Уррраа!!!! Работает! И СканерШК и ККМ ШТРИХ-МИНИ-ФР-К. Пока в тестовом варианте, в понедельник в тесте проверю Феликс-02К (нет под рукой не фискализированного). В планах недели через 2 (не позже) - в "боевых" усл. все оборудование. Отпишусь. Все по порядку: (Поправьте, если что не так!) > remserial патчили ? Если нет, то где взять бинарник? http://lpccomp.bc.ca/remserial/ лучше из source code , на федоре9 компиляция с ошибкой, взял готовый там же, альтовцам - из сизифа (см http://bugs.etersoft.ru/show_bug.cgi?id=2498#c2 ) уже писалось. На клиенте (где железные кома) лучше рутом, или узером, входящим в группу uucp [root@adms ~]# remserial -d -p 7200 -s "9600 raw" /dev/ttyS0 & - для сканера [root@adms ~]# remserial -d -p 7201 -s "19200 raw" /dev/ttyS1 & - для ШТРИХа (115200 для феликс-02К). Впоследствии либо писать службу, либо как то еще автоматизировать запуск, лучше с проверкой на 'запущена'. > Какая версия wine? Вот-вот - версия current (с патчами) - брать из http://updates.etersoft.ru/pub/Etersoft/WINE@Etersoft/current/WINE/ Я тоже сначала попутался - закзал оплаченную 1.0.9 beta через "систему отгрузки Этерсофт" - нареканий нет, но это не та сборка!!! из неё берем только свежую закрытую часть. !Вниманию разработчиков! - На федора9 При первом запуске вайна (хоть --admin, хоть просто) косяк: окошко 'MFC Runtime Module' (mfc42u.dll) прячется за красивой заставкой, достаём окошечко любым методом, жмаем ОК, далее (вроде) без ошибок (--attach не проверял). На сервере принимаем кома - я решил сразу в Вайн соответсвующим юзером (в ttyS* рутом не получилось - не заморачивался почему): [stasw@vaio ~]$ remserial -d -r 192.168.10.110 -p 7200 -l /home/stasw/.wine/dosdevices/com5 /dev/ptmx & [stasw@vaio ~]$ remserial -d -r 192.168.10.110 -p 7201 -l /home/stasw/.wine/dosdevices/com6 /dev/ptmx & Драйвер сканера и феликса - Атоловский ДТО6 от 25.07.08 (с их сайта), хорошо описано в баг52 Шильниковым, в драйв.сканера указать суффикс #13. Ранее юзал старый атоловский драйвер - тоже работает, свежий драйвер понравился больше (внимание - в версии ДТО6 от 06.06.08 драйвер сканера (только у меня?) не работает). ШТРИХ работает 'из коробки'. 1с77 ТоргИскл, usb ключ, настройка Е-Фарма (хотя должно быть без разницы). След.этап - завести проброс с бездиска.
Пробовал Феликс-ФР-02К+Сканер Metrologic USB (/dev/ttyUSB0) подключаются нормально и даже работают... За 4 часа "работы" (ковыряний) 1с упала раз 10 (точнее отвалился драйвер атол). p.s. логи пока не высылаю, закономерность установить пока не удалось, но есть одна проблема: фискальник выставлен на скорость 4800, в параметрах remserial так и указал, а драйвер фр.атол при поиске на проброшенном порту находит его на 1200 (и нормально работает). После нескольких попыток "сказать" ему, что скорость должна быть 4800 драйвер падает. Сканер вроде номально работал, за исключением некоторых задержек по ssh (видимо сказывается нагрузка на сеть), под nx вроде норм.
внедрил еще две точки. На одной с пробросом комов через remserial (сканерШК и Феликс02К) с бездисковой Thinstasion на XDMCP (вставил remserial в образ). Все работает и даже без глюков, меньше всего нареканий к ККМ. Но обнаружилась новая напасть - при сканировании (одинаково и с локального сканера (ttyS0), и с промаппированного (pts*->*/dosdevices/com1) выявлена задержка передачи сканкода из драйвера в 1с в предопределенную процедуру (или в ней) ОбработкаВнешнегоСобытия(Источник,Событие,Данные) 1-3сек (непредсказуемо). Только затем запускается непосредственно обработка по переданному сканкоду. Если сканкод забить в окно ввода вручную (как сканер в разрыв клавиатуры)- то все моментально без задержки. Это долго. Действительно неудобно работать! В драйвер (пробовал все, в том числе от Штрих) сканкод попадает без задержек, даже если просмотр его запущен не через тестовую утилиту, а из 1с (сервис-параметры). Далее упомянутая задержка (наглядно - в АРМ кассира (1с) в строке состояния время задержки от сканирования до появления "выполняется обработка"). Т.е. либо под вайном сканкод от драйвера долго обрабатывается в этой процедуре, либо до неё. Под виндовс на той же конфигурации этой задержки нет. Надо это исправлять как то - какие есть предложения! На сканер в разрыв переход не предлагать!
Наткнулся на интересную вешь: http://www.atol.ru/forums/index.php?showtopic=5467&view=findpost&p=55767 Цитата: "В драйвере ККМ используется програмное управление потоком, весь обмен производится по линиям RX и TX, сигналы готовности и управления не задействуются. Возможно что из за этого и не работают ваши связки."
Вот еще на эту тему http://forum.shtrih-m.ru/viewtopic.php?p=55665#55665
Проверена задержка при сканировании на всех драйверах (Штрих, Атол, Scanopos) и локально и через проброшенный ком порт, и на стандартной 1с торг+склад (демобаза), и на тестовой от штрих, и на е-фарме. Для чистоты эксперимента заставил работать все перечисленные варианты (даже scanopos) - везде есть 1-4 сек задержка (комент.#60), под виндовс упомянутой задержки нет. Как собрать логи для решения этой проблемы? Чем еще могу помочь? Как будем решать эту проблему?!
Вот бага по подвисания 1с при передаче данных со сканера http://bugs.etersoft.ru/show_bug.cgi?id=2611 все новые камменты по этой теме туда Также хотелось бы, чтобы Вы оценили небольшой ман по настройке сканера http://wiki.etersoft.ru/ProgrammnoeObespechenie/TorgovoeOborudovanie?v=123g Рад буду слышать конструктивную критику, т.к. идеальных описаний не бывает.
Нагуглил вот такое средство для проброса портов: http://www.tibbo.com/vspdl.php Было бы неплохо попробовать.
(In reply to comment #65) > Нагуглил вот такое средство для проброса > портов: > http://www.tibbo.com/vspdl.php > Было бы неплохо попробовать. > проприетарщина?!
(In reply to comment #65) > Нагуглил вот такое средство для проброса > портов: > http://www.tibbo.com/vspdl.php > Было бы неплохо попробовать. Ну так и попробуйте - меня не удовлетворило решение от Тиббо для проброса в линуксе - сыро и сложно и на новых ядрах с бубном! Для винды (у меня) именно так и работает именно тиббо с бездисков WtPro - описание проброса на w2k3s на сайте http://wtpro.ru/com.html. И не надо больше ничего выдумывать - для вайна используйте сборку current и remserial - уже вторую неделю работает в БОЕВЫХ условиях (см.выше) с одной только проблемой - http://bugs.etersoft.ru/show_bug.cgi?id=2611 , но имхо проброс здесь ни при чем - проброс работает!
> проприетарщина?! Модуль ядра под GPL: $ grep -n GPL * vspm.c:544:MODULE_LICENSE("GPL"); Остальное вроде как проприетарное.
Пробовал vspdl действительно с установкой грабли были, remserial гораздо удобнее...
Предлагаю закрыть багу, т.к. именно с пробросом порта нет проблем. На данный момент проблема только с задержкой в вайне, когда при проверке в атоле ее нет.
Предлагаю опубликовать статью по пробросу на внешней wiki - и тогда сразу закрыть багу.
Константин, просыпаемся :) > Также хотелось бы, чтобы Вы оценили > небольшой ман по настройке сканера > http://wiki.etersoft.ru/ProgrammnoeObespechenie/TorgovoeOborudovanie?v=123g > Рад буду слышать конструктивную критику, > т.к. идеальных описаний не бывает.
Так нечестно! Ты дописал с тех пор, как выкладывал ссылку! :) Признаю, fixed.
(In reply to comment #72) > Константин, просыпаемся :) > > Также хотелось бы, чтобы Вы оценили > > небольшой ман по настройке сканера > > http://wiki.etersoft.ru/ProgrammnoeObespechenie/TorgovoeOborudovanie?v=123g > > Рад буду слышать конструктивную критику, > > т.к. идеальных описаний не бывает. > Да, хорошее описание! Достаточное для включения и юзания комовских устройств. Закрыли багу!
сам себе - однако проблема!!!! > Закрыли багу! > и срочно открываем - в новом багфикс-релизе 1.0.9-eter40 НЕ РАБОТАЕТ проброс комов через remserial. (при первом(втором) обращении виснут все (любые) программы для работы с проброшенным ком-портом) Пробовал ставить на рабочий сервер (--update), срочно вернулся на 1.0.9-eter39 !!! Настроено и работает в боевых усл как в ош.58 (с тех пор) Подскажите - как запустить wine (теперь все новые сборки только на тестовой машине!-( ) , чтоб составить для вас отчет для исправления ошибки!
Да, 1С 7.7 виснет, как только выбирается соответствующий сканеру COM-порт. > Подскажите - как запустить wine (теперь все > новые сборки только на тестовой машине!-( ) , > чтоб составить для вас отчет для > исправления ошибки! В отчёте нет необходимости, так как проблема воспроизвелась.
Проблема вызвана патчем "ntdll: Use additional buffers in COMM_DeviceIoControl (eterbug #2827)." Надо его откатить.
Надо приложить к 1.0.9 патчи: Revert "ntdll: Use additional buffers in COMM_DeviceIoControl (eterbug #2827)." ntdll: Prevent crash (eterbug #2827).
Попытался проверить на 1.0.10 alt10/alt6, в параметры 1С заходит нормально, но при попытке выполнить поиск оборудования и считать код ничего не выходит, но если порбовать cat com5, то коды приходят.. Может я что то не так делаю? Саша, проверь пожалуйста. Можно тестировать в бутылке 1c77/1c77-remserial. Сканер сейчас подключен в testing.
Пофиксил. Патч: ntdll: Hack for remserial (eterbug #553).
