Уважаемая поддержка. Подскажите, как корректно настроить канал типа 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 - все заработало как часы (китайские ).
Вот только неудобно теперь проект отлаживать - время не прочитаешь.... 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 :
ответ на первый вопрос нашел в тестовых примерах. Прошу прощения за невнимательность
![[Пдмигивание / Wink]](wink.gif)
).