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

[Филоненко Владислав]

Товарищи, а не кажется ли Вам, что подход к управлению движением в виде 1 ФБ "сделай всё" в корне не верен?
ИМХО, правильнее было бы разделить задачу на:
1. Вычисление кривой движения (делает основной цикл ПЛК)
2. Деление кривой на N отрезков (опять же основной цикл)
3. Выдача импульсов по отрезкам силами PRU

Проводить сложные вычисления с плавающей точкой (или её эмуляциями) внутри PRU - это много лишнего кода и времени.
Код генератор N импульсов с M периодом и подгрузкой нового отрезка по мере выполнения - гораздо проще и гибче.

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

Товарищи, а не кажется ли Вам, что подход к управлению движением в виде 1 ФБ "сделай всё" в корне не верен?
ИМХО, правильнее было бы разделить задачу на:
1. Вычисление кривой движения (делает основной цикл ПЛК)
2. Деление кривой на N отрезков (опять же основной цикл)
3. Выдача импульсов по отрезкам силами PRU

Проводить сложные вычисления с плавающей точкой (или её эмуляциями) внутри PRU - это много лишнего кода и времени.
Код генератор N импульсов с M периодом и подгрузкой нового отрезка по мере выполнения - гораздо проще и гибче.

теоретически конечно так, а на практике нужно будет организовывать кэш в памяти ПРУ ( довольно маленькой!), ибо такт основного цикла в 1 мс не сильно подходит для бесшовной передачи новых блоков... а способ "забирать" подготовленные данные средствами ПРУ, по необходимости, из основной памяти пока не понятен

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

Товарищи, а не кажется ли Вам, что подход к управлению движением в виде 1 ФБ "сделай всё" в корне не верен?
ИМХО, правильнее было бы разделить задачу на:
1. Вычисление кривой движения (делает основной цикл ПЛК)
2. Деление кривой на N отрезков (опять же основной цикл)
3. Выдача импульсов по отрезкам силами PRU

Проводить сложные вычисления с плавающей точкой (или её эмуляциями) внутри PRU - это много лишнего кода и времени.
Код генератор N импульсов с M периодом и подгрузкой нового отрезка по мере выполнения - гораздо проще и гибче.

Я бы решал задачи по мере поступления. Конечно, можно год-два потратить на проектирование идеального ФБ (или двух), но по-моему, лучше сделать 1-ую версию хоть какую (но рабочую), а потом уже дорабатывать (или переделывать нафиг) по мере необходимости.

Скажу честно, что я не представляю какие "строительные PRU кирпичики" нужны для того же самого ШД. Я сторонник того, чтобы слушать что просят и фильтровать.
Конечно, есть ещё вариант выпить чаю с кем-то типа Вольда/Прибориста/Newcomer'а/ВЕТЕРа и собрать требований/пожеланий на "ШД мечты", но без понимания требований я никак не могу сказать верен или нет в корне подход "сделай всё".
Конечных же пользователей детали реализации волновать вообще не должны.


Текущая программа работает? Работает.
Параметры удобные? Удобные.
Лишние параметры есть? Вроде, нет.
Какие претензии? Я вовсе не обижаюсь, а просто выступаю адвокатом дьявола.

Ну, реально, если ФБ решает нужную задачу, то зачем его делать "более концептуальным"?

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


Будет более сложная задача -- будем решать, и, вполне возможно, делить задачи между HOST и PRU.


Непосредственно сейчас у меня 2 задачи:
1) Либо завести PRU1. Сейчас PRU1.prg не подхватывается:

................................................
Retain init
Slave Retain loaded
EEPROM init
PRU0 user programm loaded
Dublicate PRU programm
PRU1 user prg not loaded!

2) Либо сделать управление двумя ШД в рамках PRU0. На текущий момент я упираюсь в количество регистров PRU (все R1...R29 используются, не хватает 4 DWORD регистров). Тут я либо найду какую-нибудь лишнюю переменную, либо сделаю register spilling (временную выгрузку ненужных регистров в оперативную память).
Некая проблема, что все переменные у меня DWORD (step_count, max_speed, quantity, accel_ramp, decel_ramp, accel_count, decel_count, step_delay) и ещё несколько BYTE переменных. Т.е. один блок занимает ~12 регистров. Два занимают 24 и уже на временные вычисления не особо хватает. Не то, чтобы прямо беда, но ограничение даёт о себе знать.


Более того, можно даже опрос провести: сколько разработчиков (из тех, которые употребляют ШД в проектах) смогут правильно составить и протестировать код разгона ШД?


Я вовсе не к тому, что "я тут самый умный".
Я к тому, что задача действительно непростая, и конечному пользователю блок типа "Выдача импульсов по отрезкам" будет практически бесполезным. Конечному пользователю нужен именно высокоуровневый API типа "пододвинуть ШД на столько-то импульсов", "ой, всё, двигай назад" и т.п.


1) В текущей моей программе на каждом шаге выполняется одно деление и несколько сложений.
Есть смысл выносить одно это деление в HOST?
На мой взгляд, это лишь повысит сложность и хрупкость системы.

2) На мой взгляд, управление требует знания текущей скорости/положения. Одно дело, когда ШД стоит на месте, и HOST спокойно планирует движение, и совсем другое дело, когда ШД едет куда-то, и внезапно сказали "ехать по-другому". У PRU процессора есть актуальная информация. У HOST'а информация неактуальна.

Тут, на мой взгляд, разумно, чтобы HOST вычислял "общее движение", и передавал в PRU команды одно-два ближайших движения. Одно движение -- одна "трапеция". Но это, конечно, вилами по воде. Будут конкретные задачи -- посмотрим.

