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

[drvlas]

По журналированию я много расспрашивал в другой теме (http://owen.ru/forum/showthread.php?t=16563). Получил много полезных советов, уже год работает програмка 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-байтные) целые были на кратных четырём адресах, например. Оно само так и получается, как правило, но можно и начудить, скажем, прочитать структуру как массив байт, а потом обращаться к её элементам через типизированный указатель.

[drvlas]

можно и начудить, скажем, прочитать структуру как массив байт, а потом обращаться к её элементам через типизированный указатель.Ну, в КДС я уже научился работать через указатели, у меня достаточно много на этом построено. Так что "с той стороны" проблем не должно быть. А при приеме буду разбирать пайтоном. Есличьо - разберемся.
Да скоро и попробую.Сейчас переделаю свое описание программы, сформулирую, так сказать, ТЗ. Ну и начну чудить-кодить.

Еще раз благодарю всех за помощь!

[Yegor]

в КДС я уже научился работать через указателиТоже про себя так думал, пока не лоханулся (http://www.owen.ru/forum/showthread.php?t=19648&p=154412&viewfull=1#post154412) (читать до 44 поста).

[drvlas]

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

Но вот это:

1) оператор присваивания (функция ADR) игнорирует тип операнда,

я даже использую :)

В общем, запихнуть пяток переменных в структуру, массив структур дописать в файл - вродь как не виДю проблем. Поставлю пойнтер на начала и 16 байтиков фьють! - и готово.
Жаль, что не могу проверить сию секунду. Торгуюсь с заказчиком, не до творчества.

[Sergey666]

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

.

Ну-Ну величайший создатель протокола , не в Метре работал !?
А , что будет , если в "теле" есть и 254 и 255 ???
(*================================================ ==================*)
А если по теме , то использование бинарника существенно уменьшает "расход" памяти ПЛК и упрощает программу .
Единственно - расшифровка , но с этим легко справиться .
Стартер ! Можно написать приложуху , которая распакует бинарник в csv , а с csv уже будет работать предыдущий парсер .:p Не выкидывать же его.:o

[drvlas]

Можно написать приложуху , которая распакует бинарник в csv
Это разве что для дальнейшей тренировки в пайтоне :) Но у меня впереди еще столько реальных задач, что одной программы для тренировки будет достаточно.
Ну и с двоичным файлом - спасибо за конкретный ответ. Оно канешна, вроде как очевидно (вся эта тема не стоит такого количества постов, ИМХО), но я чьот трухнул - смотрю, год назад я выбрал CSV, ну, думаю, не дурак же был, что-то думал... Оказалось, дурак и был.


а с csv уже будет работать предыдущий парсер .:p Не выкидывать же его.:o
А предыдущий парсер написан не мной (спасибо Yegor-у еще раз, мне год назад с киевскими событиями было не до освоения новых инструментов, так что палюбасу коллега х-у-н-т-е помог), а я жуть как не люблю править чужие программы. Даже хорошие. Поэтому и пишу свое.

[capzap]

Это разве что для дальнейшей тренировки в пайтоне :) Но у меня впереди еще столько реальных задач, что одной программы для тренировки будет достаточно.
Ну и с двоичным файлом - спасибо за конкретный ответ. Оно канешна, вроде как очевидно (вся эта тема не стоит такого количества постов, ИМХО), но я чьот трухнул - смотрю, год назад я выбрал CSV, ну, думаю, не дурак же был, что-то думал... Оказалось, дурак и был.


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

когда перейдете то на плк с вставляемыми флешками? Там вновь не понадобится заботится о бинарниках, csv достаточно будет, есть одна фишка которая мне понравилась в панелях вейнтек, это чтоб разумно тратить пространство памяти, они сохраняют в ОЗУ 4кб и только после этого пишут во флеш

[drvlas]

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


чтоб разумно тратить пространство памяти, они сохраняют в ОЗУ 4кб и только после этого пишут во флешХех, я ведь в ПЛК100 тоже делаю 200 записей в память (это было 56*200=11,2 Кбайт, теперь будет втрое меньше), а потом уже дописываю в файл-журнал. Ресурс флеши нужно беречь :)

[Sergey666]

когда перейдете то на плк с вставляемыми флешками? Там вновь не понадобится заботится о бинарниках, csv достаточно будет, есть одна фишка которая мне понравилась в панелях вейнтек, это чтоб разумно тратить пространство памяти, они сохраняют в ОЗУ 4кб и только после этого пишут во флеш

Из-за этой мерзости приходится искать плк адекватный с флэш вставляемой . Мерзость - при выключении панели - архивные записи иногда теряются и заказчик говорит , что запись должна быть , а ее нету !!!! (Одна запись- 56 байт). И кстати по наблюдениям при запись во внутр.память данных больше теряется , с внешней флэш как-то по другому не 4кб , но все равно пропуски имеются и это ж..а !
Приходится лопать глазами - добрыми-предобрыми и лопотать что-то про китаезских программеров.
И еще косяк при записи в тексте - архивы то пишуться иногда чтобы проследить не стырил ли оператор пару машин чего-нибудь .
Оператор нонче пошел грамотный , выташшит фрэшку да и подправит или удалит чего-не надо .
У вайнтека архивы пишуться в формате .dtl , кстати , и переводится в .csv ихней же приблудкой кривоватой , но рабочей (как почти все у китайцев).

