Что там у вас - это дело десятое. Частично ФБ вы протестировали и хорошо.Цитата:
Сообщение от приборист
Сейчас задача проверить ФБ на ШД. ШД должен быть размером не с гулькин нос, а ватт на 200.
Вид для печати
Что там у вас - это дело десятое. Частично ФБ вы протестировали и хорошо.Цитата:
Сообщение от приборист
Сейчас задача проверить ФБ на ШД. ШД должен быть размером не с гулькин нос, а ватт на 200.
А где последний релиз вашего ФБ для ШД ?Цитата:
Сообщение от Владимир Ситников
да я про веремя и не заикался больше, сообщил что Вы неправильно что то посчитали и забыл, то что не совсем совпало, понятно что правильно надо было поделить в нужном месте.Цитата:
Сообщение от Владимир Ситников
Про натурные испытания это я про график зависимости от количества импульсов. Например здесь рисунок 2-6, показаны шаги с разной продолжительностью по времени, по расчетам в каждом шаге одинаковое количесвто импульсов, когда мы перенесем эти импульсы на равноудаленные расстояния(чтоб создать график зависимость от количества импульсов), график изменится на кривую которая представлена на картинке у дельты
Ещё раз прошу. Удалите, пожалуйста свои сообщения #447, #450, #455, #470Цитата:
Сообщение от capzap
Я удалю свои ответы на них. Да, с 2606мс был мой косяк, но я с самого начала и сказал, что "конкретная цифра не важна".
Я почти неделю ждал, пока администраторы меня переименовали.
Не надо осложнять им жизнь.
Я много раз говорил, что "натурные испытания" это добавление лишних сущностей в проблему.Цитата:
Сообщение от capzap
Есть алгоритм -- должен быть график его работы.
Попытка приплести "натурные испытания" для того, чтобы объяснить почему график не соответствует теоретическому описанию это полный бред.
У дельты описана вполне конкретная формула. С чего вы думаете, что "график изменится на кривую которая представлена на картинке у дельты"?Цитата:
Сообщение от capzap
Вот, реально, с чего бы ему измениться?
Каким боком алгоритм "от AVR" относится к дельте? Правильно, никаким.
Хотя бы свой java код посмотрите, и увидите, что зависимость "y" от "i" у вас линейная.
И, да, если построить график "частота от количества импульсов" в равноускоренном разгоне, то он будет выглядеть как "график корня".
steps = a * t2/2
speed = a * t
Т.е. speed = a * SQRT(2*steps/a) == SQRT(2 * a * steps)
Кривая корня выглядит вовсе не так, как кривая на графике дельты.
В ПЛК110 М02 есть 4 быстрых выхода, с помощью которых можно управлять шаговыми двигателями и серво-системами.
Сам инструментарий для создания "быстрых" программ на текущий момент широкой публике не доступен и обсуждается в теме Программирование ПЛК110 М02 для задач реального времени
Я записался на beta тестирование и мне удалось сделать PRU программу, которая выдаёт указанное количество импульсов на быстрый 3-ий выход.
Должно получиться управление четыремя ШД (одновременно только 2). Один ШД на выходы 1 или 2, второй -- на выходы 3 или 4.
Сама тема "использования PRU" программ пока под вопросом -- ОВЕН пока никак не обозначили свою позицию.
Тем не менее, можно надеяться, что PRU0.prg будет работать и в будущих версиях прошивки ПЛК110.
Внимание, для работы нужно подключать библиотеку pruAccessLib.lib, которую берут тут http://www.owen.ru/forum/showthread....l=1#post180471
2016-12-19: Доступно обновление Hardella IDE 1.6.0: https://hardella.com/blog.
* Блок управления ШД встроен в стандартную библиотеку, пример входит в базовую поставку
2016-10-02: 12-ая версия Вложение 26798
* Поправлен цикл задержки. Частота на выходе должна лучше соответствовать уставке.
* "decel_ramp>0 AND enable=false" баг исправлен
2016-10-02: 10-ая версия Вложение 26781
* Уж теперь-то 2 ШД должны заработать. Помним, что одновременно могут работать следующие комбинации выходов: 1 и 3, 1 и 4, 2 и 3, 2 и 4.
* За частоту PRU взята 200MHz (совпадает с тестами dima64)
* Убран выходной параметр "READY". Вместо него стоит проверять STATE=STOP_STEPPER.
* Добавлен выходной параметр "CURRENT_SPEED : REAL"
* Изменён тип параметра "STATE" на enum PRU_STEPPER_STATE
* Баг: при ненулевом decel_ramp enable=false не останавливает генерацию
Демонстрация "разгона ПЛК110 М02 до 2МГц": http://recordit.co/XLaOe3LOYE (то же самое в виде анимированного gif: http://g.recordit.co/XLaOe3LOYE.gif )
2016-09-30: 8-ая версия Вложение 26764
* Добавлен выходной параметр "количество сгенерированных импульсов"
* За частоту PRU теперь берётся 228МГц, а не 150МГц
2016-09-30: 7-ая версия Вложение 26763
* Добавлен параметр "минимальная скорость"
* Параметр OUT_NUM теперь должен работать по-настоящему. Т.е. выбирать номер выхода. Тем не менее, для разных выходов лучше использовать разные экземпляры ФБ PRU_STEPPER.
2016-09-30: 6-ая версия Вложение 26762
* не работает
2016-09-29: 5-ая версия Вложение 26744
* Исправлено поведение при quantity=0, 1 (т.е. выдаётся 0 и 1 импульс)
* PRU1.prg подхватится, но работать не будет
2016-09-26: 4-ая версия Вложение 26720
* Реализован разгон-торможение
* Реализован режим "выдачи нужного количества импульсов без разгона/торможения"
* Реализован "внезапный останов" (включается торможение с текущей позиции)
ШД управляется следующим блоком (pru_stepper.lib):
max_speed/quantity/accel_ramp/decel_ramp можно менять только в состоянии INIT. Т.е. менять на ходу параметры нельзя.Код:FUNCTION_BLOCK PRU_STEPPER
VAR_INPUT
ENABLE: BOOL;
MIN_SPEED: REAL; (* Гц *)
MAX_SPEED: REAL; (* Гц *)
QUANTITY: DWORD; (* количество импульсов *)
ACCEL_RAMP: REAL; (* Гц/сек, положительное. Например, 10000Гц/20сек == 500Гц/сек *)
DECEL_RAMP: REAL; (* Гц/сек, положительное. Например, 10000Гц/10сек == 1000Гц/сек *)
OUT_NUM: BYTE; (* 1, 2, 3 или 4 *)
END_VAR
VAR_OUTPUT
STATE : PRU_STEPPER_STATE; (* INIT -> ACCEL -> RUN -> DECEL -> STOP *)
CURRENT_SPEED: REAL;
PULSES_GENERATED: DWORD;
END_VAR
VAR
TMP: DWORD;
pru_num : BYTE;
bit_num : BYTE;
END_VAR
TYPE PRU_STEPPER_STATE : (
INIT_STEPPER, (* STEPPER is waiting for new configuration and activation ENABLE=TRUE signal *)
ACCEL_STEPPER, (* STEPPER is accelerating *)
RUN_STEPPER, (* STEPPER is moving at MAX_SPEED *)
DECEL_STEPPER, (* STEPPER is decelerating *)
STOP_STEPPER (* STEPPER is stopped and it is waiting for ENABLE=FALSE to switch to INIT state *)
);
END_TYPE
ENABLE можно выключать в любое время (будет плавный останов, если исходно был плавный запуск).
Для экстренного останова сначала перевести decel_ramp в 0, а потом уже передавать ENABLE=FALSE -- будет просто останов, без плавного торможения.
Если ACCEL_RAMP равно нулю, то ускорения/замедления не происходит, а просто генерируются QUANTITY импульсов с частотой MAX_SPEED
Если QUANTITY равно -1 (16#ffffffff), то генерируется бесконечное количество импульсов. Генератор работает до перевода ENABLE в false.
До 100кГц должно работать с запасом.
Для использования, нужно залить файлы PRU0.prg/PRU1.prg в контроллер и перезагузить его.
При использовании PRU0.prg/PRU1.prg напрямую работать с fast output 3, 4 не получится. При использовании PRU1.prg выходы 1 и 2 будут доступны только через программу ШД.
Вот несколько графиков, на которых отображена работа библиотеки:
Вложение 26718
Вложение 26719
Лицензия: Apache License 2.0
Тестирование выполнялось как на эмуляторе сопроцессора (графики выше получены с эмулятора), так и на реальном сервоприводе.
Понимаю и уважаю это мнение, но, пожалуйста, тема далеко не про вас, не про меня, не про дельту, а про ПЛК110 М02 и его PRU.Цитата:
Сообщение от capzap
Все, кому надо (кто читал тему) уже увидели. Кому не надо -- тому и не надо.
Напишите в дельту -- и спросите у них.Цитата:
Сообщение от capzap
По-моему, мы слишком много времени тратим на дельту в теме про ПЛК110.
Ничего нового оно нам не даёт и не даст.
BETEP правильно сказал. Если и смотреть, то в сторону дальнейшего развития: корректировка по ходу работы, больше чем 1 ШД и т.п.
Товарищи, а не кажется ли Вам, что подход к управлению движением в виде 1 ФБ "сделай всё" в корне не верен?
ИМХО, правильнее было бы разделить задачу на:
1. Вычисление кривой движения (делает основной цикл ПЛК)
2. Деление кривой на N отрезков (опять же основной цикл)
3. Выдача импульсов по отрезкам силами PRU
Проводить сложные вычисления с плавающей точкой (или её эмуляциями) внутри PRU - это много лишнего кода и времени.
Код генератор N импульсов с M периодом и подгрузкой нового отрезка по мере выполнения - гораздо проще и гибче.
теоретически конечно так, а на практике нужно будет организовывать кэш в памяти ПРУ ( довольно маленькой!), ибо такт основного цикла в 1 мс не сильно подходит для бесшовной передачи новых блоков... а способ "забирать" подготовленные данные средствами ПРУ, по необходимости, из основной памяти пока не понятенЦитата:
Сообщение от Филоненко Владислав
Я бы решал задачи по мере поступления. Конечно, можно год-два потратить на проектирование идеального ФБ (или двух), но по-моему, лучше сделать 1-ую версию хоть какую (но рабочую), а потом уже дорабатывать (или переделывать нафиг) по мере необходимости.Цитата:
Сообщение от Филоненко Владислав
Скажу честно, что я не представляю какие "строительные PRU кирпичики" нужны для того же самого ШД. Я сторонник того, чтобы слушать что просят и фильтровать.
Конечно, есть ещё вариант выпить чаю с кем-то типа Вольда/Прибориста/Newcomer'а/ВЕТЕРа и собрать требований/пожеланий на "ШД мечты", но без понимания требований я никак не могу сказать верен или нет в корне подход "сделай всё".
Конечных же пользователей детали реализации волновать вообще не должны.
Текущая программа работает? Работает.
Параметры удобные? Удобные.
Лишние параметры есть? Вроде, нет.
Какие претензии? Я вовсе не обижаюсь, а просто выступаю адвокатом дьявола.
Ну, реально, если ФБ решает нужную задачу, то зачем его делать "более концептуальным"?
И, да, конечным пользователям "мелкие PRU блоки" всё равно не нужны -- у них нет возможности составлять свои PRU программы. Даже если сделать "концептуально" в виде "PRU кирпичиков", то конечные пользователи всё равно не поймут разницы, т.к. они что так, что сяк, не могут составлять PRU программы.
Будет более сложная задача -- будем решать, и, вполне возможно, делить задачи между HOST и PRU.
Непосредственно сейчас у меня 2 задачи:
1) Либо завести PRU1. Сейчас PRU1.prg не подхватывается:
2) Либо сделать управление двумя ШД в рамках PRU0. На текущий момент я упираюсь в количество регистров PRU (все R1...R29 используются, не хватает 4 DWORD регистров). Тут я либо найду какую-нибудь лишнюю переменную, либо сделаю register spilling (временную выгрузку ненужных регистров в оперативную память).Код:................................................
Retain init
Slave Retain loaded
EEPROM init
PRU0 user programm loaded
Dublicate PRU programm
PRU1 user prg not loaded!
Некая проблема, что все переменные у меня 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 код понимал и управлял "в какую сторону едем".
А Владимир Ситников все уже сделал, быстро и качественно. ;) Зачем в основной программе делать первые два пункта ума не приложу. Чем такое предлагать вы бы лучше оказали Владимиру Ситникову системную поддержку чтобы он мог двигаться дальше. Вот что от вас давно ждут.Цитата:
Сообщение от Филоненко Владислав
ПЛК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 входа работают нормально.
Вложение 26739
Еще 2 видео, видно потерю шагов. https://yadi.sk/i/DdQkzzG3vshXD, https://yadi.sk/i/zSCk7rURvshZT.
Вы ничего не написали про значения ускорения. Какие значения задавали, пробовали менять ?
До какой максимальной частоты удается разогнать ШД ?
Резонансные явления должен давить драйвер ШД. Значит драйвер плохой.
Нее. Скорее всего, это решится добавлением параметра стартовой скорости.Цитата:
Сообщение от Newcomer
По крайней мере, в теории все пишут, что 200Гц для ШД это неудобная частота и как правило проблему решают просто стартом с большей частоты.
Обратите внимание на фразу Компенсация резонанса. Все качественные драйвера это делают. Если задать большую стартовую скорость, то ШД может вообще не стартовать.Цитата:
Сообщение от Владимир Ситников
Ускорения ставил разные, результат один. Все это происходит в самом начале разгона и в конце торможения.
А заданное количество импульсов ШД правильно отрабатывает ? Запомните положение вала ШД, задайте такое количество импульсов чтобы вал сделал 100 оборотов (это 20 000 импульсов, если нет дробления шага) и посмотрите положение вала. Дробление шага пробовали делать ?Цитата:
Сообщение от dima64
Без разгона и торможения отрабатывает правильно и 100 и 1000 об.
Владимир, что можете сказать по поводу: При заливке в ПЛК PRU0.prg перестают работать первые 4 входа (все время включены), при удалении PRU0.prg входа работают нормально.
Вложение 26739
А частота максимальная при этом какая была ? 10 кГц задавали ?Цитата:
Сообщение от dima64
Максимум 1100, потом срывается. Без дробления.
Так и должно быть. Заливаемая программа вытесняет программу по умолчанию. Если они нужны в основной программе - программа PRU должна их передавать туда.Цитата:
Сообщение от dima64
Без специально подготовленного ШД - 1100 Гц - приличный результатЦитата:
Максимум 1100, потом срывается. Без дробления.
У меня ПЛК110-32. У него 2 быстрых входа, 3 и 4 обычные входа. Но не работают первые 4 (ВСЕ время включены).
Обычное явление, при подаче напруги в обмотки ротор встаёт в ближайшее "устойчивое" положение. Одна из причин почему во время позиционирования ENABLE никогда не снимают, драйвер должен уметь держать движок половинным током, чтобы нагрев уменьшить.Цитата:
Сообщение от dima64
Судя по видео Ваш движок с драйвером в полном шаге на низкой скорости работать не может (масса ротора). Включите полушаг, пожалуй это самый оптимальный режим для движка.
И кстати да, желательно чтобы у рампы присутствовала стартовая и стоповая частота.
Все правильно. Без разгона до больших частот ШД не разогнать. Надо В.Ситникову подумать о кривой разгона. Линейное ускорение при разгоне и торможении не дает хорошего результата. В ПЛК Delta не зря сделано нелинейное ускорение.Цитата:
Сообщение от dima64
Всё равно входа через PRU. И да, они работать не будут, их обслуживает программа PRU. Тут или обычная программа или PRU0.prg
Ну, ещё в программе присутствовал фрагмент "IF quantity<=2...".Цитата:
Сообщение от BETEP
Вынесу случай quantity=0 отдельно.
Вышел патч.
Теперь compilator.exe правильно генерит программу для 1-го PRU.
Это не тот ENABLE, который у драйвера ЩД. В ФБ ENABLE - это VAR_INPUT , который дает разрешение на начало формирования импульсов. У В.Ситникова тут глюк.Цитата:
Сообщение от BETEP
Подобный движок от http://electroprivod.ru/ использовал для перемещения винтом маленького штампа (гидравлика).
полушаг, скорость максимально возможная, разон с торможением линейные (ступеньки по 4 mc), стартовая и стоповая частота не нулевые.
Был и режим от кнопок, когда медленно перемещался.
Да, я имел в виду ENABLE функционального блока.
Владимир можете добавить в PRU чтение входов?
Пробуем pru_pulse_v5.zip
PRU1 должна залиться, но управлять fast output'ом она не сможет. Надо ещё программу поправить.
Да, чтение добавить можно, но тут вопрос: что именно читать, какая фильтрация, и импульсы какой минимальной длительности планируется ловить?Цитата:
Сообщение от dima64
Если вопрос "как сделать так, чтобы "не быстрые" discrete inputs заработали в конфигураторе, то тут вопрос к Владиславу.
Если он расскажет (хотя бы мне лично) как из PRU программы передавать данные в КДС программу (я имею ввиду не pruAccessLib, а "передавать данные в plcconfiguration") -- сделаю.
Ну, в лучшем случае, как в конфигураторе. Что бы можно было задавать фильтрацию для конкретной задачи.
Я правильно понимаю, что если залиты PRU, то ни быстрые счетчики, ни быстрый энкодер уже работать не будет?
И да и нет.Цитата:
Сообщение от dima64
В PRU программе можно любую программу писать.
Хоть счётчик, хоть энкодер, хоть декодер UART, хоть что.
Я понял. Имел в виду в конфигураторе.
Тему сильно почикали и перемещают туда-сюда. Что за странная возня ?
Важно ли это?Цитата:
Сообщение от Вольд
Важно то, что PRU1 не заводилось не из-за того, что "моя заводилка не концептуальна", а из-за того, что "beta-версия ОВЕН компилятора физически не поддерживала PRU1".
А чем v5 отличается от v4. Или только подхват PRU1?Цитата:
Сейчас PRU1.prg не подхватывается
Завтра попробую.
Странно от добровольца-тестера слышать такие слова. Бета-тест для того и создан, чтобы были баги. Пока 1 штука :) Работайте интенсивнее :cool:Цитата:
Сообщение от Владимир Ситников
Добровольно -значит бесплатно :cool:
Тестер? А я думал разработчик ...:confused:
Вот Вы,rovki, тоже начинали у нас как тестер.Цитата:
Сообщение от rovki
А теперь уважаемый разработчик макросов, и у нас появляетесь часто, и новинки получаете в первых рядах и т.п.
Если человек сам выразил желание потестить углублённо - зачем ему мешать.