This is topic 2 небольшие проблемы в одной теме: вывод строк и время пересчета in forum TRACE MODE 6 бесплатная Базовая версия / TRACE MODE 6 free Base version at Форум TRACE MODE: техническая поддержка.
1-я проблема: задача: необходимо выводить в текстовый графический элемент некие сообщения из программы в зависимости от результатов "вычислений" попытка решения: - создается аргумент экрана типа string и in - создается аргумент программы типа string и out - создается ГЭ типа "текст" - аргумент программы привязывается к аргументу экрана - ГЭ "текст" привязывается к тому же аргументу экрана результат: строка выводится, но лишь первые 4 символа вопрос: что можно сделать, чтобы сообщение из программы выводилось целиком?
2-я проблема: задача: установить для критических частей проекта минимальное время пересчета, равное по ттх системы 10 мс попытка решения: - в редакторе узла установлен период=1 и разрешение=0,01 - в редакторе программы во вкладке "основные" период=1 и единица измерения=цикл calk для проверки создан счетчик - аргумент программы, который считает от 0 до 6000. счетчик привязан к ГЭ "текст" экрана. результат: полный цикл счета осуществляется примерно за 95 секунд, т.е. временная дискретность системы получилась 16 мс, а не 10. причем результат абсолютно одинаков на 2 компьютерах (2-ядерный ноут и 4-ядерный компутер). попытка сэкономить на графике установив в редакторе период=10 (100 мс), а потом период=100 (1 секунда) ничего не изменили вопрос: как все-таки обеспечить цикл пересчета 10 мс? в принципе и 16 мс с натяжкой можно считать приемлемым результатом. но этот результат должен быть предсказуемым. т.е. если 10 мс - значит 10 мс, если 16 - значит 16 и т.д. или может это связано с настройками уиндоуззз?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1. При связи между аргументами экрана и программы передается только 4 символа (это документировано). Чтобы передать большее количество символов, используйте в качестве промежуточного компонента текстовый атрибут какого-либо канала, например, КОММЕНТАРИЙ.
2. Реальное квантование по времени ресурса CPU, предоставляемого приложению, определяется в ОС. В Windows это теоретически 10 мс. Но, видимо от настроек ОС и реальной загрузки ПК этот квант может возрастать. Экспериментально получено на двух ПК с Windows 7: заданный период 10 мс на типовом проекте поддерживается в пределах 10-11 мс. В Windows XP (на двух ПК) на том же проекте был получен реальный период 15 мс.
Возможно, что общий период узла можно оставить достаточно большим, а в критических частях задать период FAST (с соответствующим заданием величины периода ключом FSTLOOP в файле *.cnf.
Posted by merny (Участник № / Member № 2290) on :
quote:Отправитель / Originally posted by AdAstra Technical Support: 1. При связи между аргументами экрана и программы передается только 4 символа (это документировано). Чтобы передать большее количество символов, используйте в качестве промежуточного компонента текстовый атрибут какого-либо канала, например, КОММЕНТАРИЙ.
2. Реальное квантование по времени ресурса CPU, предоставляемого приложению, определяется в ОС. В Windows это теоретически 10 мс. Но, видимо от настроек ОС и реальной загрузки ПК этот квант может возрастать. Экспериментально получено на двух ПК с Windows 7: заданный период 10 мс на типовом проекте поддерживается в пределах 10-11 мс. В Windows XP (на двух ПК) на том же проекте был получен реальный период 15 мс.
Возможно, что общий период узла можно оставить достаточно большим, а в критических частях задать период FAST (с соответствующим заданием величины периода ключом FSTLOOP в файле *.cnf.
да, у меня на обеих машинах стоит ХР, наверное это особенность системы в "справке" есть подробное описание FAST?
Posted by merny (Участник № / Member № 2290) on :
что-то я не нашел ни одного файла с расширением cnf
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
О периоде пересчета FAST см. раздел "Период пересчета канала", о ключе FSTLOOP и файле *.cnf - раздел "Задание параметров работы мониторов".
Posted by merny (Участник № / Member № 2290) on :
про цикл FAST в справке сказано следующее: "(9) цикл FAST – период в циклах FAST (см. Потоки монитора );" и это все правильно ли я понимаю логику работы в режиме "жесткого" реального времени: - вместо цикла CALC указать цикл FAST - конкретную длительность периода пересчета задать в файле *.cnf в ключе FSTLOOP - на этом всё
теперь вопросы по *.cnf - этот файл штатно существует где-то или его надо создавать вручную (похоже, что вручную)? - в имени файла TMcom_<ordinal>.cnf под <ordinal> понимается имя файла проекта? - время цикла FAST задается в миллисекундах. какой диапазон допустимых значений? можно ли записать любое количество миллисекунд, хоть 1 мс? насколько стабильно выдерживается цикл (важна не минимальная длительность а именно стабильность)?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Вы правильно понимаете порядок задания периода обработки FAST.
Согласно документации: - файл TMcom_<ordinal>.cnf создается проектировщиком вручную и помещается в папку узла ("Некоторые параметры работы мониторов могут быть заданы с помощью ключей команды запуска или с помощью файла TMcom_<ordinal>.cnf (создается вручную в папке узла). "), - в разделе "Имена и идентификаторы объектов структуры" указано "Узлы нумеруются (начиная с 0) по порядку их создания в проекте и сохраняют свои порядковые номера (ordinal) при любых операциях с узлами в ИС. ". В папке узла , например, файл базы каналов <имя проекта>_<ordinal>.dbb.
Методического ограничения на задание величины периода FAST нет. Однако реально период не будет меньше разрешения, которое задано в настройках узла в разделе "Пересчет" на вкладке "Основные", и кванта времени, реализуемого ОС (не менее 10 мс). Стабильность периода пересчета определяется стабильностью квантования со стороны ОС (см. предыдущие посты).
Posted by merny (Участник № / Member № 2290) on :
но тогда не видно разницы. я задаю период 1 и разрешение 0,01 (10 мс) для узла и получаю 16 мс из-за особенностей ХР в цикле FAST я могу задать 10 мс и все равно получу 16 мс, т.к. операционная система та же и работает так же значит выход один - исходить из минимального кванта в 16 мс и к нему привязывать длительность критически важных процессов, а в редакторе узла задавать как и прежде 10 мс (1*0,01с), т.к. при задании 16 мс можно нарваться на увеличение периода в 1,5 раза, т.е. миллисекунд на 20 конечно, было бы удобнее, если бы инструментальная система и мрв подстраивались бы под разницу между теоретическим (10 мс) и реальным квантами времени. иначе все процессы, привязанные к данному кванту, выходят пропорционально более медленными
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Если Вы для всего узла зададите цикл пересчета 1*0.01, то вполне вероятна ситуация, когда для реализации всех задач основного потока 10-16 мс будет недостаточно и реальный цикл обработки, в том числе и для критических задач, будет увеличен.
Если "некритические" задачи будут обрабатываться в основном потоке с периодом, существенно большим, чем 10-16 мс, то критические задачи в потоке FAST будут выполняться с большей динамикой.
Posted by merny (Участник № / Member № 2290) on :
ну у меня проект маленький, из одного узла, одной программы и 2-3 экранов. когда-то я аналогичное лет 15-20 назад писал на ассемблере и на 386 процессоре это выполнялось с дискретизацией 25 мкс. ТМ это не ассемблер, но и современные компьютеры несколько производительнее 386. да и дискретизация в 25 мкс не требуется. в перспективе критическую задачу планирую перевести в отдельный контроллер (там даже плавающей точки нет, но все равно он справится) а за ТМ оставлю медленную электроавтоматику и графику вопрос еще и в следующем: если указать период 1 и разрешение 1 (1 с), то реальное время пересчета будет 1 секунда или 1,6 секунды?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1 секунда.
Posted by merny (Участник № / Member № 2290) on :
провел проверку времени пересчета схема следующая: вывод во внешний модуль поочередно высокого и низкого напряжения на каждом вызове программы. протокол modbustcp так что быстродействие протокола влиять не должно. к выходу напряжения подключил осциллограф результат: меандра с частотой 50 Гц (по 10 мс на высокий и низкий уровень) обнаружить не удалось. вместо этого наблюдается хаотичная последовательность импульсов и промежутков между ними с длительностью кратной 10 мс (от 10 мс до 30 мс) со средним значением на длительном промежутке (сравнимом с секундой) около 16 мс что это? 1) либо виндоуз глотает кванты времени и выделяет их не гарантированно по 10 мс, а кратно этому числу 2) либо tracemode не всегда справляется за выделенный ей квант времени
я склоняюсь к первому варианту, т.к. трудно предположить что современный компьютер не успевает вывести число за такое огромное время как 10 мс
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