[drvlas]

Мерзость - при выключении панели - архивные записи иногда теряютсяФигасе... "Вы меня изводите", как говаривал сатирик. Я недопонял: ты говоришь о панелях вайнтек или о ПЛК ОВЕН?
Мой скромный опыт работы с ПЛК пока обнадеживает: пока аккум держит, все вовремя записывается, клиенты не жаловались. Но эксплуатация-то всего на одном объекте, так что выводы я не могу делать.
Вообще, мои дозаторы на ПЛК100 работают, в основном, совершенно автономно, в пыли и грязи, но без внешних командиров. Ща только начинаю их прикручивать к системам. Основное решение (оно же и первое исторически) - подключайся по модбасу и читай-пиши, что надо. Даже командуй - есть парочка регистров, которая позволяет давать ПЛК команды, типа СТАРТ, СТОП. Конечно, так можно и отчет о проделанной работе собирать и в ПК архив создавать. Но это убого, ибо ПК держать все время включенным... не камильфо.
Поэтому я решил попробовать создавать архив в ПЛК. Уж он-то не спит, когда дозатор работает :) Создал его самопально, просто в программе открываю файл и пишу, если пора. Каких-то специальных архиваторов не юзаю. И очень надеюсь, что флеш не подведет. Иначе что - просто ставить в систему внешний архиватор? Грустно было бы, с моими-то дешевыми серийными системами...

[Sergey666]

Фигасе... "Вы меня изводите", как говаривал сатирик. Я недопонял: ты говоришь о панелях вайнтек или о ПЛК ОВЕН?
Мой скромный опыт работы с ПЛК пока обнадеживает: пока аккум держит, все вовремя записывается, клиенты не жаловались. Но эксплуатация-то всего на одном объекте, так что выводы я не могу делать.
Вообще, мои дозаторы на ПЛК100 работают, в основном, совершенно автономно, в пыли и грязи, но без внешних командиров. Ща только начинаю их прикручивать к системам. Основное решение (оно же и первое исторически) - подключайся по модбасу и читай-пиши, что надо. Даже командуй - есть парочка регистров, которая позволяет давать ПЛК команды, типа СТАРТ, СТОП. Конечно, так можно и отчет о проделанной работе собирать и в ПК архив создавать. Но это убого, ибо ПК держать все время включенным... не камильфо.
Поэтому я решил попробовать создавать архив в ПЛК. Уж он-то не спит, когда дозатор работает :) Создал его самопально, просто в программе открываю файл и пишу, если пора. Каких-то специальных архиваторов не юзаю. И очень надеюсь, что флеш не подведет. Иначе что - просто ставить в систему внешний архиватор? Грустно было бы, с моими-то дешевыми серийными системами...

Я имел в виду панель вайнтек .
Вообще с вашими умениями работы с микроконтроллерами и каким-то серийным производством пора задуматься над ... собственной самоделкой , благо сейчас готовых "китов" даже с сенсорными экранами навалом .
Реализовывать модбас на "С" по стандарту сумел , остальное проще репы пареной .

[drvlas]

Я имел в виду панель вайнтекВот и славненько. Успокоил.


Вообще с вашими умениями работы с микроконтроллерами и каким-то серийным производством пора задуматься над ... собственной самоделкой , благо сейчас готовых "китов" даже с сенсорными экранами наваломЯ, коллега, лет 15 выпускал свой контроллер. Сделано около 2000 штук. Там и МК менялся, и формфактор, но это был достаточно дубовый и качественный специализированный контроллер для задач весового дозирования (и просто взвешивания, ясен перец).
И что я скажу? Теперь такая перспектива не вставляет :) Вот, чисто по моим предпочтениям - это не интересно. Я-то метролог, а не вычислитель. Нашел в 2009-м ПЛК100, ИП320 - да, бляха муха, решают мои скромные задачки! От добра добра не ищут.
Это не рецепт для других. Я только о себе. Мне интересно разрабатывать платки с метрологической задачей, а также собирать весь этот гамуз в рабочую систему. И вот сейчас, писк моих мечтаний - нахлобучить над всем этим комп. Я элементарно изучаю программирование на ПК задач работы с внешними устройствами. Это кльово, если хорошо понимаешь и любишь те самые внешние устройства :)

[SuP]

Прошу прощения за некоторую некрофилию, но вдруг тема жива. Интересует, насколько вообще при записи вот такого лога флеш встроенная изнашивается? Ресурс у неё небольшой. Файл, чай, пишется всё время на одно и то же место, да ещё и какими-нибудь порциями по 16 байт, так как у флеша - тонкая страничная организация на стирание/запись... Можете это всё пояснить с обоснованием фактами, что, дескать, так и так это работает, поэтому проработает в таком режиме как минимум 20 лет... Тоже хочу сделать архив внутри ПЛК, но пока опасаюсь. Ибо когда-то был опыт неаккуратного обращения с флеш-памятью сигнального процессора )

[Валенок]

Ресурс - 300млн записей размером 1-512байт. Не чаще 1 сек - до 10лет.
Нужно чаще или дольше - программно оптимизируете через промежуточный буфер для порций по 512 байт.
(первый "кластер" в файле что-то 464 байта вроде - уточнить)

[SuP]

Спасибо! А можно ссылку на какое-нибудь описание по организации файлов на flash овеновских контроллеров, из которого всё это следует? Был бы признателен.