Вход на форум 
В начало e-Mail

Форум

Ресурсы Rockwell

Product Directory

Essential Components

Literature Library

Knowledge Base

Electronic News&Magazines

Блог

Encompass Program

Product Certification

  


Предыдущие результаты



Предыдущие результаты



Предыдущие результаты

 [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 - стандартные структуры как в классических языках программирования.



Предыдущие результаты


Ещё результаты



Предыдущие результаты

Разделы


Предыдущие результаты



Предыдущие результаты


 Shadow (Дмитрий)

 Shadow (Дмитрий)

 Shadow (Дмитрий)

 ShadowADV (Дмитрий)

 Shagidullin (Ленар)

 shagov (Сергей)

 shagovs (Sergey)

 shairom (shai)

 Shakhvorosotv (Александр)

 shaktimur (Тимур)


Предыдущие результаты


Ещё результаты




Выберите страницу:   [ << Предыдущая страница ] 1 2 3 4


  
RA & VDT GmbH


Облако тэгов
RSLogix ControlLogix sound FTView Control Logix MVI56-104S 1734-AENTR Altivar Add-on Instruction MVI46MCM Ethernet PLC-5 SLC-500 1757-SRM Firmware ComactLogixL32E 1756-L75 1756-RM2 Controlnet cable Promass Client Memory 1769-L32E execution minutes seconds Windows Build 00000d5c Unspecified terminate geehrter automatisch keine globalen Fehlermeld

Яндекс цитирования

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.144 секунды