Re: Штрих-Мини-К. Программирование через SharpDrv.dll в 1С.
Ну ребята, я так понимаю, что следующим шагом станет поддержка SQL запросов каких-нибудь... Давайте мы все-таки как-нибудь научимся отделять мясные полуфабрикаты от насекомых. Виталь, твоя безграничная фантазия, как-нибудь сыграет с тобой злую шутку:), но самое плохое, что у тебя тут же появляются последователи
.
Все, выше написанное, конечно же стоит воспринимать как шутку, но как говорится: в каждой шутке, есть доля шутки. Давайте не будем требовать от устройства с памятью программ в 64 КБайта (из которых свободных остался 1) того, что ему, нуууу совсем..., не свойственно делать!!! Я считаю, что вопрос увеличения скорости обмена не стоит решать за счет переноса на клиентский уровень серверного функционала. Если задуматься, то программа, которая инициализировала регистры начальными значениями, просто обязана знать какие регистры она инициализировала, дабы не опрашивать ненужные... Да и десятитысячного количества этих регистров в кассе нет, там, как я уже сказал выше, из-за скудности ресурсов, их в десять раз меньше, всего 1000.
Обнуление регистров происходит при снятии отчета с гашением по товарам, там же на печать выводятся и ненулевые регистры остатков.
Что касается задержки. Провел эксперимент на ККМ YARUS-TK, с теми же исходными данными, только там задержка отсутствует, и возможна работа на 115200. Версия драйвера 1.7.16. Плюс процессор работает на много быстрее чем в ШТРИХ-МИНИ-К. Хотя я думаю, что результаты будут приблизительно одинаковые из-за наличия прерываний для обработки различной периферии.
Вот результаты:
скорость RS_____Скорость______Время выполнения команды_______Чт. 1000 регистров____Увеличение скорости
__Бод__________команд/с________________с______________________с (мин:сек)____________%
115200____________~7,7_________________0,13____________________133 (2:13)_____________+30
9600______________5,(5)_________________0,18____________________186 (3:06)______________0
Какие выводы напрашиваются:
1. Увеличение скорости обмена влияет не настолько существенно, как того хотелось бы (прирост производительности в лучшем случае 30%).
2. Удаление задержки (со слов Виталия в этой теме, на ШТРИХ-МИНИ-К команда выполняется за 0.3 с {1000 команд за 5 мин.}) + ~50% к производительности.
Отсюда мораль, основную задержку формирует ККМ при обработке запроса!!! По-этому, друзья, давайте, все-таки, вернемся к тому, что это системная ККМ, а не ФР и, уж тем более, не POS терминал. Её ресурсов едва хватает на обеспечение собственных потребностей, а вы от нее хотите отчеты, да еще и в реальном времени....
Ну и мои выводы по доработкам: если есть острая необходимость получать отчеты не за 5 мин, а приблизительно за 3 -- 3:30, то задержку я могу убрать в настройку (еще раз только напоминаю про замену ПО!!!). Про ненулевые регистры, извините братцы, тут точно мимо.