Период у меня означает величину обратную частоте, т.е. T = 1/F. Я же график в одном из постов приводил. Обсуждать остальное сил уже нет, спать хочется.
Вид для печати
Период у меня означает величину обратную частоте, т.е. T = 1/F. Я же график в одном из постов приводил. Обсуждать остальное сил уже нет, спать хочется.
Что-то вы мое ТЗ переиначили на свой лад. Что в результате получится я просто не представляю.
Тестировать есть что-нибудь?)));)
Правильно говорят, что утро вечера мудренее. Соглашусь с В.Ситниковым, что достаточно для первого ФБ (отработка ШД заданного количества импульсов) задать только количество импульсов и ускорение (замедление). Будем полагать, что ускорение и замедление противоположны по знаку, но имеют одинаковый модуль. Ускорение (замедление) можно задавать от сколь угодно малого до предельно возможного для данной механической системы.
Для второго ФБ надо задавать частоту до которой должен раскрутиться ШД и ускорение (замедление).
Зачем использовать формат данных REAL ?
Во вложении документ на буржуйский ПЛК. На стр. 92 этого документа подробно расписано как работает функция управления ШД в этом ПЛК. Это примерно то, что я изначально хотел. Если заработает то, что предлагаете вы (задавать ускорение), то это будет круче чем у забугорных друзей.
Программа "ШД с разгоном": Вложение 26625
max_speed/quantity/accel_ramp/decel_ramp можно менять только в состоянии INIT. Т.е. менять на ходу параметры нельзя.Код:Step motor control via AM1808 PRU
FUNCTION_BLOCK PRU_STEPPER
(* Output will be generated to FAST OUTPUT 3 *)
VAR_INPUT
ENABLE: BOOL;
MAX_SPEED: DWORD; (* Гц *)
QUANTITY: DWORD; (* количество импульсов *)
ACCEL_RAMP: DWORD; (* Гц/сек, положительное. Например, 10000Гц/20сек == 500Гц/сек *)
DECEL_RAMP: DWORD; (* Гц/сек, положительное. Например, 10000Гц/10сек == 1000Гц/сек *)
OUT_NUM: BYTE; (* 1, 2, 3 или 4 *)
END_VAR
VAR_OUTPUT
READY : BOOL; (* TRUE: можно запускать ещё раз, FALSE: предыдущие импульсы ещё идут *)
STATE : BYTE; (* 0: INIT, 1: ACCEL, 2: RUN, 3: DECEL, 4: STOP *)
END_VAR
ENABLE можно выключать в любое время (будет плавный останов, если исходно был плавный запуск).
Если ACCEL_RAMP равно нулю, то ускорения/замедления не происходит, а просто генерируются QUANTITY импульсов с частотой MAX_SPEED
Если QUANTITY равно -1 (16#ffffffff), то генерируется бесконечное количество импульсов. Генератор работает до перевода ENABLE в false.
Если в двух словах, то для того, чтобы не пришлось править пользовательскую КДС программу при обновлении PRU программы.
Например, если передавать "max_speed" как DWORD в герцах, то уже невозможно задать 100.5 Гц. Либо 100, либо 101.
Конечно, можно договориться, что "max_speed" передаётся как "частота, умноженная на 256" (т.е. вместо 100.5 передавать 25728), но это дичь.
Гораздо лучше будет, если на вход блоку будет передаваться осмысленное значение (частота в герцах), а уже сам блок при передаче команды в PRU будет либо просто округлять, либо домножать на 256 (или сколько нужно).
Тогда "в следующих версиях блока" можно менять лишь PRU0.prg/stepper.lib, а саму программу, которая подаёт команды менять не придётся. Программа как передавала "частоту в герцах", так и продолжит передавать.
Аналогично, если окажется, что для "ускорений" у dword'а точность низкая, то опять же, можно будет поправить реализацию самой PRU программы, и не трогать пользовательский код.
Наконец-то мы поняли друг друга.
Я думаю задавать частоту и ускорение с точностью до 1 будет достаточно. Если меандр будет формироваться для управления ШД, то десятые и сотые доли точно будут не нужны.
Интересные вопросы:
1) с какой точностью будет поддерживаться частота, формируемая ФБ;
2) будет ли эта частота держаться стабильно или будет плавать.
Например, задали частоту 1000,11 Гц. Подключим к выходу ПЛК частотомер и что увидим ?
Если частота сформированного сигнала будет точной и стабильной, то имеет смысл использовать формат REAL.
Если PRU управляет одним выходом (пока это так), то точность ширины импульса составляет где-то 0.01мкс (один-два такта PRU, частота которого 150МГц)
С точки зрения алгоритма, плавать не будет. В реальности -- всё зависит от того, насколько точно PRU процессор держит свою частоту 150МГц.
Можно ли от одного PRU запитать сразу 2 ШД -- пока не знаю, надо подумать.
Сейчас для вычислений используется целое значение частоты.
Например, для 1000Гц импульс будет 75000 тактов единица, потом 75000 тактов ноль.
Для 1000.11 можно было бы сделать 74992 единица, 74992 ноль -- по факту это было бы 1000.1067 Гц == 150e6/(2*74992)
Поэтому я и говорю, что если заложить REAL'ы с самого начала, то потом уже можно подстраиваться.
Меня интересует не точность ширины импульса, а точность периода следования импульсов. Будет ли этот период поддерживаться с точностью до сотых долей герц и будет ли период держаться стабильным. Вы при формировании частоты в своей программе от чего синхронизируетесь ? Если это кварцованная частота, то она будет очень точная.
И?
Тут "перед вызовом блока" предлагается сделать расчёт времени разгона.
Именно так и просил Newcomer с самого начала -- просил, чтобы на вход блоку давалось "время разгона".
Но потом мы сошлись на том, что "время разгона" расчитывать и подавать на вход блоку не нужно, т.к. это неудобно и всё такое.
Если задать ускорение и предельную частоту, то далее в программе можно посчитать время разгона, если это вообще надо делать.
Нет в CoDeSys никаких проблем с REAL.
При отработке ШД заданного количества импульсов самое главное чтобы ШД отработал эти импульсы за минимальное время без пропуска импульсов. Для этого надо опытным путем определить максимально возможное ускорение и задать его. Далее ФБ все сделает автоматом.
Если задавать ускорение, как предложил В.Ситников, то никакие времена не нужны. Проще один раз для конкретной механической системы с ШД подобрать предельное ускорение чем каждый раз подбирать времена.
1) Длительность импульса я вычисляю как просто 150'000'000/частота в целых числах. Тут может быть погрешность. Относительная погрешность растёт линейно и составляет 0.15% для частот порядка 100кГц (т.е. 150Гц для 100кГц, и примерно 2Гц погрешности на частотах 10кГц)
Тут повысить точность можно, но я почему-то сразу не думал об этом.
2) "синхронизируюсь" я по выполненным тактам самого процессора. Т.е. считается, что процессор работает на частоте 150МГц, и у него есть счётчик количества выполненных команд. На основе этого счётчика я и делаю задержки. Так сказать, "наматываю счётчик" выполнением пустых команд, пока он не достигнет нужного значения. Конечно, хорошо бы в реальности проверить и измерить частоту.
Плавает ли частота у самого кристалла -- фиг знает.
Если для формирования тактовой частоты кристалла используется кварцевый генератор, то частота будет стабильной. Это надо у В.Филоненко узнать стоит у них кварц на PRU или нет.
Не надо мне своих слов приписывать.
Я говорил, что должно подаваться только полное количество импульсов.
А на стр.92 чёрным по белому видно, что в дельту подавать нужно не только общее количество импульсов, но и отдельно "число импульсов на разгон", "число импульсов на торможение".
Если на выходе ФБ можно будет иметь кварцованную (высокостабильную) частоту, которую можно менять в широких пределах, то это расширяет область использования этого ФБ. В этом случае для задания частоты имеет смысл вводить формат REAL.
Там говорится про "количество импульсов на разгон" и про "частоту шага замедления/ускорения".
Это практически то же самое, что и "время разгона". Прямо реально то же самое.
Вот тут было:
Это лишь по вашему. Я утверждал, что должно подаваться только общее количество импульсов. Вы же упираетесь, что "в дельте так же". Ни разу там не так же.
Если не разобрались в вопросе -- либо хватит тупить, либо идите и разберитесь. Всё уже написано.
Мне было непросто переубедить Newcomer'а, но в конце концов мы поняли друг друга. Я понял, что Newcomer мыслил "по дельтавски", а он понял, что мой вариант будет удобнее.
Не хочу. Авторы дельта неправы. Я сделал так, как надо для программ "выдачи нужного количества импульсов".
Если будет потребность в блоках на "составное движение" (грубо говоря, восьмёрки двумя ШД выписывать), то можно и такое сделать. Но, опять же, там речи о "количесте импульсов на разгон" и/или "времени разгона" не будет.
И, значение "начальной скорости" добавить действительно можно. Ну, чтобы разгон начинался не с нуля, а с какой-то ненулевой скорости и не возникало каких-нибудь палёных резонансов в районе 200Гц.
Справедливости ради, в дельте S-кривой нет. По крайней мере, то, что описано на стр. 92 и вокруг говорит о том, что дельта делает ступенчатое увеличение скорости.
У меня -- линейное увеличение скорости, а у них ступеньками.
Разумеется, в момент перехода с одной ступеньки на другую могут быть проблемы.
Реальная система не может скачком изменить скорость.
S-кривые это уже про "плавное изменение самого ускорения".
Может показаться, что график внизу 93 страницы "диаграмма, иллюстрирующая выполнение программы" показывает "нелинейное увеличение скорости", но это только на первый взгляд.
По оси X у них не время, а "количество импульсов". Количество импульсов от времени зависит нелинейно, поэтому из самого графика крайне сложно понять "как зависит скорость от времени"
И вообще, возможно, сам график у них неправильный (в смысле, ошибка в самом графике).
это ПЯТЬ!!!! Овен - ретрограды, Дельты - косячат ))) Что осталось?! Омрон да Сименс опустить ))) и на освободившейся поляне ярко засияет восходящая звезда промавтоматики! ))))))Цитата:
Авторы дельта неправы. Я сделал так, как надо
пы.сы Алиенбрадли и Ваго мелко дрожжат от ужос-ужоса! ))))
Надо признать гениально, с такими то допущениямипеременная accel_ramp := 10000/10 легко может превратится во два входных аргумента количество импульсов за разгон и частота шага, зато можно говорить что не так как у ДельтыЦитата:
Это практически то же самое, что и "время разгона"
Молчали бы лучше и не засоряли тему.
Скажите как на дельте решить вот такие задачи: http://www.owen.ru/forum/showthread....507#post221507
На моём ФБ они решаются в одну строку.
На дельте без пол-литра они не решаются.
Это и подтверждает тот факт, что между блоками есть существенное отличие.
Это бред сивой кобылы.
Цитирую первую задачу №1: Сделать 300 импульсов, максимальная скорость 60 Гц.
Это полный цикл, включая разгон, ход, и замедление. За весь цикл должно быть ровно 300 импульсов.
Сделаете такое на дельте -- тогда и продолжим разговор.
Вы утверждаете, что "что нибудь обязательно" -- вы и ищите где там "найдётся".
Я много раз говорил, что в дельте нет блока, который можно удобно использовать для обозначенных мной задач.
Newcomer со мной согласился.
И он, похоже, гораздо лучше вас разбирается в дельте.
Господа, прекращайте этот спор. Стендовые испытания все покажут. Владимир, когда ваш ФБ будет полностью готов чтобы Приборист смог его как следует погонять ?
Уже готов и я ещё утром отправил личное сообщение прибористу, чтобы он завёл шарманку.
Собственно, 4-ая версия ШД-программы: http://www.owen.ru/forum/showthread....l=1#post221591
Можно добавить минимальную скорость (ну, чтобы стартовало не с нулевой скорости, а, скажем, с 500 Гц).
Ещё нужно придумать как завести PRU1.
Ну и подумать над S-кривой.
В ПЛК110 два сопроцессора PRU0 и PRU1.
Оба работают на частоте 150МГц.
К PRU0 подключены "fast out 3, 4"
К PRU1 подключены "fast out 1, 2" и "fast in 1, 2, 3, 4".
Чтобы задействовать 2 ШД нужно либо в программу для PRU0 встраивать одновременное управление двумя выходами (это сложновато, т.к. каждый выход будет пытаться работать на своей частоте, а цикл общий), либо "просто" запитать ШД1 от PRU0 и ШД2 от PRU1.
Но есть проблема. При заливке программы в PRU1 сам PRU1 почему-то "не отвечает".
Возможно, у него не активирован "счётчик выполненных команд".
Тут, я уже говорил, если кто-нибудь покажет хоть какой-нибудь пример PRU1 программы, которая оперирует со счётчиком команд -- будет хорошо.
В примерах "ОВЕН" про PRU1 ни слова.
Кто-нибудь может залить приложенные файлы под именем PRU1.prg? (PRG0.prg тоже должен быть. Как вариант -- можно одновременно файл как PRU0 и PRU1 заливать)
В результате -- один из выходов должен мигать с частотой 10кГц.
Вложение 26700
Тут внутри 3 разновидности: blink1, blink2, blink3. Они должны делать одно и то же. Собственно, вопрос: какие из программ будут реально мигать выходом (1-ым или 2-ым быстрым выходом)
А отец-основатель В.Филоненко что про это говорит ?
т.е. вы меняете время цикла ПРУ с каждым шагом?Цитата:
Чтобы задействовать 2 ШД нужно либо в программу для PRU0 встраивать одновременное управление двумя выходами (это сложновато, т.к. каждый выход будет пытаться работать на своей частоте, а цикл общий), либо "просто" запитать ШД1 от PRU0 и ШД2 от PRU1.
Вот будут обсуждаться эти темы -- блеснёте своими знаниями.
В математике, физике, программировании и их прикладных применениях вы явно не разбираетесь.
Говорили про разные вещи.
В том-то и дело, что:
1) В случае дельты нет простого способа рассчитать "количество импульсов на разгон".
2) Если подбирать, то подбирать придётся для каждого конкретного значения "общего количества импульсов и макс скорости".
В моём же блоке рассчитывать ничего не нужно, и подбирать "для каждого значения скорости" тоже не нужно.
В мой блок просто подаётся общее количество импульсов.
Ясен пень, что "рано или поздно" можно решить задачу "перемещения на 400 импульсов" на дельте.
Другое дело, что если меняются условия (например, количество импульсов или скорость), то в случае дельты подгонометрией нужно заниматься заново, а в моём случае -- достаточно просто использовать правильный параметр.
Вы уже в который раз показываете своё непонимание физики/математики и их прикладных применений.
С ГСЧ вы бесконечно долго пытались убедить, что "в ПЛК законы математики не действуют".
И тут тоже пытаетесь убедить, что "а не для потребителя".
Хватит тугодумить. Если хотите развиваться, то учитесь думать и слушать других.
Если считаете, что "можете других поучать", то, сильно прошу -- хватит засорять тему своими домыслами.
Ваши сообщения в этой теме уже давно вышли за край возможного.
Еще раз повторюсь, ШД у меня нет.
У меня драйвер сервопривода Ledshine с сервомотором (+ энкодер в нем).
Завтра притащу второй.
Залил программу в ПЛК.
Работает интересно :)
При отсутствии торможения\разгона - двигатель проворачивался на месте в момент старта и стопа (стоит жопой на полу, ось получается перпендикулярно полу).
Соответственно на оборудовании при таком никому не нужный удар.
При применении торможения\разгона - все плавненько.
По хорошему проверить бы количество передаваемых импульсов (для меня критично, потому что в итоге может накапливаться ошибка)
Но осциллографа нет, проверить нечем.
Скорости более 10000 мне врядли пригодятся (драйвер улетает в ошибку в районе 23000-25000).
Интересно выставляется скорость разгона\торможения. Можно разгонять и за секунду, и за пол-секунды либо сразу с ходу.
Режим без остановки - тоже работает.
В общем респект!
Как это будет работать на реальном объекте - не знаю.
Попробовать смогу лишь при работе двух сервомоторов.
P.S.
ШД в моем понятии не имеет обратной связи в виде энкодера и управляется чисто шагами.
Хотя может разница лишь в энкодере и типе двигателя (у меня трехфазный)