Я про это то же ранее писал.Цитата:
Сообщение от Владимир Ситников
Вид для печати
Я про это то же ранее писал.Цитата:
Сообщение от Владимир Ситников
А потом окажется новая проблема: "ой, генерация завершилась за 14мс, что делать".Цитата:
Сообщение от Newcomer
Это не проблема. Главное что бы генерация завершилась не позднее 16,7 мс. Уменьшать минимальное значение интервала (14...15 мс) то же не хорошо, т.к. это ведет к увеличению расчетного значения accel_ramp, что может привести к пропуску импульсов ШД.Цитата:
Сообщение от Владимир Ситников
Владимир, задаю заведомо большее чем над accel_ramp и получаю совсем плохой результат. Пачка импульсов генерируется много дольше расчетного времени. Т.е. ФБ steper не верно интерпретирует accel_ramp, который ему задается.
Приподниму малость тему.
Моя разработка модуля PRU-энкодера с детектором машинного нуля уже успешно работает около трех месяцев в режиме 24\7.
После модернизации оборудования, при наладке, выявился интересный глюк. Установка имеет несколько электромагнитных клапанов, которые управляются с ПЛК через промежуточные реле. Напряжение питания их соленоидов 230VAC. При размыкании (отпускании) реле одного из соленоидов происходил сброс показаний энкодера в ноль. Флаг машинного нуля при этом не сбрасывался, как не наблюдалось сбоев и в ПЛЦ_ПРГ. Проблему мы конечно решили методом изменения и экранировки разводки, но как говорится, "осадочек остался". Я понимаю, что это вопрос к производителю ПЛК, однако я не могу понять почему сбрасывался один регистр ПРУ, но не сбрасывался другой.
--------------
Другой вопрос.
Есть задумка модернизации еще одной установки, но там нужен ПРУ-модуль почти как для ШД.
Установка содержит три не очень навороченных сервопривода с возможностью управления от Step\Dir.
Задача заключается в том, что бы на привод №1 выдать образцовую частоту вращения F, на привод №2выдать F +- дельта, где дельта= 3% с максимально плавной регулировкой, на привод №3 выдать F+5% с ограничением момента (это функционал привода).
Частота импульсов примерно 30-50кГц. Т.е. например на привод №1 отправляем 32500Гц, на привод №2 - 32614Гц, на привод №3 - 32894Гц. Направление менять не требуется, ибо вращение идет всегда только в одну сторону. Рассматриваю так же просто передачу уставки скорости по Модбасу, но там только в Гц, и думаю будет грубовато.
Собственно вопросы:
1). В процессе работы есть оперативная необходимость изменения частоты любого из приводов без останова генератора, т. к. останов недопустим. Получится ли сделать три таких независимых генератора импульсов?
2). Генераторы должны работать бесконечно.
А катушки ЭМ клапанов RC-цепочками зашунтированы ?
По второй задаче особых проблем не вижу. Но интересно что скажет отец основатель Hardella IDE В.Ситников.
Это хорошоЦитата:
Сообщение от Sulfur
Т.е. установка уже может принимать уставку частоты по modbus с точностью до Гц, и вы всё равно хотите заменить?Цитата:
Сообщение от Sulfur
Почему же тогда?
Вообще говоря, 32500Гц это 30769.2нс, а 32501 это 30768.3нс.
Если у вас установка может не только принимать "с точностью до Гц", но ещё и реально выставлять частоту с точностью до Гц, то зачем же её "модернизировать"?
Там, говорите, серво?Цитата:
Сообщение от Sulfur
Т.е. им можно выдавать приближенную частоту, а они подстроятся?
3 генератора сделать можно. И подстройку частоты тоже можно сделать.
Вопрос в точности, которая нужна.
Например, если поставить цикл PRU в 1мкс, то грубо говоря, генерируемые импульсы будут кратны 1мкс.
Импульс в 32мкс (16 единиц, 16 нулей) это 31'250Гц.
Импульс в 33мкс (17 единиц, 16 нулей) это 30'303Гц.
Импульс в 34мкс (17 единиц, 17 нулей) это 29'412Гц.
В итоге, при уставке в 30'000Гц PRU будет чередовать 33мкс и 34мкс импульсы примерно так: 33 34 33 ... Тут так получается, что 33+34+33=100мкс, а 3 импульса за 100мкс это как раз 30кГц=3/100мкс.
Вряд ли, конечно, вам будет это мешать, но вдруг.
Вы это понимаете, и вас устраивает?
Это, конечно, можно.Цитата:
Сообщение от Sulfur
Уставка задается в Гц с точностью 0.01Гц в диапазоне 1.50...50.00 Гц. С имеющимися двигателями дискретность уставки получается примерно 0.3 об\мин. Вероятно хватит, но на всякий случай буду прорабатывать вариант с Степ\Дир. В данный момент используется аналоговое управление высокоточным многообортным переменным резистором (10 оборотов), для получения нужного результата оператору иногда приходится вращать ручку буквально на несколько градусов.Цитата:
Т.е. установка уже может принимать уставку частоты по modbus с точностью до Гц, и вы всё равно хотите заменить?
Почему же тогда?
Приведенные мною цифры весьма условные, чисто для понимания задачи.Цитата:
Вообще говоря, 32500Гц это 30769.2нс, а 32501 это 30768.3нс.
Стоят асинхронные двигатели с установленными резольверами. В приводе резольверный сигнал преобразуется в "энкодерный" 1024имп\об. Для задачи частоты требуется подавать внешний сигнал по формуле 4х, т.е. чтобы вал двигателя повернулся на 1 оборот нужно выдать 4096 импульсов. Обычная скорость вращения - 300-600 об\мин. Да, привод подстраивает частоту, т.к. она немного плавает от внешних механических возмущений (люфты, неравномерность нагрузки и т.п.)Цитата:
Там, говорите, серво?
Т.е. им можно выдавать приближенную частоту, а они подстроятся?
3 генератора сделать можно. И подстройку частоты тоже можно сделать.
По факту получается, что нужно иметь генератор в диапазоне 20..50кГц с возможностью оперативного изменения частоты с дискретностью 1 Гц. Например для частоты 40000 Гц обороты двигателя будут равны 585,94 об\мин, для 40001 Гц это составит 585,95 об\мин. Грубо - 1Гц равен 0.01 об\мин. В принципе это очень высокая точность, даже излишняя. Думаю дискретности задающей частоты в 5 Гц будет достаточно. Это в 6 раз точнее, чем через Модбас.
Завтра понаблюдаю за реальными цифрами на пока еще живой установке)).
32мкс = 457,76 об\минЦитата:
Вопрос в точности, которая нужна.
Импульс в 32мкс (16 единиц, 16 нулей) это 31'250Гц.
Импульс в 33мкс (17 единиц, 16 нулей) это 30'303Гц.
Импульс в 34мкс (17 единиц, 17 нулей) это 29'412Гц.
33мкс = 443,89 об\мин
34мкс = 430,84 об\мин.
Это очень грубая дискретность.
Можно ли в ПРУ ставить время цикла меньше, чем 1 мкс?
Не уверен что во всех (5 шт) есть помехоподавляющие цепи. Уже закуплены аналогичные катушки, но с напряжением 24VDC и помехоподавляющими приспособами. Поменять пока не получается, т. к. поскольку всё работает, меня не подпускают к машине ))).Цитата:
Сообщение от Newcomer
Вы правильно поняли?Цитата:
Сообщение от Sulfur
Вы тут оперируете словом "количество оборотов в минуту", а я говорю о том, что 33-34 мкс импульсы будут быстро-быстро меняться так, что "в среднем" (скажем, среднее за несколько секунд) окажется 33.333333.
Ну или пример для ваших "443,89 об\мин 430,84 об\мин"
Допустим, уставка 437.00 об\мин.
PRU может генерировать такие импульсы: 33 34 34 33 34 33 34 33 34 33 34 33 34 33 34 33 34 33 34 33 34 33 34 33 34...
Это 25 импульсов за 838мкс или 33.52мкс/импульс или 437.006 Гц в среднем за эту "секунду".
За это время (25 имп) вал провернётся на 1.83 градуса.
Вам точно такой точности не хватит?
Текущий ШД-блок именно так делает. Он размазывает импульсы и в среднем получается указанная частота.
Надо, конечно, смотреть PRU статистику. Может, и можно ставить меньше 1мкс, но сильно меньше не получится.Цитата:
Сообщение от Sulfur
Ну, поставим 0.5мкс, но это всё равно не будет чем-то кардинально более точным.
Сделать "безцикловый режим", наверное, можно, но непросто. 1мкс это 1000нс, или 200 команд PRU процессора.
Я с самого начала говорил, что "точность в 1 Гц на частоте 30кГц" это то же самое, что и "точность в 1нс".
А PRU ядро на одну команду тратит 5нс. Как вы собираетесь делать точность в 1нс при этом?
Начнём с того, что (пишу по памяти):
1) Нужно сделать какой-то обмен между PRU и PLC_PRG. Он может занять, например, 100-200нс. Конечно, зависит от количества обменных переменных и т.п.
2) "Цикл ожидания времени" на PRU сам по себе занимает ~50нс
3) Ну и самое коварное: вы же хотите 3 генератора одновременно. Может так оказаться, что "нужно сгенерировать импульс через 50нс для 1-го, потом через 1нс импульс для 2-го и ещё через 2нс импульс для третьего генератора". Если "подождать 50нс до генерации 1-го импульса PRU ещё может", то после этого не так то и просто будет "за 1 нс сгенерировать второй импульс".
Либо вариант "2 ПЛК", "по 2 PRU ядра в каждом", "на каждом PRU ядре свой генератор". Но это, по-моему, дичь какая-то.
Посмотрел реальную ситуацию на реальной установке. Девиация оборотов в рабочем режиме под нагрузкой по индикации приводов составляет +-1 об\мин от установленного значения. Пришел к мысли, что наворачивать ШД-подобную логику не имеет смысла, вполне будет достаточно передавать уставку по Модбасу.
Так что, как говорится, прошу прощения за беспокойство.
Здравствуйте!
Подскажите, как можно изменить скорость шд на ходу через pru_stepper?
Сейчас нельзя.Цитата:
Сообщение от DeeZ
А в чём заключается задача, когда нужно менять скорость на ходу?
Задача перемотки ленты, которую производим. Перемотка с натяжением, иногда необходимо на ходу немного корректировать скорость этой перемотки. Это моментальная задача.Цитата:
Сообщение от Владимир Ситников
А вообще более глобальная задача - поддерживать определённую скорость, так как при перемотке изменяется диаметр намотки, соответственно скорость при одинаковых количествах импульсов изменяется.
Написать самому ФБ для PRU. Как-то начал делать такой ФБ да не закончил.Цитата:
Сообщение от DeeZ
To Владимир Ситников.
Обновил Java 8. Это не скажется на работоспособности Hardella IDE ?
Как раз для Hardella эта версия Java и нужна. Т.е. должно работатьЦитата:
Сообщение от IVM
Java 8 постоянно обновляется. Это не страшно ?Цитата:
Сообщение от Владимир Ситников
Не страшно. На Java 9 не запустится, а на 8-ой проблем быть не должно.Цитата:
Сообщение от IVM
Написать фб, конечно, можно. Интересовался, чтобы не изобретать велосипед.Цитата:
Сообщение от IVM
Тогда за дело. ;)Цитата:
Сообщение от DeeZ
Такой вопрос к В.Ситникову. Как максимально точно оценить за какое время ФБ Steper сгенерирует заданное количество импульсов ?
Например, запустить блок на эмуляторе.Цитата:
Сообщение от IVM
Вот, например: https://github.com/vlsi/pru-emulator...Test.java#L182 указываем параметры, запускаем, смотрим на время.
А как этот эмулятор запустить ? Насколько точно этот эмулятор замерит время ? Есть ли такой инструмент в Hardela - задаешь ускорение, замедление, количество импульсов, нажимаешь кнопку Start и получаешь на выходе это самое время.Цитата:
Сообщение от Владимир Ситников
Сейчас нужно скачать проект, открыть его в Java IDE (например, IntelliJ IDEA), указать параметры, запустить тест.Цитата:
Сообщение от IVM
Вот как оно выглядит:
Вложение 34385
Думаю, точность будет порядка 5-10нс. Осциллографом же проверяли ШИМ генераторы на основе Hardella -- теоретическая частота совпадает с практической.Цитата:
Сообщение от IVM
STEPPER блок не зависит от основного цикла, поэтому там время работы весьма и весьма точное.
Если запуск выполняется из "основного цикла ПЛК", то, конечно, время реакции тоже нужно учитывать (+сколько-то миллисекунд).
Если же запуск выполняется из PRU, то нужно учитывать и время PRU цикла (+сколько-то микросекунд)
Вот тут вопрос целесообразности.Цитата:
Сообщение от IVM
С одной стороны, встроить можно. С другой вопрос того, насколько часто оно нужно. Как-никак, встраивание это время на разработку.
Прямо нужен инструмент?
Если вопрос в обсчёте нескольких вариантов -- могу запустить.
Тут периодически возникает вопрос о смене подхода. Так, чтобы можно было менять параметры движения на ходу (например, менять количество импульсов или "внезапно" уменьшать-увеличивать скорость).
Разумеется, в случае "изменения скорости на ходу" и инструмент "нажимаешь кнопку Start и получаешь на выходе это самое время" будет несколько другим, ведь тогда будет зависеть не только от PRU, но и от того, в какой момент будут эти команды на смену режима работы.
ФБ Steper для PRU, который меняет параметры движения на ходу бы очень интересен.
Такая утилита была бы очень полезна. Желательно бы было выводить:Цитата:
Сообщение от Владимир Ситников
1) время и число импульсов (n) при разгоне;
2) время и число импульсов при работы с постоянной скоростью;
3) время и число импульсов при торможении;
4) общее время и число импульсов.
Также хорошо бы было видеть графики f=F(t) и n=F(t).
Делать или нет решать вам. По хорошему фирме "ОВЕН" давно пора обратить внимание на Hardela и оплатить ваш труд. Инструментарий весьма добротный, ничего лучшего пока нет.
Еще один вопрос. Как узнать сколько памяти занимает программа для PRU ? Размер памяти - 1 кБ, так ?
Максимальный размер программы -- 1024 PRU команды (4096 байт). Суммарно может быть 2 программы одновременно (одна для PRU0, вторая для PRU1)Цитата:
Сообщение от IVM
Размер занимаемой памяти видно в коде генерируемой ..._PruXInit программы.
Например:
Это означает (см объявление переменной pruCode), что программа BlinkningLeds занимает 38 из 1024 команд в PRU1.Код:...
PROGRAM BlinkningLeds_Pru1Init
(* Generated by Hardella IDE 1.8.0: https://hardella.com *)
VAR_INPUT
enable : BOOL := TRUE; (* PRU is reset on the R_TRIG(enable) *)
END_VAR
VAR_OUTPUT
running : BOOL := FALSE; (* TRUE when PRU is running *)
END_VAR
VAR
initDone : BOOL := FALSE;
enTrg : R_TRIG;
xx, yy : POINTER TO DWORD;
x, i : DWORD;
pruCode : ARRAY[1..38] OF DWORD :=
16#51000102, 16#15012121, 16#01002141, 16#15012161, 16#24f08082, 16#2402fac2, 16#91000303, 16#51000306, 16#51020301, 16#51030302
, 16#91040301, 16#24000003, 16#81000303, 16#24780ce3, 16#f1002383, 16#013ce3e3, 16#66e2e3f6, 16#00e2e0e0, 16#24780ce3, 16#f1002384
, 16#010ae4e4, 16#48e4e203, 16#240000e5, 16#21001ee1, 16#04e4e2e5, 16#c900e502, 16#1501e5e5, 16#5100e503, 16#0502e5e5, 16#6f00e5ff
, 16#e1002385, 16#11ffde82, 16#090841c2, 16#12c28282, 16#090961c2, 16#12c28282, 16#010082de, 16#210000e1;
END_VAR
...
Значит общая память 1024 команды для двух PRU. А деление памяти между PRU произвольное? Например 30% для PRU1 и 70% для PRU2.
Нет. У каждого PRU ядра своя память.Цитата:
Сообщение от IVM
PRU0 -- 1024 команды
PRU1 -- 1024 команды
Все команды для PRU четырехбайтные ?
Да, все занимают по 4 байта.Цитата:
Сообщение от IVM
Владимир, у меня PRU1 управляет драйвером ШД. Код занимает 490 слов. Хочу управлять через PRU1 еще одним драйвером ШД. Правильно я понимаю, что памяти для этого хватит (490 + 490 = 980) ?Цитата:
Сообщение от Владимир Ситников
Пробуйте. Да, может получиться.Цитата:
Сообщение от IVM
И, да, если расскажете о задаче, может навести меня на какую-нибудь мысль.
Я всё подумываю добавить "изменение скорости на ходу" и т.п., но никак не приходит в голову как оно концептуально должно работать.
Как какая-то очередь команд что-ли?
Грубо говоря:
host -> pru: "едем 2 метра". "Ок, поехали"
host -> pru: "кстати, потом ещё метр". "Ясно, не забуду"
host -> pru: "а потом останавливаемся по DI1". "Ясно, не забуду"
host -> pru: "Эй, тормози прямо щас, там палец прижало!". pru: "Хорошо, стоим"
Так что-ли?
Я в своей задаче от идеи изменения скорости ШД на ходу отказался. Вместо этого хочу ввести в проект еще один ШД. Итого хочу управлять тремя ШД. Если от одного PRU получится управлять двумя ШД, то задача, скорее всего, будет решена. Памяти для программы вроде хватает, а вот хватит ли регистров для хранения переменных, объявленных в FB Steper. У меня в этом FB несколько переменных объявлены как DWORD. Компилятор Hardella выдаст сообщение если регистров не будет хватать ?
Да, кстати, может не хватить. Если не хватит, то будет ошибка.Цитата:
Сообщение от IVM
Еще вопрос. Как в программе для PRU объявить два одинаковых ФБ ?
Что значит "два одинаковых"?Цитата:
Сообщение от IVM
Если они прямо совсем одинаковые, то достаточно один раз объявить, и при использовании создать 2 переменых.
Например:
drive1: PRU_STEPPER;
drive2: PRU_STEPPER;
Если немного разные, то, например, ctrl+c/v и вперёд.
Все ясно. Завтра попробую.Цитата:
Сообщение от Владимир Ситников