 | |
Предыдущие результаты
[quote:67a9dfeedd="oldDad"][quote:67a9dfeedd="DiabloXan"]И все равно из выше написанного не увидел как сделать выполнение любого блока 1 раз в секунду в главной рутине([/quote:67a9dfeedd]
Вам же уже написали:
[quote:67a9dfeedd="AlexV"]Простейшие вариант:
таймер TON, после его DN - ONS RES ADD инструкции[/quote:67a9dfeedd]
Таймер считает в главной программе, и ADD считается только в том цикле, в котором устанавливается DN таймер, т.е. каждую секунду.
Позвольте также поинтересоваться, чем Вам не нравится задача, запускаемая ядром операционной системы контроллера точно раз в секунду? Этот механизм специально придуман именно для того, чтобы реализовывать функции, подлежащие периодическому выполнению. При этом Ваш ADD будет считаться в такой задаче принципиально более точно, чем при реализации периодического "интегрирования" пользовательским таймером. Объяснить, почему?[/quote:67a9dfeedd]
Всем огромное спасибо<вроде более менее разобрался!
oldDAD - Не нравится тем что нельзя объединять процедуры или блоки в процедурах в задаче запускаемой ядром операционной системы контроллера 1 раз в секунду и главной задачи контроллера-я работал на сименсе и там все вместе (можно выбрать цикличность любого блока поотдельности)-ну привык я так, мне удобнее - не судите строго, кому как удобнее)
|
[quote:2f71e9d8a4="DiabloXan"]как быть если нужно создать блок под определенную задачи и которого нет в стандартной библиотеке
[/quote:2f71e9d8a4] Создайте свои собственные AOI. Они именно для этого и предназначены.
[quote:2f71e9d8a4]Есть ли у роквела что-то типо надстройки (Библиотеки) блоков (У сименса аналог CEMAT)-читал много инфы про роквел-но пока подобного не встречал.[/quote:2f71e9d8a4]
Это называется [url=http://search.rockwellautomation.com/search?site=sample_code&client=samplecode&output=xml_no_dtd&proxystylesheet=samplecode]Sample Code Library[/url].
Наберите в поисковой строке, например, [url=http://search.rockwellautomation.com/search?q=AOI&filter=0&num=20&getfields=*&btnG=Search&client=samplecode&output=xml_no_dtd&proxystylesheet=samplecode&ulang=de&sort=date%3AD%3AL%3Ad1&entqrm=2&wc=200&wc_mc=1&oe=UTF-8&ie=UTF-8&ud=1&exclude_apps=1&site=sample_code]AOI[/url].
|
[quote:952f4cfd99="AlexV"][quote:952f4cfd99="Locky"]А можно и без ONS RES если записать:
XIC Timer.DN ADD Variable Accum Accum
XIO Timer.DN TON 1000 0[/quote:952f4cfd99]
Нельзя! :P
Логическая ошибка, ADD будет выполняться на следующий скан после установки DN таймера.[/quote:952f4cfd99]Ну, расчет суммы задержится на один скан, но работать будет и даже результат сильно не изменится т.к. все отсчеты на этот один скан будут сдвинуты. Строки можно местами поменять, тоже работать будет, и уже в том же скане когда DN установится. :P
В данном примере просто хотел показать что для управления таймером можно обойтись без доп. операторов (ONS & RES) если знать что сброс входного условия таймера сбрасывает его аккумулятор, что в свою очередь приводит к сбросу бита DN.
|
[quote:b8f7578fc8="Locky"]А можно и без ONS RES если записать:
XIC Timer.DN ADD Variable Accum Accum
XIO Timer.DN TON 1000 0[/quote:b8f7578fc8]
Нельзя! :P
Логическая ошибка, ADD будет выполняться на следующий скан после установки DN таймера.
И еще добавлю свои 5 копеек :roll:
Фоновая задача имеет не просто низкий, а САМЫЙ низкий приоритет.
|
[quote:a88c028a49="oldDad"]Немножко сложновато да? Задавайте вопросы, если что.[/quote:a88c028a49]Да нет, ничего сложного, просто действительно забыл что где исполняется и что continuous task (это ведь она кроется под "фоновой пользовательской программой"?)имеет низкий приоритет.
Большое СПАСИБО за столь подробный ответ.
|
Давайте посмотрим на момент, в который выяснится, что таймер в фоновой пользовательской программе досчитал до DN и пора выполнять действия.
Момент, когда таймер отсчитает 1000мс, - это необязательно момент, когда фоновой задаче станет это известно, т.к. время пользовательского таймера течет асинхронно по отношению к актуальному времени, текущему в скане фоновой задачи. Время этого таймера течет параллельно скану фоновой задачи и отсчитывается системным таймером ядра операционной системы.
С высокой вероятностью, то, что таймер готов, выяснится только через некоторое время ([i:95e6ec6eb6]несколько[/i:95e6ec6eb6] единиц миллисекунд или даже десяток миллисекунд) после того, как этот таймер станет готов.
Иначе говоря, факт DN выяснится через время
[b:95e6ec6eb6]T [/b:95e6ec6eb6]= [b:95e6ec6eb6]T[/b:95e6ec6eb6]pre + [b:95e6ec6eb6]Т[/b:95e6ec6eb6]от_начала_скана_мс.
Это время, в принципе, нестабильно, т.к. [b:95e6ec6eb6]Т[/b:95e6ec6eb6]от_начала_скана_мс до обнаружения факта готовности таймера зависит от актуального времени скана, которое колеблется.
Эти флюкутации времени скана зависят, как мы знаем, от количества и характера имеющихся в фоновой задаче зависящих от внешних условий логических операций (actions) и связанных с ними действий (reactions), как от начала скана до момента определения готовности пользовательского таймера, так и после него до конца скана и, затем, снова из конца программы в начало следующего скана, от предшествующей этому моменту в следующем скане логики и связанных с этой логикой действий. Такие флюктуации могут достигать единиц и даже иной раз десятков миллисекунд.
Кроме того, как мы знаем, в многозадачной операционной среде реального времени с прерываниями работают задачи, имеющие более высокий, по отношению к фоновой задаче, приоритет, которые рвут контекст фоновой задачи тогда, когда им нужно, и так надолго, насколько им нужно. Они отбирают у фоновой задачи процессор и возвращают его ей через некоторое (также неопределенное) время, которое им необходимо для обработки, и которое также нестабильно.
В итоге, в такой системе флюктуации момента обнаружения готовности пользовательского таймера, расположенного в фоновой задаче, могут составлять даже десятки миллисекунд. А если рвущая фоновую задачу более приоритетная задача прерывается ещё более приоритетной и.т.п., каждая из которых (непредсказуемо для фоновой задачи) требует процессорного времени, то и еще больше.
Если, к тому же, система построена неоптимальным образом, и более приоритетные задачи загружены сильнее, чем низкоприоритетные, что в корне неверно, или же вообще не используется многозадачность, а всё тупо прописывается в одной фоновой задаче, то система превращается в тормоз ( всё в относительном времени, разумеется), и её динамика будет в несколько раз хуже, чем у оптимизированой многозадачной среды.
Теперь давайте рассмотрим альтернативу.
Имеется очень короткая очень высокоприоритетная задача, запускаемая периодически раз в секунду по системному таймеру ядра, имеющему наивысший приоритет. Эта задача состоит из строчки с оператором ADD, где наращивается интегральный расход. И всё. Логику сброса интегрального расхода в нужной ситуации можно спокойно поместить в фоновую задачу.
Время выполнения такой высокоприоритетной задачи будет доли миллисекунды, это время будет [i:95e6ec6eb6]всегда[/i:95e6ec6eb6] идентично, без вариаций, и она [i:95e6ec6eb6]всегда[/i:95e6ec6eb6] будет запускаться [i:95e6ec6eb6]ровно раз в секунду[/i:95e6ec6eb6], без никаких флюктуаций, по системному таймеру ядра операционной системы. Поэтому точность вычисления интегрального расхода в этом случае будет намного выше.
Немножко сложновато да? Задавайте вопросы, если что.
|
[quote:ed920ff713="AlexV"]Простейшие вариант: таймер TON, после его DN - ONS RES ADD инструкции[/quote:ed920ff713]А можно и без ONS RES если записать:
XIC Timer.DN ADD Variable Accum Accum
XIO Timer.DN TON 1000 0
|
[quote:ad091eb44f="DiabloXan"]И все равно из выше написанного не увидел как сделать выполнение любого блока 1 раз в секунду в главной рутине([/quote:ad091eb44f]
Вам же уже написали:
[quote:ad091eb44f="AlexV"]Простейшие вариант:
таймер TON, после его DN - ONS RES ADD инструкции[/quote:ad091eb44f]
Таймер считает в главной программе, и ADD считается только в том цикле, в котором устанавливается DN таймер, т.е. каждую секунду.
Позвольте также поинтересоваться, чем Вам не нравится задача, запускаемая ядром операционной системы контроллера точно раз в секунду? Этот механизм специально придуман именно для того, чтобы реализовывать функции, подлежащие периодическому выполнению. При этом Ваш ADD будет считаться в такой задаче принципиально более точно, чем при реализации периодического "интегрирования" пользовательским таймером. Объяснить, почему?
|
Столкнулся с такой проблемкой:
не удаётся прочитать/записать данные в/из контроллера MicroLogix1400.
Инструкции MSG(в slc) вываливаются в ошибку(connection was broken).
Между собой две slc-хи общаются нормально, а с ложиком не хотят.
Может кто сталкивался с такой проблемой?
В линксе контроллер виден, данные через дата-монитор доступны.
|
Создаешь Routine в программе, потом вызываешь ее с помощью хоть JSR инструкции, хоть FOR для циклического вызова c индексацией.
В отличие от сименса, тут допустима запись вида array1[index1,index2]
Т.е. тут реализовано стандартное структурное процедурное программирование. UserType - стандартные структуры как в классических языках программирования.
|
Предыдущие результаты
Ещё результаты |
|
| |
|