зависают чеки на DATECS FP-3530T
зависают чеки на DATECS FP-3530T
DATECS FP-3530T подключены к тонким клиентам по ком порту.
Часто бывает что 1С говорит мол фискальный регистратор не обнаружен и хуже всего если это происходит в момент печати чека, потому как печать просто прерывается и ты не можешь быстро отпустить клиента и очередь растет.
Хотел добавить в config параметр syslog=<IP-адресу машины, на которой запущен wtware-конфигуратор> что бы посомотреть детальный LOG, так wtware ругается мол ошибка в конфигурационном файле. В чем дело? как посмотреть детальный LOG ?
версия wtware 5.1.39 и 5.2.10
проблема есть давно у разных клиентов с разными ОС в качестве терминального сервера.
Часто бывает что 1С говорит мол фискальный регистратор не обнаружен и хуже всего если это происходит в момент печати чека, потому как печать просто прерывается и ты не можешь быстро отпустить клиента и очередь растет.
Хотел добавить в config параметр syslog=<IP-адресу машины, на которой запущен wtware-конфигуратор> что бы посомотреть детальный LOG, так wtware ругается мол ошибка в конфигурационном файле. В чем дело? как посмотреть детальный LOG ?
версия wtware 5.1.39 и 5.2.10
проблема есть давно у разных клиентов с разными ОС в качестве терминального сервера.
Re: зависают чеки на DATECS FP-3530T
Лицензии есть !
Вот стандартный конфигурационный файл
server=192.168.0.119
user=kasir3:kasir3
clienthostname=MLN.KASSA3
resolution=1024x768
serial=com1
timezone=FLE Standard Time
graphic=f
turnoffmenu=always
mouse_accel_mult=2
keyboard=ru
language=ru,default
redraw_delay=50
connection
Вот стандартный конфигурационный файл
server=192.168.0.119
user=kasir3:kasir3
clienthostname=MLN.KASSA3
resolution=1024x768
serial=com1
timezone=FLE Standard Time
graphic=f
turnoffmenu=always
mouse_accel_mult=2
keyboard=ru
language=ru,default
redraw_delay=50
connection
-
- Разработчик
- Сообщения: 11842
- Зарегистрирован: Ср окт 01, 2003 12:06 am
- Откуда: Роcсия, Тольятти
- Контактная информация:
Re: зависают чеки на DATECS FP-3530T
Нет больше параметра про лог в конфиге, лог снимается руками.
В конфигураторе выбери терминал. Перейди на вкладку "Логи". Нажми на большую кнопку "получить лог".
Не перегружай терминал, не выключай конфигуратор пока не случится ошибка.
Ещё лог можно посмотреть интернетэксплорером, зайти на IP терминала. Но лучше конфигуратором и заранее, до ошибки, чтобы в логе были отметки времени.
В конфигураторе выбери терминал. Перейди на вкладку "Логи". Нажми на большую кнопку "получить лог".
Не перегружай терминал, не выключай конфигуратор пока не случится ошибка.
Ещё лог можно посмотреть интернетэксплорером, зайти на IP терминала. Но лучше конфигуратором и заранее, до ошибки, чтобы в логе были отметки времени.
Re: зависают чеки на DATECS FP-3530T
Вот лог одного из терминальных клиентов за весь день работы, но он не похож на полный. Ошибки в работе были но здесь насколько я могу понять ничего не видно.
18-16-46-947| Close connection with wtc.exe.
18-16-46-947| Send WTCU discover to 192.168.0.119.
18-16-46-947| Send WTCU discover to 192.168.0.119.
18-16-46-950| Connection from wtc.exe at 192.168.0.119.
07-24-13-520| [pfac] Got command line /sbin/resolver 09d8c5b0 dns [192.168.0.119].
07-24-13-598| [pfac] Ok, PID 632.
07-24-13-598| [pfac] Process pid 632 terminated, status 00000000.
07-24-13-598| [gm] 192.168.0.119 => 192.168.0.119.
07-24-13-598| [gm] Free ram before fork terminal client /sbin/rdpclient (session 6): 174064 Kb.
07-24-13-598| [pfac] Got command line /sbin/rdpclient 6.
07-24-13-598| [pfac] Ok, PID 633.
07-24-13-598| [rdpclient 633] RDP Terminal Client, WTware v.5.2.10, pipe 6, pid 633.
07-24-13-614| [rdpclient 633] Add serial redirection, COM3 in the session = hardware COM1.
07-24-13-614| [rdpdr-serial 0] New client connection, id 6.
07-24-13-614| [rdpclient 633] Make RDP session with 192.168.0.119:3389.
07-24-13-614| [rdpclient 633] Username: "kasir3".
07-24-13-614| [rdpclient 633] Password: present.
07-24-13-614| [rdpclient 633] No domain.
07-24-13-614| [rdpclient 633] No shell.
07-24-13-614| [rdpclient 633] No directory.
07-24-13-629| [rdpclient 633] Window: 1024x768@16.
07-24-13-629| [rdpclient 633] PFlags 0x000000AF.
07-24-13-629| [rdpclient 633] Keyboard 00000419:00000000.
07-24-13-629| [rdpclient 633] My hostname "MLN.KASSA3".
07-24-13-629| [rdpclient 633] TCP: connecting to 192.168.0.119:3389.
07-24-13-629| [rdpclient 633] TCP: connection with 192.168.0.119:3389 established.
07-24-13-629| [rdpclient 633] Turn keepalive on.
07-24-13-629| [rdpclient 633] Free ram after buffers allocation: 170472 KB.
07-24-13-645| [rdpclient 633] Process RDP server certificate.
07-24-13-645| [rdpclient 633] RDP4 encryption.
07-24-13-645| [rdpclient 633] Timezone "(UTC+02:00) Helsinki, Kyiv, Riga, Sofia, Tallinn, Vilnius".
07-24-14-129| [rdpclient 633] LOGON_EX_LOGONERRORS 0xfffffffe 0x00000002.
07-24-14-301| [rdpclient 633] SessionId 0x00000002: SERVER1\kasir3.
14-15-00-392| [rdpclient 633] ERRINFO_LOGOFF_BY_USER
14-15-00-503| [rdpclient 633] Receive Disconnect Provider Ultimatum.
14-15-00-553| [gm] TSClient gracefully end.
14-15-00-557| [pfac] Process pid 633 terminated, status 00000000.
14-15-00-558| [rdpdr-serial 0] Close client connection 0 (id 6).
14-15-00-567| [rdpclient 633] Caught signal SIGTERM.
14-15-02-624| [pfac] Got command line /sbin/resolver 09d8c5b0 dns [192.168.0.119].
14-15-02-682| [pfac] Ok, PID 634.
14-15-02-689| [pfac] Process pid 634 terminated, status 00000000.
14-15-02-689| [gm] 192.168.0.119 => 192.168.0.119.
14-15-02-699| [gm] Free ram before fork terminal client /sbin/rdpclient (session 7): 174008 Kb.
14-15-02-699| [pfac] Got command line /sbin/rdpclient 7.
14-15-02-714| [pfac] Ok, PID 635.
14-15-02-714| [rdpclient 635] RDP Terminal Client, WTware v.5.2.10, pipe 7, pid 635.
14-15-02-718| [rdpclient 635] Add serial redirection, COM3 in the session = hardware COM1.
14-15-02-718| [rdpdr-serial 0] New client connection, id 7.
14-15-02-724| [rdpclient 635] Make RDP session with 192.168.0.119:3389.
14-15-02-725| [rdpclient 635] Username: "kasir3".
14-15-02-740| [rdpclient 635] Password: present.
14-15-02-747| [rdpclient 635] No domain.
14-15-02-758| [rdpclient 635] No shell.
14-15-02-758| [rdpclient 635] No directory.
14-15-02-770| [rdpclient 635] Window: 1024x768@16.
14-15-02-771| [rdpclient 635] PFlags 0x000000AF.
14-15-02-783| [rdpclient 635] Keyboard 00000419:00000000.
14-15-02-784| [rdpclient 635] My hostname "MLN.KASSA3".
14-15-02-799| [rdpclient 635] TCP: connecting to 192.168.0.119:3389.
14-15-02-800| [rdpclient 635] TCP: connection with 192.168.0.119:3389 established.
14-15-02-816| [rdpclient 635] Turn keepalive on.
14-15-02-816| [rdpclient 635] Free ram after buffers allocation: 170388 KB.
14-15-02-834| [rdpclient 635] Process RDP server certificate.
14-15-02-834| [rdpclient 635] RDP4 encryption.
14-15-02-839| [rdpclient 635] Timezone "(UTC+02:00) Helsinki, Kyiv, Riga, Sofia, Tallinn, Vilnius".
14-15-03-222| [rdpclient 635] LOGON_EX_LOGONERRORS 0xfffffffe 0x00000002.
14-15-03-703| [rdpclient 635] SessionId 0x00000002: SERVER1\kasir3.
14-19-56-175| [rdpclient 635] ERRINFO_RPC_INITIATED_DISCONNECT_BYUSER
14-19-56-252| [rdpclient 635] Receive Disconnect Provider Ultimatum.
14-19-56-304| [gm] TSClient gracefully end.
14-19-56-307| [pfac] Process pid 635 terminated, status 00000000.
14-19-56-307| [rdpdr-serial 0] Close client connection 0 (id 7).
14-19-56-311| [rdpclient 635] Caught signal SIGTERM.
14-20-47-571| [pfac] Got command line /sbin/resolver 09d8c5b0 dns [192.168.0.119].
14-20-47-623| [pfac] Ok, PID 636.
14-20-47-627| [pfac] Process pid 636 terminated, status 00000000.
14-20-47-628| [gm] 192.168.0.119 => 192.168.0.119.
14-20-47-631| [gm] Free ram before fork terminal client /sbin/rdpclient (session
: 174008 Kb.
14-20-47-631| [pfac] Got command line /sbin/rdpclient 8.
14-20-47-635| [pfac] Ok, PID 637.
14-20-47-635| [rdpclient 637] RDP Terminal Client, WTware v.5.2.10, pipe 8, pid 637.
14-20-47-640| [rdpclient 637] Add serial redirection, COM3 in the session = hardware COM1.
14-20-47-640| [rdpdr-serial 0] New client connection, id 8.
14-20-47-645| [rdpclient 637] Make RDP session with 192.168.0.119:3389.
14-20-47-645| [rdpclient 637] Username: "kasir3".
14-20-47-648| [rdpclient 637] Password: present.
14-20-47-649| [rdpclient 637] No domain.
14-20-47-652| [rdpclient 637] No shell.
14-20-47-652| [rdpclient 637] No directory.
14-20-47-656| [rdpclient 637] Window: 1024x768@16.
14-20-47-657| [rdpclient 637] PFlags 0x000000AF.
14-20-47-664| [rdpclient 637] Keyboard 00000419:00000000.
14-20-47-664| [rdpclient 637] My hostname "MLN.KASSA3".
14-20-47-668| [rdpclient 637] TCP: connecting to 192.168.0.119:3389.
14-20-47-668| [rdpclient 637] TCP: connection with 192.168.0.119:3389 established.
14-20-47-672| [rdpclient 637] Turn keepalive on.
14-20-47-672| [rdpclient 637] Free ram after buffers allocation: 170388 KB.
14-20-47-677| [rdpclient 637] Process RDP server certificate.
14-20-47-677| [rdpclient 637] RDP4 encryption.
14-20-47-682| [rdpclient 637] Timezone "(UTC+02:00) Helsinki, Kyiv, Riga, Sofia, Tallinn, Vilnius".
14-20-48-095| [rdpclient 637] SessionId 0x00000002: SERVER1\kasir3.
22-00-54-627| [rdpclient 637] ERRINFO_RPC_INITIATED_DISCONNECT_BYUSER
22-00-54-721| [rdpclient 637] Receive Disconnect Provider Ultimatum.
22-00-54-768| [gm] TSClient gracefully end.
22-00-54-768| [pfac] Process pid 637 terminated, status 00000000.
22-00-54-768| [rdpdr-serial 0] Close client connection 0 (id
.
22-00-54-768| [rdpclient 637] Caught signal SIGTERM.
18-16-46-947| Close connection with wtc.exe.
18-16-46-947| Send WTCU discover to 192.168.0.119.
18-16-46-947| Send WTCU discover to 192.168.0.119.
18-16-46-950| Connection from wtc.exe at 192.168.0.119.
07-24-13-520| [pfac] Got command line /sbin/resolver 09d8c5b0 dns [192.168.0.119].
07-24-13-598| [pfac] Ok, PID 632.
07-24-13-598| [pfac] Process pid 632 terminated, status 00000000.
07-24-13-598| [gm] 192.168.0.119 => 192.168.0.119.
07-24-13-598| [gm] Free ram before fork terminal client /sbin/rdpclient (session 6): 174064 Kb.
07-24-13-598| [pfac] Got command line /sbin/rdpclient 6.
07-24-13-598| [pfac] Ok, PID 633.
07-24-13-598| [rdpclient 633] RDP Terminal Client, WTware v.5.2.10, pipe 6, pid 633.
07-24-13-614| [rdpclient 633] Add serial redirection, COM3 in the session = hardware COM1.
07-24-13-614| [rdpdr-serial 0] New client connection, id 6.
07-24-13-614| [rdpclient 633] Make RDP session with 192.168.0.119:3389.
07-24-13-614| [rdpclient 633] Username: "kasir3".
07-24-13-614| [rdpclient 633] Password: present.
07-24-13-614| [rdpclient 633] No domain.
07-24-13-614| [rdpclient 633] No shell.
07-24-13-614| [rdpclient 633] No directory.
07-24-13-629| [rdpclient 633] Window: 1024x768@16.
07-24-13-629| [rdpclient 633] PFlags 0x000000AF.
07-24-13-629| [rdpclient 633] Keyboard 00000419:00000000.
07-24-13-629| [rdpclient 633] My hostname "MLN.KASSA3".
07-24-13-629| [rdpclient 633] TCP: connecting to 192.168.0.119:3389.
07-24-13-629| [rdpclient 633] TCP: connection with 192.168.0.119:3389 established.
07-24-13-629| [rdpclient 633] Turn keepalive on.
07-24-13-629| [rdpclient 633] Free ram after buffers allocation: 170472 KB.
07-24-13-645| [rdpclient 633] Process RDP server certificate.
07-24-13-645| [rdpclient 633] RDP4 encryption.
07-24-13-645| [rdpclient 633] Timezone "(UTC+02:00) Helsinki, Kyiv, Riga, Sofia, Tallinn, Vilnius".
07-24-14-129| [rdpclient 633] LOGON_EX_LOGONERRORS 0xfffffffe 0x00000002.
07-24-14-301| [rdpclient 633] SessionId 0x00000002: SERVER1\kasir3.
14-15-00-392| [rdpclient 633] ERRINFO_LOGOFF_BY_USER
14-15-00-503| [rdpclient 633] Receive Disconnect Provider Ultimatum.
14-15-00-553| [gm] TSClient gracefully end.
14-15-00-557| [pfac] Process pid 633 terminated, status 00000000.
14-15-00-558| [rdpdr-serial 0] Close client connection 0 (id 6).
14-15-00-567| [rdpclient 633] Caught signal SIGTERM.
14-15-02-624| [pfac] Got command line /sbin/resolver 09d8c5b0 dns [192.168.0.119].
14-15-02-682| [pfac] Ok, PID 634.
14-15-02-689| [pfac] Process pid 634 terminated, status 00000000.
14-15-02-689| [gm] 192.168.0.119 => 192.168.0.119.
14-15-02-699| [gm] Free ram before fork terminal client /sbin/rdpclient (session 7): 174008 Kb.
14-15-02-699| [pfac] Got command line /sbin/rdpclient 7.
14-15-02-714| [pfac] Ok, PID 635.
14-15-02-714| [rdpclient 635] RDP Terminal Client, WTware v.5.2.10, pipe 7, pid 635.
14-15-02-718| [rdpclient 635] Add serial redirection, COM3 in the session = hardware COM1.
14-15-02-718| [rdpdr-serial 0] New client connection, id 7.
14-15-02-724| [rdpclient 635] Make RDP session with 192.168.0.119:3389.
14-15-02-725| [rdpclient 635] Username: "kasir3".
14-15-02-740| [rdpclient 635] Password: present.
14-15-02-747| [rdpclient 635] No domain.
14-15-02-758| [rdpclient 635] No shell.
14-15-02-758| [rdpclient 635] No directory.
14-15-02-770| [rdpclient 635] Window: 1024x768@16.
14-15-02-771| [rdpclient 635] PFlags 0x000000AF.
14-15-02-783| [rdpclient 635] Keyboard 00000419:00000000.
14-15-02-784| [rdpclient 635] My hostname "MLN.KASSA3".
14-15-02-799| [rdpclient 635] TCP: connecting to 192.168.0.119:3389.
14-15-02-800| [rdpclient 635] TCP: connection with 192.168.0.119:3389 established.
14-15-02-816| [rdpclient 635] Turn keepalive on.
14-15-02-816| [rdpclient 635] Free ram after buffers allocation: 170388 KB.
14-15-02-834| [rdpclient 635] Process RDP server certificate.
14-15-02-834| [rdpclient 635] RDP4 encryption.
14-15-02-839| [rdpclient 635] Timezone "(UTC+02:00) Helsinki, Kyiv, Riga, Sofia, Tallinn, Vilnius".
14-15-03-222| [rdpclient 635] LOGON_EX_LOGONERRORS 0xfffffffe 0x00000002.
14-15-03-703| [rdpclient 635] SessionId 0x00000002: SERVER1\kasir3.
14-19-56-175| [rdpclient 635] ERRINFO_RPC_INITIATED_DISCONNECT_BYUSER
14-19-56-252| [rdpclient 635] Receive Disconnect Provider Ultimatum.
14-19-56-304| [gm] TSClient gracefully end.
14-19-56-307| [pfac] Process pid 635 terminated, status 00000000.
14-19-56-307| [rdpdr-serial 0] Close client connection 0 (id 7).
14-19-56-311| [rdpclient 635] Caught signal SIGTERM.
14-20-47-571| [pfac] Got command line /sbin/resolver 09d8c5b0 dns [192.168.0.119].
14-20-47-623| [pfac] Ok, PID 636.
14-20-47-627| [pfac] Process pid 636 terminated, status 00000000.
14-20-47-628| [gm] 192.168.0.119 => 192.168.0.119.
14-20-47-631| [gm] Free ram before fork terminal client /sbin/rdpclient (session
![Cool 8)](./images/smilies/icon_cool.gif)
14-20-47-631| [pfac] Got command line /sbin/rdpclient 8.
14-20-47-635| [pfac] Ok, PID 637.
14-20-47-635| [rdpclient 637] RDP Terminal Client, WTware v.5.2.10, pipe 8, pid 637.
14-20-47-640| [rdpclient 637] Add serial redirection, COM3 in the session = hardware COM1.
14-20-47-640| [rdpdr-serial 0] New client connection, id 8.
14-20-47-645| [rdpclient 637] Make RDP session with 192.168.0.119:3389.
14-20-47-645| [rdpclient 637] Username: "kasir3".
14-20-47-648| [rdpclient 637] Password: present.
14-20-47-649| [rdpclient 637] No domain.
14-20-47-652| [rdpclient 637] No shell.
14-20-47-652| [rdpclient 637] No directory.
14-20-47-656| [rdpclient 637] Window: 1024x768@16.
14-20-47-657| [rdpclient 637] PFlags 0x000000AF.
14-20-47-664| [rdpclient 637] Keyboard 00000419:00000000.
14-20-47-664| [rdpclient 637] My hostname "MLN.KASSA3".
14-20-47-668| [rdpclient 637] TCP: connecting to 192.168.0.119:3389.
14-20-47-668| [rdpclient 637] TCP: connection with 192.168.0.119:3389 established.
14-20-47-672| [rdpclient 637] Turn keepalive on.
14-20-47-672| [rdpclient 637] Free ram after buffers allocation: 170388 KB.
14-20-47-677| [rdpclient 637] Process RDP server certificate.
14-20-47-677| [rdpclient 637] RDP4 encryption.
14-20-47-682| [rdpclient 637] Timezone "(UTC+02:00) Helsinki, Kyiv, Riga, Sofia, Tallinn, Vilnius".
14-20-48-095| [rdpclient 637] SessionId 0x00000002: SERVER1\kasir3.
22-00-54-627| [rdpclient 637] ERRINFO_RPC_INITIATED_DISCONNECT_BYUSER
22-00-54-721| [rdpclient 637] Receive Disconnect Provider Ultimatum.
22-00-54-768| [gm] TSClient gracefully end.
22-00-54-768| [pfac] Process pid 637 terminated, status 00000000.
22-00-54-768| [rdpdr-serial 0] Close client connection 0 (id
![Cool 8)](./images/smilies/icon_cool.gif)
22-00-54-768| [rdpclient 637] Caught signal SIGTERM.
-
- Разработчик
- Сообщения: 11842
- Зарегистрирован: Ср окт 01, 2003 12:06 am
- Откуда: Роcсия, Тольятти
- Контактная информация:
Re: зависают чеки на DATECS FP-3530T
Да, лог хороший, ошибок не видно. За этот день, т.е. за время записи этого лога, регистратор отваливался?
Ничего хорошего не могу сказать. Если бы ошибку можно было повторить, я бы сделал версию с развёрнутой отладкой. Но за день этой развёрнутой отладки гигабайт будет, я в ней потом не разберусь.
Покопайся в настройках 1C и драйвера сканера, может там где-нибудь таймауты можно побольше сделать.
Ты проверял, как этот ФР работает через mstsc.exe? Если там тоже будут отваливания, можно трясти производителя ФРа и копать интернет. Если через mstsc.exe он скажем неделю отработает без единого отваливания, значит дело в втвари. К этому ФРу огромное количество утилит есть: http://service.systema.com.ua/index.php?id=fp-3530t Можно покопать в эту сторону, найти то, что работает через mstsc.exe, но не работает через втварь.
В любом случае надо рыть, простого решения не вижу![Sad :(](./images/smilies/icon_sad.gif)
Ничего хорошего не могу сказать. Если бы ошибку можно было повторить, я бы сделал версию с развёрнутой отладкой. Но за день этой развёрнутой отладки гигабайт будет, я в ней потом не разберусь.
Покопайся в настройках 1C и драйвера сканера, может там где-нибудь таймауты можно побольше сделать.
Ты проверял, как этот ФР работает через mstsc.exe? Если там тоже будут отваливания, можно трясти производителя ФРа и копать интернет. Если через mstsc.exe он скажем неделю отработает без единого отваливания, значит дело в втвари. К этому ФРу огромное количество утилит есть: http://service.systema.com.ua/index.php?id=fp-3530t Можно покопать в эту сторону, найти то, что работает через mstsc.exe, но не работает через втварь.
В любом случае надо рыть, простого решения не вижу
![Sad :(](./images/smilies/icon_sad.gif)
Re: зависают чеки на DATECS FP-3530T
Ошибки выпадают часто, так что если есть возможность сделать развернутый лог я мог бы сохранить фрагмент с предполагаемой ошибкой.
Не у верен что у драйвера вообще есть конфигурируемые настройки, это тупо DLL и где у нее гайки крутятся это вопрос.
1С программист говорит что там есть какие то таймауты, я попросил его посмотреть.
Сам буду искать рабочий ПК для того что бы проверить вариант с mstsc.
Не у верен что у драйвера вообще есть конфигурируемые настройки, это тупо DLL и где у нее гайки крутятся это вопрос.
1С программист говорит что там есть какие то таймауты, я попросил его посмотреть.
Сам буду искать рабочий ПК для того что бы проверить вариант с mstsc.
Re: зависают чеки на DATECS FP-3530T
Не совсем понял, что должно работать через mstsc и не работать через wtwareaka писал(а):К этому ФРу огромное количество утилит есть: http://service.systema.com.ua/index.php?id=fp-3530t Можно покопать в эту сторону, найти то, что работает через mstsc.exe, но не работает через втварь.
В любом случае надо рыть, простого решения не вижу
Re: зависают чеки на DATECS FP-3530T
Программист 1С сказал что одинэска открывает компорт при запуске и закрывает его при закрытие. Так что таймингов каких то изменить не получиться.
Поставил вместо ПК с wtware, ПК с windows 8.1 и работаем через mstsc, вроде как проблемы пропали, посмотрим еще завтра. Давайте смотреть детальные логи.
Поставил вместо ПК с wtware, ПК с windows 8.1 и работаем через mstsc, вроде как проблемы пропали, посмотрим еще завтра. Давайте смотреть детальные логи.
-
- Разработчик
- Сообщения: 11842
- Зарегистрирован: Ср окт 01, 2003 12:06 am
- Откуда: Роcсия, Тольятти
- Контактная информация:
Re: зависают чеки на DATECS FP-3530T
Мне Яндекс такую картинку показал:
[img]http://бизнесплюспермь.рф/wp-content/uploads/2013/05/PropFR1C.jpg[/img]
Это драйвера Штрих-М. Тоже тупо dll, однако настройка таймаута есть. У ваших драйверов такого нет?
Вот тут включена отладка обмена с COM-портом:
http://pxe.ru/files/testing/201410180022.zip
Но там реально много лога. Надо научиться воспроизводить проблему, иначе в мегабайтах лога я ничего не пойму.
И начало хоть одного лога хочу видеть.
[img]http://бизнесплюспермь.рф/wp-content/uploads/2013/05/PropFR1C.jpg[/img]
Это драйвера Штрих-М. Тоже тупо dll, однако настройка таймаута есть. У ваших драйверов такого нет?
Вот тут включена отладка обмена с COM-портом:
http://pxe.ru/files/testing/201410180022.zip
Но там реально много лога. Надо научиться воспроизводить проблему, иначе в мегабайтах лога я ничего не пойму.
И начало хоть одного лога хочу видеть.
Re: зависают чеки на DATECS FP-3530T
Спустя столько времени все же решил вернуться к своим баранам.
Хоть ошибки вылетают не так часто как было в начале, но все же по нескольку раз на день.
И как мне написал администратор аптеки: "пока кассиры пытаются провести не проведенный чек, стоит раздраженная очередь из клиентов, которые, в виду последних событий в стране и в общем, считают за честь унизить и оскорбить сотрудников аптеки."
Так что я скачал http://pxe.ru/files/testing/201410180022.zip, и поставил на терминалы.
Увы но я не знаю как эту ошибку воспроизвести, поэтому просто включаю лог в конфигураторе wtware, в надежде что лог сохранится, а девушки из аптеки передадут мне сбойные чеки на которых есть точное время.
Очень плохо, что лог нужно включать вручную, когда терминалы включаются, когда перезагружаются и т.д.
Плюс ко всему, к моему удивлению, я не могу посмотреть или сохранить больше чем 10к сток лога.
Может быть есть какое то более адекватное решение ?![Sad :(](./images/smilies/icon_sad.gif)
Хоть ошибки вылетают не так часто как было в начале, но все же по нескольку раз на день.
И как мне написал администратор аптеки: "пока кассиры пытаются провести не проведенный чек, стоит раздраженная очередь из клиентов, которые, в виду последних событий в стране и в общем, считают за честь унизить и оскорбить сотрудников аптеки."
Так что я скачал http://pxe.ru/files/testing/201410180022.zip, и поставил на терминалы.
Увы но я не знаю как эту ошибку воспроизвести, поэтому просто включаю лог в конфигураторе wtware, в надежде что лог сохранится, а девушки из аптеки передадут мне сбойные чеки на которых есть точное время.
Очень плохо, что лог нужно включать вручную, когда терминалы включаются, когда перезагружаются и т.д.
Плюс ко всему, к моему удивлению, я не могу посмотреть или сохранить больше чем 10к сток лога.
Может быть есть какое то более адекватное решение ?
![Sad :(](./images/smilies/icon_sad.gif)
-
- Разработчик
- Сообщения: 11842
- Зарегистрирован: Ср окт 01, 2003 12:06 am
- Откуда: Роcсия, Тольятти
- Контактная информация:
Re: зависают чеки на DATECS FP-3530T
Если ошибка случается по нескольку раз в день, что сложного оставить на день включенный конфигуратор для одного терминала и получить логи нескольких ошибок? Этим надо заняться. Более простого способа найти ошибку, которая случается непонятно когда, и которую не удяётся связать ни с какими внешними событиями, я не знаю.
Логе больше 10к строк не нужны. Логи - они же не машине скармливаются, их будет читать человек, который закопается раньше, чем поймёт 10к строк![Sad :(](./images/smilies/icon_sad.gif)
Логе больше 10к строк не нужны. Логи - они же не машине скармливаются, их будет читать человек, который закопается раньше, чем поймёт 10к строк
![Sad :(](./images/smilies/icon_sad.gif)
Re: зависают чеки на DATECS FP-3530T
Сегодня в 11 часов дня запустил лог, и получается первая временна я метка в логе должна быть что то вроде этого - [11-01-32-110].
Но на деле я вижу метку [17-39-57-309] как будто лог включен час назад.
По мере поступления данных в лог временна я метка смещается вверх. таким образом сняв лог в сейчас, я ни разу не увижу что было два часа назад.
Никто не просит читать все 100к строк лога, мне скажут когда была ошибка, а в логе есть временная метка.
Потому что за час у меня набегает 8-10 к строк.
Но на деле я вижу метку [17-39-57-309] как будто лог включен час назад.
По мере поступления данных в лог временна я метка смещается вверх. таким образом сняв лог в сейчас, я ни разу не увижу что было два часа назад.
Никто не просит читать все 100к строк лога, мне скажут когда была ошибка, а в логе есть временная метка.
Потому что за час у меня набегает 8-10 к строк.
-
- Разработчик
- Сообщения: 11842
- Зарегистрирован: Ср окт 01, 2003 12:06 am
- Откуда: Роcсия, Тольятти
- Контактная информация:
Re: зависают чеки на DATECS FP-3530T
Но мне же надо читать весь лог. От начала и до ошибки. Чтобы понять, что там происходит. Начало лога обязательно, в половине случаев ответ там. Логгилку никто не учил работать с логами из десятков тысяч строк потому что пользы от таких гиганстких логов мало, врядли удастся понять, что там не так...
Попробуй вот это:
http://pxe.ru/files/testing/201504171946.zip
Может, получится лог на пол миллиона строк. Но тормозить будет...
Попробуй вот это:
http://pxe.ru/files/testing/201504171946.zip
Может, получится лог на пол миллиона строк. Но тормозить будет...
Re: зависают чеки на DATECS FP-3530T
Я вас понял. Есть шанс на то, что девушки меня наберут сразу при возникновении проблемы, и больше нескольких строк за это время не набежит. Другое дело, записать и начало и саму ошибку, думаю тут как раз http://pxe.ru/files/testing/201504171946.zip и пригодиться.
И еще мне этот лог показался хоть и длинным, но однотипным. Вот например запись конца сегодняшнего рабочего дня http://1drv.ms/1DS3idw правда влезло всего несколько минут.
И еще мне этот лог показался хоть и длинным, но однотипным. Вот например запись конца сегодняшнего рабочего дня http://1drv.ms/1DS3idw правда влезло всего несколько минут.
Последний раз редактировалось sfmc Сб апр 18, 2015 8:25 am, всего редактировалось 1 раз.
Re: зависают чеки на DATECS FP-3530T
Позвонил в аптеку, оказывается что в 20:39 и 20:41 чеки был аннулированы, после чего кассу перегрузили, так что в том логе что я прислал по идее должны быть ошибки, правда нету начала.
-
- Разработчик
- Сообщения: 11842
- Зарегистрирован: Ср окт 01, 2003 12:06 am
- Откуда: Роcсия, Тольятти
- Контактная информация:
Re: зависают чеки на DATECS FP-3530T
Что делать с этой ссылкой? В трёх браузерах открыл, кнопки скачать файл себе не нашёл.sfmc писал(а):Язапись конца сегодняшнего рабочего дня http://www.ex.ua/628400203438
Re: зависают чеки на DATECS FP-3530T
Не пойму что произошло, но вот еще раз. Перезалил в другое место и заменил не рабочую ссылку в предыдущем посте.
Там теперь еще и сегодняшний лог включения этого же терминала.
Там теперь еще и сегодняшний лог включения этого же терминала.
-
- Разработчик
- Сообщения: 11842
- Зарегистрирован: Ср окт 01, 2003 12:06 am
- Откуда: Роcсия, Тольятти
- Контактная информация:
Re: зависают чеки на DATECS FP-3530T
Я в этих логах не вижу ошибок. В них даже коды завершения все успешные, IoStatus у всех вызовов 0x00000000. Я не смогу это исправить без локализации ошибки, без указания места, где точно случилась ошибка.
Re: зависают чеки на DATECS FP-3530T
http://1drv.ms/1CZi2Cb
еще лог за сегодня, в 12:43:57 фискальный регистратор напечатал чек "чек анульовано" вот такого типа http://screencloud.net/v/53G0
часы в логе и на регистраторе синхронизированы не до секунды конечно, но за этим вроде бы следят.
еще лог за сегодня, в 12:43:57 фискальный регистратор напечатал чек "чек анульовано" вот такого типа http://screencloud.net/v/53G0
часы в логе и на регистраторе синхронизированы не до секунды конечно, но за этим вроде бы следят.
Re: зависают чеки на DATECS FP-3530T
часто логгер не работает:
19-22-21-682| Close connection with wtc.exe.
19-22-21-682| Send WTCU discover to 192.168.0.119.
19-22-21-682| Connection from wtc.exe at 192.168.0.119.
и так может висеть до упора.
Что бы оно соединилось, нужно ребутать терминал, либо энное количество раз перезапускать конфигуратор.
19-22-21-682| Close connection with wtc.exe.
19-22-21-682| Send WTCU discover to 192.168.0.119.
19-22-21-682| Connection from wtc.exe at 192.168.0.119.
и так может висеть до упора.
Что бы оно соединилось, нужно ребутать терминал, либо энное количество раз перезапускать конфигуратор.
Re: зависают чеки на DATECS FP-3530T
мне кажется происходит вот это:
12-41-45-308| [rdpdr-serial 0] rdpdr[]-main.cpp ( 104): IRP_MJ_DEVICE_CONTROL
12-41-45-323| [rdpdr-serial 0] rdpdr[serial]-worker.cpp ( 1583): IOCTL_SERIAL_PURGE
12-41-45-323| [rdpdr-serial 0] rdpdr[serial]-worker.cpp ( 1208): Flush both queues.
12-41-45-323| [rdpdr-serial 0] rdpdr[serial]-worker.cpp ( 1219): Purges all write requests.
12-41-45-323| [rdpdr-serial 0] rdpdr[serial]-worker.cpp ( 1232): Purges all read requests.
или это норма ?
12-41-45-308| [rdpdr-serial 0] rdpdr[]-main.cpp ( 104): IRP_MJ_DEVICE_CONTROL
12-41-45-323| [rdpdr-serial 0] rdpdr[serial]-worker.cpp ( 1583): IOCTL_SERIAL_PURGE
12-41-45-323| [rdpdr-serial 0] rdpdr[serial]-worker.cpp ( 1208): Flush both queues.
12-41-45-323| [rdpdr-serial 0] rdpdr[serial]-worker.cpp ( 1219): Purges all write requests.
12-41-45-323| [rdpdr-serial 0] rdpdr[serial]-worker.cpp ( 1232): Purges all read requests.
или это норма ?
Re: зависают чеки на DATECS FP-3530T
И вот снова в 1С висит сообщение "Фискальные регистратор не отвечает.Код ошибки 100"
а в логе последнее такие записи:
09-30-36-590| [rdpdr-serial 0] rdpdr[]-main.cpp ( 49): Set g_clientId to 1.
09-30-36-606| [rdpdr-serial 0] rdpdr[]-main.cpp ( 77): Recv from RDP: DeviceId 1 FileId 1 CompletionId 2 MajorFunction 0xe MinorFunction 0x0, 32 bytes in stream.
09-30-36-606| [rdpdr-serial 0] rdpdr[]-main.cpp ( 104): IRP_MJ_DEVICE_CONTROL
09-30-36-622| [rdpdr-serial 0] rdpdr[serial]-worker.cpp ( 1607): IOCTL_SERIAL_WAIT_ON_MASK
09-30-36-622| [rdpdr-serial 0] rdpdr[serial]-worker.cpp ( 1339): Wait on mask (mask 0x00000001, CompletionId 2).
09-30-36-637| [rdpdr-serial 0] rdpdr[]-main.cpp ( 49): Set g_clientId to 1.
09-30-36-653| [rdpdr-serial 0] rdpdr[]-main.cpp ( 77): Recv from RDP: DeviceId 1 FileId 1 CompletionId 1 MajorFunction 0xe MinorFunction 0x0, 36 bytes in stream.
09-30-36-653| [rdpdr-serial 0] rdpdr[]-main.cpp ( 104): IRP_MJ_DEVICE_CONTROL
09-30-36-668| [rdpdr-serial 0] rdpdr[serial]-worker.cpp ( 1583): IOCTL_SERIAL_PURGE
09-30-36-668| [rdpdr-serial 0] rdpdr[serial]-worker.cpp ( 1208): Flush both queues.
09-30-36-684| [rdpdr-serial 0] rdpdr[serial]-worker.cpp ( 1219): Purges all write requests.
09-30-36-684| [rdpdr-serial 0] rdpdr[serial]-worker.cpp ( 1232): Purges all read requests.
09-30-36-684| [rdpdr-serial 0] rdpdr[]-main.cpp ( 305): IRP Completion: Device 1, CompletionId 1, IoStatus 0x00000000, result 0, 0 bytes of data.
пересмотрел несколько логов и вижу что эти строки везде идентичны.
а в логе последнее такие записи:
09-30-36-590| [rdpdr-serial 0] rdpdr[]-main.cpp ( 49): Set g_clientId to 1.
09-30-36-606| [rdpdr-serial 0] rdpdr[]-main.cpp ( 77): Recv from RDP: DeviceId 1 FileId 1 CompletionId 2 MajorFunction 0xe MinorFunction 0x0, 32 bytes in stream.
09-30-36-606| [rdpdr-serial 0] rdpdr[]-main.cpp ( 104): IRP_MJ_DEVICE_CONTROL
09-30-36-622| [rdpdr-serial 0] rdpdr[serial]-worker.cpp ( 1607): IOCTL_SERIAL_WAIT_ON_MASK
09-30-36-622| [rdpdr-serial 0] rdpdr[serial]-worker.cpp ( 1339): Wait on mask (mask 0x00000001, CompletionId 2).
09-30-36-637| [rdpdr-serial 0] rdpdr[]-main.cpp ( 49): Set g_clientId to 1.
09-30-36-653| [rdpdr-serial 0] rdpdr[]-main.cpp ( 77): Recv from RDP: DeviceId 1 FileId 1 CompletionId 1 MajorFunction 0xe MinorFunction 0x0, 36 bytes in stream.
09-30-36-653| [rdpdr-serial 0] rdpdr[]-main.cpp ( 104): IRP_MJ_DEVICE_CONTROL
09-30-36-668| [rdpdr-serial 0] rdpdr[serial]-worker.cpp ( 1583): IOCTL_SERIAL_PURGE
09-30-36-668| [rdpdr-serial 0] rdpdr[serial]-worker.cpp ( 1208): Flush both queues.
09-30-36-684| [rdpdr-serial 0] rdpdr[serial]-worker.cpp ( 1219): Purges all write requests.
09-30-36-684| [rdpdr-serial 0] rdpdr[serial]-worker.cpp ( 1232): Purges all read requests.
09-30-36-684| [rdpdr-serial 0] rdpdr[]-main.cpp ( 305): IRP Completion: Device 1, CompletionId 1, IoStatus 0x00000000, result 0, 0 bytes of data.
пересмотрел несколько логов и вижу что эти строки везде идентичны.
-
- Разработчик
- Сообщения: 11842
- Зарегистрирован: Ср окт 01, 2003 12:06 am
- Откуда: Роcсия, Тольятти
- Контактная информация:
Re: зависают чеки на DATECS FP-3530T
MSDN говорит:
Когда следом за IOCTL_SERIAL_PURGE приходит IRP_MJ_CLOSE, и сразу после этого закрывается RDP сеанс, это выглядит вполне логично. Очистили очереди, закрыли порт, завершили работу. Но когда эта команда приходит посреди обмена данными с железкой, это действительно странно. Все команды приходят от сервера, втварь только выполняет, сама втварь не сочиняет команды. Если хочешь, я могу собрать сборку, в которой purge ничего делать не будет, посмотрим что изменится. Но мне кажется, purge не причина, а следствие проблемы, управляющая железкой программа обнаружила выход за таймауты/неверный ответ железки/плохую фазу луны и сбрасывает железку, очищает очереди, чтобы не стало хуже.
Очищает очереди чтения из порта и записи в порт. Прослеживается закономерность между зависаниями чеков и purge в логе?The IOCTL_SERIAL_PURGE request cancels the specified requests and deletes data from the specified buffers. The purge request can be used to cancel all read requests and write requests and to delete all data from the receive buffer and the transmit buffer.
Когда следом за IOCTL_SERIAL_PURGE приходит IRP_MJ_CLOSE, и сразу после этого закрывается RDP сеанс, это выглядит вполне логично. Очистили очереди, закрыли порт, завершили работу. Но когда эта команда приходит посреди обмена данными с железкой, это действительно странно. Все команды приходят от сервера, втварь только выполняет, сама втварь не сочиняет команды. Если хочешь, я могу собрать сборку, в которой purge ничего делать не будет, посмотрим что изменится. Но мне кажется, purge не причина, а следствие проблемы, управляющая железкой программа обнаружила выход за таймауты/неверный ответ железки/плохую фазу луны и сбрасывает железку, очищает очереди, чтобы не стало хуже.
-
- Разработчик
- Сообщения: 11842
- Зарегистрирован: Ср окт 01, 2003 12:06 am
- Откуда: Роcсия, Тольятти
- Контактная информация:
Re: зависают чеки на DATECS FP-3530T
Читаю лог WTware_AC.F1.DF.40.6A.EB_2015-04-18_16-02-26.txt
12-41-18-148 закончилось чтение, один байт прочитало.
Затем 20 секунд паузы.
12-41-41-610 думаю, начался новый блок обмена. IOCTL_SERIAL_GET_COMMSTATUS - программа (та, что работает на виндовсе и управляет железкой) спрашивает у порта, как дела. Затем IRP_MJ_WRITE - программа пишет в порт, в следующей строке указано, сколько байт пишет.
Чтение из порта в программе организовано грамотно. Делается IOCTL_SERIAL_WAIT_ON_MASK с маской 0x00000001, это SERIAL_EV_RXCHAR. Затем втварь отвечает, что событие, которого программа ждёт, случилось. Программа делает IOCTL_SERIAL_GET_COMMSTATUS, втварь ей отвечает, сколько байт можно прочитать прямо сейчас. И только после этого программа читает. Если программа умная, может стоит с разработчиками связаться? Вдруг у них тоже логи есть.
IRP_MJ_WRITE на 10 байт случился в 12-41-41-642.
IOCTL_SERIAL_WAIT_ON_MASK, то есть начало чтения ответа, началось в 12-41-41-657. И сразу же ответило, что байтики у железки есть, готовы принимать. Это текст "Wait On Mask completion", значит втварь отвечает виндовсу, что ожидание закончено, байтики можно читать.
И затем следующий IRP_MJ_WRITE на 30 байт в 12-41-41-876.
IOCTL_SERIAL_WAIT_ON_MASK в 12-41-41-907, опять байтики сразу в порту готовы.
IRP_MJ_WRITE на 26 байт в 12-41-42-219, и опять железка отвечает немедленно.
А вот последний IOCTL_SERIAL_WAIT_ON_MASK в 12-41-43-155 не ответил "Wait On Mask completion". Оно так устроено, если байтиков в порту нет, то WAIT_ON_MASK ничего не отвечает, пока байтики в порту не появятся. Или пока управляющая программа не прервёт ожидание через IOCTL_SERIAL_PURGE.
Байтики в порту так и не появились, и через две секунды управляющая программа отправила IOCTL_SERIAL_PURGE. Вроде вполне логично.
12-41-18-148 закончилось чтение, один байт прочитало.
Затем 20 секунд паузы.
12-41-41-610 думаю, начался новый блок обмена. IOCTL_SERIAL_GET_COMMSTATUS - программа (та, что работает на виндовсе и управляет железкой) спрашивает у порта, как дела. Затем IRP_MJ_WRITE - программа пишет в порт, в следующей строке указано, сколько байт пишет.
Чтение из порта в программе организовано грамотно. Делается IOCTL_SERIAL_WAIT_ON_MASK с маской 0x00000001, это SERIAL_EV_RXCHAR. Затем втварь отвечает, что событие, которого программа ждёт, случилось. Программа делает IOCTL_SERIAL_GET_COMMSTATUS, втварь ей отвечает, сколько байт можно прочитать прямо сейчас. И только после этого программа читает. Если программа умная, может стоит с разработчиками связаться? Вдруг у них тоже логи есть.
IRP_MJ_WRITE на 10 байт случился в 12-41-41-642.
IOCTL_SERIAL_WAIT_ON_MASK, то есть начало чтения ответа, началось в 12-41-41-657. И сразу же ответило, что байтики у железки есть, готовы принимать. Это текст "Wait On Mask completion", значит втварь отвечает виндовсу, что ожидание закончено, байтики можно читать.
И затем следующий IRP_MJ_WRITE на 30 байт в 12-41-41-876.
IOCTL_SERIAL_WAIT_ON_MASK в 12-41-41-907, опять байтики сразу в порту готовы.
IRP_MJ_WRITE на 26 байт в 12-41-42-219, и опять железка отвечает немедленно.
А вот последний IOCTL_SERIAL_WAIT_ON_MASK в 12-41-43-155 не ответил "Wait On Mask completion". Оно так устроено, если байтиков в порту нет, то WAIT_ON_MASK ничего не отвечает, пока байтики в порту не появятся. Или пока управляющая программа не прервёт ожидание через IOCTL_SERIAL_PURGE.
Байтики в порту так и не появились, и через две секунды управляющая программа отправила IOCTL_SERIAL_PURGE. Вроде вполне логично.
-
- Разработчик
- Сообщения: 11842
- Зарегистрирован: Ср окт 01, 2003 12:06 am
- Откуда: Роcсия, Тольятти
- Контактная информация:
Re: зависают чеки на DATECS FP-3530T
А вот следующего случая я не понимаю. IRP_MJ_WRITE в 12-44-07-003, 18 байт записано. Затем начинается чтение: IOCTL_SERIAL_WAIT_ON_MASK, IOCTL_SERIAL_GET_COMMSTATUS, IRP_MJ_READ на один байт, и так по кругу, каждый раз читая по одному байту, до тех пор пока в 12-44-08-141 (т.е. секунда с небольшим) втварь на IOCTL_SERIAL_GET_COMMSTATUS не ответила "31 bytes in IN queue". Думаю, один байт ответа это статус "я печатаю", а 31 байт - какое-то развёрнутое сообщение. Затем программа читает эти 31 байт, и затем идёт IOCTL_SERIAL_PURGE, типа сброс.
Мне вот эти 31 байт не нравится. В логе WTware_AC.F1.DF.40.6A.EB_2015-04-17_20-47-25.txt тоже перед IOCTL_SERIAL_PURGE железка отвечает 31 байт. Жалко я распечатку содержимого пакетов не включил, может там текстом строка ошибки написана. В логах два раза повторяется сценарий "много ответов железки по одному байту, затем железка отвечает 31 байт, и затем программа делает PURGE".
Можешь заменить втварь на виндовс с mstsc.exe? Чтобы всё в точности то же: тот же сервер, то же помещение, тот же канал связи с сервером с теми же задержками, та же железка, тот же логин на сервер, абсолютно всё то же, только mstsc.exe? А то может мы зря роем.
Мне вот эти 31 байт не нравится. В логе WTware_AC.F1.DF.40.6A.EB_2015-04-17_20-47-25.txt тоже перед IOCTL_SERIAL_PURGE железка отвечает 31 байт. Жалко я распечатку содержимого пакетов не включил, может там текстом строка ошибки написана. В логах два раза повторяется сценарий "много ответов железки по одному байту, затем железка отвечает 31 байт, и затем программа делает PURGE".
Можешь заменить втварь на виндовс с mstsc.exe? Чтобы всё в точности то же: тот же сервер, то же помещение, тот же канал связи с сервером с теми же задержками, та же железка, тот же логин на сервер, абсолютно всё то же, только mstsc.exe? А то может мы зря роем.
-
- Разработчик
- Сообщения: 11842
- Зарегистрирован: Ср окт 01, 2003 12:06 am
- Откуда: Роcсия, Тольятти
- Контактная информация:
Re: зависают чеки на DATECS FP-3530T
Попробуй вот это:
http://pxe.ru/files/testing/201504212145.zip
Убрал из логов пару неинтересных строк, добавил дампы байтов, которые пересылаются через порт. Логи давай почтой на aka@pxe.ru, мало ли там какая-то частная информация будет.
http://pxe.ru/files/testing/201504212145.zip
Убрал из логов пару неинтересных строк, добавил дампы байтов, которые пересылаются через порт. Логи давай почтой на aka@pxe.ru, мало ли там какая-то частная информация будет.
Re: зависают чеки на DATECS FP-3530T
Как по мне, да - закономерность прослеживается.aka писал(а): Очищает очереди чтения из порта и записи в порт. Прослеживается закономерность между зависаниями чеков и purge в логе?
Вчера сохранил несколько фрагментов лога,
открытие управляющей программы http://1drv.ms/1OEQYik,
и её завершение http://1drv.ms/1OEQMQ9.
Так же получилось словить лог, с пуржами во время ошибок в управляющей программе, в котором я выделил открытие 1С, закрытие 1С и сами пуржи. http://1drv.ms/1OdlEw8
+лог OLE драйвера при помощи которого управляющая программа общается с железкой http://1drv.ms/1JsTWop
Сегодня поставлю http://pxe.ru/files/testing/201504212145.zip посмотрим что там шлется.
-
- Разработчик
- Сообщения: 11842
- Зарегистрирован: Ср окт 01, 2003 12:06 am
- Откуда: Роcсия, Тольятти
- Контактная информация:
Re: зависают чеки на DATECS FP-3530T
В логе http://1drv.ms/1OdlEw8 файл WTware_AC.F1.DF.40.6A.EC_2015-04-21_16-22-14.txt - там же регистратор действительно не отвечает.
16-17-48-163 в регистратор записывается 16 байт. В логе OLE драйвера это "Печать Х,Z отчетов". Затем регистратор читают, он отдаёт по одному байту. Я думаю, этот байт означает "подождите, я занят". В последних логах, которые с распечаткой пересылаемых байтиков, есть такие же периоды, когда регистратор шлёт по одному байту со значением 16 несколько раз подряд, а OLE драйвер ждёт. И затем регистратор присылает более длинную посылку, драйвер проглатывает и не делает purge.
Но в этом логе ничего проме однобайтовых четыре секунды не приходит. Через четыре секунды OLE драйвер решает прекратить ждать, делает purge. Плохо представляю, в чём здесь может быть виновата втварь.
Затем после пуржа в 16-18-42-950 опять в регистратор записывается 17 байт, "Удаление артикула" в логе OLE драйвера. Читается аж целых 211 байт, затем 8 байт, ещё раз 8 байт, ещё два байта. Затем три секунды регистратор ничего не отдаёт, втварь слушает порт, но данных в порту нет. И в 16-18-46-226 OLE драйвер ругается в лог и делает purge.
Вот на этой операции проблема стабильно воспроизводится? Здесь два зависания за минуту, очень удобно рыть. Надо подключить регистратор к машине с виндовсом. Запустить mstsc.exe. Зайдя на тот же сервер тем же юзером. И повторить эту операцию раз десять.
Если проблема повторится на mstsc.exe - не надо мучать втварь, мы не сможем перенаправлять порт лучше mstsc. Надо пинать авторов OLE драйвера. И их не надо пугать словом "втварь", им надо показать проблему на mstsc.exe.
Если на mstsc.exe проблема не повторится - я покажу, где взять следующую логгилку, которая на виндовсе запишет все операции с физическим портом. Эту логгилку надо будет поставить на виндовс с mstsc.exe, к которой подключен регистратор. И сравнивать байтики, которые пишет в физический порт втварь, и которые пишет в порт mstsc. Возможно, откопается какое-то преобразование потока, которое надо делать.
16-17-48-163 в регистратор записывается 16 байт. В логе OLE драйвера это "Печать Х,Z отчетов". Затем регистратор читают, он отдаёт по одному байту. Я думаю, этот байт означает "подождите, я занят". В последних логах, которые с распечаткой пересылаемых байтиков, есть такие же периоды, когда регистратор шлёт по одному байту со значением 16 несколько раз подряд, а OLE драйвер ждёт. И затем регистратор присылает более длинную посылку, драйвер проглатывает и не делает purge.
Но в этом логе ничего проме однобайтовых четыре секунды не приходит. Через четыре секунды OLE драйвер решает прекратить ждать, делает purge. Плохо представляю, в чём здесь может быть виновата втварь.
Затем после пуржа в 16-18-42-950 опять в регистратор записывается 17 байт, "Удаление артикула" в логе OLE драйвера. Читается аж целых 211 байт, затем 8 байт, ещё раз 8 байт, ещё два байта. Затем три секунды регистратор ничего не отдаёт, втварь слушает порт, но данных в порту нет. И в 16-18-46-226 OLE драйвер ругается в лог и делает purge.
Вот на этой операции проблема стабильно воспроизводится? Здесь два зависания за минуту, очень удобно рыть. Надо подключить регистратор к машине с виндовсом. Запустить mstsc.exe. Зайдя на тот же сервер тем же юзером. И повторить эту операцию раз десять.
Если проблема повторится на mstsc.exe - не надо мучать втварь, мы не сможем перенаправлять порт лучше mstsc. Надо пинать авторов OLE драйвера. И их не надо пугать словом "втварь", им надо показать проблему на mstsc.exe.
Если на mstsc.exe проблема не повторится - я покажу, где взять следующую логгилку, которая на виндовсе запишет все операции с физическим портом. Эту логгилку надо будет поставить на виндовс с mstsc.exe, к которой подключен регистратор. И сравнивать байтики, которые пишет в физический порт втварь, и которые пишет в порт mstsc. Возможно, откопается какое-то преобразование потока, которое надо делать.
-
- Разработчик
- Сообщения: 11842
- Зарегистрирован: Ср окт 01, 2003 12:06 am
- Откуда: Роcсия, Тольятти
- Контактная информация:
Re: зависают чеки на DATECS FP-3530T
Лог в kassa2.
22.04.2015/17:58:59 Исходящая очередь: $X800;9
Символы 00;9 есть и в логе втвари, в самом конце. 10 байт пишется в порт. Затем из порта читается байт со значением 16, предположительно "я занят". И затем длинная посылка из 32 байт. Первый байт - те же 16, "я занят". Затем 31 байт, начинается на байт со значением 1. Все посылки регистратору и от регистратора начинаются на байт со значением 01 и заканчиваются байтом со значением 03. Вроде вполне нормально выглядит, регистратор ответил, втварь переслала, но почему-то эта посылка не появилась в логе OLE драйвера.
В логе kassa3 перед первым purge такая же фигня: дежурный байт 16 "я занят" объединился с посылкой. Хорошие посылки начинаются на 01 и заканчиваются на 03, а здесь получилось, что драйверу одной посылкой отправилось 16 и затем 01 ... полезные байтики ... 03. Драйвер OLE этого не понимает и игнорирует посылку.
Свяжись с авторами OLE драйвера, покажи им этот текст. Возможно, в каких-то случаях драйвер забывает разделить служебный байт 16 и саму посылку. Втварь не виновата, втварь ничего не может сделать, тот же эффект должен быть и на mstsc.exe. Байты из COM порта читаются потоком и могут быть произвольным образом объединены.
А вот если запускать 1С и драйвер локально, безо всяких терминалов, и регистратор к той же машине подключать, то такого эффекта, с объединением байта 16 и собственно ответа, не получится. На локальной машине байты от железки к программе доходят намного быстрее, чем они идут по сети от терминала на сервер. Чтобы такой эффект стабильно увидеть, надо перенаправлять железку через mstsc.exe, и подключаться через медленный канал, чем канал медленнее, чем чаще эффект объединения посылок будет проявляться.
22.04.2015/17:58:59 Исходящая очередь: $X800;9
Символы 00;9 есть и в логе втвари, в самом конце. 10 байт пишется в порт. Затем из порта читается байт со значением 16, предположительно "я занят". И затем длинная посылка из 32 байт. Первый байт - те же 16, "я занят". Затем 31 байт, начинается на байт со значением 1. Все посылки регистратору и от регистратора начинаются на байт со значением 01 и заканчиваются байтом со значением 03. Вроде вполне нормально выглядит, регистратор ответил, втварь переслала, но почему-то эта посылка не появилась в логе OLE драйвера.
В логе kassa3 перед первым purge такая же фигня: дежурный байт 16 "я занят" объединился с посылкой. Хорошие посылки начинаются на 01 и заканчиваются на 03, а здесь получилось, что драйверу одной посылкой отправилось 16 и затем 01 ... полезные байтики ... 03. Драйвер OLE этого не понимает и игнорирует посылку.
Свяжись с авторами OLE драйвера, покажи им этот текст. Возможно, в каких-то случаях драйвер забывает разделить служебный байт 16 и саму посылку. Втварь не виновата, втварь ничего не может сделать, тот же эффект должен быть и на mstsc.exe. Байты из COM порта читаются потоком и могут быть произвольным образом объединены.
А вот если запускать 1С и драйвер локально, безо всяких терминалов, и регистратор к той же машине подключать, то такого эффекта, с объединением байта 16 и собственно ответа, не получится. На локальной машине байты от железки к программе доходят намного быстрее, чем они идут по сети от терминала на сервер. Чтобы такой эффект стабильно увидеть, надо перенаправлять железку через mstsc.exe, и подключаться через медленный канал, чем канал медленнее, чем чаще эффект объединения посылок будет проявляться.
Re: зависают чеки на DATECS FP-3530T
В место блокнота я использую notepad++ и в нем этот байт отображается как "SYN" - http://1drv.ms/1DsEaVXaka писал(а):Затем регистратор читают, он отдаёт по одному байту. Я думаю, этот байт означает "подождите, я занят". В последних логах, которые с распечаткой пересылаемых байтиков, есть такие же периоды, когда регистратор шлёт по одному байту со значением 16 несколько раз подряд, а OLE драйвер ждёт.
Если речь идет о "F:DelArticle(0000,0) Удаление артикула", то в логе драйвера я больше не видел ошибок после этой функции.aka писал(а): Вот на этой операции проблема стабильно воспроизводится?
Давайте программку, буду пробовать и такой вариант.aka писал(а): Если на mstsc.exe проблема не повторится - я покажу, где взять следующую логгилку, которая на виндовсе запишет все операции с физическим портом.
Глядя разные логи, вижу что это утверждение справедливо только для IRP_MJ_WRITE , но не для IRP_MJ_READ - http://1drv.ms/1b6bXO1aka писал(а): Все посылки регистратору и от регистратора начинаются на байт со значением 01 и заканчиваются байтом со значением 03.
Еще заметил что PURGE, всегда после посылки IRP_MJ_READ, начинающейся на 00000000:1601 и заканчивающиеся на 03. Размер посылки может быть разный, но начало и конец всегда одинаковы. Остальные посылки проходят без проблем, даже если вначале 00000000:16.