Сообщение от
Филоненко Владислав
Товарищи, а не кажется ли Вам, что подход к управлению движением в виде 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, конечно, можно, но прямо сейчас для меня это осложнит тестирование.
Ответить с цитированием
Зачем в основной программе делать первые два пункта ума не приложу. Чем такое предлагать вы бы лучше оказали Владимиру Ситникову системную поддержку чтобы он мог двигаться дальше. Вот что от вас давно ждут.
