Куда вам такая реакция? И встречный вопрос: "Используя ПЛК с временем цикла равным миллисекундам откуда вы возьмете микросекунды?"
Куда вам такая реакция? И встречный вопрос: "Используя ПЛК с временем цикла равным миллисекундам откуда вы возьмете микросекунды?"
Аппаратное прерывание — когда процессор при некотором событии в железе забывает про всё на свете и бежит исполнять кусок кода (обработчик), который зарегистрирован на это прерывание, а уже потом возвращается к рутине. В автоматизации фишка часто встречается урезанной до «тупого» счётчика импульсов, который нужен, например, для энкодера.Используя ПЛК с временем цикла равным миллисекундам откуда вы возьмете микросекунды?
Только Вы понимаете, что при написании такой программы обработки прерывания должны выполнятся весьма жесткие требования?
Я это понял так: от момента появления сигнала на DI вызвать кусок кода, обработать его и отдать управляющий сигнал на DO. И все это за 10мкс. Если не прав, ок, учту.а существует ли возможность на ПЛК Овен создать полноценное аппаратное прерывание по сигналу с любого входа со временем реакции, ну хотя бы 10мкс?
термины не путаете?
http://social.msdn.microsoft.com/Sea...%82%D1%8C&ac=4
Конечно же без быстрых выходов в такое время не уложиться. Но реакция это не обязательно вывод сигнала на выход ПЛК — вполне может быть и просто регистрация событий с высоким разрешением по времени.Я это понял так: от момента появления сигнала на DI вызвать кусок кода, обработать его и отдать управляющий сигнал на DO. И все это за 10мкс. Если не прав, ок, учту.
Очень приятно услышать столько интересных и разнообразных мнений по поводу прерывания! Однако, хотелось бы услышать и разработчиков. Повторюсь: ВОЗМОЖНО ЛИ НА ПЛК ОВЕН РЕАЛИЗОВАТЬ ПРЕРЫВАНИЕ ПО ВНЕШНЕМУ СОБЫТИЮ.
И что за странная строка в планировщике событий "TASK_I01"?
ПЛК110 - "быстрый таймер" - прерывания с периодом от 20 мкс.... опрашивайте свои внешние события и реагируйте на них...
К сожалению, языки CoDeSys (а скорее сам компилятор), не предназначены для написания прерываний. Очень уж неоптимизированный код получается.
Плюс большие накладные расходы на сам вызов программы CoDeSys из прерывания.
Поэтому 20 мкс - это тот предел, ниже которого ПЛК будет выполнять только код прерывания. Даже на простой программе.
Поэтому в ПЛК110 новой редакции мы применили 2 сопроцессора для обработки быстрых входов/выходов.
И высокоскоростная обработка буде происходить внутри сопроцесоров. На текущий момент поддержан весь "быстрый" функционал ПЛК110, в дальнейшем функционал будет расширен, Для реализациии типовых высокоскоростных задач.
Достигнутый цикл обработки = 1 мкс и не подвержен джиттеру.
Тролль-наседка, добрый, нежный и ласковый
Писать в CoDeSys обработчик прерывания - неблагодарное занятие, да и ненужное. В самом языке поддерживается идея вытесняющей многозадачности и для контроллеров имеющих быстрые входы можно реализовать переход к более приоритетной задаче при наличии события на таком входе (по сути это и есть прерывание) но при одном условии - если разработчики заложили такую функцию в свое изделие. У Овена есть быстрые входы, в планировщике задач есть вызов задачи по внешнему событию, и даже в этих событиях заложены две позиции TASK_Т01 и TASK_I01, первая из которых - вызов задачи по сигналу таймера. Что означает вторая - похоже военная тайна (ну, или я не заметил ее расшифровки между строк всей документации) хотя судя по написанию - это и есть физический вход, но тогда какой?И самое главное - непонятно, как работает вызов такой задачи, по принципу вытесняющей многозадачности или не вытесняющей. Собственно вот те несколько вопросов на которые я хотел бы услышать ответ.
Или, хотя бы, "...в током-то и таком-то контроллере такая функция реализована...", но в ответ - тишина....
Простите, не тишина, а куча идей на отвлеченную тему.
Ваши права
Ответить с цитированием