Главная категория > Посцентр (ШТРИХ-М)

Предложения по прошивкам онлайн-касс Штрих-М

<< < (21/22) > >>

chester198:
Очень хотелось бы увидеть программное отключение датчика крышки. Очень актуально для РР-03 и лайтов.

kkmspb:
У меня предложение
1.  Отказаться от  использования типа VT_CY в драйвере и просто использовать VT_INT8. Как следствие вы получите нормальную  (без костыльную) интеграцию с программами написанными на С++.
Например скажите, что суммы посылаются в виде целого числа, где последние 4  десятичные знака это копейки. Мне кажется никому не придется потом переделывать работающий софт, все должно продолжить работать корректно.

2. Реализуете посылку команд через  json пакет. Хотя бы пробитие чека.

Slava:

--- Цитата: kkmspb от 30/03/2025 15:41:16 ---У меня предложение
1.  Отказаться от  использования типа VT_CY в драйвере и просто использовать VT_INT8. Как следствие вы получите нормальную  (без костыльную) интеграцию с программами написанными на С++.
Например скажите, что суммы посылаются в виде целого числа, где последние 4  десятичные знака это копейки. Мне кажется никому не придется потом переделывать работающий софт, все должно продолжить работать корректно.

2. Реализуете посылку команд через  json пакет. Хотя бы пробитие чека.





--- Конец цитаты ---


Так прошива вроде на нижнем протоколе работает - тупо команда ответ .
Это всё жутко интересно , но вот когда Вы разберетё нижний  уровень Атола на П5 это будет бомба .
Это реально крутая тема .

Klaus1900:
Раз уж касса все равно обязана смотреть в инет, сделайте автообновление актуальной лицензии.

dfdf:
Исправить, наконец, два старых бага:
1. Если в ФР был включён DHCP, а потом в табл. 16 выключили и прописали статику, то ОЧЕНЬ часто нужно ВКЛ./ВЫКЛ. аппарата (ну или reboot через тест драйвера/программно), чтобы это заработало. В обратную сторону (статика->DHCP) аналогично.
2. Периодически прилетает ошибка (-1) "нет связи" без всякой закономерности. В логах драйвера, если включить, есть сообщение о проблеме (к сожалению, сейчас не вспомню, что именно - включу в одной из точек - посмотрю - допишу), и по логу видно, что драйвер просто должен повторить команду (т.к. у него это настроено), но нет.
3. У разработчиков драйвера, судя по всему, нет одного важного знания о том, как ведёт себя Windows при "выдёргивании" открытого COM-порта. Я это знание почерпнул из исходников  W2K3/WXP (есть на просторах интернета). Проблема старая, наблюдается и под 10й тоже (на 11й пока не смотрел).
Суть проблемы: у нас есть USB-COM, открываем этот порт, даём команду (программно) на ребут ФР. Поскольку ФР уходит на ребут, Windows удаляет устройство (смотрим в дисп. устройств) И УДАЛЯЕТ ЗАПИСЬ о порте по пути HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM. А хэндл открыт... ФР перезагрузился, USB-COM вернулся, но неполноценный - в реестре по пути HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM НЕТ записи про порт (а в дисп. устройств - есть устройство), т.к. запись делает драйвер (который, по определённым причинам, не может это сделать, т.к. на момент возвращения устройства есть открытый хэндл). Всё, пока запись по указанному пути в реестре не появится, порт переоткрыть заново не выйдет. Именно поэтому вкл/выкл. аппарата, подключённого по USB, периодически приводит к необходимости повторять эту процедуру или перезагружать машину. Вписать запись верхнее ПО не может, т.к. прав ADMIN/SYSTEM этому ПО никто не даст.
Вывод: нужно успеть мгновенно закрыть порт сразу после подачи команды на ребут. В идеале - ФР должен уходить на ребут с задержкой (что делается уже в прошивке), чтобы успеть закрыть порт/вызвать метод Disconnect драйвера

Навигация

[0] Главная страница сообщений

[#] Следующая страница

[*] Предыдущая страница