Цитата:
|
Сообщение от Sergey Cherevko
Немного поясню.
События могут разные, но для SMH и Pixel актуальны всего два:
1. Изменение состояния входа (прерывание по входу)
2. Асинхронное к тику прерывание по времени
Обработчики событий нужны для уменьшения времени реакции контроллера. А реакции SMH и Pixel хватает лишь на не очень быстрые процессы.
Пример из жизни. Pixel с 2 МР, проект на чуть меньше 1000 блоков. Реальный тик 50...55мс, заданный 75. Железяка с датчиками положения и довольно низкой динамикой позиционируется пикселом на границе схода флажка с датчика после его "пролета".
Конечно, можно собрать несложную схему на внешних реле с реакцией на срабатыание датчика менее 1мс. Но это же не наш метод  Обычно всё наоборот и разные ошибки проектирования устраняются программными методами...
Поэтому и хотелось бы иметь какой-либо обработчик событий. Например, каждую 1мс контроллер бросает остальные дела и обрабатывает заданный пользователем макрос. В макросе опросил вход, обработал алгоритм и тут же выдал результат на выход. |
1) В пределах своего быстродействия что SMH, что Пиксель "прерывание" отработают. Не стоит их применять в неподходящих им задачах. Если вам нужна реакция 1 мс, то контроллер должен иметь время цикла не более 0.5 мс. Иначе любые ухищрения только усугубят ситуацию.
2) Асинхронность асинхронностью, но смысл в каком-то внеочередном выполнении какого-то макроса, если циклу подчинены также и обновление входов и выходов? Ну, обработал макрос данные, куда он их денет? Правильный вариант решения указанной вами проблемы - кардинальное сокращение времени общего цикла.
Во всех мощных системах с ОС реального времени просто очень маленькое время цикла (менее 1 мс), поэтому возникает ощущение "прерывания" и "параллельной работы". Но это ощущение, не более.
У нас есть продукт, который можно использовать в системах позиционирования - это FS-01, у неё время срабатывания измеряется долями миллисекунд.
PS. Не поделитесь, какие-такие реле срабатывают быстрее, чем 1 мс?
PPS. Вы представили очень упрощённую модель, правильно это делается так: каждую 1мс контроллер бросает остальные дела, опрашивает входы, сохраняет контекст основной задачи, обрабатывает заданный пользователем макрос, выдаёт результат на выход, восстанавливает контекст основной задачи. В результате такой чехарды времени потратится больше, чем 1 мсек. Но самое грубое, что произойдёт - это потеряется синхронность выполнения основной программы. Например: основная программа включает 2 дискретных выхода. Важно, чтобы они включились одновременно. Контроллер включает один, в это время возникает прерывание, в течении которого он выполняет макрос из 100 блоков. Тратит на это 1-2 мс. В итоге второй дискретный выход включится с задержкой.