Работа с USB Flash карт в новом ПЛК110

[energvk]

У меня такая проблема тоже была при использовании SysLibFile на М02, пришел на OwenLibFileAsync.
Для форматирование есть команда в ПЛК-Браузер formatFFS.

у меня на обеих библиотеках такая проблема. Возможно потому что изначально попробовал на SysLibFile?
Просто в списке команд такой нет, не знал. Спасибо, попробую

[monteg]

И не забудьте, что OwenFileOpenAsync, stMode = 'a', 'w+', 'r'

[energvk]

Да это вроде помню)

[Филоненко Владислав]

в case 2 Вы задаёте библиотеке следующую команду, в Вашем случае на запись.
а в case 3 вы периодически опрашиваете библиотеку: "Не выполнила ли ты мою команду"

Собственно запись в файл происходит асинхронно в промежутке между case2 и ответом ASYNC_DONE в case3.

И подавать на вход функции записи строку надо всегда одну и ту же и не менять её значение до ASYNC_DONE! Стековые переменные для данных записи не использовать, только статические или глобальные переменные.

[ovkru]

Спасибо.

Стековые переменные для данных записи не использовать, только статические или глобальные переменные.

Следовать этому совету - возражений нет. Однако, хотелось бы уточнить понятия: стековые, статические переменные. В РЭ ПЛК (в.1.9) в "Руководстве пользователя по программированию ПЛК в CoDeSys 2.3" упоминаются "стек ранее введенных команд", "стек вызовов". Стековые переменные не упоминаются. Статические переменные тоже.
Прошу уточнить Ваш совет.

[Филоненко Владислав]

в "Руководстве пользователя по программированию ПЛК в CoDeSys 2.3" нет основ программирования, подразумевается, что они уже изучены

Если Вы получили строку/массив через входные параметры функции/ФБ - это 95% стековая переменная.
Если Вы получили переменную по указателю - её содержимое внезапно может поменяться где-то там и Вы получите трудноотлаживаемую ошибку.
Если Вы объявили переменную в блоке VAR - она статическая
Если Вы объявили переменную в блоке VAR_GLOBAL - она глобальная

[Филоненко Владислав]

SysFileReadAsync === SysFileRead + асинхронность. Чего там угадывать то. И пример есть.

[-=Vovka=-]

Добрый день!
На втором этапе появляется статус

ASYNC_QUERY_FULL:= -1001, (*>5 запросов в очереди*)

- как с этим бороться?

 CASE g_LogState OF
  0:	(*Открытие файла - этап 1*)
    g_LogRes := OwenFileOpenAsync( g_LogFileLog, 'a', ADR(g_LogHandle));
    IF g_LogRes = ASYNC_WORKING THEN g_LogState := 1;
    END_IF

  1:	(*Открытие файла - этап 2*)
   g_LogRes := OwenFileOpenAsync( g_LogFileLog, 'a', ADR(g_LogHandle));
   IF g_LogRes = ASYNC_DONE  THEN
    IF g_LogHandle<>0 THEN	g_LogState := 2;
    ELSE				g_LogState := 0;
    END_IF
   ELSIF g_LogRes<0 THEN
    g_LogState := 0;
   END_IF
 .....

[Евгений Пашигоров]

О библиотеке OwenLibFileAsync.

Читаю только что скачанную документацию.
Какая-то путаница с возвращаемыми типами у функций:

Функция SysFileOpenAsync
Функция возвращает значение типа DWORD

Функция SysFileCloseAsync
возвращает значение типа BOOL

Функция SysFileWriteAsync
возвращает значение типа DWORD – количество записанных байт данных

А в примерах функции вызываются в виде:

res:=OwenFileXxxAsync(xxx);

переменная res имеет тип ASYNC_RET_VALUE (в документации отсутствует описание этого типа, догадайся сам)

Ну ладно, ASYNC_RET_VALUE, допустим, совместимо с DWORD (как по мне, должна быть ошибка), но DWORD и BOOL один и тот же тип?

Примеры с IF-ами и CASE-ми выглядят громоздко и запутанно.

Я бы хотел написать так:

(***********************************************************)
VAR
    f_work: T_F_WORK; (*перечислимый тип: открыть, закрыть, записать и т.д.*)
    res: ASYNC_RET_VALUE;
END_VAR

(*вызываем нужную функцию*)

CASE f_work OF

	F_OPEN:
			res := OwenFileOpenAsync(f_name,'a',ADR(f_handle));
	F_CLOSE:
			res := OwenFileCloseAsync(f_handle, ADR(f_result));
	F_WRITE:
			res := OwenFileWriteAsync(f_handle, ADR(f_buff), SIZEOF(f_buff), ADR(f_result));
	F_NONE: ;

END_CASE

(*обрабатываем результат*)

CASE res OF

	ASYNC_WORKING: (*ждем...*);

	ASYNC_DONE:
		f_work := F_NONE;
        (*проверка на ошибки*)
          (*...*);
    (*а еще res возвращает некоторые ошибки!*)
    (*как к ним относиться, неясно*)
    (*но ведь как-то надо обработать!*)
(*  ASYNC_PAUSED:
    ASYNC_QUERY_FULL:
    ASYNC_BLOCK_ACCESS:
    ASYNC_GENERAL_ERROR:
    ASYNC_INVALID_HANDLE_ERROR:
*)
END_CASE
(********************************************************************)

Гораздо компактнее и проще.

И опять, в описании не сказано, имеется ли логическая переменная для возврата наличия ошибки для всех функций (в старом описании такая переменная имелась). А ведь это позволит написать обработку файловых ошибок в одном месте, а не размазывать по всей программе.

Документацию надо бы поправить и дополнить.

[A.Simonov]

Добрый день.

Все функции возвращают тип ASYNC_RET_VALUE

Описание этого типа есть в самой библиотеке

ASYNC_RET_VALUE.png

Коды ошибок попадают в переменную res (типа ASYNC_RET_VALUE).
Через CASE они обрабатываются без проблем.