VK_RS232 Ромикс отзовись #414189

2 Проблеммы с компонентой 1. Самая главная проблемма - возникает зависание при мапинге ком-порта на терминал. Имеем сканер Metrologic 5145 Eclipse с эмуляцией com через USB. Регулярно зависает терминальный сеанс при попытки открыть или закрыть порт. Зависает наглухо причем проблема проявляется не на всех компьютерах. При этом может 2 дня нормально отработать потом глюк. Перустановка винды, драйверов сканера, изменения версии терминального клиента ничего не дает. Проблемы с локальной сетью исключены. Лечится установкой другого компа либо перезапуском 1С в терминальном сеансе.  Такое подозрение, что глючит именно связка компонента+мапинг порта на терминал. 2.Также возникает проблемма такого порядка: 1)Открываем несуществующий порт, например COM10 - компонента честно нас предупреждает о том что не удается найти указанный файл. Вроде все логично порта нет в системе. 2)Закрываем COM10 компонента опять говорит что порт не был открыт тоже верно. 3)Открываем реальный живой порт COM2 и невероятное! Компонента говорит что порт уже инициализирован. Хотя это не так. лечится перезапуском компоненты. Помогите разобраться. Спасибо.

Вот еще нарыл похожая проблемма:

upp

Исходники же есть...

Не может он при закрытии порта говорить, что порт не был открыт. Нет там такого.

что значит нет такого? Готов привести скрины

Давай

У меня сейчас не на чем тестить к сож. поэтому я могу по аське списаться завтра на предмет изменений. Если проглючивания неизвестного происхождения (например дрова чудят), то может быть закрывать и открывать порт по каждому считыванию, хотя это конечно не аккуратно. Еще можно попробовать штатную scanopos.dll - как будет с ней.

вот код: ----------

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

как версия ощущение что глюк возникает из-за того, что при открытии порта сразу же валится пустой символ или что то в этом роде ,компонента сразу же переходит в режим приема данных и ждет символа конца строки, однако данные не поступают и поэтому поток висит тем самым вешает 1С. Этим объясняется почему 1С вдруг при сканировании вдруг оживает.

up

Было такое

При сворачивании, разворачивании окна терминала - посылается 0-код с клавы

Счаст проапгрэйдю либу

Пока попробуй при рабочей компоненте свернуть/развернуть окно терминала

а что ты там изменил?

Вот так всегда. Постоянно клювами стучат, апают, а стоит начать заниматься - поднимаются на крыло.

Прям как чуствовал :-) Ты с окном терминала попробовал поиграца?

Пропускаю отлов нулевого символа с клавы.

Опять убёг

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

1.Попробывал принудительно убивать поток:          if g_isOpen=False then            Raise Exception.Create('Порт не был открыт');      end; эфекта не дало 2.В модуле uComPort функция  T_ComPort.ReadString вставка на поиск нулевого символа if pos(#0, ReadBuffer)>0 then begin эффекта не дало У меня подозрение что проблемма возникает в разделе T_ComPort.ReadString т.е. чтото в буфер приходит и это что то без кода конца строки, именно изза этого управление не возвращается в 1С но на разных компах видимо разные версии какихто виндовых библиотек поэтому гдето процесс втихую грохается а гдето по непонятным мне причинам ожидается завершение процесса а он не завершается т.к. конец сторки не поступил и имеем сабж. Какие есть еще идеи?

Попробуй

Вообще прошелся по коду - ну нет там ничего заковыристого, где бы проблемы были бы.. Единственное:

Увеличь буфер и число символов на чтение: var Buff: Array[1..10000] of char;    nil  );

А вообще, отладчик Delphi в зубы (чегой-то я перегрелся). И все ясно станет.

все варианты с ромиксом перебрали, процесс не гасится. Путем отладки выяснили что ReadFile не просакивает а ожидает завршения приема, именно поэтому зависание. Как устранить не понятно. Да проблемма воспроизводится и в терминале и локально на проблеммных машинах. Пока грешим на драйвера хотя хз

а если размер буфера ограничить?

ЗЫ исходников не видел

гипертерминал и pvrscan ( работают на проблеммных машинах как ни в чем не бывало. Видимо всетаки есть альтернатива методу ReadFile для работы с COM

я вот не могу понять... где вы ухитряетесь такие проблемы найти. ни разу сканера (тем более метроложэики) не глючили. порты мапячтся прекрасно главное правильно сервер настроить. безх всяких вк и открытия портов с родными атоловскими дровами... кроме сканеров имел дело с весами иЭККА в терминале. никаких проблем. везло?

за всё время была проблема один раз. сканер блу-туз (радио) который эмулировал порт и таких сканеров было два на двух тачках. нюанс был в том что блутуз обоих эмулировал один и тот же порт. но маленькая хитрость с приминением головы решила проблему. полёт прекрасный уже пол-года без проблем

претензий к сканеру нет он работает нормально, проблемма в компоненте, а точнее в её механизме связи с драйвером, это механизм очевидно не все нюансы работы порта учитывает. А тебе просто везло, пока везло.

проблемма в методологии постройки приема данных, согласно статье: существует 2 метода синхронный и асинхронный. Наиболее полным является асинхронный, в компоненте задействован синхронный, а он не учитывает некоторые особенности драйвера поэтому и происходит зависание. Вот выдержка из статьи: ------------------------ ... Перечислю основные "аксиомы". Работа с портом только в асинхронном режиме, дабы не "подвисать" из-за особенностей конкретного устройства "висящего" на СОМ-порту; Открытие порта с нужными настройками осуществляется сразу по старту программы, дабы не попасть в ситуацию "нужен порт, а его какая-то сволочь забрала под себя". Если возможность выбора порта и его настроек заложена в интерфейсе пользователя, то вначале выполняется закрытие порта, а затем открытие его с пользовательскими настройками (естественно с проверкой успешности операции); Закрытие порта — перед закрытием приложения; Запись информации в порт осуществляется только в основном потоке. Возможен вариант записи в порт в дочернем потоке в случае, когда одна транзакция обмена состоит из нескольких фаз по жесткому алгоритму, но первая фаза записи — все равно должна быть в основном потоке; Обработка всех эвентов от порта и, связанные с этим, действия выполняются в дочернем потоке (чтение принятых байт, запрос состояния модемных линий и т.п.). Передача информации, полученной в дочернем потоке, основному потоку только посредством PostMessage; Анализ текущей транзакции обмена с устройством проводится в основном потоке, и только по принципу — "передал, взвел таймер", "принял, опустил таймер, проанализировал полученные данные". ...