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

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

Сделал вычисление разгона-торможения.

Всё основывается на четырёх параметрах:

input quantity : DWORD;  (* Общее количество импульсов *)
input accel_ramp : DWORD; (* Ускорение имп/сек^2 *)
input decel_ramp : DWORD; (* Замедление имп/сек^2 *)
input max_speed : DWORD; (* Максимально допустимая скорость имп/сек *)

Иными словами, на вход подаём "сколько нужно проехать и какие ограничения скорости", и в результате оно само планирует как именно ехать.

Текущее ограничение -- разгон до макс скорости должен укладываться в 2³²-1.
По-моему, этого должно хватать на все разумные случаи.
Например:
1) если макс скорость составляет 100кГц, то разгон нужно выполнить не дольше, чем за 11 часов (==((1<<32)-1)/100000/3600).
2) если макс скорость составляет 10кГц, то разгон нужно выполнить не дольше, чем за 119 часов (==((1<<32)-1)/10000/3600).

Примеры графиков.
На каждом из графиков после расчётного количества импульсов блок начинает выдавать статус "приехали, больше не надо"

3500 импульсов, разгон 500 имп/сек², торможение 1000 имп/сек²
move_3500steps_1kHz_500_1000_output.png

CPU %:
На этом графике видно, что "подготовка" действительно занимает какое-то время.
Тут это было 768 тактов, т.е. целых 5.1 мкс. Не исключено, что можно соптимизировать, но деления-умножения там делать приходится.
Первый генерируемый импульс составляет 42.7 мс, и все вычисления просто немного сокращают длительность "ожидания".
move_3500steps_1kHz_500_1000_cpu_use.png

2250000 импульсов, разгон 5000 имп/сек², торможение 6666 имп/сек²
move_2250000steps_100kHz_5000_6666_output.png

CPU %:
Тут подготовка была 867, т.е. 5.8 мкс.
move_2250000steps_100kHz_5000_6666_cpu_utilization.png

А теперь сделаем короткое передвижение (так, что максимальная скорость не достигается).
1000 импульсов, разгон 500 имп/сек², торможение 1000 имп/сек²

move_1000_100khz_500_1000.png


Теперь осталось:
1) добавить "общий цикл", который будет моргать выходом и передавать параметры
2) добавить "экстренное торможение" (если enable переходит в false раньше времени, то вычислить торможение и начать это самое торможение)

[Дмитрий Артюховский]

Программирование PRU - это прежде всего реальное, детерминированное время выполнения. Трансляция кода с ЯВР никогда не покажет предсказуемого времени выполнения алгоритма, при наличии хотя бы одного ветвления. Для систем реального времени - это фатально.

Кроме того не забываем что время выполнения даже чистого С (лучших трансляторов) увеличено в 2 -2.5 раза по сравнению с ассемблерным кодом (не оптимизированным по ухищрениям! там разница еще больше). Для близкого к данной теме примера - код написанный на ST выполняется раза в 3 медленнее описания алгоритма на IL, оптимизировал для быстрого таймера поэтому натрахался с этой темой вволю.

Для контроллеров также весьма критичен размер кода... знает ли господин Ситников что у него в распоряжении всего 1 кслов памяти программ? что-то сомневаюсь, ибо он в код ПРУ загоняет и блоки умножения деления и даже квадратный корень считает, есть "мамонты" которые сами писали эти алгоритмы и помнят сколько кода они забирают? ))... и это он еще собственно рабочий алгоритм не начал ....

Среда разработки которую предлагает он лучше всего подойдет для приложений hello_world, и конечно пригодиться в жизни, но сейчас это не самое важное. Разумеется это предложение интересно и безусловно имеет право на жизнь, но не в этой теме.

Есть концепция овена, которая предлагает именно РЕАЛЬНОЕ ВРЕМЯ и стыкуется с системами программирования логических контроллеров. Данная тема заведена разработчиками для тестирования предложенной технологии, отладки и доведения до уровня беспроблемного применения. То что происходит - злобный оффтопик ))))

Если кому-то интересно что именно я делаю - решаю вопросы своей работы )) В текущий момент - это и модуль энкодера и шаговый двигатель, синхронизированный с энкодерам по плавающему алгоритму. В настоящий момент с уверенностью могу заявить что PRU это круто и за ним будущее! Будет свободное время - формализую модуль по стандартам модулей овена.

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

Программирование PRU - это прежде всего реальное, детерминированное время выполнения. Трансляция кода с ЯВР никогда не покажет предсказуемого времени выполнения алгоритма, при наличии хотя бы одного ветвления. Для систем реального времени - это фатально.

Подучите теорию. ST это язык низкого уровня. В моих программах используются пока только BYTE/WORD/DWORD, как раз те типы, с которыми PRU процессор работает напрямую. Поэтому, язык на котором я пишу является "языком низкого уровня", хоть в нём и есть "человекопонятные IF/WHILE/CASE/и т.п."
Но, ладно, буду думать, что вы под словами "ЯВР" имели ввиду "не ассемблер".

Вот, уже второй говорит, что "фатально" (первый был Владислав)
Хватит бросаться словами.
Без ветвлений вообще невозможно нормальную программу сделать. Иначе процессор выполнит свои 1024 инструкции и остановится.
Хочешь не хочешь, а ветвление необходимо.

Откройте END_1_1.asm и посмотрите сколько там ветвлений (там есть условные переходы).
Откройте PRU_OUT1.asm и посмотрите сколько там ветвлений (и там есть условные переходы).


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

И, да, не забываем, что у всех моих алгоритмов время работы предсказуемо.

Кроме того не забываем что время выполнения даже чистого С (лучших трансляторов) увеличено в 2 -2.5 раза по сравнению с ассемблерным кодом (не оптимизированным по ухищрениям! там разница еще больше). Для близкого к данной теме примера - код написанный на ST выполняется раза в 3 медленнее описания алгоритма на IL, оптимизировал для быстрого таймера поэтому натрахался с этой темой вволю

Вы сказали, только то, что в КДС плохой компилятор ST. Да, компилятор КДС туп как валенок.
И?

Как "плохой компилятор КДС" влияет на мой компилятор ST?
Правильно, никак.

Если вам нравится "IL вволю" -- я ни коем образом не останавливаю. Но поймите, что "трахаться с IL" равно как "трахаться с PRU ASM" очень мало кому нравится.
Людям нужно реальные задачи решать, а не воевать с ассемблером.

Для контроллеров также весьма критичен размер кода... знает ли господин Ситников что у него в распоряжении всего 1 кслов памяти программ? что-то сомневаюсь, ибо он в код ПРУ загоняет и блоки умножения деления.... и это он еще собственно рабочий алгоритм не начал ....

Во-первых, не "1 кслов памяти", а 4 килобайта, т.е. 1024 команды.

Алгоритм ШД с разгоном и торможением уже реализован.
Графики разгона-торможения получены с реального алгоритма.

Этот самый блок ШД со всеми квадратными корнями занимает 342 команды.
Ещё немного добавится на обмен с HOST'ом, поэтому пока никаких проблем нет. Если реально будут проблемы с размером кода, то поработаю над этим.

даже квадратный корень считает, есть "мамонты" которые сами писали эти алгоритмы и помнят сколько кода они забирают? ))...

Смеётся тот, кто смеётся последним.
SQRT(DWORD): DWORD занимает 16 PRU команд.

Если вы не поняли, то это доказывает, что вы не понимаете то, о чём пишете. 16 команд на блок квадратного корня вполне можно себе позволить.

Среда разработки которую предлагает он лучше всего подойдет для приложений hello_world, и конечно пригодиться в жизни, но сейчас это не самое важное. Разумеется это предложение интересно и безусловно имеет право на жизнь, но не в этой теме.

Моя среда, как минимум, позволяет делать полноценную программу для ШД. С разгоном и торможением. С перемещением на ровно указанное количество импульсов.

Hello_world это или нет -- не важно. Важно то, что мой подход позволяет решать реальные задачи на производстве. Вариант "от ОВЕН" -- не позволяет.

Более того, можно даже энкодер и ПИД управление (этим самым ШД) прикрутить, если есть потребность в таком управлении.

Есть концепция овена, которая предлагает именно РЕАЛЬНОЕ ВРЕМЯ и стыкуется с системами программирования логических контроллеров. Данная тема заведена разработчиками для тестирования предложенной технологии, отладки и доведения до уровня беспроблемного применения. То что происходит - злобный оффтопик ))))

Компания ОВЕН свою технологию предоставила.
И компания получила обратную связь. На этой технологии невозможно ни разрабатывать, ни тестировать, ни отлаживать.
Разумеется, на каждую даже самую ужасную технологию найдётся один-два человека, которому именно она в кайф и будет, но в целом, всем стало понятно, что:

1) Есть реальные задачи на применение 100кГц от ПЛК110. Например, управление ШД
2) Предоставленный ОВЕНом инструмент непригоден для общего применения. Блок ШД на инструменте ОВЕН если и можно сделать, то это займёт уйму времени и нервов
4) Упоминаемого "реального времени" пока никому не нужно. Вместо абстрактных слов "реальное время" лучше бы привели пример, где и как это реальное время пригодится на производстве.
Например, задача "ШД с разгоном" понятна всем. Всем понятно почему на простых выходах ПЛК это сделать не получится. А слова "реальное время" это какой-то миф.

Если кому-то интересно что именно я делаю - решаю вопросы своей работы )) В текущий момент - это и модуль энкодера и шаговый двигатель, синхронизированный с энкодерам по плавающему алгоритму. В настоящий момент с уверенностью могу заявить что PRU это круто и за ним будущее! Будет свободное время - формализую модуль по стандартам модулей овена.

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

Я не говорю, что "мой компилятор генерирует код лучше, чем любой рукописный", но я категорически не согласен с тем, что "переписывание на ST замедлит код в 2-3 раза".

И, да, даже, если вдруг замедлит в эти самые 2-3 раза, то частота PRU закрывает это с лихвой. Например, при управлении ШД, процессор простаивает больше 97% времени.
Поэтому на первый план должна выходить не "оптимальность кода", а "сложность поддержки", "возможность отладки" и т.п. Вот у варианта на ассемблере шансов на "исправление ошибки сторонним человеком" никаких нет.

И, да, если покажете пример хоть какой-нибудь программы для PRU1, то скажу большое спасибо. Я пробовал читать "регистр счётчика выполненных команд по адресу 0x7800+0xC", но почему-то не работает. У PRU0 счётчик команд находится по адресу 0x7000 + 0xC, а у PRU1 должен (вроде как) быть в 0x7800+0xC.

[Вольд]

Именно поэтому на такие проекты не нанимают фрилансеров.

Вы отстали от жизни. Полмира так уже работает.

[Newcomer]

Хочу немного подкорректировать интерфейс своего первого ФБ для управления ШД (см. вложение). Дело в том, что существует большое разнообразие ШД и драйверов к ним разных производителей. В каждом конкретном случае потребуется подбор времени разгона и торможения ШД чтобы не было пропуска шагов.
Надо чтобы у пользователя была возможность самостоятельно подобрать эти времена.

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

Хочу немного подкорректировать интерфейс своего первого ФБ для управления ШД (см. вложение). Дело в том, что существует большое разнообразие ШД и драйверов к ним разных производителей. В каждом конкретном случае потребуется подбор времени разгона и торможения ШД чтобы не было пропуска шагов.
Надо чтобы у пользователя была возможность самостоятельно подобрать эти времена.

Почему времена?

Я предлагаю указывать "скорость торможения" и скорость разгона. По-просту говоря, "ускорение", которе измеряется в имп/сек².

Времена неудобно в случаях, когда "импульсов слишком мало, чтобы разогнаться до максимальной скорости"

[Newcomer]

Почему времена?

Я предлагаю указывать "скорость торможения" и скорость разгона. По-просту говоря, "ускорение", которе измеряется в имп/сек².

Времена неудобно в случаях, когда "импульсов слишком мало, чтобы разогнаться до максимальной скорости"

Время разгона и торможения - это более понятно. По заданному времени можно рассчитать и ускорения. Когда импульсов слишком мало, то и времена будут маленькими. Пользователь методом эксперимента на реальном объекте подберет эти времена.

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

Когда импульсов слишком мало, то и времена будут маленькими.

И кто эти импульсы будет считать?
Откуда пользователь узнает "за какое время нужно выполнять разгон"?
Подбирать отдельно для каждого количества импульсов? Это ересь.

Время разгона и торможения - это более понятно. Когда импульсов слишком мало, то и времена будут маленькими.

Да что значит "более понятно" то?

Проблема пропуска импульсов не "во временах разгона", а в том, что у системы есть момент инерции.
Т.е. у каждой связки "ШД-исполнительный механизм" будет какой-то момент инерции, и на его основе можно вычислить предельно допустимое ускорение/замедление.
Вот статья, где с примерами приводятся вычисления допустимых ускорений для разных систем: http://www.orientalmotor.com/product...alculation.pdf
Считают момент инерции, смотрят на мощность движка и понимают предельно допустимое ускорение.

Грубо говоря, импульсы пропускаются не из-за того, что "разгон происходит за 5 секунд вместо 10", а импульсы пропускаются, когда разгон идёт слишком быстро (учитывать нужно не только длительность, но и фактическое изменение скорости за это самое время разгона).
Т.е. влияет не только время разгона, а то, какое изменение скорости при этом происходит.

То что предлагаю я -- указывать параметры "разгоняться с ускорением 10кГц/5 секунд==2000 имп/сек²" и "тормозить с ускорением 10кГц/2сек == 5000 имп/сек²".
Что в этом "непонятного"?

Ускорения -- первичны. "времена разгона-торможения" -- вторичны.

[Newcomer]

На практике никто момент инерции считать не будет. Это не тривиальная задача. А будут тупо, методом тыка, подбирать время разгона. Скажите у вас возникнут какие-то принципиальные проблемы, если на входе ФБ будет указано время, а не ускорение.
И как это задать ускорение 10кГц/2сек ? Какое это будет число ? 5 что ли ?

[ASo]

Что в этом "непонятного"?

Ускорения -- первичны. "времена разгона-торможения" -- вторичны.

Ээээээ... Вы просто не понимаете, где и для чего применяют шаговый движок. В отличии от линейного.