Сообщение от
Yegor
упаковывать основательно — вплоть до экономии отдельных битов.
Ну уж...
Ок, я расскажу, как я сейчас вижу.
Одна запись в файл будет представлять собой структуру:
Код:
TYPE LOG_STRUCT:
STRUCT
Number: DWORD;
TWeight: DINT;
TimeStamp: DT;
Weight: INT;
Unit: BYTE;
CheckS: BYTE;
END_STRUCT
END_TYPE
Смысл отдельных переменных ясен (а точнее - не играет роли в данном топике).
Из "лишнего" здесь разве что один байт CheckS. Особой роли он не играет, ибо контроль правильности передачи файлов осуществляется выше, но размер структуры 16 байт как-то привлекает больше. Ну, и я себе нафантазировал, что, чисто теоретически, можно "поймать синхронизацию", если принять файл не с начала (сбой в передаче). Тогда можно начать с любого байта и вычислять контрольную сумму на 16 байт. Если не ноль (правильное значение), то брать следующий байт - и так до 15 раз. Где-то контролька совпадет и можно от этой точки восстанавливать файл. Паранойя, конечно, но нДравится - и все тут! За это заплачу увеличением длины на 1/15
Жаль. Мой первый вариант программы парсера уже работал. Теперь много править - и в ПЛК, и в парсере. Но должно быть красиво.
Вообще, именно для задачи мониторинга (в противовес управлению) использовать PLC_IO.EXE очень даже удобно. ПЛК работает себе спокойно, а у него из-под носа данные уволакивают "наверх".
Я еще поиграюсь с тем же Пайтоном для работы с ПЛК "по-правильному", через драйвер Модбаса или тот же Конфигуратор ввода-вывода - посмотрю, насколько это удобно. Пора разобраться. Ибо работать с ПЛК со стороны ПК уже пора, мои ноги понемногу вырастают из шортиков, а с Мастер-СКАДА мне не понравилось вааще. Мои (примитивные) задачи решать скадой не хочется. Но это отдельная тема...
2 capzap: не понял про кодирование...