Программирование ПЛК110 [М02] для задач реального времени

[Newcomer]

Период у меня означает величину обратную частоте, т.е. T = 1/F. Я же график в одном из постов приводил. Обсуждать остальное сил уже нет, спать хочется.

[Newcomer]

Что-то вы мое ТЗ переиначили на свой лад. Что в результате получится я просто не представляю.

[приборист]

Тестировать есть что-нибудь?)))

[Newcomer]

Правильно говорят, что утро вечера мудренее. Соглашусь с В.Ситниковым, что достаточно для первого ФБ (отработка ШД заданного количества импульсов) задать только количество импульсов и ускорение (замедление). Будем полагать, что ускорение и замедление противоположны по знаку, но имеют одинаковый модуль. Ускорение (замедление) можно задавать от сколь угодно малого до предельно возможного для данной механической системы.

Для второго ФБ надо задавать частоту до которой должен раскрутиться ШД и ускорение (замедление).

Зачем использовать формат данных REAL ?

Во вложении документ на буржуйский ПЛК. На стр. 92 этого документа подробно расписано как работает функция управления ШД в этом ПЛК. Это примерно то, что я изначально хотел. Если заработает то, что предлагаете вы (задавать ускорение), то это будет круче чем у забугорных друзей.

[Владимир Ситников]

Программа "ШД с разгоном": pru_pulse_v4.zip

Step motor control via AM1808 PRU

FUNCTION_BLOCK PRU_STEPPER
(* Output will be generated to FAST OUTPUT 3 *)
VAR_INPUT
  ENABLE: BOOL;
  MAX_SPEED: DWORD; (* Гц *)
  QUANTITY: DWORD; (* количество импульсов *)
  ACCEL_RAMP: DWORD; (* Гц/сек, положительное. Например, 10000Гц/20сек == 500Гц/сек *)
  DECEL_RAMP: DWORD; (* Гц/сек, положительное. Например, 10000Гц/10сек == 1000Гц/сек *)
  OUT_NUM: BYTE; (* 1, 2, 3 или 4 *)
END_VAR
VAR_OUTPUT
  READY : BOOL; (* TRUE: можно запускать ещё раз, FALSE: предыдущие импульсы ещё идут *)
  STATE : BYTE; (* 0: INIT, 1: ACCEL, 2: RUN, 3: DECEL, 4: STOP *)
END_VAR

max_speed/quantity/accel_ramp/decel_ramp можно менять только в состоянии INIT. Т.е. менять на ходу параметры нельзя.

ENABLE можно выключать в любое время (будет плавный останов, если исходно был плавный запуск).

Если ACCEL_RAMP равно нулю, то ускорения/замедления не происходит, а просто генерируются QUANTITY импульсов с частотой MAX_SPEED

Если QUANTITY равно -1 (16#ffffffff), то генерируется бесконечное количество импульсов. Генератор работает до перевода ENABLE в false.

[Владимир Ситников]

Зачем использовать формат данных REAL ?

Если в двух словах, то для того, чтобы не пришлось править пользовательскую КДС программу при обновлении PRU программы.

Например, если передавать "max_speed" как DWORD в герцах, то уже невозможно задать 100.5 Гц. Либо 100, либо 101.
Конечно, можно договориться, что "max_speed" передаётся как "частота, умноженная на 256" (т.е. вместо 100.5 передавать 25728), но это дичь.

Гораздо лучше будет, если на вход блоку будет передаваться осмысленное значение (частота в герцах), а уже сам блок при передаче команды в PRU будет либо просто округлять, либо домножать на 256 (или сколько нужно).

Тогда "в следующих версиях блока" можно менять лишь PRU0.prg/stepper.lib, а саму программу, которая подаёт команды менять не придётся. Программа как передавала "частоту в герцах", так и продолжит передавать.

Аналогично, если окажется, что для "ускорений" у dword'а точность низкая, то опять же, можно будет поправить реализацию самой PRU программы, и не трогать пользовательский код.

Если заработает то, что предлагаете вы (задавать ускорение), то это будет круче чем у забугорных друзей.

Наконец-то мы поняли друг друга.

[Newcomer]

Я думаю задавать частоту и ускорение с точностью до 1 будет достаточно. Если меандр будет формироваться для управления ШД, то десятые и сотые доли точно будут не нужны.

Интересные вопросы:
1) с какой точностью будет поддерживаться частота, формируемая ФБ;
2) будет ли эта частота держаться стабильно или будет плавать.

Например, задали частоту 1000,11 Гц. Подключим к выходу ПЛК частотомер и что увидим ?

Если частота сформированного сигнала будет точной и стабильной, то имеет смысл использовать формат REAL.

[Владимир Ситников]

1) с какой точностью будет поддерживаться частота, формируемая ФБ;

Если PRU управляет одним выходом (пока это так), то точность ширины импульса составляет где-то 0.01мкс (один-два такта PRU, частота которого 150МГц)

2) будет ли эта частота держаться стабильно или будет плавать.

С точки зрения алгоритма, плавать не будет. В реальности -- всё зависит от того, насколько точно PRU процессор держит свою частоту 150МГц.

Можно ли от одного PRU запитать сразу 2 ШД -- пока не знаю, надо подумать.

Например, задали частоту 1000,11 Гц. Подключим к выходу ПЛК частотомер и что увидим ?

Сейчас для вычислений используется целое значение частоты.
Например, для 1000Гц импульс будет 75000 тактов единица, потом 75000 тактов ноль.
Для 1000.11 можно было бы сделать 74992 единица, 74992 ноль -- по факту это было бы 1000.1067 Гц == 150e6/(2*74992)

Поэтому я и говорю, что если заложить REAL'ы с самого начала, то потом уже можно подстраиваться.

[Newcomer]

Меня интересует не точность ширины импульса, а точность периода следования импульсов. Будет ли этот период поддерживаться с точностью до сотых долей герц и будет ли период держаться стабильным. Вы при формировании частоты в своей программе от чего синхронизируетесь ? Если это кварцованная частота, то она будет очень точная.

[Newcomer]

Это что такое было, показательный пример как надо спорить и признавать свои ошибки?
По моему в документе говорится как раз то, о чем утверждал Ситников, никакое время тут не задается, а рассчитывается из введенных данных, частоты и импульсов

Понял, что Ситников был прав и написал об этом.

А вы про у ускорение забыли.