This is topic CALL - RFile(128)/WFile(129) in forum Редактор проекта TRACE MODE 6 / at Форум TRACE MODE: техническая поддержка.


To visit this topic, use this URL:
http://forum.adastra.ru/ultimatebb.php/ubb/get_topic/f/32/t/000184.html

Posted by Jurgen (Участник № / Member № 2755) on :
 
Уважаемая поддержка.
Подскажите, как корректно настроить канал типа CALL для записи атрибутов в файл с возможностью поддержки секций, как написано в help
Запись в файл (129, WFile) - при присвоении этому атрибуту значения N (натуральное число) текущие значения аргументов канала записываются в текстовый файл <имя канала>_<N>.dat, каждая строка которого содержит имя аргумента и его значение. Если имя канала содержит двоеточие (т.е. имеет вид <строка1>:<строка2>), то текущие значения аргументов канала записываются в секцию N файла с именем <строка1> без расширения;
В случае, когда имя канала в виде <строка1> и N - натуральное, запись в одноименный файл производится.
В случае, когда имя канала в виде <строка1>:<строка2> и N - натуральное, запись в секцию N файла НЕ производится. Создается просто пустой файл... В чем может быть проблема?
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
В документации отражен побочный эффект кода. Его последствия в ОС не гарантированы.
Этот механизм применять не рекомендуется. Его описание будет удалено из документации.
 
Posted by Dmitry.niimm (Участник № / Member № 3380) on :
 
Уважаемая техподдержка,

Поддержите, меня, пожалуйста, по поводу работы RFile/WFile.

Имеется некий канал Call c некоторым (у меня 720) количеством аргументов типа REAL и DATE_AND_TIME, идущими попеременно (два реала+время). Заполнение аргументов выполняется другим каналом через SetArgument, но это не важно и к делу не относится.

Итак, делаем WFile(1), т.е. посылаем в атрибут 129 единицу. В каталоге узла появляется файл .dat, в котором абсолютно правильно отображены все аргументы.

Теперь делаем тому же каналу RFile(1) и получаем: аргументы типа реал вычитаны не все - часть прочитано нормально, часть имеет значение 0, а несколько штук неправильное ненулевое значение; аргументы типа дейт_тайм либо не прочитались вообще (отображается "..."), либо потеряли время (т.е. осталась только дата и 0:00:00), но несколько штук оказалось в порядке.

Эксперименты показали, что если все аргументы имеют тип REAL, то чтение/запись работает на ура, а проблемы начинаются при наличии аргументов типа дата/время.
 
Posted by Dmitry.niimm (Участник № / Member № 3380) on :
 
И вдогонку...

Поменял тип всех аргументов DATE_AND_TIME на UDINT - все заработало как часы (китайские [Пдмигивание / Wink] ).

