Anviz CCH с Face ID

Обратился клиент, на новом устройстве FDEEP3M не считывается журнал проходов через мою компоненту CCH.

На старых с типом FACE7FAI все работает.

Причем через старую компоненту CKT со старых устройств FDEEP3M данные считываются, а с новых — нет.

Поставил ему демо-приложение из SDK на C#, который использую, как образец — там все работает.

Начал смотреть протокол своей компоненты — мощная штука, позволяет обходиться без отладчика. Оказывается при запросе очереди возвращается сообщение типа 151 (CCHEX_RET_TM_NEW_RECORD_INFO_TYPE):

Get All records ret: 1
Enter wait event: 71
  Event: 0 wait for: 71 Time: 27.09.2023 13:36:27
  Event: 151 wait for: 71 Time: 27.09.2023 13:36:27

А в обычных устройствах возвращается сообщение типа 71 (CCHEX_RET_GET_NEW_RECORD_INFO_TYPE):

Get All records ret: 1
Enter wait event: 71
  Event: 0 wait for: 71 Time: 27.09.2023 13:31:21
  Event: 71 wait for: 71 Time: 27.09.2023 13:31:21
OK Log Read Event
Enter wait event: 71
  Event: 71 wait for: 71 Time: 27.09.2023 13:31:21
OK Log Read Event
Enter wait event: 71
  Event: 71 wait for: 71 Time: 27.09.2023 13:31:21

В коде я жду и обрабатываю именно сообщение 71.

У 151 сообщения своя логика обработки:

В отличии от типового сообщения 71:

Структуры данных возвращаются тоже разные. Вот типовая:

А вот TM (171):

Видно, что тут добавлена температура (видимо это важно для китайцев при борьбе с ковидом), а тажке изменено название байта входа-выхода с Rsv на OpenType.

Пришлось немного изменить код на C#, чтобы можно было ждать два сообщения из очереди:

И пойти на преступление — изменение типа результат. Возвращать не бесполезный результат метода CChex_Update, а код полученного сообщения:

К счастью, больше нигде я результат не сравниваю, так что такая метаморфоза пройдет нормально.

fixin

Программирую на 1С с 1999 года. В 1С просто Гений. В 2020 году ушел из офиса на вольные хлеба фриланса. Принимаю заказы.

Читайте также:

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *