Программная перезагрузка COM порта

[who i]

Есть кассовый аппарат, подключаемый к ПК посредством порта. Кассиры как-то умудряются загнать аппарат(или порт) до такой степени, что ответа от порта не дождешься.Суть вопроса: каким макаром можно перегрузить драйвер(вкл выкл) порта средствами делфи не из диспетчера устройств, или в какую сторону хотя бы копать?

[Stilet]

Выкл/вкл аппарат.
А вообще нужно знать что за прога у кассира, и как она с кассой работает. Чаще всего такие программы пишут рукозадые создавазды, поэтому спасти может только диспетчер задач.
ИМХО ты бы лучше узнал как именно операторы доводят кассу до такого состояния. Вот это будет полезнее.

[who i]

Сообщение от Stilet

Выкл/вкл аппарат.
А вообще нужно знать что за прога у кассира, и как она с кассой работает. Чаще всего такие программы пишут рукозадые создавазды, поэтому спасти может только диспетчер задач.
ИМХО ты бы лучше узнал как именно операторы доводят кассу до такого состояния. Вот это будет полезнее.

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

[Stilet]

и даже hardreset аппарата не спасает.

А вот это уже форменная глупость. Мне конечно по барабану как вы там с аппаратурой обращаетесь, но все же скажу: Так не делай.

Прога у кассира я знаю какая, я же ее и писал.

Ну тогда извини: Ты индокодер. Если твоя программа держит СОМ всегда открытым, в то время, как рекомендуется его закрывать после проведения платежа, или хотя бы реагировать на ответы кассы, то это конктретно твои недоработки, и выброс из диспетчера или принудительная разлочка порта в то время как "уже все случилось" тебя никак не спасет. Я как раз работаю с кассовыми аппаратами, и очень хорошо знаю, как не нужно писать под них программы.

Какие операторы уловить сложно

Вывод: Логи ты не ведешь. Еще один минус в карму. А вот стоит логировать каждое обращение к аппарату.

обычно, это происходит когда полно клиентов и касса работает не отключаясь

Это не оправдание. Есть туча причин, по которой касса лочится. Например затор бумаги (если не термуха), или ошибка передачи платежей в ГНИ по интернету. А вообще у тебя с кассой должна быть книжеца со списком возможных ошибок. Рекомендую ее проработать как можно тщательнее.

потому как утилитой которая была приложена к девайсу я смог загнать порт(или аппарат) в ступор.. а вкл/выкл порта спасает

Это еще одно оправдание )
Ты попросту себе льстишь. Ладно, может хамлю, если сильно - извиняюсь.
Скажу просто как делаю я: Достаю одну из списанных касс. Подключаю. Гоняю. Описываю в программе почти каждый случай возможной ошибки. Обязательно выясняю, как повлияет разрыв соединения после каждого платежа (а точнее платежи собираю в пакет, провожу по кассе, логирую, потом закрываю СОМ).
Логирование обязательно. И обязательно если что-то произошло спрашиваю у оператора что именно. Бывает что СОМ блочится со стороны компа.

В обшем учитывая все что ты рассказал - двойка тебе. Я уж 4 года с такими программистами ругаюсь.

[who i]

Сообщение от Stilet

А вот это уже форменная глупость. Так не делай.

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

Сообщение от Stilet

Если твоя программа держит СОМ всегда открытым, в то время ...

максимальный тайм аут сессии - 5 минут после чего закрывается принудительно (это на случай непонятно чего), а так закрывается после каждой выполненной(невыполненной) операции

Сообщение от Stilet

Вывод: Логи ты не ведешь. Еще один минус в карму. А вот стоит логировать каждое обращение к аппарату.

Согласен, было бы замечательно вести логи, но обстоятельства сложились так как сложились.

[Stilet]

в саппорт где мне и посоветовали делать хардресет

Ну саппорт тебя подставляет...

было бы замечательно вести логи, но обстоятельства сложились так как сложились.

А что мешает повлиять на обстоятельства, выпустив патч своей проги?

Т.е. я правильно понимаю - у тебя есть транзакция, которая на момент проведения просто стопорится. Ты не в курсе как при этом ведет себя касса, не выяснял, не подключался по удаленке, не спрашивал что на индикаторе и т.д., но хочешь полюбому транзакцию вышибить?
Тогда возникает резонный вопрос: Если транзакция уже зафиксировалась в базе, но не зафиксировалася в кассе - у тебя дневной отчет рвется. Как-то я не оч. понимаю, как ты такие обрывы оправдывать будешь перед контролерами?
Кассир не обязан писать отчет о расхождении кассы (скажем Z-ки), раз глючной признана ПО. Согласись, это не его головная боль.
Соответственно опять приходим к выводу: При проявлении стопора аппарата нужно чтоб кассир рассказал, что именно произошло. Повторюсь - затор механизма, обрыв связи, антивирус... Это кляузная область, тут деньга крутится и недовольные обслуживанием клиенты могут поднять серьезную бучу, и будут правы. Так почему же ты не желаешь выяснить причины таких сбоев, вместо этого пытаясь устранить последствия, которые могут аукнутся потом в отчетах? Пусть не дневных, но периодических точно аукнутся. Нельзя такие вещи дергать программным путем, их нужно упреждать.
Мне лично пока не очень понятно почему "обстоятельства сложились так как сложились"...