Тормозит печать чека на фискальный регистратор через RDP
Добрый день! Проблема - тормозит печать чека на фискальном регистраторе при печати из 1С через RDP (удаленная точка, подключена через интернет по выделенке). Печать занимает 8 секунд. Прилагаю скриншот с замером времени, из которого видно, что именно операции с драйвером занимают все время.
Сервер - 16 Гб памяти, нормальный
Связь по выделенке, нормальная
1С - Комплексная автоматизация 1.1
ФР - атоловский FPrint
драйвера - атоловские, стоят на сервере, на клиент RDP пробрасывается порт
Отпишитесь, плиз, кто сталкивался с подобной проблемой
Сервер - 16 Гб памяти, нормальный
Связь по выделенке, нормальная
1С - Комплексная автоматизация 1.1
ФР - атоловский FPrint
драйвера - атоловские, стоят на сервере, на клиент RDP пробрасывается порт
Отпишитесь, плиз, кто сталкивался с подобной проблемой
Прикрепленные файлы:
По теме из базы знаний
Найденные решения
(10) Kutuzov,
Для начала. (возможно эти рекомендации уже решат твои проблемы) Сделай следующие вещи.
1) Если на сервере есть физические СОМ порты, то задай им такие номера, что бы случайный появившийся маппинговый порт их не перекрывал.
ПРИМЕР:
Физический СОМ1 => СОМ61
Физический СОМ2 => СОМ62
ВАЖНО!
Это касается и возможных виртуальных портов на сервере (при временном подключении какого нибудь USB устройства с эмуляцией RS232.
2) Раз у тебя есть вариации работы по ADSL.(Да чего греха таить многие провайдеры и по Ethernet подключают методом PPPoE)
То нам необходимо защитить пакеты для предотвращения дропа и(или) фрагментации пакетов промежуточным устройством при прохождении через программно-аппаратный туннель провайдеров.
Для этого достаточно изменить размер MTU сетевой карты. Как правило у Windows размер MTU = 1500 байт. Количество байт для инкапсуляции может быть различным. Но больше 50 байт инкапсуляцию уж точно никто не делает.
Поэтому достаточно изменить размер MTU = 1450 байт.
При чем меняй размер и у сервера и у клиентов. Т.к. неизвестно где какой провайдер.
ВАЖНО!
После изменения размера MTU компьютер необходимо перезагрузить! Для вступления настроек в силу.
Как менять размер MTU описывать не буду. в интернете полно примеров. Вот один из них
После этого проверь скорость печати чеков.
П.С. И не используй для ФР через маппинг большие скорости UART. Не больше 57600. Зачастую 9600 и 19200 достаточно.
П.П.С А вообще MTU лучше подбирать опытным путем , до тех пор пока пакет передачи данных перестанет фрагментироватся.
Для это выполняй такую команду
ping адрес_назначения - f - l xxxx где (хххх - это размер пакета в байтах)
Начинаешь с 1500 и потихоньку снижаешь размер по 10-12 байт.
Фрагментируемый пакет будет отображаться так
а вот как только он станет отображаться следующим образом
Значит пакет прошел сразу! Целиком без разбиения на части и потери драгоценного времени. (Т.к. любое разбиение пакета заставляет генерировать новую контрольную сумму, добавь к этому еще и генерацию контрольной суммы на шинах RS232)
После это побробуй немного увеличить размер, по 2-3 байта, что бы найти оптимальную точку когда пакет не дробиться.
Слишком маленький MTU тоже не сулит ничего хорошего.
П.П.П.С
Кстати если работа с 1С в режиме тонкого клиента тормозит. а интернет вроде как работает. "Поиграться" с MTU то же имеет смысл.
Для начала. (возможно эти рекомендации уже решат твои проблемы) Сделай следующие вещи.
1) Если на сервере есть физические СОМ порты, то задай им такие номера, что бы случайный появившийся маппинговый порт их не перекрывал.
ПРИМЕР:
Физический СОМ1 => СОМ61
Физический СОМ2 => СОМ62
ВАЖНО!
Это касается и возможных виртуальных портов на сервере (при временном подключении какого нибудь USB устройства с эмуляцией RS232.
2) Раз у тебя есть вариации работы по ADSL.(Да чего греха таить многие провайдеры и по Ethernet подключают методом PPPoE)
То нам необходимо защитить пакеты для предотвращения дропа и(или) фрагментации пакетов промежуточным устройством при прохождении через программно-аппаратный туннель провайдеров.
Для этого достаточно изменить размер MTU сетевой карты. Как правило у Windows размер MTU = 1500 байт. Количество байт для инкапсуляции может быть различным. Но больше 50 байт инкапсуляцию уж точно никто не делает.
Поэтому достаточно изменить размер MTU = 1450 байт.
При чем меняй размер и у сервера и у клиентов. Т.к. неизвестно где какой провайдер.
ВАЖНО!
После изменения размера MTU компьютер необходимо перезагрузить! Для вступления настроек в силу.
Как менять размер MTU описывать не буду. в интернете полно примеров. Вот один из них
После этого проверь скорость печати чеков.
П.С. И не используй для ФР через маппинг большие скорости UART. Не больше 57600. Зачастую 9600 и 19200 достаточно.
П.П.С А вообще MTU лучше подбирать опытным путем , до тех пор пока пакет передачи данных перестанет фрагментироватся.
Для это выполняй такую команду
ping адрес_назначения - f - l xxxx где (хххх - это размер пакета в байтах)
Начинаешь с 1500 и потихоньку снижаешь размер по 10-12 байт.
Фрагментируемый пакет будет отображаться так
а вот как только он станет отображаться следующим образом
Значит пакет прошел сразу! Целиком без разбиения на части и потери драгоценного времени. (Т.к. любое разбиение пакета заставляет генерировать новую контрольную сумму, добавь к этому еще и генерацию контрольной суммы на шинах RS232)
После это побробуй немного увеличить размер, по 2-3 байта, что бы найти оптимальную точку когда пакет не дробиться.
Слишком маленький MTU тоже не сулит ничего хорошего.
П.П.П.С
Кстати если работа с 1С в режиме тонкого клиента тормозит. а интернет вроде как работает. "Поиграться" с MTU то же имеет смысл.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Прилагаю скриншот с замером времени, из которого видно, что именно операции с драйвером занимают все время.
Где?
Тормозит печать чека на фискальный регистратор через RDPЭто не удивительно, честно сказать ни разу не видел, чтобы печать чека через RDP при удаленном сервере работала быстро.
При локальном серваке обычно проблем нет
1. RDP - в локалке или через инет?
2. Скорость на портах какая? (на компах и на ФР)
3. Локально если подключить ФР скорость печати такая же, или шустро печатает? (Исключить кривость драйвера. Т.к. например у Штриха есть драйвер 1С-ных и тест-драйвер это разные длл с разным набором функций.)
2. Скорость на портах какая? (на компах и на ФР)
3. Локально если подключить ФР скорость печати такая же, или шустро печатает? (Исключить кривость драйвера. Т.к. например у Штриха есть драйвер 1С-ных и тест-драйвер это разные длл с разным набором функций.)
(5) Kutuzov, Если хотите получить дельный ответ сообщите:
1. Пинг с клиента на сервер.
2. Попробуйте распечтать (чек, Х-отчет) на ФР который локально подключен к клиенту. (Тупо дровина может быть не хорошая)
3. Скорость портов какая? (Пример штрих АСПД максимум 57600 поддерживает и наблюдалось улучшение работы при снижении скорости портов)
Вы же когда к врачу приходите отвечаете на его вопросы, показываете результаты анализов. Одним замером производительности не обойтись))))
Вот еще ветка про АТОЛ
1. Пинг с клиента на сервер.
2. Попробуйте распечтать (чек, Х-отчет) на ФР который локально подключен к клиенту. (Тупо дровина может быть не хорошая)
3. Скорость портов какая? (Пример штрих АСПД максимум 57600 поддерживает и наблюдалось улучшение работы при снижении скорости портов)
Вы же когда к врачу приходите отвечаете на его вопросы, показываете результаты анализов. Одним замером производительности не обойтись))))
Вот еще ветка про АТОЛ
(4) Kutuzov,
Конечно известная проблема :) Все думают о пингах и ширине канала. А зрить нужно в корень.
Механизмы передачи пакетов данных TCP, RS232. То о чем выше писал.
Надо запомнить главное! Быстрый - не значит качественный!
10000 гастробайтеров быстрее перенесут тонну кирпичей, чем один погрузчик, но это не значит, что это лучший вариант :)
Конечно известная проблема :) Все думают о пингах и ширине канала. А зрить нужно в корень.
Механизмы передачи пакетов данных TCP, RS232. То о чем выше писал.
Надо запомнить главное! Быстрый - не значит качественный!
10000 гастробайтеров быстрее перенесут тонну кирпичей, чем один погрузчик, но это не значит, что это лучший вариант :)
Я рекомендую не использовать маппинг СОМ-порта через RDP.
Используйте механизм RS232-Ethernet-RS232 т.е. проброс портов по сети.
Для этого прекрасно зарекомендовала себя программа(бесплатная)
Устанавливается на торговых точках(серверный режим) и на сервере(клиентский).
На торговых точках необходимо настроить проброс TCP порта для программы.
Пример:
Настройки точек для ком порта на самом компе указывает только порт прослушки (и этот порт прослушки пробрасываем "наружу" в интернет)
(Точка-1) com1 = внеш.адрес: 123.123.123.123 порт: 7000
(Точка-2) com1 = внеш.адрес: 223.223.223.223 порт: 7000
Настройка сервера для созданных виртуальных комп портов указываем адрес и порт.
адрес: 123.123.123.123 порт: 7000 = com1
адрес: 223.223.223.223 порт: 7000 = com2
Получаем на сервере СОМ-порты на каждую торговую точку. В настройках Торг.оборудования настраиваем ФР каждой кассы на соответствующий порт.
Скорость ком. портов лучше делать небольшую.
от 19200 до 57600.И тайм аут выставлять в 300 мс. (Лучше немного поиграть с этими настройками)
На текущий момент в таком режиме работает порядка 40 магазинов заказчиков.
Используйте механизм RS232-Ethernet-RS232 т.е. проброс портов по сети.
Для этого прекрасно зарекомендовала себя программа(бесплатная)
Устанавливается на торговых точках(серверный режим) и на сервере(клиентский).
На торговых точках необходимо настроить проброс TCP порта для программы.
Пример:
Настройки точек для ком порта на самом компе указывает только порт прослушки (и этот порт прослушки пробрасываем "наружу" в интернет)
(Точка-1) com1 = внеш.адрес: 123.123.123.123 порт: 7000
(Точка-2) com1 = внеш.адрес: 223.223.223.223 порт: 7000
Настройка сервера для созданных виртуальных комп портов указываем адрес и порт.
адрес: 123.123.123.123 порт: 7000 = com1
адрес: 223.223.223.223 порт: 7000 = com2
Получаем на сервере СОМ-порты на каждую торговую точку. В настройках Торг.оборудования настраиваем ФР каждой кассы на соответствующий порт.
Скорость ком. портов лучше делать небольшую.
от 19200 до 57600.И тайм аут выставлять в 300 мс. (Лучше немного поиграть с этими настройками)
На текущий момент в таком режиме работает порядка 40 магазинов заказчиков.
(10) Kutuzov,
Тут главный момент, что на конкретный сом-порт, конкретный туннель-устройство.
А при RDP если на нескольких точках касса на COM1, то и для каждого сеанса устройство будет на COM1.
Т.е. технологически на сервере получается несколько COM1 (но в разрезе разных сеансов).
А как такой механизм работает неизвестно потому как документации нет.
Мой же механизм реализует идентификацию COM портов, независимо от сеансов!
Главное правильно настроить соответствие "настройки кассы"-"COM порт"
А то может получиться такое:
Покупку пробили в Череповце, а чек вылез в Самаре :)
Тут главный момент, что на конкретный сом-порт, конкретный туннель-устройство.
А при RDP если на нескольких точках касса на COM1, то и для каждого сеанса устройство будет на COM1.
Т.е. технологически на сервере получается несколько COM1 (но в разрезе разных сеансов).
А как такой механизм работает неизвестно потому как документации нет.
Мой же механизм реализует идентификацию COM портов, независимо от сеансов!
Главное правильно настроить соответствие "настройки кассы"-"COM порт"
А то может получиться такое:
Покупку пробили в Череповце, а чек вылез в Самаре :)
(10) Kutuzov,
Для начала. (возможно эти рекомендации уже решат твои проблемы) Сделай следующие вещи.
1) Если на сервере есть физические СОМ порты, то задай им такие номера, что бы случайный появившийся маппинговый порт их не перекрывал.
ПРИМЕР:
Физический СОМ1 => СОМ61
Физический СОМ2 => СОМ62
ВАЖНО!
Это касается и возможных виртуальных портов на сервере (при временном подключении какого нибудь USB устройства с эмуляцией RS232.
2) Раз у тебя есть вариации работы по ADSL.(Да чего греха таить многие провайдеры и по Ethernet подключают методом PPPoE)
То нам необходимо защитить пакеты для предотвращения дропа и(или) фрагментации пакетов промежуточным устройством при прохождении через программно-аппаратный туннель провайдеров.
Для этого достаточно изменить размер MTU сетевой карты. Как правило у Windows размер MTU = 1500 байт. Количество байт для инкапсуляции может быть различным. Но больше 50 байт инкапсуляцию уж точно никто не делает.
Поэтому достаточно изменить размер MTU = 1450 байт.
При чем меняй размер и у сервера и у клиентов. Т.к. неизвестно где какой провайдер.
ВАЖНО!
После изменения размера MTU компьютер необходимо перезагрузить! Для вступления настроек в силу.
Как менять размер MTU описывать не буду. в интернете полно примеров. Вот один из них
После этого проверь скорость печати чеков.
П.С. И не используй для ФР через маппинг большие скорости UART. Не больше 57600. Зачастую 9600 и 19200 достаточно.
П.П.С А вообще MTU лучше подбирать опытным путем , до тех пор пока пакет передачи данных перестанет фрагментироватся.
Для это выполняй такую команду
ping адрес_назначения - f - l xxxx где (хххх - это размер пакета в байтах)
Начинаешь с 1500 и потихоньку снижаешь размер по 10-12 байт.
Фрагментируемый пакет будет отображаться так
а вот как только он станет отображаться следующим образом
Значит пакет прошел сразу! Целиком без разбиения на части и потери драгоценного времени. (Т.к. любое разбиение пакета заставляет генерировать новую контрольную сумму, добавь к этому еще и генерацию контрольной суммы на шинах RS232)
После это побробуй немного увеличить размер, по 2-3 байта, что бы найти оптимальную точку когда пакет не дробиться.
Слишком маленький MTU тоже не сулит ничего хорошего.
П.П.П.С
Кстати если работа с 1С в режиме тонкого клиента тормозит. а интернет вроде как работает. "Поиграться" с MTU то же имеет смысл.
Для начала. (возможно эти рекомендации уже решат твои проблемы) Сделай следующие вещи.
1) Если на сервере есть физические СОМ порты, то задай им такие номера, что бы случайный появившийся маппинговый порт их не перекрывал.
ПРИМЕР:
Физический СОМ1 => СОМ61
Физический СОМ2 => СОМ62
ВАЖНО!
Это касается и возможных виртуальных портов на сервере (при временном подключении какого нибудь USB устройства с эмуляцией RS232.
2) Раз у тебя есть вариации работы по ADSL.(Да чего греха таить многие провайдеры и по Ethernet подключают методом PPPoE)
То нам необходимо защитить пакеты для предотвращения дропа и(или) фрагментации пакетов промежуточным устройством при прохождении через программно-аппаратный туннель провайдеров.
Для этого достаточно изменить размер MTU сетевой карты. Как правило у Windows размер MTU = 1500 байт. Количество байт для инкапсуляции может быть различным. Но больше 50 байт инкапсуляцию уж точно никто не делает.
Поэтому достаточно изменить размер MTU = 1450 байт.
При чем меняй размер и у сервера и у клиентов. Т.к. неизвестно где какой провайдер.
ВАЖНО!
После изменения размера MTU компьютер необходимо перезагрузить! Для вступления настроек в силу.
Как менять размер MTU описывать не буду. в интернете полно примеров. Вот один из них
После этого проверь скорость печати чеков.
П.С. И не используй для ФР через маппинг большие скорости UART. Не больше 57600. Зачастую 9600 и 19200 достаточно.
П.П.С А вообще MTU лучше подбирать опытным путем , до тех пор пока пакет передачи данных перестанет фрагментироватся.
Для это выполняй такую команду
ping адрес_назначения - f - l xxxx где (хххх - это размер пакета в байтах)
Начинаешь с 1500 и потихоньку снижаешь размер по 10-12 байт.
Фрагментируемый пакет будет отображаться так
а вот как только он станет отображаться следующим образом
Значит пакет прошел сразу! Целиком без разбиения на части и потери драгоценного времени. (Т.к. любое разбиение пакета заставляет генерировать новую контрольную сумму, добавь к этому еще и генерацию контрольной суммы на шинах RS232)
После это побробуй немного увеличить размер, по 2-3 байта, что бы найти оптимальную точку когда пакет не дробиться.
Слишком маленький MTU тоже не сулит ничего хорошего.
П.П.П.С
Кстати если работа с 1С в режиме тонкого клиента тормозит. а интернет вроде как работает. "Поиграться" с MTU то же имеет смысл.
(13)
Для ОС семейства Windows в команде ping после ключа -l указывается не MTU (Maximum Transmission Unit), а MSS (Maximum Segment Size)
И начинать надо не с 1500, а с 1472. От 1500 (размер кадра Ethernet) отнимаем 28 (размер заголовков протоколов IP и ICMP, которые добавляются к пакету), получаем 1472 (максимальный размер пакета, проходящего через интерфейс Ethernet).
Начинаешь с 1500 и потихоньку снижаешь размер по 10-12 байт
Для ОС семейства Windows в команде ping после ключа -l указывается не MTU (Maximum Transmission Unit), а MSS (Maximum Segment Size)
И начинать надо не с 1500, а с 1472. От 1500 (размер кадра Ethernet) отнимаем 28 (размер заголовков протоколов IP и ICMP, которые добавляются к пакету), получаем 1472 (максимальный размер пакета, проходящего через интерфейс Ethernet).
Как правило моментально.
Т.к. создаються отдельные каналы-туннели по которым передается просто текстовая строка (команды драйвера в фр и обратно)
А т.к. на каждый девайс свой канал, то приоритет у него единственный-высший :)
а по RDP валит сборная солянка всяких перенаправлений и какой пакет имеет высший приоритет одному богу и команде Билла известно :)
Т.к. создаються отдельные каналы-туннели по которым передается просто текстовая строка (команды драйвера в фр и обратно)
А т.к. на каждый девайс свой канал, то приоритет у него единственный-высший :)
а по RDP валит сборная солянка всяких перенаправлений и какой пакет имеет высший приоритет одному богу и команде Билла известно :)
Кстати совсем забыл.
Но это только для тех у кого Штрих-М
Ребята с Ростова сделали Драйвер-Сервер под "штрихи".
Механизм простой.
На торг.точке ставиться эта программулина у неё есть TCP порт (возможна работа по SSL- шифровани данных)
Через этот порт можно и управлять фискальником и печатать. Когда серверу нужно напечатать чек, он формирует xml-ку и пуляет её по нужному порту в нужный адрес. И все!
Офигенно надежно и быстро, своими глазами видел целую сеть АЗС на данном механизме.
Никаких сом-портов и потерянных сессий.
И главное(!) кроссплатформенность!
Но это только для тех у кого Штрих-М
Ребята с Ростова сделали Драйвер-Сервер под "штрихи".
Механизм простой.
На торг.точке ставиться эта программулина у неё есть TCP порт (возможна работа по SSL- шифровани данных)
Через этот порт можно и управлять фискальником и печатать. Когда серверу нужно напечатать чек, он формирует xml-ку и пуляет её по нужному порту в нужный адрес. И все!
Офигенно надежно и быстро, своими глазами видел целую сеть АЗС на данном механизме.
Никаких сом-портов и потерянных сессий.
И главное(!) кроссплатформенность!
Подниму тему
С одним лишь отличием: регистраторы печатали быстро,а теперь всё медленее и медленее. Т.е. проблема не врожденная,а приобретенная
Скоро чек 20 сек займёт. Причём сначала думает долго, потом печатает понемногу, отдохнет 3-5 сек и дальше печатает, отдохнет 3-5 сек и дальше печатает.
Портов нет с одинаковыми номерами.
Это происходит на всех регистраторах и на всех компах. Даже есть функция ОТКРЫТЬ ЯЩИК ( т.е. без печати текста) и то она жутко тормозить стала
феликс-02к
Подскажите где можно копнуть
С одним лишь отличием: регистраторы печатали быстро,а теперь всё медленее и медленее. Т.е. проблема не врожденная,а приобретенная
Скоро чек 20 сек займёт. Причём сначала думает долго, потом печатает понемногу, отдохнет 3-5 сек и дальше печатает, отдохнет 3-5 сек и дальше печатает.
Портов нет с одинаковыми номерами.
Это происходит на всех регистраторах и на всех компах. Даже есть функция ОТКРЫТЬ ЯЩИК ( т.е. без печати текста) и то она жутко тормозить стала
феликс-02к
Подскажите где можно копнуть
(17) spacecraft,
Перезагружал. Загрузка памяти совсем небольшая.
И конечно подкупает тот факт, что еще месяц назад всё работало исправно и быстро.
Вот лог фискальника:
Driver.Report
30.04.2015 10:12:36 0000000000 Посылка команды ККМ: 00 00 67 01
0000000000 Получен ответ: 55 66 00
30.04.2015 10:12:36 0000000000 Ошибка! ResultCode = -16 ResultDescription = "Не поддерживается в данном режиме устройства" BadParam = 0 BadParamDescription = "Ошибок в параметрах нет"
30.04.2015 10:12:38 0000002418 Driver.SetMode
30.04.2015 10:12:38 0000000000 Посылка команды ККМ: 00 00 48
0000000015 Получен ответ: 55 00 00
30.04.2015 10:12:39 0000000890 Driver.Report
30.04.2015 10:12:39 0000000000 Посылка команды ККМ: 00 00 67 01
0000000015 Получен ответ: 55 66 00
30.04.2015 10:12:39 0000000000 Ошибка! ResultCode = -16 ResultDescription = "Не поддерживается в данном режиме устройства" BadParam = 0 BadParamDescription = "Ошибок в параметрах нет"
0000006817 Driver.Set_Mode 2
30.04.2015 10:12:48 0000001404 Driver.SetMode
30.04.2015 10:12:48 0000000000 Посылка команды ККМ: 00 00 48
0000000000 Получен ответ: 55 00 00
30.04.2015 10:12:48 0000000000 Посылка команды ККМ: 00 00 56 02 00 00 00 30
0000000016 Получен ответ: 55 00 00
30.04.2015 10:12:48 0000000842 Driver.Report
30.04.2015 10:12:48 0000000000 Посылка команды ККМ: 00 00 67 01
0000000000 Получен ответ: 55 00 00
30.04.2015 10:12:50 0000001014 Посылка команды ККМ: 00 00 45
0000000843 Получен ответ: 55 22 00
30.04.2015 10:12:51 0000001014 Посылка команды ККМ: 00 00 45
0000000827 Получен ответ: 55 22 00
30.04.2015 10:12:53 0000001014 Посылка команды ККМ: 00 00 45
0000004149 Получен ответ: 55 02 00
30.04.2015 10:13:09 0000011997 Разрушение объекта нижнего уровня
0000000000 SetStateEvent
30.04.2015 10:13:09 0000000000 Объект старого протокола разрушен
################################################################
30.04.2015 10:13:09 0000000000 Устройство включено = 0
0000000000 Waiting for EventThread...
0000000000 EventThread destroyed successfully
0000000015 Port closed
30.04.2015 10:13:09 0000000000 Разрушение объекта нижнего уровня
30.04.2015 10:13:09 0000000000 Объект старого протокола разрушен
################################################################
30.04.2015 10:13:09 0000000000 Разрушение объекта нижнего уровня
30.04.2015 10:13:09 0000000000 Объект старого протокола разрушен
################################################################
30.04.2015 10:13:09 0000000000 Разрушение объекта нижнего уровня
30.04.2015 10:13:09 0000000000 Объект старого протокола разрушен
################################################################
30.04.2015 10:13:09 Завершаем запись в лог...
Перезагружал. Загрузка памяти совсем небольшая.
И конечно подкупает тот факт, что еще месяц назад всё работало исправно и быстро.
Вот лог фискальника:
Driver.Report
30.04.2015 10:12:36 0000000000 Посылка команды ККМ: 00 00 67 01
0000000000 Получен ответ: 55 66 00
30.04.2015 10:12:36 0000000000 Ошибка! ResultCode = -16 ResultDescription = "Не поддерживается в данном режиме устройства" BadParam = 0 BadParamDescription = "Ошибок в параметрах нет"
30.04.2015 10:12:38 0000002418 Driver.SetMode
30.04.2015 10:12:38 0000000000 Посылка команды ККМ: 00 00 48
0000000015 Получен ответ: 55 00 00
30.04.2015 10:12:39 0000000890 Driver.Report
30.04.2015 10:12:39 0000000000 Посылка команды ККМ: 00 00 67 01
0000000015 Получен ответ: 55 66 00
30.04.2015 10:12:39 0000000000 Ошибка! ResultCode = -16 ResultDescription = "Не поддерживается в данном режиме устройства" BadParam = 0 BadParamDescription = "Ошибок в параметрах нет"
0000006817 Driver.Set_Mode 2
30.04.2015 10:12:48 0000001404 Driver.SetMode
30.04.2015 10:12:48 0000000000 Посылка команды ККМ: 00 00 48
0000000000 Получен ответ: 55 00 00
30.04.2015 10:12:48 0000000000 Посылка команды ККМ: 00 00 56 02 00 00 00 30
0000000016 Получен ответ: 55 00 00
30.04.2015 10:12:48 0000000842 Driver.Report
30.04.2015 10:12:48 0000000000 Посылка команды ККМ: 00 00 67 01
0000000000 Получен ответ: 55 00 00
30.04.2015 10:12:50 0000001014 Посылка команды ККМ: 00 00 45
0000000843 Получен ответ: 55 22 00
30.04.2015 10:12:51 0000001014 Посылка команды ККМ: 00 00 45
0000000827 Получен ответ: 55 22 00
30.04.2015 10:12:53 0000001014 Посылка команды ККМ: 00 00 45
0000004149 Получен ответ: 55 02 00
30.04.2015 10:13:09 0000011997 Разрушение объекта нижнего уровня
0000000000 SetStateEvent
30.04.2015 10:13:09 0000000000 Объект старого протокола разрушен
################################################################
30.04.2015 10:13:09 0000000000 Устройство включено = 0
0000000000 Waiting for EventThread...
0000000000 EventThread destroyed successfully
0000000015 Port closed
30.04.2015 10:13:09 0000000000 Разрушение объекта нижнего уровня
30.04.2015 10:13:09 0000000000 Объект старого протокола разрушен
################################################################
30.04.2015 10:13:09 0000000000 Разрушение объекта нижнего уровня
30.04.2015 10:13:09 0000000000 Объект старого протокола разрушен
################################################################
30.04.2015 10:13:09 0000000000 Разрушение объекта нижнего уровня
30.04.2015 10:13:09 0000000000 Объект старого протокола разрушен
################################################################
30.04.2015 10:13:09 Завершаем запись в лог...
В свое время решал задачу печати по RDP при плохой связи. Проблема была в том, что трафик при печати был большой.
Проблему решил передачей данных для печати на компьютер рядом с принтером через TCP/IP, который уже и формировал картинку и отправлял на принтер.
Проблему решил передачей данных для печати на компьютер рядом с принтером через TCP/IP, который уже и формировал картинку и отправлял на принтер.
Используйте механизм RS232-Ethernet-RS232 т.е. проброс портов по сети.
Для этого прекрасно зарекомендовала себя программа(бесплатная) Tibbo Device Server Toolkit
Для этого прекрасно зарекомендовала себя программа(бесплатная) Tibbo Device Server Toolkit
Я правильно понимаю, что для этого необходимо сначала приобрести и затем использовать устройства Tibbo (Tibbo-конверторы)?
Т.е. без этих "физических устройств" com-порты по сети не пробросить?
(20) volk13,
Зачем?. На машине РМК (рабочее место кассира) у вас ФР на COM-порту. Ставите приложение (выберите нужную разрядность). Настраиваете в режиме сервера, на "удобный" для вас порт. С этого момента при обращеннии к IP адресу Компа РМК по этому порту вы обращаетесь к ФР.
Теперь на сервере устанавливаете то же приложение, но в режиме клиента указываете нужный IP адрес и порт, а также назначаете номер COM-порта.
И на сервере появляется виртуальный COM-порт, который по TCP/IP связан с ФР. Вот и все.
П.С. Если Комп РМК подключен к интернету через роутер, то позаботтесь о пробросе необходимого порта через роутер.
Зачем?. На машине РМК (рабочее место кассира) у вас ФР на COM-порту. Ставите приложение (выберите нужную разрядность). Настраиваете в режиме сервера, на "удобный" для вас порт. С этого момента при обращеннии к IP адресу Компа РМК по этому порту вы обращаетесь к ФР.
Теперь на сервере устанавливаете то же приложение, но в режиме клиента указываете нужный IP адрес и порт, а также назначаете номер COM-порта.
И на сервере появляется виртуальный COM-порт, который по TCP/IP связан с ФР. Вот и все.
П.С. Если Комп РМК подключен к интернету через роутер, то позаботтесь о пробросе необходимого порта через роутер.
(48) flint_sk8,
После установки "Tibbo Device Server Toolkit" открываешь "Tibbo VSP Manager" и добавляешь соединения (кнопка "ADD").
В форме диалога нового соединения по сути и так все понятно.
Если нужно создать вещание (как ты выразился), то это серверный режим (Routing mode = Server), тогда в этой же группе реквизитов "Networking" в поле "Listening port" устанавливаешь номер порта по которому будет вестись прослушка.
Если же нужно подключиться к удаленной машине, то это клиентский режим (Routing mode = Client), тогда активизируется группа реквизитов "Destination", где ты задаешь параметры сервера к которому нужно подключиться Адрес и Порт.
После установки "Tibbo Device Server Toolkit" открываешь "Tibbo VSP Manager" и добавляешь соединения (кнопка "ADD").
В форме диалога нового соединения по сути и так все понятно.
Если нужно создать вещание (как ты выразился), то это серверный режим (Routing mode = Server), тогда в этой же группе реквизитов "Networking" в поле "Listening port" устанавливаешь номер порта по которому будет вестись прослушка.
Если же нужно подключиться к удаленной машине, то это клиентский режим (Routing mode = Client), тогда активизируется группа реквизитов "Destination", где ты задаешь параметры сервера к которому нужно подключиться Адрес и Порт.
(49) bzmax,
Нажимаю добавить выбираю компорт в моем случае com1 (на нем стоит *) выставлю сервер ввожу порт для сети. нажимаю ОК
Захожу в устройства и у меня в списке два com порта COM1 (один оригинальный, второй TIBBO) при этом некакого соединения судя по монитору нету. Могу скинуть скрины.
Нажимаю добавить выбираю компорт в моем случае com1 (на нем стоит *) выставлю сервер ввожу порт для сети. нажимаю ОК
Захожу в устройства и у меня в списке два com порта COM1 (один оригинальный, второй TIBBO) при этом некакого соединения судя по монитору нету. Могу скинуть скрины.
На словах вроде понятно, а на практике проверить пока не могу, нет под рукой подходящего компьютера и девайса для экспериментов.
Существует-ли какое-либо описание на русском языке, как настроить данную программу в режиме сервера и в режиме клиента? Там есть такие режимы? (сервер и клиент)?
Просто в прикреплённом файле находится инструкция, в которой про режимы сервера и клиента ничего не сказано, и из неё мне непонятно, почему например в примере используют порты именно 2001 и 2002...
PS.
А задача у меня такая:
на РМ сотрудника установлена Ubuntu 14.04, из которой он по rdp в локальной сети подключается к WinServer2008, к самописной конфигурации 1С77.
необходимо из этой конфигурации печатать "спец.чек" на принтер чеков, установленный на РМ сотрудника, т.е. подключенный к линуксовому компьютеру.
Таких РМ с Ubuntu - много, все в локальной сети, но территориально в разных зданиях.
Вот думаю, как ещё можно сделать, кроме варианта - на все РМ поставить принтеры чеков с ethernet интерфейсом.
Существует-ли какое-либо описание на русском языке, как настроить данную программу в режиме сервера и в режиме клиента? Там есть такие режимы? (сервер и клиент)?
Просто в прикреплённом файле находится инструкция, в которой про режимы сервера и клиента ничего не сказано, и из неё мне непонятно, почему например в примере используют порты именно 2001 и 2002...
PS.
А задача у меня такая:
на РМ сотрудника установлена Ubuntu 14.04, из которой он по rdp в локальной сети подключается к WinServer2008, к самописной конфигурации 1С77.
необходимо из этой конфигурации печатать "спец.чек" на принтер чеков, установленный на РМ сотрудника, т.е. подключенный к линуксовому компьютеру.
Таких РМ с Ubuntu - много, все в локальной сети, но территориально в разных зданиях.
Вот думаю, как ещё можно сделать, кроме варианта - на все РМ поставить принтеры чеков с ethernet интерфейсом.
Прикрепленные файлы:
Инструкция.pdf
(29) bzmax,
Обычно так настраивают, в случаях, когда клиентские компы ничего окромя древнего линукса с rdp клиентом, или windows 98/NT5 с ним же, по характеристикам не вытягивают.
Только ненадежное это решение, особенно для ритейла.
MTU, у него действительно может быть мелкий указан, в подобных ситуациях с глюками фр ленивому мне обычно помогали утилиты проброса rs-232 портов, от Eltima, либо FabulaTech(пакеты у них меньшего размера, вроде при работе создаются).
Ну и дрова на кабель контроллер rs-232, обновить не помешает, если подключение фр по usb, с эмуляцией rs-232 идет.
Лежат тут:
Обычно так настраивают, в случаях, когда клиентские компы ничего окромя древнего линукса с rdp клиентом, или windows 98/NT5 с ним же, по характеристикам не вытягивают.
Только ненадежное это решение, особенно для ритейла.
MTU, у него действительно может быть мелкий указан, в подобных ситуациях с глюками фр ленивому мне обычно помогали утилиты проброса rs-232 портов, от Eltima, либо FabulaTech(пакеты у них меньшего размера, вроде при работе создаются).
Ну и дрова на кабель контроллер rs-232, обновить не помешает, если подключение фр по usb, с эмуляцией rs-232 идет.
Лежат тут:
(29) bzmax,
спасибо за отклик
При наличии локальной сети почему-то через RDP работает в три раза быстрее, чем без RPD ( лицензия на 5 рабочих мест есть). Поэтому работаем так.
Bryuhanov
конечно я прочитал про утилиты проброски портов. Воспользуюсь ими.
Меня до сих пор смущает тот факт, что пару месяцев назад всё работало нормально: без проброски портов, без изменения MTU и т.п...
п.с. на всех компах WIN7, фискальники на COM портах
спасибо за отклик
При наличии локальной сети почему-то через RDP работает в три раза быстрее, чем без RPD ( лицензия на 5 рабочих мест есть). Поэтому работаем так.
Bryuhanov
конечно я прочитал про утилиты проброски портов. Воспользуюсь ими.
Меня до сих пор смущает тот факт, что пару месяцев назад всё работало нормально: без проброски портов, без изменения MTU и т.п...
п.с. на всех компах WIN7, фискальники на COM портах
(31) camel,
Локальная сеть, локальной сети рознь!
Я уже тысячу раз об этом писал. Просто объеденить компьютеры в сеть мало! ВАЖНО что бы компьютеры в сети друг друга находили моментально!
(Здесь медвежью услугу играет виндовс, т.к. до сих пор они используют netbios т.е. компьютер можеть находиться только по имени компьютера без имени домена и если при таком раскладе у вас не WINS сервера, то ЛЮБАЯ(!) сетевая карта ЛЮБОГО(!) устройства в сети может стать основным обозревателем в сети используя свой кеш(!), что в сою очередь просто загаживает локальную сеть "броадкастами") - как правило так все делают по дефолту.
Хочешь что бы сеть работала моментально:
1) Отключаешь на всех компах NetBIOS поверх TCP/IP (многие этого пугаются т.к. в сетевом окружении не видно ни одного компа, оно и понятно обозреватель сети без НЕТБИОС не работает. К каждому компу нужно подключаться введя в адресной строке полное имя. Например \\копм1.мой_домен.loc\шара_для_всех. Если нужны сетевые пути для кого-то то нужно использовать сценарии подключения сетевых дисков, а не "открывать" всю сеть любому обозревателю, что бы любой пользователь мог видеть всю локальную сеть).
2) Правильно настраиваешь DNS в сети. (каждый комп должен иметь ПОЛНОЕ(!) имя. Например копм1.мой_домен.loc)
3) Настройка серверов и клиентских программ к ним ТОЛЬКО(!) по полному имени!
4) Если ключи раздаются не сервером 1С, а менеджером HASP лицензий, то на каждом клиентском компе должны быть жесткие настройки на сервер лицензий (настройка файла nethasp.ini), а не поиск лицензий по броадкастам.
Вот тогда и будешь радоваться работе своей сети.
П.С. Простыми словами. Хочешь что бы сеть и сервера работали быстро и грамотно - забудь о дефолтных настройках и настраивай все сам.
Локальная сеть, локальной сети рознь!
Я уже тысячу раз об этом писал. Просто объеденить компьютеры в сеть мало! ВАЖНО что бы компьютеры в сети друг друга находили моментально!
(Здесь медвежью услугу играет виндовс, т.к. до сих пор они используют netbios т.е. компьютер можеть находиться только по имени компьютера без имени домена и если при таком раскладе у вас не WINS сервера, то ЛЮБАЯ(!) сетевая карта ЛЮБОГО(!) устройства в сети может стать основным обозревателем в сети используя свой кеш(!), что в сою очередь просто загаживает локальную сеть "броадкастами") - как правило так все делают по дефолту.
Хочешь что бы сеть работала моментально:
1) Отключаешь на всех компах NetBIOS поверх TCP/IP (многие этого пугаются т.к. в сетевом окружении не видно ни одного компа, оно и понятно обозреватель сети без НЕТБИОС не работает. К каждому компу нужно подключаться введя в адресной строке полное имя. Например \\копм1.мой_домен.loc\шара_для_всех. Если нужны сетевые пути для кого-то то нужно использовать сценарии подключения сетевых дисков, а не "открывать" всю сеть любому обозревателю, что бы любой пользователь мог видеть всю локальную сеть).
2) Правильно настраиваешь DNS в сети. (каждый комп должен иметь ПОЛНОЕ(!) имя. Например копм1.мой_домен.loc)
3) Настройка серверов и клиентских программ к ним ТОЛЬКО(!) по полному имени!
4) Если ключи раздаются не сервером 1С, а менеджером HASP лицензий, то на каждом клиентском компе должны быть жесткие настройки на сервер лицензий (настройка файла nethasp.ini), а не поиск лицензий по броадкастам.
Вот тогда и будешь радоваться работе своей сети.
П.С. Простыми словами. Хочешь что бы сеть и сервера работали быстро и грамотно - забудь о дефолтных настройках и настраивай все сам.
Все просто до безобразия.
Когда Вам провайдер говорит о надежном широком канале, то это в подавляющем случае наиболее оптимистичный редко встречающийся случай.
Ширина меняется много раз за время отправки кода на принтер много раз.
Код здоровенный не постскрипт же, да и он то же мал.
Сказки нет - красивый чек = большой файл на печать. При помтоянно меняющейся ширине канала, печать будет долго, а 1С висит.
Когда Вам провайдер говорит о надежном широком канале, то это в подавляющем случае наиболее оптимистичный редко встречающийся случай.
Ширина меняется много раз за время отправки кода на принтер много раз.
Код здоровенный не постскрипт же, да и он то же мал.
Сказки нет - красивый чек = большой файл на печать. При помтоянно меняющейся ширине канала, печать будет долго, а 1С висит.
(36) Ну если усе именно так и это локальная сеть. Значит идем к сисадмину. Ударяем его моськой о стол и говорим: "Что ж ты га..дина в домен наш локальный в ДНС не прописал!" и еще разок его моськой, чтоб перестал жрать сухари, когда с ним разговаривают.
Нет проблемы к каналом, значит есть проблемы с поискам доменной машины (там АД хранится). А нужно это чтоб найти комп и убедиться, что туда можно слать на печать.
Аминь.
Нет проблемы к каналом, значит есть проблемы с поискам доменной машины (там АД хранится). А нужно это чтоб найти комп и убедиться, что туда можно слать на печать.
Аминь.
Правильно это когда:
1) В сети один DHCP (если он есть). И DNS интегрирован с DHCP. Т.е. при выдаче любого адреса запись "А" тут же появляется в DNS.
2) Серверы в сети имеют статический адрес. И все должны быть вручную заведены в DNS. Как "A" записи, так и "PTR"(при наличии обратной зоны).
3) Не обязательно, но желательно что бы была и обратная зона, в которой должны быть прописаны минимум адреса DNS сервера и статические адреса серверов (1С, СУБД).
4) Резолвинг всех(!) адресов (в том числе и интернет) только через твой(и) DNS сервер(а). Т.е. на DNS должна быть настроена ретрансляция резолвинга, если адрес не из твоей подсети.
Вот собственно все.
1) В сети один DHCP (если он есть). И DNS интегрирован с DHCP. Т.е. при выдаче любого адреса запись "А" тут же появляется в DNS.
2) Серверы в сети имеют статический адрес. И все должны быть вручную заведены в DNS. Как "A" записи, так и "PTR"(при наличии обратной зоны).
3) Не обязательно, но желательно что бы была и обратная зона, в которой должны быть прописаны минимум адреса DNS сервера и статические адреса серверов (1С, СУБД).
4) Резолвинг всех(!) адресов (в том числе и интернет) только через твой(и) DNS сервер(а). Т.е. на DNS должна быть настроена ретрансляция резолвинга, если адрес не из твоей подсети.
Вот собственно все.
(40) camel,
Гавное 1С сервер в своих настройках то же должен быть по полному имени.
Посмотри в консоль администрирования сервера 1С. Название сервера и рабочих процесов только NetBIOS-овское без домена.
Для того что бы название сервера было полным необходимо остановить сервер.
И отредактировать файлы:
C:\Program Files\1cv8\srvinfo\1cv8wsrv.lst
и
C:\Program Files\1cv8\srvinfo\reg_1541\1CV8Clst.lst
вместо "Program Files" может быть "Program Files (x86)" зависит от разрядности сервера.
Так вот, найди в этих файлах имя компа и добавь к нему доменный суффикс (что бы полное имя было).
После этого запусти сервер.
Вот тогда "Картинка" совсем будет "Красивой" :)
Гавное 1С сервер в своих настройках то же должен быть по полному имени.
Посмотри в консоль администрирования сервера 1С. Название сервера и рабочих процесов только NetBIOS-овское без домена.
Для того что бы название сервера было полным необходимо остановить сервер.
И отредактировать файлы:
C:\Program Files\1cv8\srvinfo\1cv8wsrv.lst
и
C:\Program Files\1cv8\srvinfo\reg_1541\1CV8Clst.lst
вместо "Program Files" может быть "Program Files (x86)" зависит от разрядности сервера.
Так вот, найди в этих файлах имя компа и добавь к нему доменный суффикс (что бы полное имя было).
После этого запусти сервер.
Вот тогда "Картинка" совсем будет "Красивой" :)
Друзья, подыму тему.
Поставил тибо на клиента с ФР, и на сервер терминалов, сделал проброску портов, сделал ddns.
На клиенте ФР атол висит на com10, тибо создал ком20. На терминале видит поры 10 и 20.
Но как указать ФР и где (на клиенте или сервере) чтобы работал ФР через 20 порт, пробую на сервере в драйвере ФР поставить 20 порт, он его не видит, так же на клиенте пробую 20 порт, но не видит потому что ФР сидит на 10 порту.
Поставил тибо на клиента с ФР, и на сервер терминалов, сделал проброску портов, сделал ddns.
На клиенте ФР атол висит на com10, тибо создал ком20. На терминале видит поры 10 и 20.
Но как указать ФР и где (на клиенте или сервере) чтобы работал ФР через 20 порт, пробую на сервере в драйвере ФР поставить 20 порт, он его не видит, так же на клиенте пробую 20 порт, но не видит потому что ФР сидит на 10 порту.
Присоединюсь к flint_sk8 и lalalSSSS
В диспетчере устройств на сервере тиббо(Рабочее место кассира) появляется второй comХ порт.
Получается что на одном, к примеру, com10 сидит ФР
А тиббо создает свой виртуальный com10 и получается полная лажа.
В диспетчере устройств на сервере тиббо(Рабочее место кассира) появляется второй comХ порт.
Получается что на одном, к примеру, com10 сидит ФР
А тиббо создает свой виртуальный com10 и получается полная лажа.
У кого-то получилось программно пробросить RS-232 в ethernet? Или нужно покупать аппаратный преобразователь? Столкнулись с проблемой тормозов на Штрихах по RDP, УТ 10.3 стандартный чек печатает относительно нормально, если добавлять логотип или строки в чек, то жуткие тормоза, на один чек 1-1.5 минуты
(120) Чисто теоретически, описать подробно можно, вот только тут масса нюансов, которые зависят от конфигурации, настройки сети, магнитного поля Земли и т.п., гораздо проще найти специалиста за определенную плату, которому объяснять не придется, чтобы он все настроил.
Отличное решение! Это аналог того о чем я писал в 15 посту.Только там:
1) Решение платное.
2) Решение кроссплатформенное (win, lin)
Проверил.Печатал чек из Питера в Красноярске (без логотипов, 15 позиций в чеке) задержка менее секунды.
Отличный результат.
Ставлю плюс.
1) Решение платное.
2) Решение кроссплатформенное (win, lin)
Проверил.Печатал чек из Питера в Красноярске (без логотипов, 15 позиций в чеке) задержка менее секунды.
Отличный результат.
Ставлю плюс.
Коллеги, здравствуйте!
Просьба подсказать пути решения такой проблемы:
- есть сканер ШК 2Д - YOUJIE4600 (установлен и проброшен через COM-порт на удаленный рабочий стол)
- принимающее окно - 1С
- сканер настроен через "сервис - торговое оборудование"
- тест сканер проходит корректно
- драйвера все последние
проблема на удаленном рабочем столе:
- при считывании одномерного ШК - задержек нет
- при считывании QR-кода проходит, Примерно, секунд 7-10, пока в принимающем окне появится декодированная строка
на локальной машине при тех же условиях задержка в пределах 1 секунды только при считывании QR-кода
Просьба подсказать пути решения такой проблемы:
- есть сканер ШК 2Д - YOUJIE4600 (установлен и проброшен через COM-порт на удаленный рабочий стол)
- принимающее окно - 1С
- сканер настроен через "сервис - торговое оборудование"
- тест сканер проходит корректно
- драйвера все последние
проблема на удаленном рабочем столе:
- при считывании одномерного ШК - задержек нет
- при считывании QR-кода проходит, Примерно, секунд 7-10, пока в принимающем окне появится декодированная строка
на локальной машине при тех же условиях задержка в пределах 1 секунды только при считывании QR-кода
А что тут думать то?
Линейный ШК это строка в единицы байт, а QR-код это строка в сотни байт, а то и килобайты.
А скорость порта сканера по дефолту всего 9600 бод. :) Вот и посчитай.
Скорость порта сканера увеличивай и таймаут поменьше сделай.
Линейный ШК это строка в единицы байт, а QR-код это строка в сотни байт, а то и килобайты.
А скорость порта сканера по дефолту всего 9600 бод. :) Вот и посчитай.
Скорость порта сканера увеличивай и таймаут поменьше сделай.
(64) bzmax, проверил hyperterminal-ом. Считывает в пределах секунды. В отладчике проверил, что подключение драйвера сканера идет с настройками, которые я установил. Скорости 152000 и таймаут 75 (Стандартный, не меняется в настройках)
Сканер цепляю к своей форме в конфигурации БГУ.
процедуру подлючитьклиента и отключитьклиента вызываю при открытии и закрытии формы
данные штрихкода получаю через внешнее событие. тут все просто, вроде. что еще проверить можно?
Сканер цепляю к своей форме в конфигурации БГУ.
процедуру подлючитьклиента и отключитьклиента вызываю при открытии и закрытии формы
данные штрихкода получаю через внешнее событие. тут все просто, вроде. что еще проверить можно?
С момента считывания штрихкода и срабатыванием ВнешнегоСобытия проходит 2 секунды. Дело точно не в сканере, т.к. гипертерминал получает данные со штрихкода (навороченного цифрами, кириллицей и англ. буквами и спецсимволами) за 1 секунду
(71) bzmax, у меня на локальной машине событие отрабатывает в течение 2-3 секунд. А в гипертерминал считывает буквально за 1 сек без задержек. Т.е. МТУ мне не поможет.я к своей форме прикрутил считывание. Использую стандартные процедуры из обработки СерверТО.
функции ПодключитьКлиента, отключить и внешнее событие в моей форме. Где мог ошибиться?? Литературы уже перечитал, но ответ не нашел
функции ПодключитьКлиента, отключить и внешнее событие в моей форме. Где мог ошибиться?? Литературы уже перечитал, но ответ не нашел
(70) mms76,
А им зачем? Они девайсы выпускают :) И описание для работы с ними :) Дальше задача программистов :)
Единственное не все а точнее только АТОЛ не дает протоколы для работы со своими девайсами, поэтому подключать их оборудование всегда приходиться с "танцами и бубном".
Штрих-М, СервисПлюс и прочие более демократичны в этом плане.
А им зачем? Они девайсы выпускают :) И описание для работы с ними :) Дальше задача программистов :)
Единственное не все а точнее только АТОЛ не дает протоколы для работы со своими девайсами, поэтому подключать их оборудование всегда приходиться с "танцами и бубном".
Штрих-М, СервисПлюс и прочие более демократичны в этом плане.
(72) bzmax,
Проблему решил след. образом:
Обратил внимание, что в компоненте от 1С при проверке устройства - есть параметр ТаймаутСОМ. Нашел в обработке от 1С функцию В (1СScanopos.epf):
// Функция осуществляет подключение устройства.
// (API v2.0)
//
// Параметры:
// Объект -
// - Объект драйвера торгового оборудования.
//
// Возвращаемое значение:
// - Результат работы функции.
//
Функция Подключить(Объект) Экспорт
Объект.Драйвер.ИмяСобытия = "ПолученШтрихкод";
Объект.Драйвер.ТаймаутCOM = 0; // <= надо выставить в "0" и будет без задержек срабатывать внешнее событие
Проблему решил след. образом:
Обратил внимание, что в компоненте от 1С при проверке устройства - есть параметр ТаймаутСОМ. Нашел в обработке от 1С функцию В (1СScanopos.epf):
// Функция осуществляет подключение устройства.
// (API v2.0)
//
// Параметры:
// Объект -
// - Объект драйвера торгового оборудования.
//
// Возвращаемое значение:
// - Результат работы функции.
//
Функция Подключить(Объект) Экспорт
Объект.Драйвер.ИмяСобытия = "ПолученШтрихкод";
Объект.Драйвер.ТаймаутCOM = 0; // <= надо выставить в "0" и будет без задержек срабатывать внешнее событие
bzmax, Подскажите пожалуйста в каком месте мы указываем в клиентсокй части в программе Tibbo Device Server Toolkit, что нужно с виртуального порта сом2 печатать на физический порт сом1?
Давай ка уточним что ты понимаешь под "Клиентской частью"
Установил tdst и программу Ip_to_Com. Теперь чеки печатаются не 2 минуты, а 30 сек. Можно было бы радоваться, но некоторые чеки почему то непонятно себя ведут. При закрытии чека выдается сообщение "Чек аннулирован". Подключаешь через RDP с подключенными портами, чек печатается без ошибок, но 2 минуты. Подскажите люди добрые куда копать?
Версия 1С 8.2
Драйвера АТОЛ 6,20,0,1
tdst версия 5,09,10
6_ip_com_v3_0_0
Версия 1С 8.2
Драйвера АТОЛ 6,20,0,1
tdst версия 5,09,10
6_ip_com_v3_0_0
Тоже геморой с ККМ (меркурий MSK на Штрих-М дровах) + rdp по инету.
Пинг до сервака около 40. А чек печатает секунд 17.
Читаю инфостарт вроде люди решают проблему но прям конкретно как не говорят и теряются))
Хоть бы кто публикацию запилил что ли с конкретными инструкциями =\
Вариант с прямым пробросом порта по рдп. - медленно.
Буду подключать белый ip к клиентской и пробовать по tcp.
1) IP_TO_COM + tibbo
2) Через Штрих-М сервер ФР
Пинг до сервака около 40. А чек печатает секунд 17.
Читаю инфостарт вроде люди решают проблему но прям конкретно как не говорят и теряются))
Хоть бы кто публикацию запилил что ли с конкретными инструкциями =\
Вариант с прямым пробросом порта по рдп. - медленно.
Буду подключать белый ip к клиентской и пробовать по tcp.
1) IP_TO_COM + tibbo
2) Через Штрих-М сервер ФР
доброго времени суток!
Максим, вы советовали в самом начале TDST.
Бился целый день и результата не получил.
На месте кассира в тиббо устанавливаю серер. Порт указываю 7000.
На роутере пробросил 7000 порт.
Антивирус удалил, фаерволл отключил.
Касса висит на *COM3
Выбираю его для создания виртуального ком порта.
На терминальном сервере ставлю клиента. Указываю белый IP рабочего места кассира, порт указываю 7000.
При проверке кассы из 1С тибо монитор пишет, что connection refused.
Я так понимаю, что место кассира не принимает подключение? Правильно? (напомню, что фаерволл отключен и никаких антивирусов нет, порт проброшен).
На РКМ, такое ощущение, что тиббо не слушает порт.
Выдает сообщение
02/05/17 18:33:40 - COM3 (INFO): VSP opened, transport=TCP(TDI), routing=server, local port=7000, OTF=out-of-band
02/05/17 18:33:40 - COM3 (INFO): Listening on TCP port 7000
02/05/17 18:33:44 - COM3 (INFO): Device closed
Через 2ip смотрю открыт 7000 порт или нет. - ПОРТ ЗАКРЫТ.
Не подскажете что я мог упустить и почему может не работать?
Уже голова кипит :) Вроде все просто, вроде делаю правильно, но работать не хочет! :(
Максим, вы советовали в самом начале TDST.
Бился целый день и результата не получил.
На месте кассира в тиббо устанавливаю серер. Порт указываю 7000.
На роутере пробросил 7000 порт.
Антивирус удалил, фаерволл отключил.
Касса висит на *COM3
Выбираю его для создания виртуального ком порта.
На терминальном сервере ставлю клиента. Указываю белый IP рабочего места кассира, порт указываю 7000.
При проверке кассы из 1С тибо монитор пишет, что connection refused.
Я так понимаю, что место кассира не принимает подключение? Правильно? (напомню, что фаерволл отключен и никаких антивирусов нет, порт проброшен).
На РКМ, такое ощущение, что тиббо не слушает порт.
Выдает сообщение
02/05/17 18:33:40 - COM3 (INFO): VSP opened, transport=TCP(TDI), routing=server, local port=7000, OTF=out-of-band
02/05/17 18:33:40 - COM3 (INFO): Listening on TCP port 7000
02/05/17 18:33:44 - COM3 (INFO): Device closed
Через 2ip смотрю открыт 7000 порт или нет. - ПОРТ ЗАКРЫТ.
Не подскажете что я мог упустить и почему может не работать?
Уже голова кипит :) Вроде все просто, вроде делаю правильно, но работать не хочет! :(
пробую в локальной сети все это дело организовать - тиббо монитор пишет следующее
02/06/17 12:44:32 - COM2 (INFO): VSP opened, transport=TCP(TDI), routing=client, remote=192.168.1.30:5555, connect=on data, OTF=out-of-band
02/06/17 12:44:44 - COM2 (ERROR): "On-the-Fly" command for 192.168.1.30 - set DTR to low...timed out
02/06/17 12:44:44 - COM2 (WARNING): "On-the-Fly" settings disabled (until connection established or port opened next time)
02/06/17 12:44:44 - COM2 (INFO): Device closed
параметр DTR вообще не нашел где установить его ниже...
На рабочем месте ставлю сервера, порт другой и так же - порт закрыт :(
02/06/17 12:44:32 - COM2 (INFO): VSP opened, transport=TCP(TDI), routing=client, remote=192.168.1.30:5555, connect=on data, OTF=out-of-band
02/06/17 12:44:44 - COM2 (ERROR): "On-the-Fly" command for 192.168.1.30 - set DTR to low...timed out
02/06/17 12:44:44 - COM2 (WARNING): "On-the-Fly" settings disabled (until connection established or port opened next time)
02/06/17 12:44:44 - COM2 (INFO): Device closed
параметр DTR вообще не нашел где установить его ниже...
На рабочем месте ставлю сервера, порт другой и так же - порт закрыт :(
Я полгода назад тоже долго бился с ошибками. Потом тупо отключил все проверки и потоком отправлял что надо на печать. И к моему удивлению всё заработало. Кому интересно вот обрезанная обработка:
Оставил только одну проверку в конце: "Вышел ли чек или нет"
Оставил только одну проверку в конце: "Вышел ли чек или нет"
ГОСПОДА. Приветствую всех.
Хоть тема давно закрыта, я смотрю вопрос в пробросе ком-портов до сих пор актуален.
Сам я уже давно этим не занимаюсь, т.к. перешел на тонкие клиенты (управляемые формы).
Но могу сразу сказать всем следующее.
То что я советовал использовать TDST с двух сторон (сервер и клиент) - это устаревшая информация. Все течет, все меняется разработчик вносит коррективы. Серверный функционал TDST теперь работает только в купе с своим оборудованием (преобразователи компании Tibbo).
Теперь TDST можно применять ТОЛЬКО как клиента (т.е. устанавливается на сервере RDP как клиент для связи с открытыми портами расшаренных касс на удаленных торговых точках).
Серверную часть на торговой точке RS232-TCP необходимо реализовывать на другом программном продукте, либо (что намного лучше) на преобразователе интерфейса.
Ввиду актуальности и нужности данной информации. Сегодня напишу статью с двумя вариантами реализации (программным и аппаратным) и опубликую здесь на портале.
Хоть тема давно закрыта, я смотрю вопрос в пробросе ком-портов до сих пор актуален.
Сам я уже давно этим не занимаюсь, т.к. перешел на тонкие клиенты (управляемые формы).
Но могу сразу сказать всем следующее.
То что я советовал использовать TDST с двух сторон (сервер и клиент) - это устаревшая информация. Все течет, все меняется разработчик вносит коррективы. Серверный функционал TDST теперь работает только в купе с своим оборудованием (преобразователи компании Tibbo).
Теперь TDST можно применять ТОЛЬКО как клиента (т.е. устанавливается на сервере RDP как клиент для связи с открытыми портами расшаренных касс на удаленных торговых точках).
Серверную часть на торговой точке RS232-TCP необходимо реализовывать на другом программном продукте, либо (что намного лучше) на преобразователе интерфейса.
Ввиду актуальности и нужности данной информации. Сегодня напишу статью с двумя вариантами реализации (программным и аппаратным) и опубликую здесь на портале.
Максим, по крайней мере я, с нетерпением жду статью!!! )
Возможно скажу глупость, но все же.
Может быть у Вас остался TDST старой версии, который позволяет использовать тиббо, програмно, как сервер? Чтобы воспроизвести то решение, о котором вы писали в самом начале?
Возможно скажу глупость, но все же.
Может быть у Вас остался TDST старой версии, который позволяет использовать тиббо, програмно, как сервер? Чтобы воспроизвести то решение, о котором вы писали в самом начале?
Настроил сегодня работу, пока в тестовом режиме.
На рабочем месте кассира поставки VSPE, на терминальном сервере использовал TDST в качестве клиента.
Одна позиция в чеке печатается почти моментально. 3-5 секунд. 10 позиций выходят в течении секунд 30.
На что грешить?
Возможно ли где то буфер обмена больше поставить?
Или дело в ширине канала? Там адсл.
Спасибо!
На рабочем месте кассира поставки VSPE, на терминальном сервере использовал TDST в качестве клиента.
Одна позиция в чеке печатается почти моментально. 3-5 секунд. 10 позиций выходят в течении секунд 30.
На что грешить?
Возможно ли где то буфер обмена больше поставить?
Или дело в ширине канала? Там адсл.
Спасибо!
(93)
Андрей :) Надо было сразу писать что у вас ККМ F-Print (Атоловский девайс).
8-ая версия драйверов для Атола уже давно реализовала работу по сети :)
(как минимум 4 года уже)
Тут надо понимать что Атоловские драйвера бесплатно работают только с "своими" ККМ.
Андрей :) Надо было сразу писать что у вас ККМ F-Print (Атоловский девайс).
8-ая версия драйверов для Атола уже давно реализовала работу по сети :)
(как минимум 4 года уже)
Тут надо понимать что Атоловские драйвера бесплатно работают только с "своими" ККМ.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот