Снова о журналировании работы ПЛК

[drvlas]

По журналированию я много расспрашивал в другой теме. Получил много полезных советов, уже год работает програмка LogParser, предоставленная коллегой Yegor-ом.
Настало время кое-что изменить, начал я переосмысливать и появился вопрос, который не хочу приклеивать в хвост к той громоздкой теме.

Итак, у меня в программе работы ПЛК создается файл-журнал. Он имеет типичный CSV формат, каждая строчка - запись одного измерения с временнім штампом, номером замера, результатами. Длина записи - 56 байт. В ходе работы файл пишется до 10 тысяч строк (это полмегабайта), а потом начинает записывать с начала.
Что не нравится: файл большой. Я его вычитываю в ходе запуска из своего приложения известной программы PLC_IO.EXE. И тянется процесс чтения из ПЛК несколько минут (по етернету). Сократить число записей можно - но до 5 тысяч, ниже не хотелось бы. Вот я и думаю, а что, собсно, я выигрываю от текстового формата файла-журнала? Ну, один "плюсик" есть: можно качнуть "голой" PLC_IO.EXE, закинуть в ПК и открыть прям сразу как электронную таблицу. Но... Огромный лист таблицы, все равно фильтровать надо.
А программа LogParser как раз и фильтрует. И так же может быть написана вторая-третья-десятая программка. которая этот самый файл-журнал будет обрабатывать. Даже я со своими кривыми ручками уже написал такую програмульку. так теперь вопрос: а зачем же я в ПЛК сначала заворачиваю свои данные в текстовый формат, потом тяну этот распухший файл в ПК, а там все равно извлекаю из строки нужную мне инфу для выполнения фильтрации?

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

Спасибо!

[Yegor]

Да какие там могут быть грабли? Нету их. Только в бинарник если упаковывать, то упаковывать основательно — вплоть до экономии отдельных битов.

[capzap]

ну, выше уже написано, что такие файлы называются бинарными, в добавок могу подсказать направление, взять за основу кодирование принятое в cмcках на латинице

[drvlas]

упаковывать основательно — вплоть до экономии отдельных битов.

Ну уж...
Ок, я расскажу, как я сейчас вижу.
Одна запись в файл будет представлять собой структуру:

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: не понял про кодирование...

[capzap]

переведите любой знак в шестнадцатеричном исчислении в char и Вы увидите что остается не занятым старший разряд символа, поэтому в мобильниках латиница передается по количеству символов в два раза больше чем кирилический текст, так что можно что нибудь сообразить в сжатии данных

[drvlas]

Со всем уважением - но это излишне. После моих 56 байт на запись (с которыми все работает целый год, то есть по размерам файла все чики-пики) нынешние предполагаемые 16 байт - сказка!
Меня больше интересует оценка моего выверта сознания с последним байтом в качестве контрольной суммы по предыдущим 15 байтам. Видите ли вы в этом хоть какой-то потенциальный смысл - или нуегонафик?

[capzap]

помоему поиск по перебору нахождения контрольной суммы соразмерен повторной посылке данных с начала файла

[Scream]

Внесу свои пять копеек.
Я считаю что если есть хоть какаято возможность НЕ архивироватьв плк, то её надо использовать, но бывают, понятное дело, и другие ситуации...

Про бинарные файлы vs CSV.
Конечно бинарные намного дешевле обходятся. Со структурой тоже возился, но там есть большая проблема всегда кратно 4 байтам и всякие пляски приходится делать.
От структур ушел. По опыту понял что нужно использовать "свои" протоколы и использовать хеш суммы не обязательно. Я обхожусь 3 байтами, 1й - старт (254), 2й - следующее колво байт (length-1), последний (255).
Этого вполне достаточно, плюс в протоколе нет ограничения по длине, она может быть динамической благодаря 2му байту.

Насчет считывания.
Поигрался и пришел положительному результату. Вобщем как сказали уже если грузится на ПК, то там праграмма парсер потом расшифрует эти данные, так вот я выкачиваю файлы по модбас с помощью 20й функции. Это очень удобно, и глубоких навыков не понадобилось реализовать хоть на паскале, хоть в java. К сожелению готового решения нет, показать пока не могу, все по кускам пробовал, реализовывать готовое решение (для себя) буду позже, времени нет.
Считаю что архивировать надо с помощью библиотек, а выкачивать через модбас (также можно установить с какого байта будете считывать файл, тоесть не обязательно качать весь).

Есть и минусы такого подхода.
1) Имя файла нельзя изменить без перепрошивки плк.
2) Довольно спецефическая бибка, и иногда невозможно создать файл с именем, которое использовалось раньше, файл удалили не освободив дискриптор и тогда мешает пункт 1. Там много магии...

Насчет сжатия.
Естественно если 8 булево переменных пакуем, то их закидываем в 1 байт. Например 16 дискретных входов плк = 2 байтам. Далее все просто, если переменная никогда не будет > 255, то это байт, не более 65535, то word ну вы поняли. Еще лично я, очень не люблю real, часто их кидаю в word * 10(*100), конечно при этом я знаю границы показаний датчика, ктото скажет не красиво, я отвечу поф.наКрАсАту, далее все парсится программой и в конечном итоге пользователю выводится дробное, как должно быть.

[drvlas]

Со структурой тоже возился, но там есть большая проблема всегда кратно 4 байтам и всякие пляски приходится делать

Кратно 4 байтам - где? В файл нельзя записать 3 байта? Вот если взять описанную мною выше структуру (16 байт) и изменить ее так, что добавится еще 1 байт. Структура станет 17 байт. И будет занимать в ОЗУ и потом в файле уже 20 байт?
Читал когда-то о выравнивании, но подзабыл...

Считаю что архивировать надо с помощью библиотек

Ну, я с этими либами еще не работал. Это впереди. Пока у меня самодельный архив.

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

Ну да, если ПЛК контролирует процесс обмена - тогда ясно. Много чего можно. А если файлы с его флеша качает PLC_IO, то там возможности ограничены. Вот там мне и нужен файл покороче.
Хотя согласен, что это очень частный случай. Поэтому считаю мой вопрос отвеченным (о выравнивании почитаю, спасибо)

[Yegor]

Кратно 4 байтам - где? В файл нельзя записать 3 байта?

Можно, но только считывать надо так, чтобы данные легли на кратные своим элементарным типам адреса. Ну то есть чтобы 32-битные (4-байтные) целые были на кратных четырём адресах, например. Оно само так и получается, как правило, но можно и начудить, скажем, прочитать структуру как массив байт, а потом обращаться к её элементам через типизированный указатель.