А какая она ненулевая начальная скорость ? А с нулевой начальной скоростью есть возможность работать ?Цитата:
Сообщение от Владимир Ситников
Вид для печати
А какая она ненулевая начальная скорость ? А с нулевой начальной скоростью есть возможность работать ?Цитата:
Сообщение от Владимир Ситников
А вообще режим "сбавить скорость и продолжить на минимальной" нужен?Цитата:
Сообщение от dima64
В конкретном, случае, конечно, ошибка (не предусмотрен вариант моргания enable").
Как это без резисторов ? Это грубая ошибка. А чем входная цепь драйвера ШД питаться будет ? Надо сделать как у меня на картинке в посте #358.Цитата:
Сообщение от dima64
Понятия "нулевая начальная скорость" не существует. Равно как и "нулевая начальная частота".Цитата:
Сообщение от Newcomer
ШД двигается импульсами.
Ну невозможно подавать импульсы с нулевой частотой. Хоть тресни, но с нулевой частотой невозможно.
Вот вопрос: какая скорость в момент подачи первого импульса?
С технической точки зрения, интервал между первыми фронтами (первым и вторым) импульсов в случае min_speed=0 равен sqrt(2/accel_ramp)*0.676 сек
1 / (sqrt(2/30)*0.676) ~= 6Гц
1 / (sqrt(2/300)*0.676) ~= 18Гц
1 / (sqrt(2/3000)*0.676) ~= 60Гц
Посмотрел ФБ PRU_STEPPER. Не понял почему PULSES_GENERATED объявлен как DWORD.
Значит не нулевая начальная частота. Зачем тогда в ФБ введены обозначения MIN_SPEED и MAX_SPEED ? Разьве SPEED это не скорость ?Цитата:
Сообщение от Владимир Ситников
QUANTITY : DWORD;Цитата:
Сообщение от Newcomer
PULSES_GENERATED: DWORD
Л- логика, не?
Какого типа ещё может быть PULSES_GENERATED?
А что такое PULSES_GENERATED ? Где то, что подается на быстрый дискретный выход ПЛК ?Цитата:
Сообщение от Владимир Ситников
Как зачем?Цитата:
Сообщение от Newcomer
Для плавного запуска/останова и для избегания резонанса ШД.
Разумеется, физически невозможно выдрежать min_speed=0. Хоть ты тресни, но генерировать импульсы с частотой 0 Гц невозможно.
Тем не менее, ШД подаёт импульсы так, что фактический закон вращения вала ШД становится близким к "идеальному равноускоренному движению из 0 частоты".
Посмотрите на график разгона от 0 до 5кГц (1-ая картинка)
Там видно, что в начале скорость меняется ступеньками. Ступеньками т.к. большие интервалы между импульсами. Т.е. каждая ступенька это отдельный импульс.
Переименуйте MIN_SPEED и MAX_SPEED в MIN_FREQ и MAX_FREQ чтобы не сбивать людей с толку.
PULSES_GENERATED это количество фактически сгенерированных импульсов.Цитата:
Сообщение от Newcomer
Как где?Цитата:
Сообщение от Newcomer
Внутри программы. Если вы не поняли, то у меня "самодостаточная программа". Т.е. заливаем PRU0.prg/PRU1.prg и всё. Можно управлять ШД.
Номер выхода задаётся через OUT_NUM: BYTE; (* 1, 2, 3, or 4 *)
Какой смысл делать выходной параметр "OUT", если вы его всё равно ни к чему подключить не сможете?
Не в основном же цикле собрались переключать быстрые выходы?
И, да, ОВЕН не разрешает создавать *.prg файлы из hardella, а адаптировать ШД программу "под ОВЕНовский beta-формат PRU ФБ" я смысла не вижу.
С одной стороны, просто смысла нет. Ну кто реально будет через КДС и bat'ники создавать программы?! Есть желающие? Поднимайте руки! Только помните, что для сложения двух переменных нужен один блок, а для сложения переменной и константы -- другой.
И, с другой стороны, моя ШД программа требует довольно много регистров и это будет тяжело подружить с "ОВЕН beta компилятором", т.к. ОВЕНовский вариант идёт совсем в противоположном направлении: у меня регистры активно переиспользуются по ходу программы, а ОВЕН вариант предполагает, что даже после простого блока PRU_ADD регистры переиспользовать нельзя. Пара ОВЕНовских блоков, и всё, закончились регистры.
Не сказать, что мой блок идеально работает с регистрами, но мой компилятор сам догадывается какие регистры уже не нужны, а какие ещё нужны.
[QUOTE=Newcomer;222645]Как это без резисторов ? Это грубая ошибка. А чем входная цепь драйвера ШД питаться будет ?QUOTE]
Вложение 26824
Все понятно. Вопросов нет. Пока.
Я на этот глюк случайно попал. Было бы хорошо скорость на лету менять.Цитата:
Сообщение от Владимир Ситников
Да. А для серво резистор включил между +24 и выходом DO.
Это не правда. Транслятор с фбд вполне себе разбирается с высвобождением и переиспользованием регистров.Цитата:
а ОВЕН вариант предполагает, что даже после простого блока PRU_ADD регистры переиспользовать нельзя. Пара ОВЕНовских блоков, и всё, закончились регистры.
Да, но при таком подходе мы теряем 4 входа и 2 или 1 (без PRU1) выхода. А вариантов задач может быть миллион. На каждую задачу придется свои PRU делать.Цитата:
Сообщение от Владимир Ситников
Проверяли? Если честно, я не проверял, а лишь "как обычно", поверил Владиславу на слово:Цитата:
Сообщение от Дмитрий Артюховский
Как ещё можно понять слова "принудительным хранением результатов работы каждого ФБ в ОЗУ или регистровой памяти"?Цитата:
Сообщение от Филоненко Владислав
смотри картинку:Цитата:
Сообщение от Newcomer
Вложение 26828
все верно. см.Вложение 26831
Да никакой там ток не течет, если транзистор закрыт. Резистор является нагрузкой для ПЛК и включен он параллельно оптрону. А вот форма импульсов улучшилась кардинально. 2кОм можно поставить, не спорю. Хотя и при 1 нагрузка на выход ПЛК 25 мА. (допустимая 400 мА).
Перестают управляться 2 быстрых (ПЛК-110.32) и первые 2 простых входов. Вложение 26835Цитата:
Сообщение от capzap
Не заливать, конечно можно, но и генерировать нечем будет. Нафига тогда эти PRU предложили?
Это проблемы роста. ;)Цитата:
Сообщение от dima64
Да как он там течет? Я не схемотехник, нарисуй картинку.
Вердикт: эксперимент показывает, что регистры _не_ переиспользуются. Тут всё ровно так, как и говорил Владислав.Цитата:
Сообщение от Дмитрий Артюховский
Дмитрий, я требую извинений.
Вот пример: Вложение 26836, Вложение 26834
Видно, что после того, как первые AND'ы отрабатывают, то регистры можно и переиспользовать для следующих AND'ов.
Компилируем и видим такое (в конце):
Видно, что номера регистров только растут. Т.е. регистры с меньшими номерами не переиспользуются.Код:#defFB PRU_AND2_64 PRU_AND2
R8.b2
R8.b3
R9.b0
#defFB PRU_AND2_59 PRU_AND2
R7.b1
R9.b0
R9.b1
#defFB PRU_AND2_65 PRU_AND2
R5.b2
R9.b1
R9.b2
Пойдём в target.trg файл, и уменьшим значение REG_END=28 до 8-и. Ну, сделаем вид, что в нашем PRU всего-навсего 8 регистров.
Что нам скажет компилятор?
Он нам скажет "unknown ID 0 in element", и вообще не сможет скомпилировать такое FBD.
Т.е. по факту, компилятору не хватило R2..R8 регистров (7 штук по 4 байта каждый, т.е. 28 байт!).
А по факту, видно, что регистры для "AND" блоков очень быстро становятся ненужными.
По факту, тут 4 "FROM_HOST" блока. Да, 16 байт действительно нужно постоянно хранить (информация с HOST'а обновляется далеко не в каждом PRU цикле). Но остаётся целых 12 байт == 28-16, и линкер всё равно не смог выполнить несколько AND'ов? Что за ерунда?
Поэтому я и говорю, что мой подход и подход ОВЕН в части компиляции существенно отличаются.
Ну это я к чему, не к тому, что "инструмент beta PRU плохой", а к тому, что это моя аргументация почему я не могу просто взять и оформить свою ШД программу "по правилам ОВЕН". Тут не только моё субъективное "не хочу тратить время", но и вполне конкретная техническая проблема.
Откуда тут земля нарисовалась? Посмотри картинку PRONET1.
Я ошибся. при закрытом транзисторе ток через светодиод вообще не течет.Цитата:
Сообщение от dima64
На этот вопрос (можно ли выводить результаты PRU программы в "plc configuration") тов. Филоненко говорит решительное нет. Ну, что, якобы, адреса памяти КДС назначает произвольно, что это в концепцию ПЛК110 не укладывается и т.п.Цитата:
Сообщение от capzap
С моей точки зрения, звучит, конечно, неубедительно. Свои fast encoder/fast counter программы в ОВЕН как-то сделали и в конфигуратор сумели вывести? Значит и для PRU программ такая возможность может быть. Да, возможно, это потребует доработку прошивки, но fast encoder же как-то сделали модулем в plc configuration?
Тем не менее, над конкретно этим вопросом предлагаю не заострять внимание, а воспринимать его как "данность свыше".
Обмен только через pruaccesslib.lib? Ну, ок.
Конечно, и в части "обмена host-pru" можно сделать более удобные механизмы, но нет никакого смысла тратить время и силы на обсуждение механизмов обмена данными и plc configuration, если ОВЕН молчит про саму возможность составлять PRU программы.
нет,я не про это, протестил конечный пользователь работу пру и перешел к повседневным делам. как ему вернуть контроль, если залитая программа в пру до сих пор крутится, как от нее избавиться?
Отступать нельзя -- позади Москва.Цитата:
Сообщение от capzap
Можно залить пустой файл -- тогда всё вренётся к обычному режиму.
Вы так пробовали? Судя по скрину заблокированы и два обычных входа, в Вашем коде вряд ли они используются и тем не менее заняты, чем это будет отличаться от пустого файла?
Тем, что в "конфигуратор" быстрые входы попадают через "программу PRU по умолчанию".Цитата:
Сообщение от capzap
Если PRU*.prg не залиты, то входы-выходы работают как обычно.
Если PRU*.prg залиты, то входы-выходы работают согласно залитой программе. В текущей моей "программе ШД" входы никак не обрабатываются, поэтому Дима и пишет, что "перестают работать входы".
Другое дело, что всем нужно одновременно и ШД крутить, и со входов информацию получать.
Для этого есть 2 варианта:
1) Звонить в ОВЕН
2) Просить меня, чтобы расширить "программу ШД" и добавить туда какую-нибудь обработку входов
Я просто удаляю PRU0, PRU1 из ПЛК-браузер, перегружаю, и все ПЛК чист, как из коробки.Цитата:
Сообщение от capzap
Кстати, если PRU1 не загружен, то первые 2 быстрых выхода работают из конфигуратора.
в этом примере дело не в "анд"-ах а в 4-х кратном размещении "pru_host". в том виде как он сделан в библиотеке - он читает 1 фиксированный регистрЦитата:
Сообщение от Владимир Ситников
кстати, продам наблюдение - "подход овена" - это по сути локализация (русификация с извращениями) соответствующего инструмента TI, т.е. достаточно широко используемого инструмента.... Ну конечно "черепаха" круче всего мирового опыта программирования - тут без сомнений. Керниган, Ричи и Кнут плачут горькими слезами ))))
На всякий пожарный, поддержка Дельты ответила, что "тот самый документ" давным-давно устарел и нужно смотреть новые функции.Цитата:
Сообщение от Newcomer
В новой документации у них линейное ускорение, но возможностью активации режима "s кривой" (про этот режим ни слова более не сказано).
Вложение 26849
ну или делать на совместимость с блоками овена - тогда любой может нарисовать нужную ему картинку )))Цитата:
Сообщение от Владимир Ситников
Вот вариант с 1 PRU_FROM_HOST.Цитата:
Сообщение от Дмитрий Артюховский
Всё равно не работает с параметрами REG_START=2, REG_END=6. В прошлый раз я не учёл, что "последний" регистр линкер не использует, т.е. по факту REG_START=2, REG_END=6 это не 4, а 3 регистра для манёвров, но на такую схему 3 регистра вполне должно хватать?
Т.е. регистров R2, R3, R4, R5 ему оказывается мало для того, чтобы сделать AND'ы от одного-единственного PRU_FROM_HOST.
В чём проблема на этот раз?
Вложение 26850
Во-первых, я уже писал почему это сделать невозможно.Цитата:
Сообщение от Дмитрий Артюховский
А во вторых, ещё причина: блоки ОВЕН поддерживают _только_ байтовые входы-выходы. Хотите WORD/DWORD -- уже никак.
И как с этим работать?
надеюсь к загрузочному проекту это не относится, просто наличие файлов в плк имеет значениеЦитата:
Сообщение от dima64
на скрине и со слов автора скрина влияние программа ПРУ оказывает и на два обычных входа или же четыре входа, четыре выхода, не зависимо от того какой у них типЦитата:
Сообщение от Владимир Ситников