Вид для печати
День добрый.
Подскажите пожалуйста, какой библиотекой из стандартных нужно пользоваться для работы с файлами из нескольких потоков (задач)?
Сейчас использую SysFile, но несмотря на синхронизацию BOLT-ом периодически затирают друг друга записи в файле. Есть подозрение, что после завершения SysFileFlush ещё некоторое время производится запись файла.
Добрый день.Цитата:
Сообщение от fatlortroll
Насколько я знаю - специальных библиотек для работы с файлами из нескольких потоков не существует.
Т.е. даже с учётом синхронизации -- будет затирание данных в файле?
Если синхронизация реализована корректно и в каждый момент времени файл используется только в одном месте - то "затираний", естественно, не будет.Цитата:
Сообщение от fatlortroll
Значит, у меня криво реализована синхронизация:
Цитата:
// Mt_GVL
VAR_GLOBAL
DataDefender_ : CAA.BOLT; //
END_VAR
Цитата:
// Журнал сообщений
FUNCTION_BLOCK FINAL LoggerActions
VAR CONSTANT
UnlockWaitTimeMax_ : TIME := T#20ms;
END_VAR
VAR
FileHandle_ : SysTypes.RTS_IEC_HANDLE := SysTypes.RTS_INVALID_HANDLE;
END_VAR
Вот так сделано сейчас. Оставил только то, что относится к синхронизации. Если видны какие-либо ошибки -- покажите, пожалуйста.Цитата:
// Добавить в лог сообщение об ошибке.
METHOD MsgError : SysTypes.RTS_IEC_RESULT
VAR
CtValue : CAA.COUNT := 0;
UnlockWaitTime : TIME := T#0ms;
END_VAR
UnlockWaitTime := TIME();
WHILE ((UnlockWaitTime + UnlockWaitTimeMax_) > TIME()) AND_THEN
(Mt_GVL.DataDefender_.Reserve(CtValue) = TRUE)
DO
// Здесь работа с файлом, запись в него форматированной строки и flush по завершении записи.
CtValue := 0;
UnlockWaitTime := T#0ms;
Mt_GVL.DataDefender_.Free();
END_WHILE
Похоже, весь код -- одна большая ошибка.
А как правильно сделать -- пока не пойму.
Давайте лучше по нашему обычному сценарию?
Какую практическую задачу из вашей предметной области вы пытаетесь сейчас решить? (без попытки пригвоздить себя к конкретной реализации)
> Какую практическую задачу из вашей предметной области вы пытаетесь сейчас решить?
Запись в один файл из нескольких потоков. Журнал действий пользователей, и системы.
Ну ок, пойдём длинным путём.Цитата:
Сообщение от fatlortroll
C чем связано требование про потоки?
> Ну ок, пойдём длинным путём.
:-D Ну не могу я выложить всё, не могу! :-D
В одном потоке читаются по modbus входы/выходы, во втором -- логика приложения.
А если сделать какой-то один объект (FB) с методом AddToLog()?Цитата:
Сообщение от fatlortroll
Пусть внутри FB файл всегда будет открыт, а AddToLog туда будет писать?
...и ещё можно извратиться и сделать через штатные Тревоги. Дёргать их, а на их обработчик (активацию) повесить свю функцию записи в свой файл.
Плюс этого решения ещё и в том, что все строки сообщений будут в одном месте находиться (в описании тревог), а не будут по коду раскиданы.
Если чтение I/O сложить в один поток с логикой, получатся неприличные задержки.
А, там ещё вместе с I/O ещё обмен данными с шестью частотниками.
> А если сделать какой-то один объект (FB) с методом AddToLog()
Так и сделано, но, похоже, там конкуренция среди них. И я криво реализовал синхронизацию.
А что ты называешь потоками? Разные задачи?Цитата:
Сообщение от fatlortroll
А если сделать очередь? =) Типа при вызове AddToLog всё пишется в очередь (массив структур с данными), а потом он спокойно скидывается на диск. В одном, своём потоке (задаче)
Шаман, как обычно, смотрит в корень - то, что события могут формироваться в разных потоках, не мешает обрабатывать их в каком-то одном потоке.
Использование SysFile и других библиотек с синхронными вызовами - действительно довольно простой способ получить "неприличные задержки".Цитата:
Если чтение I/O сложить в один поток с логикой, получатся неприличные задержки.
Для большинства библиотек есть асинхронные варианты - например, в случае файлов это библиотека CAA File.
> А что ты называешь потоками? Разные задачи?
Ага.
> А если сделать очередь?
Там тоже проблемы могут вылезти, хотя бы при попытках одновременной записи в эту очередь разных потоков. Тоже синхронизировать надо.
> обрабатывать их в каком-то одном потоке
Но от синхронизации записи никуда не деться, в любом случае.
Если это один поток и всё же SysFile - о какой вообще синхронизации речь?Цитата:
Сообщение от fatlortroll
Вызовы SysFileOpen, SysFileWrite и т.д. - блокирующие.
Возможно, я некорректно представляю модель исполнения CoDeSys, но разве при вызове метода ФБ из разных потоков (задач) не может случиться коллизия, даже если функции внутри этого метода блокирующие?
А зачем вообще об этом думать?Цитата:
Сообщение от fatlortroll
Пример реализации, совпадающий с озвученной выше Шаманом идеей ("простое лучше сложного"):
- глобальный ARRAY [FIRST_EVENT...LAST_EVENT] OF BOOL
- из разных потоков по событиям взводим нужные флаги массива (доступ к массиву по константным индексам - можно через красивый ENUM - все события заранее известны и определены)
- в одном конкретном потоке: открываем файл, в цикле проходим по массиву - для каждого установленного флага вызываем SysFileWrite (и здесь же можно реализовать форматирование сообщения, если требуется) и сбрасываем флаг - после выхода из цикла закрываем файл
Да! Евгений Кислов всё рассказал!
Я такое делал с очередью отправки СМСок: брал массив на 20-30 событий, через вызов функции пихал их туда.
При этом инкремент счётчика занятых элементов делал именно в той функции.
А основная задача, медленная, извлекала события из этого массива-очереди, и пихала их в модем, ожидая отправку каждого из них.
Задумка была на тот случай, с которым ты и столкнулся: "Ой! А вдруг разом десяток аварий будет, и тонна СМСок прилетит".
Всё-таки расскажи нам, ЧТО там у тебя ТАКОГО интересного! У меня проект (я ща как раз его дальше ваяю, в ночи), где опрашивается 9 штук модулей по SysCom (очень-очень быстро). И ещё и отслеживанием ошибок связи с ними и логгеньем в тревоги ПЛК... Вот у тебя ещё быстрее, чем у меня? Я хочу это представить! =)
> ЧТО там у тебя ТАКОГО интересного
Всего лишь промышленный станок. Ничего интересного. :-)
Добрый день, подскажите пожалуйста. Не выходит залить прошивку в виртуальный ПЛК т.к. таргет версии 3.5.6, а сам ПЛК 3.5.5. Как найти и поставить версии 3.5.5 control win? (Галочка "показать старые версии" не дает эффекта нужного)Вложение 65529
Добрый день.Цитата:
Сообщение от ADS
Таргет 3.5.5.0 входит в состав CODESYS V3.5 SP5 Patch 5.
Как я понимаю (судя по версии рантайма виртуальника) - вы эту версию устанавливали?
Тогда см. п. 8.2 здесь:
https://ftp.owen.ru/CoDeSys3/11_Docu..._FAQ_v.1.3.pdf
После этого галочка "показать старые версии" действительно должна показать старые версии.
В общем, в очередной раз оказалось "сам дурак". Размер строки, отдаваемой форматтером сообщений журнала оказался недостаточен для отдельных сообщений, что и привело к эффекту "наложения" записей друг на друга. Увеличил размер строки -- всё работает, синхронизация синхронизируется, журнал пишется.
Это не дурак =) Это - БАЛАМУТ! =))Цитата:
Сообщение от fatlortroll
Смелое заявление, требующее обоснования! :-)
Спасибо большое. ПолучилосьЦитата:
Сообщение от Евгений Кислов
Здравствуйте Евгений. Дело в том, что видеоинструкция не соответствует реалиям. Скрины прилагаю.Вложение 65589Вложение 65590
Добрый день.Цитата:
Сообщение от TATARin
Какая у вас версия прошивки ПЛК?
plc210 1.3.0309.1257Вложение 65591
В этой прошивке еще не было поддержки GPRS для модемов.Цитата:
Сообщение от TATARin
В начале видео по вашей ссылке об этом должно быть упомянуто.
Хорошо.В таком случае как подключить модем стороннего производителя? И предать, и считать переменные через модем с данной прошивкой?
Для организации подключения через GPRS-модем в данной прошивке нет штатного функционала.Цитата:
Сообщение от TATARin
Можете обновить прошивку и использовать функционал из видео, ссылку на которое вы выкладывали выше.
Т.е. Вы рекомендуете обновить прошивку, так?
Я скачал файл прошивки и в файле readme написано - "Перепрошивка с версии 1.2.xxxx.xxxx / 1.3.xxxx.xxxx на версию 2.4.xxxx.xxxx поддерживается только для устройств, выпущенных начиная с июля 2020 года (с 512 Мб flash-памяти)". Вроде всё совпадает. Прошивать?
Если для вас обмен по GRPS является ключевым функционалом, без которого не обойтись, и вы внимательно изучили инструкцию по прошивке и готовы дословно и пошагово ее повторить - то да, можете перепрошиться.Цитата:
Сообщение от TATARin
Здравствуйте.
В наличии СПК110. Codesys3.5.
Проект сохраняет снимок экрана на USB-флешку.
Если USB-флешку вытащить из СПК110 например спустя менее 5сек после команды записи снимка – то получаем файл с НУЛЕВЫМ размером – этот файл не открывается (пишет файл повреждён).
Если выждать около 1минуты, то с файлом всё в порядке – картинка отрывается – всё как положено.
ВОПРОС:
Как определить, что формирование файла на USB-флешке завершилось (не обязательно снимок с экрана, а может файл архива, который формируется архиватором)?
Существует ли параметр, что обмен СПК110 с USB-флешкой завершён – и USB-флешку можно демонтировать,
Добрый день.Цитата:
Сообщение от DuMa
Вы можете в коде определить размер файла (например, см. в библиотеке CAA File ФБ GetSize).
Или запускать таймер на ожидание (значение подберите опытным путем).
Какого-то отдельного параметра "что обмен СПК110 с USB-флешкой завершён" - нет.
Понял – действую через таймер.
А вот всё-таки,
в проекте присутствует узел «Drives».
Если его включить (канал «Enable Drives») и перед демонтажём USB-флешки из СПК110 подать команду «Размонтировать USB Flash» (канал «USB Unmount»), дождаться сигнала «Размонтирование USB Flash завершено» (канал «USB Unmount done»), только после это демонтировать USB-флешку из СПК110.
В этом случае данные не будут потеряны?