Доброго времени суток форумчане!
Подскажите как создать блок ADD который складывает 1 раз в секунду в главной рутине контроллера, а не каждый цикл контроллера. Максимум чего добился создание нового 1-секундного TASKа.
Так же имеется второй вопрос:
Создал мною написанный блок в ADD-ON-Instructions-можно ли его как нибудь отлаживать онлайн?Не нашел вообще онлайна для созданного блока в ADD-ON-Instructions, соответственно не нашел возможности редактировать этот блок когда контроллер в онлайне.
Помогите пожалуйста решить эти вопросы буду признателен)
Add-On инструкции позволяют сделать сложные программы более структурированными и наглядными, что облегчает отладку сложных проектов.
Эти инструкции, будучи однажды отлаженными, становятся как бы новыми командами, повышая удобство программирования. Отлаженный и проверенный код этих инструкций повышает надежность программы, т.к. уменьшает вероятность ошибок. _________________ Обращайтесь к профессионалам.
Доброго времени суток форумчане!
Подскажите как создать блок ADD который складывает 1 раз в секунду в главной рутине контроллера, а не каждый цикл контроллера. Максимум чего добился создание нового 1-секундного TASKа.
Так же имеется второй вопрос:
Создал мною написанный блок в ADD-ON-Instructions-можно ли его как нибудь отлаживать онлайн?Не нашел вообще онлайна для созданного блока в ADD-ON-Instructions, соответственно не нашел возможности редактировать этот блок когда контроллер в онлайне.
Помогите пожалуйста решить эти вопросы буду признателен)
Можете использовать мой вариант, все прекрасно считает, однако остается проблема с насыщением, если у вас очень большой расход то после 999 999.99 появится экспанента, как вариант предется делать обнуление накопителя. Пример
Работал долго время на сименсе-там есть возможность написать так называемые FB(FC) блоки-которые просто незаменимы когда не возможно использовать блоки из стандартной библиотеки и для нестандартных задач-и там есть полная возможность их отладки в онлайне!!!У роквела я думал Add-on-instructions подобие FB(FC) сименса-но без онлайна как было сказано выше это понтовая фишка)
Тогда встает вопрос-как быть если нужно создать блок под определенную задачи и которого нет в стандартной библиотеке (Ибо после сименса она убогая)?
Есть ли у роквела что-то типо надстройки (Библиотеки) блоков (У сименса аналог CEMAT)-читал много инфы про роквел-но пока подобного не встречал.
Создаешь Routine в программе, потом вызываешь ее с помощью хоть JSR инструкции, хоть FOR для циклического вызова c индексацией.
В отличие от сименса, тут допустима запись вида array1[index1,index2]
Т.е. тут реализовано стандартное структурное процедурное программирование. UserType - стандартные структуры как в классических языках программирования.
И все равно из выше написанного не увидел как сделать выполнение любого блока 1 раз в секунду в главной рутине(
Вам же уже написали:
AlexV писал(а):
Простейшие вариант:
таймер TON, после его DN - ONS RES ADD инструкции
Таймер считает в главной программе, и ADD считается только в том цикле, в котором устанавливается DN таймер, т.е. каждую секунду.
Позвольте также поинтересоваться, чем Вам не нравится задача, запускаемая ядром операционной системы контроллера точно раз в секунду? Этот механизм специально придуман именно для того, чтобы реализовывать функции, подлежащие периодическому выполнению. При этом Ваш ADD будет считаться в такой задаче принципиально более точно, чем при реализации периодического "интегрирования" пользовательским таймером. Объяснить, почему? _________________ Обращайтесь к профессионалам.
Последний раз редактировалось: oldDad (Вт 08 Июл, 2014 18:28:13), всего редактировалось 1 раз
mp3corp - Ваша инструкция ADD не выполняется раз в секунду-она выполняется раз в цикл контроллера при выполнении условия GRT.
И все равно из выше написанного не увидел как сделать выполнение любого блока 1 раз в секунду в главной рутине(
Почему, таймер 1000 мс, как только он насчитает бит DN станет - 1, далее идет 1 цикл счета и сброс таймера в 0 и так по кругу.
Условие GRT служит для того, чтоб расход не начал считать в обр. сторону, например будет ток <4 ма...
При этом Ваш ADD будет считаться в такой задаче принципиально более точно, чем при реализации периодического "интегрирования" пользовательским таймером. Объяснить, почему?
Объясните если не сложно. Ведь, насколько я могу помнить, период опроса модулей ввода-вывода не связан с выполнением остальных задач и одно и то же значение будет использовано как при обработке по таймеру, так и в отдельной задаче. Какой нюанс я забыл?
(Без сарказма, действительно интересно где я ошибаюсь.)
Давайте посмотрим на момент, в который выяснится, что таймер в фоновой пользовательской программе досчитал до DN и пора выполнять действия.
Момент, когда таймер отсчитает 1000мс, - это необязательно момент, когда фоновой задаче станет это известно, т.к. время пользовательского таймера течет асинхронно по отношению к актуальному времени, текущему в скане фоновой задачи. Время этого таймера течет параллельно скану фоновой задачи и отсчитывается системным таймером ядра операционной системы.
С высокой вероятностью, то, что таймер готов, выяснится только через некоторое время (несколько единиц миллисекунд или даже десяток миллисекунд) после того, как этот таймер станет готов.
Иначе говоря, факт DN выяснится через время
T = Tpre + Тот_начала_скана_мс.
Это время, в принципе, нестабильно, т.к. Тот_начала_скана_мс до обнаружения факта готовности таймера зависит от актуального времени скана, которое колеблется.
Эти флюкутации времени скана зависят, как мы знаем, от количества и характера имеющихся в фоновой задаче зависящих от внешних условий логических операций (actions) и связанных с ними действий (reactions), как от начала скана до момента определения готовности пользовательского таймера, так и после него до конца скана и, затем, снова из конца программы в начало следующего скана, от предшествующей этому моменту в следующем скане логики и связанных с этой логикой действий. Такие флюктуации могут достигать единиц и даже иной раз десятков миллисекунд.
Кроме того, как мы знаем, в многозадачной операционной среде реального времени с прерываниями работают задачи, имеющие более высокий, по отношению к фоновой задаче, приоритет, которые рвут контекст фоновой задачи тогда, когда им нужно, и так надолго, насколько им нужно. Они отбирают у фоновой задачи процессор и возвращают его ей через некоторое (также неопределенное) время, которое им необходимо для обработки, и которое также нестабильно.
В итоге, в такой системе флюктуации момента обнаружения готовности пользовательского таймера, расположенного в фоновой задаче, могут составлять даже десятки миллисекунд. А если рвущая фоновую задачу более приоритетная задача прерывается ещё более приоритетной и.т.п., каждая из которых (непредсказуемо для фоновой задачи) требует процессорного времени, то и еще больше.
Если, к тому же, система построена неоптимальным образом, и более приоритетные задачи загружены сильнее, чем низкоприоритетные, что в корне неверно, или же вообще не используется многозадачность, а всё тупо прописывается в одной фоновой задаче, то система превращается в тормоз ( всё в относительном времени, разумеется), и её динамика будет в несколько раз хуже, чем у оптимизированой многозадачной среды.
Теперь давайте рассмотрим альтернативу.
Имеется очень короткая очень высокоприоритетная задача, запускаемая периодически раз в секунду по системному таймеру ядра, имеющему наивысший приоритет. Эта задача состоит из строчки с оператором ADD, где наращивается интегральный расход. И всё. Логику сброса интегрального расхода в нужной ситуации можно спокойно поместить в фоновую задачу.
Время выполнения такой высокоприоритетной задачи будет доли миллисекунды, это время будет всегда идентично, без вариаций, и она всегда будет запускаться ровно раз в секунду, без никаких флюктуаций, по системному таймеру ядра операционной системы. Поэтому точность вычисления интегрального расхода в этом случае будет намного выше.
Немножко сложновато да? Задавайте вопросы, если что. _________________ Обращайтесь к профессионалам.
Последний раз редактировалось: oldDad (Вт 08 Июл, 2014 21:58:20), всего редактировалось 1 раз
Немножко сложновато да? Задавайте вопросы, если что.
Да нет, ничего сложного, просто действительно забыл что где исполняется и что continuous task (это ведь она кроется под "фоновой пользовательской программой"?)имеет низкий приоритет.
А можно и без ONS RES если записать:
XIC Timer.DN ADD Variable Accum Accum
XIO Timer.DN TON 1000 0
Нельзя!
Логическая ошибка, ADD будет выполняться на следующий скан после установки DN таймера.
Ну, расчет суммы задержится на один скан, но работать будет и даже результат сильно не изменится т.к. все отсчеты на этот один скан будут сдвинуты. Строки можно местами поменять, тоже работать будет, и уже в том же скане когда DN установится.
В данном примере просто хотел показать что для управления таймером можно обойтись без доп. операторов (ONS & RES) если знать что сброс входного условия таймера сбрасывает его аккумулятор, что в свою очередь приводит к сбросу бита DN.
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
Smart Solutions VDT GmbH | Friedrich-List-Allee 38, D-41844 Wegberg-Wildenrath, Germany Tel.: +49 2432 933 57 83 | e-Mail: office@vdt-solutions.de Все товарные знаки и торговые марки являются собственностью их владельцев.
При использовании материалов сайта ссылка на данный сайт обязательна. Открытие страницы: 0.136 секунды
FAQ
Поиск
Группы
Профиль
Войти и проверить личные сообщения
Вход