Вот только неудобно теперь проект отлаживать - время не прочитаешь.... 8((
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
В любом случае хранение данных происходит в формате UDINT. DATE_AND_TIME это лишь стиль отображения. Поэтому сохранять логичнее в формате UDINT
 
Posted by Dmitry.niimm (Участник № / Member № 3380) on :
 
И еще на одни грабли с этими функциями наступили:

Сохранение довольно большого (более 500 значений) массива, реализованного в виде канала Call с кучей аргументов (за неимением нормальной поддержки массивов в ТМ), у нас организовано через функции RFile/WFile, т.е. с некоторой периодичностью аргументы записываются в файл, а при старте монитора вычитываются.

НО. Уже дважды, по пока непонятной причине, данный файл оказывался испорченным, а именно: вместо нормальных данных внутри оказывалось несколько килобайт символов с кодом 255. В результате при старте монитор, попытавшись вычитать аргументы канала из файла, вылетал с ошибкой, и ситуация лечилась только изничтожением сейва.

И вопросы:

1. В результате чего мог накрыться данный файл? Есть подозрение, что машине делали ресет без останова программы и винда не сбросила буфера диска, но вряд ли - это уже второй случай с абсолютно одинаковыми симптомами.

2. Почему ТМ вылетает при нарушении структуры файла? Неужели так трудно при чтении выполнять проверки на переполнение буфера и т.п.?
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
1. Нехватило ресурсов, произошел сбой в системе, все что угодно. Нештатный выход, кстати, вполне вероятная причина такой проблемы.

2. В какой момент системы перестает работать: во время записи файла или чтения?
 
Posted by Dmitry.niimm (Участник № / Member № 3380) on :
 
1. Вариант нештатного выхода я не исключаю, но настораживает то, что это уже второй раз с абсолютно одинаковыми симптомами (вплоть до содержимого запоротого файла), а при неожиданном ребуте системы файлы с незакрытыми дескрипторами обычно или сбрасываются в нулевую длину или имеют случайное содержимое. Здесь же файл значительно увеличивается в размерах (точные цифры, каюсь, не запомнил, но где-то раз в 5) и содержит только символы FF.

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

2. Трудно сказать. Система стартует, выдает начальный экран и практически сразу валится. Учитывая, что интервал записи файла 5 секунд, может быть любой из двух вариантов. К сожалению, сейчас проверить не имею возможности - объект находится в другом городе. Попробую поэкспериментировать "на кошках", если что-то будет - напишу.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
1. А можете прислать этот поврежденный файл?

2. Можно отключить считывание файла и проверить будет ли сбои.

3. После генерации Вы как-то работаете с этими файлами? Меняете их, редактируете? Или просто сохраняете и подчитываете?
Можно поредкомендовать сохранение этих аргументов в файле DUMP (соответствующим каналам CALL надо установить флажок DUMP и задать файл сохранения состояния в настройках узла).
 
Posted by Dmitry.niimm (Участник № / Member № 3380) on :
 
1. Под рукой файла нет - объект находится в другом городе. Но особо там и рассматривать нечего - около 8 кб (размер нормального, "живого" файла обычно 3-4 кб) символов с кодом 255, т.е. никакого текста или другой осмысленной информации.

2. Попробуем. Хотя, как раз сегодня утром позвонили, что ситуация опять повторилась - система работала, но произошел сбой по питанию на подстанции и после перезагрезки компа файл снова оказался запорченным. Т.е. похоже, проблема именно из-за того, что происходит жесткий ребут в момент записи файла. Таким образом вопрос сводится не к тому, почему портится файл, а как избежать падения РТМ при попытке прочитать битый сейв.

3а. Просто сохраняем с интервалом несколько секунд и подчитываем при старте (т.е. делаем аналог дампа).

3б. А разве значения аргументов канала в дампе сохраняются? Сначала я так и пытался делать, но не работало, а потом в документации прочитал, что в дамп пишутся только атрибуты, а не аргументы.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Понятно. Аргументы каналов Call в дампе должны сохранятся. Используйте этот механизм.
 
Posted by DmitryL (Участник № / Member № 6247) on :
 
Здраствуйте!
Требуется создать программу, обрабатывающую массив состоящий из 80 значений. Пожелание заказчика: обеспечить возможность внесения изменений в массив без дополнительной компиляции программы (и проекта) операторским составом предприятия.
В идеале, значения массива должны подгружаться из файла, расположенного в папке узла.
На наш взляд, для нашей цели подошел бы канал типа CALL с атирибутом RFile(128). Но к сожалению, информации в справочной литературе по работе RFile нет.
Подскажите пожалуйста:
1. Где можно более подробно ознакомится с RFile(128)/WFile(129)?
2. Как можно прочитать текст из файла в строковую переменную? Есть ли функции преобразования строк в число в Техно ST?
2. Каким другим способом можно решить нашу проблему?
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
1. Вся информация по работе с атрибутами 128 и 129 канала CALL представлена в разделе "Атрибуты канала класса CALL".

2. Если надо импортировать числовые значения, зачем преобразовывать их в строку? В аргументы канала CALL импорт из файла осуществляется в формате, соответствующем типам данных аргументов.
Числа из текстового файла в числовые аргументы будут импортироваться в числовом формате.

3. Строки в число преобразовать нельзя.

4. Возможный вариант импорта - из БД.
 
Posted by DmitryL (Участник № / Member № 6247) on :
 
ответ на первый вопрос нашел в тестовых примерах. Прошу прощения за невнимательность
 


Новости АСУ ТП / News | SCADA / HMI | Обучение / Trainings | Свяжитесь с нами / Contact Us



Powered by Infopop Corporation
UBB.classic™ 6.7.2