Вид для печати
Добрый день, уважаемые коллеги! Подскажите пожалуйста, как прочитать файл в ПЛК110 [M02] ?? Мне нужно вывести MAC - адрес в программу. Из поиска по форуму я понял, что нужно читать файл Data_local_adress.dat, а конкретно реализации я не нашёл на просторах, Это делается с помощью библиотеки SysLibFiles ?? Как грамотно это делается?
OwenLibFileAsync.lib
Пример и библиотека во вложении
По вашему примеру у меня вопросы.
1. Зачем сделано переприсваивание state_res := state; ?Код:CASE state_res OF
0:
res:=OwenFileOpenAsync('usb:test.dat','a',ADR(handle));
IF res=ASYNC_WORKING THEN
state:=1;
END_IF
1:
res:=OwenFileOpenAsync('test.dat','a',ADR(handle));
IF res=ASYNC_DONE THEN
IF handle<>0 THEN
state:=2;
ELSE
state:=0;
END_IF
ELSIF res<0 THEN
state:=0;
END_IF
Почему недостаточно одной переменной состояния state_res ?
2. Зачем состояние 0?
Оно не делает ничего другого, что делает состояние 1.
3. Почему в состоянии 0 открывается файл 'usb:test.dat',
а в состоянии 1 - 'test.dat' ? Это ошибка?
4. При первом вызове записи в файл (состояние 2), если результат не ASYNC_WORKING,Код:2:
res:=OwenFileWriteAsync(handle,ADR(bufout),14,ADR(result));
IF res=ASYNC_WORKING THEN
state:=3;
ELSE
state:=6;
END_IF
3:
res:=OwenFileWriteAsync(handle,ADR(bufout),14,ADR(result));
IF res=ASYNC_DONE THEN
IF result=14 THEN
state:=4;
ELSE
state:=6;
END_IF
ELSIF res<0 THEN
state:=6;
END_IF
сразу уходим на закрытие файла, а в состоянии 3 еще проверяем ELSIF res<0 .
В этом есть какой-то особый смысл? Почему в состоянии 2 res не проверяется на отрицательность?
5. Состояние 2 не делает ничего другого, что делает состояние 3. Зачем оно?
(этот же вопрос для состояний 4 и 5)
1. state_res := state; - машина состояний с защёлкой. Смена состояния только в конце обработки. Так не надо думать о side effect
2. Как же одно и то же? В состоянии 0 запускается открытие файла, а в 1 мы ждем когда же оно произойдет.
3. Очепятка
4. Опять же в 2 - начинаем писать, в 3 - ждем окончания. При первом вызове функция может сразу послать или сказать "принято к исполнению", можно сразу закрывать, а в 3-м - надо ждать результата АСИНХРОННОГО действия.
5. Все этапы парные. Начал и двигаемся до финала, начал и двигаемся до финала....
Вызов функции один и тот же, хоть запуск, хоть ожидание. Разницы нет никакой по факту.Цитата:
Сообщение от Филоненко Владислав
Ладно. Объясняю на пальцах.
1.Приходите Вы в магазин. Магазин - это ПЛК.
2.Обращаетесь к продавщице, тёте Клаве - это библиотека OwenAsyncFileLib
3.И говорите: "Дайте мне ящик водки". Это первый вызов OwenFileOpenAsync
В это момент тётя Клава может сказать ASYNC_WORKING или сообщить об ошибке "Несовершеннолетним не продаём". Это первый возврат функции, он происходит мгновенно.
Если тётя Клава не выгнала Вас сразу - то она начинает выполнять асинхронную операцию "Выдать ящик водки". Это процесс не быстрый, надо грузчика Васю на склад отправить.
4. Раз в 1 секунду Вы спрашиваете тётю Клаву, ну что, когда же, трубы горят... Это циклические вызовы OwenFileOpenAsync в state==1
И когда тетя Клава завершит асихронную операцию - она воскликнет "ASYNC_DONE" - т.е. все прошло успешно или выдаст код ошибки - "Я пошла на обед, приходите завтра" - это результат выполнения АСИНХРОННОЙ операции.
5. И наконец, если все же в пункте 4 было ASYNC_DONE - то в ADR(handle) будет лежать либо ящик водки, либо NULL - сообщение от грузчика что ящик водки "разбился" и на складе нету больше.
Как мы видим есть 2 уровня взаимодействия - собственно попытка через тётю Клаву получить ящик водки (удачная или неудачная) и результат (тоже удачный или нет) - но это результат уже сам ящик водки или его отсутствие.
Это все потому, что так и не удосужились сделать нормальное описание библиотеки.
Только примеры, которые выглядят странно. Потому что не ясно, что делать в случае тех или иных ошибок.
Возвращаясь к вашему примеру.
1. Состояние 0 (открытие файла) долбит запрос, пока не получит желанный ASYNC_WORKING, больше ни на что не обращая внимания. И то, после получения желаемого ответа продолжает то же самое из состояния 1. С тем же успехом это можно делать и из состояния 1.
2. Теперь состояние 2 (запись в файл). (согласен, 2 и 3 отличаются)
Если при первом запросе на запись не получено ASYNC_WORKING, надо закрывать файл? Почему? Там может быть куча разных причин/ошибок. А может, лучше подождать?
Откуда мне знать? Описания нет.
Состояние 3 вызывает те же вопросы. Плюс к тому: если не записалась требуемамя длина, то закрыть файл? А что случилось, все равно? Может, кончилось место? Такой ошибки почему-то нет. А мне позарез надо данные сохранить!
3. Состояние 4 (закрытие файла).
Если с первого запроса не получено ASYNC_WORKING, то записать строку(???) (переход в состояние 3).
Вообще непонятно. Мне надо закрыть файл, данные кончились, что там еще записывать?Код:4: (*закрываем файл этап1*)
res:=OwenFileCloseAsync(handle, ADR(result)); (*закрываем файл*)
IF res=ASYNC_WORKING THEN (*если "работа",то переходим в состояние 5, либо в 3*)
state:=5;
ELSE
state:=3;
END_IF
А что произошло, когда при закрытии файла получено result <> 0?
Запрос на закрытие файла повторяется снова и снова. Состояния 4 и 5 делают либо одно и то же, либо переходят на вообще ненужные действия - записывать данные, которых нет.Код:5:(*закрываем файл этап2*)
res:=OwenFileCloseAsync(handle, ADR(result));
IF res=ASYNC_DONE THEN (*если "завершено", то переход в состояние 0*)
IF result=0 THEN
state:=6;
ELSE
state:=4;
END_IF
ELSIF res<0 THEN
state:=4;
END_IF
Вопрос уже практический. Пытаюсь открыть файл в памяти двухстадийным вызовом
res:=OwenFileOpenAsync('mem:test.dat','a',ADR(hand le));
Получаю res = ASYNC_DONE, но handle неизменно равен нулю. Почему?
Из ПЛК-браузера также не удается скопировать файл на устройство mem:
filecopy ffs:probe.tcl mem:probe.tcl
File copied size 0
Значит открыть библиотека не может. Повторите то же, с теми же именами и параметрами через SysLibFile (Async обёртка вокруг SysLibFile).
Ну и не забываем, что телепаты у нас все заняты, поэтому желательно видеть проект :)
SysLibFile дает ту же ошибку (f_handle = 0):
Код:
CASE f_work OF
F_OPEN: (*открыть файл на запись*)
(* res := OwenFileOpenAsync(arc_filename, 'a', ADR(f_handle)); *)
(*заменил асинхронный вызов на синхронный*)
f_handle := SysFileOpen(arc_filename, 'a');
res := ASYNC_DONE;
F_CLOSE: (*закрыть файл*)
res := OwenFileCloseAsync(f_handle, ADR(f_result));
F_WRITE: (*записать в файл*)
res := OwenFileWriteAsync(f_handle, ADR(arc_buff), SIZEOF(arc_buff), ADR(f_result));
END_CASE
CASE res OF
ASYNC_WORKING: (*wait*)
;
ASYNC_DONE:
CASE f_work OF
F_OPEN:
IF f_handle = 0 THEN
f_err := TRUE;
ELSE
FILE_OPENED := TRUE;
END_IF
F_CLOSE:
FILE_OPENED := FALSE;
F_WRITE:
;
END_CASE
f_work := F_NONE;
;
ASYNC_PAUSED, (*Система по своим внутренним причинам приостановила обработку асинхронных запросов*)
ASYNC_QUERY_FULL, (*>5 запросов в очереди*)
ASYNC_BLOCK_ACCESS, (*Запрос к уже обрабатываемому объекту с другой функцией*)
ASYNC_GENERAL_ERROR,
ASYNC_INVALID_HANDLE_ERROR: (*Запрос к неоткрытому/открытому не через асинхронную библиотеку файлу*)
f_work := F_NONE;
END_CASE
что это за префикс mem: в arc_filename? Вы точно ПЛК Овен используете? :D
Затмение какое-то. ram: конечно, надо.
Как получить список файлов на носителе (usb)?
Мне необходимо считывать файлы по сети на сервер. Я не могу придумать, как это сделать.
Файлов много (сотни в день, данные измерений).
Поэтому флешка для хранения. Необходим удаленный доступ к этим файлам.
Создаёте файл, содержащий список файлов. Т.к. только Вы создаёте файлы, Вы и знаете какие они и как называются.
Плохой способ.
Файлов много. Где хранить список? Постоянной памяти не хватит.
Да и сами же пишете, недолговечная она.
Тоже в виде файла? А при сбое в записи этого файла я теряю доступ сразу ко всем файлам?
Ну что за ...!!
Ну во всех файловых системах есть команда получить список файлов. В контроллерах Овен только такая файловая система, что невозможно получить список файлов! Ну как этого можно было добиться?!!
Если у Вас столько файлов, что их невозможно сосчитать - может быть ПЛК не подходит для решения задачи или задачу надо решить иначе?
Процедура получения списка файлов, с флешки, с каталогами, занимает ОЧЕНЬ много времени. О каком реальном времени будет идти речь в этом случае? Поэтому функции не поддержаны.
Они бессмыслены. ПЛК - не NAS.
Файлы у Вас генерятся по известному шаблону, т.е. Вы способны просканировать все файлы на наличие при старте ПЛК и в дальнейшем при работе с файлами поддерживать этот список актуальным.
И если файлов ожидается миллион - то да, места, наверное, не хватит, и запуск будет медленным - но не медленнее доступа через список файлов в директории. Зато он будет в RT, и не будет мешать основному циклу управления.
Как можно вытащить файл с флешки по сети?
Я пока что придумал только копировать в ram и отдавать через tftp.
Очень неудобно.
Вообще, раз у нас появилась флешка, ОВЕН ПЛК110 стал весьма подходить для системы сбора данных. Основное время пишем данные, а в перерывах, когда реальное время не критично, отдаем на сервер.
На флешку можно много данных записать.
А иначе вообще какой смысл в этом носителе?
Через RAM-диск. Вопрос безопасности и производительности. Если давать TFTP доступ к флешке - ПЛК только для какого-нибудь теплого пола можно использовать будет.Цитата:
Сообщение от Евгений Пашигоров
Ну или просто отправляйте данные в сыром виде по UDP, к примеру.
Пример выложенный на сайте с OwenLibFileAsync работает на отлично. Чуть модифицировал прикладную часть и все Заказчика устроило.
Пишется процесс, который потом можно проанализировать (что происходило) на компьютере.
В ПЛК110 время выставлено актуальное.
Вопрос возникает такой:
Заказчик жалуется на то, что файлы, которые он забирает с флешки всегда сохранены в 1980м году, хотя в названии файлов дата сохранения указанна верно.
Неудобно ему пересохранять файлы. Если просто складывать есть трудности сортировки по дате.
Выяснил: время создания файла всегда будет некорректное это ограничение файловой систем. Вопрос закрыт