3) На текущий момент эмулятор PRU есть, а эмулятора КДС.lib нет.
Сейчас я в пару щелчков мышкой получаю картинки про то, какой будет разгон-торможение при различных входных параметрах.

Я даже могу сделать тест, который последовательно попробует сгенерировать 10, 11, 12, ... 100'000 импульсов и проверит, что при каждом из этих значений на выходе генерируется ровно нужное количество импульсов и т.п. Просто ноутбук ночь (или сколько там) поработает и всего делов. Зато будет ясно, что количество импульсов всегда соответствует нужному значению.

Если же выносить логику в КДС.lib (конечно, в отдалённом будущем оно звучит правильно), то сейчас я потеряю возможность тестировать код на эмуляторе. Придётся делать эмулятор КДС.lib кода.

Если вы следили за темой, то, надеюсь, заметили, что все мои программы с первого раза работали в железе.
С единственным исключением: pruAccessLib.lib мне далась не с первого, а со второго раза, т.к. я не понимал как работает эта библиотека. Так вот: переносить код в в HOST, конечно, можно, но прямо сейчас для меня это осложнит тестирование.

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

подход к управлению движением

Интересный вопрос -- управление медленными выходами из PRU программы.
Например, выход "направление вращения" вполне можно делать медленным выходом и не "тратить" на него быстрый.
Но при этом, придётся управлять этим самым "выходом для направления" из обычного ПЛК цикла -- т.е. возможны косяки, что цикл ПЛК затянулся, и всё. Что PRU должен делать? Ждать отмашку от HOST'а, что "направление переключилось, можно двигать"?

Проще и менее хрупко смотрелось бы, если бы команды на медленный выход отдавал тот же PRU, и без ожиданий.

Если я правильно понимаю, то в случаях "проскальзываний" это пригодилось бы.
Т.е. мы подали на ШД команду "двигайся на 1000 импульсов". Он, такой, сделал 800, начинает тормозить, а ему говорят: "слушай, надо не 1000, а 850". Т.е. по факту, программе придётся затормозить, а потом отъехать назад. Тут было бы проще, если бы сам PRU код понимал и управлял "в какую сторону едем".

[dima64]

ПЛК110-24.32.К.М, Binary VERSION 0.3.53, pru_pulse_v4.zip.
Подключил ШД FL57ST + драйвер SMSD-4.2 (http://electroprivod.ru/st_motor.htm, http://electroprivod.ru/smsd-42.htm ). При ACC и DEC=0 ШД четко отрабатывает заданное кол-во шагов. При ACC, DEC не равным 0 возникают резонансные частоты и пропуски шагов и ШД не отрабатывает заданное число шагов. (см. видео https://yadi.sk/i/dKvU2yjdvsaAv,
https://yadi.sk/i/eqM_tJNmvsaAp). Резонанс возникает в начале разгона и в конце торможения, т. е. на маленьких частотах. Далее. При QUANTITY=0 и MAX_SPEED=0 или > 25 при подаче команды ENABLE ШД делает один шаг. При QUANTITY=0 и MAX_SPEED=от 1 до 25 при подаче команды ENABLE ШД делает два шага.
При заливке в ПЛК PRU0.prg перестают работать первые 4 входа, при удалении PRU0.prg входа работают нормально.
IN.JPG
Еще 2 видео, видно потерю шагов. https://yadi.sk/i/DdQkzzG3vshXD, https://yadi.sk/i/zSCk7rURvshZT.

[BETEP]

.......... при подаче команды ENABLE ШД делает один шаг. ................. при подаче команды ENABLE ШД делает два шага.

Обычное явление, при подаче напруги в обмотки ротор встаёт в ближайшее "устойчивое" положение. Одна из причин почему во время позиционирования ENABLE никогда не снимают, драйвер должен уметь держать движок половинным током, чтобы нагрев уменьшить.

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

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

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

Обычное явление, при подаче напруги в обмотки ротор встаёт в ближайшее "устойчивое" положение. Одна из причин почему во время позиционирования ENABLE никогда не снимают, драйвер должен уметь держать движок половинным током, чтобы нагрев уменьшить.

Ну, ещё в программе присутствовал фрагмент "IF quantity<=2...".
Вынесу случай quantity=0 отдельно.

[Newcomer]

Обычное явление, при подаче напруги в обмотки ротор встаёт в ближайшее "устойчивое" положение. Одна из причин почему во время позиционирования ENABLE никогда не снимают, драйвер должен уметь держать движок половинным током, чтобы нагрев уменьшить.

Это не тот ENABLE, который у драйвера ЩД. В ФБ ENABLE - это VAR_INPUT , который дает разрешение на начало формирования импульсов. У В.Ситникова тут глюк.

[dima64]

Да, я имел в виду ENABLE функционального блока.
Владимир можете добавить в PRU чтение входов?

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

Пробуем pru_pulse_v5.zip
PRU1 должна залиться, но управлять fast output'ом она не сможет. Надо ещё программу поправить.

Да, я имел в виду ENABLE функционального блока.
Владимир можете добавить в PRU чтение входов?

Да, чтение добавить можно, но тут вопрос: что именно читать, какая фильтрация, и импульсы какой минимальной длительности планируется ловить?

Если вопрос "как сделать так, чтобы "не быстрые" discrete inputs заработали в конфигураторе, то тут вопрос к Владиславу.
Если он расскажет (хотя бы мне лично) как из PRU программы передавать данные в КДС программу (я имею ввиду не pruAccessLib, а "передавать данные в plcconfiguration") -- сделаю.