Страница 5 из 5 ПерваяПервая ... 345
Показано с 41 по 47 из 47

Тема: Использование ООП в CODESYS V3.5

  1. #41

    По умолчанию

    Цитата Сообщение от RV9WFJ Посмотреть сообщение
    Время реакции зависит от времени цикла и скорости связи с модулями ввода/вывода.
    Время реакции - да. Я говорю о стеке. Как все происходит - По таймеру вызывается программа (предположим Main_Task). Допустим у нас есть функциональный блок, точка вызова блока выгружается в стек, на это время выполнение программы приостанавливается (пока данные не выгрузятся в стек) - это временная задержка, Далее в функциональном блоке есть другие функции, в них могут быть вложены другие функции каждый вызов - это остановка программы на время выгрузки в стек точки вызова. И потом все в обратном направлении - из стека т.е. задержки умножаем на 2. Таким образом если мне нужно вызывать какую-нибудь задачу с периодичностью 5 мс. А я, при использовании ООП на все вызовы функций буду тратить процессорное время на выгрузку/загрузку в/из стека - то тут нужно задуматься что лучше Красиво оформленный код с Объектами и кучей методов - но возросшим временем выполнения цикла или более простая реализация без лишних переходов и с минимальным количеством вызываемых функций. Вот о чем собственно я.
    Но если приложение не критично к джиттеру и цикл вызова больше 50 мс. То тут конечно можно ООП полным ходом - Объекты, методы, функции и красота и ООП.
    Последний раз редактировалось RomeoVar; 26.06.2021 в 19:31.

  2. #42

    По умолчанию

    Ну раз мы про ООП говорим то это CS3. Хоть какой-то логический смысл делать цикл 5мс есть только на ПЛК2хх. Вы можете задачу где это критично вызывать отдельным Task -ом. На ПЛК2хх это уже имеет смысл. Но по практике сдельть реалтное время выполнения цикла даже 3мс это очень постараться надо. Думаю то о чем вы пишите не имеет значения, поскольку затраты сравнимы с погрешностью измерения.

  3. #43

    По умолчанию

    А джиттер обычно графика портит. Хоть она и редко относительно вызывается, но "метко". Так что лучше графику оптимизируйте.

  4. #44

    По умолчанию

    Цитата Сообщение от RV9WFJ Посмотреть сообщение
    Ну раз мы про ООП говорим то это CS3. Хоть какой-то логический смысл делать цикл 5мс есть только на ПЛК2хх. Вы можете задачу где это критично вызывать отдельным Task -ом. На ПЛК2хх это уже имеет смысл. Но по практике сдельть реалтное время выполнения цикла даже 3мс это очень постараться надо. Думаю то о чем вы пишите не имеет значения, поскольку затраты сравнимы с погрешностью измерения.
    Насчет погрешности измерения - тут вопросов несколько. Программа в контроллере (на 210 в частности) запускается под Linux. Я, конечно, глубоко не копал но о Linux представление имею. Все Task-и запускаются скорее всего из crontab-a, а вот CS3 во что собирает? В исполняемый файл для системы (как обычное приложение)? Вероятно нет, думаю что под какой-нибудь интерпретатор (типа java) а тут уже разница в скорости исполнения существенная. Насчет графики тоже вопрос? В ОСи контроллера http сервер, обрабатывает запросы визуализации. И там-то логика точно работает через интерпретатор (php, java, или что нибудь свое, специфическое). Отсюда и такая "низкая" реакция.
    Поэтому джиттер не только из-за графики. Если графика (VISU_TASK) имеет приоритет 31, а MAIN_TASK имеет приоритет 1, то планировщик при наступлении точки вызова MAIN_TASK остановит выполнение графики, выгрузит точку останова в стек, перейдет к выполнению высокоприоритетной задачи, а уже по ее окончанию загрузит из стека точку вызова VISU_TASK и продолжит ее выполнение. И тут тоже вопрос - сколько времени требуется на выполение MAIN_TASK и VISU_TASK? Если первая 1мс, а вторая - 25, при цикле первой 5 мс. То VISU_TASK будет 4 раза остановлена соответственно и джиттер будет ого-го какой. А т.к. я думаю что crontab (ну или что там) вряд-ли вызовет MAIN_TASK заранее, чтобы успеть выгрузить в стек точку низкоприоритетной задачи. Соостветственно по джиттеру можно судить сколько времени нужно на операцию выгрузки в стек.
    Так что насчет джиттера не все так однозначно.
    Вот скорость исполнения задач графики - это да, нельзя ее делать слишком длинной. Да и вообще, я понял одно - циклы в ПЛК это зло.
    Вот, примерно то-же самое происходит и при вызовах ФБ И ФУНКЦИЙ. Так что здесь нужно балансировать между красотой и производительностью (ООП только по необходимости).

  5. #45

    По умолчанию

    Я все не читал, но за 2 последних страницы никто не вспомнил про цикл АЦП. Он может быть гораздо больше 5 мс.

  6. #46

    По умолчанию

    А цикл АЦП то тут при чем???

  7. #47

    По умолчанию

    Чет заглохла тема с ООП

Страница 5 из 5 ПерваяПервая ... 345

Похожие темы

  1. Использование УЗС-1
    от Сергей 2909 в разделе Эксплуатация
    Ответов: 0
    Последнее сообщение: 31.05.2018, 07:56
  2. Ответов: 3
    Последнее сообщение: 05.03.2015, 14:01
  3. ПЛК 110, использование RS-232
    от =MiX@$= в разделе ПЛК1хх
    Ответов: 18
    Последнее сообщение: 14.10.2011, 14:26
  4. Использование АС4
    от alex_sinjawin в разделе Сетевые технологии
    Ответов: 2
    Последнее сообщение: 10.11.2009, 18:31
  5. Использование CoDeSys Service Tool (CST).
    от Юрий_1900 в разделе ПЛК1хх
    Ответов: 1
    Последнее сообщение: 03.09.2009, 09:49

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •