Программирование ПЛК110 [М02] для задач реального времени

[приборист]

ну не томите, поделитесь :)
как себя ведет движок, если с плк ему задать полный не адекват ошибка или все же некая отработка задания

А что задать?
Я пытался как мог, все работает. (Описал вроде ранее)
Либо скорость большая и на выходе ошибка.
Вариантов то немного))

[Владимир Ситников]

Разберём то, какие команды выдаёт ФБ дельты.


В двух словах:
0) График частоты от импульсов в документации дельты неправильный. А чего вы хотели от документа 2006 года? :D
1) При использовании ступенек дельта генерирует рваный ритм движения -- это нехорошо ни для оборудования, ни для пропуска импульсов
2) Если количество ступенек равно количеству импульсов на разгон, то ритм уже не рваный, но при этом нагрузка на ШД увеличением скорости тоже растёт, а у всех ШД крутящий момент с увеличением скорости лишь падает. Т.е. с точки зрения использования характеристик ШД алгоритм странный

Но там есть ещё одно но. Я не знаю с какой точностью дельта может выдерживать частоту.
В вычислениях ниже предполагается, что точность частоты импульсов выдерживается точно.


На 93-ей странице показано как устроен алгоритм разгона.
26654

Из этого можно вынести, что разгон выполняется по ступенькам. На каждой ступеньке одинаковое количество импульсов, количество ступенек задаётся пользователем.

Дальше там рассматривается случай: "начальная скорость 1кГц, конечная 10кГц, 100Гц шаг ступеньки, 10000 импульсов на весь разгон".
Рассчитаем этот случай: должно быть (10'000Гц-1'000Гц)/(100Гц/ступенька) == 90 ступенек. В каждой из них примерно по 111 = 10000/90 импульсов.

Строить будем в r-system (https://www.r-project.org/)

delta <- data.table(i=seq(1, 10000))
delta[, freq := ((i-1) %/% 111) * 100 + 1000] # %/% это целочисленное деление
delta[, dt := 1/freq]
delta[, t:=cumsum(dt)] # сумма интервалов с накоплением

ggplot(delta, aes(i, freq))+geom_point()+scale_x_continuous("Количество импульсов")+scale_y_continuous("Частота, Гц")+ggtitle("Delta PLC, разгон от 1кГц до 10кГц шагами по 100Гц за 10000 импульсов")

График "частота от количества проделанных импульсов" выглядит почти линейно. Ну, разумеется, там же все ступеньки одинаковой длины, и ступенек 90 штук. Выглядит как ломанная прямая.
Уже тут становится очевидно, что в документации delta косяк. По крайней мере, в русской версии.

Теоретический график
26710

А вот что у дельты:
26646
Ясно видно, что у них неправильно изображена форма "разгона". Скорее всего, это ошибка copy-paste. Т.е. они тупо скопировали другой график и не подумали, что реально график так выглядеть не будет.
Copy-paste или нет, но это 100% ошибка дельты.


Посмотрим как будет выглядеть график "частота от времени":

ggplot(delta, aes(t, freq))+geom_point()+scale_x_continuous("Время, сек")+scale_y_continuous("Частота, Гц")+ggtitle("Delta PLC, разгон от 1кГц до 10кГц шагами по 100Гц за 10000 импульсов")
26711

Тут график похож на тот, который показан в документации. В документации говорится, что "макс частота" достигается через 2606мс, а, согласно нашим вычислениям это должно произойти через 2607 мс. Совпало с точностью до миллисекунд -- т.е. норм.


> tail(delta, 15)
i freq dt t
1: 9986 9900 0.0001010101 2.606330
2: 9987 9900 0.0001010101 2.606431
3: 9988 9900 0.0001010101 2.606532
4: 9989 9900 0.0001010101 2.606633
5: 9990 9900 0.0001010101 2.606734
6: 9991 10000 0.0001000000 2.606834
7: 9992 10000 0.0001000000 2.606934
8: 9993 10000 0.0001000000 2.607034
9: 9994 10000 0.0001000000 2.607134
10: 9995 10000 0.0001000000 2.607234
11: 9996 10000 0.0001000000 2.607334
12: 9997 10000 0.0001000000 2.607434
13: 9998 10000 0.0001000000 2.607534
14: 9999 10000 0.0001000000 2.607634
15: 10000 10000 0.0001000000 2.607734

Эти миллисекунды не столь важны, как сама форма кривой.


Попробуем посмотреть как зависит форма кривой от количества ступенек в лестнице.



d <- data.table()
for(n in c(2, 4, 8, 16, 128)) {
d2 <- data.table(i=seq(1, 10000))
pulses_per_step <- 10000 %/% n
d2[, freq := (i %/% pulses_per_step)*((10000-1000) %/% n) + 1000]
d2[, dt := 1/freq]
d2[, t:=cumsum(dt)]
d2[, nsteps:=n]
d <- rbind(d, d2)
}
ggplot(d, aes(t, freq))+geom_point()+scale_x_continuous("Время, сек")+scale_y_continuous("Частота, Гц")+ggtitle("Delta PLC, разгон от 1кГц до 10кГц")+facet_grid(nsteps~.)

26713

Особого смысла изучать случай "малого" количества ступенек нет. Понятно, что при ступеньках будут те самые рывки. Например, в случае когда всего 2 ступеньки, движок сначала долго фигачит на 1кГц, а потом бах -- сразу переключается на 5.5кГц.

Кому интересно, может попробовать доказать, но, практика показывает, что кривая близка к экспоненте при увеличении количества шагов.

Собственно, случай "на каждой ступеньке ровно по одному импульсу":



delta <- data.table(i=seq(1, 9000))
delta[, freq := i+1000]
delta[, dt := 1/freq]
delta[, t := cumsum(dt)]
ggplot(delta, aes(t, freq)) +
geom_point() +
scale_x_continuous("Время, сек") +
scale_y_continuous("Частота, Гц") +
ggtitle("Delta PLC, разгон от 1кГц до 10кГц")+
geom_smooth(formula = log(freq) ~ t, color="red")


26649

О чём говорит "экспоненциальный закон изменения частоты от времени"?
О том, что ускорение тоже экспоненциально возрастает от этого самого времени.

Узнаем этот самый эксп. закон:


> lm(log(delta$freq) ~ delta$t)

Call:
lm(formula = log(delta$freq) ~ delta$t)

Coefficients:
(Intercept) delta$t
6.908 1.000

Иными словами, freq == exp(6.908)*exp(t) == 1000.245 * exp(t)
Ускорение это производная от частоты, и она будет тоже равна 1000.245 * exp(t). Единицы измерения другие, но формула та же (просто у константы 1000.245 разная размерность, которая нас не волнует).

Собственно, строим самый главный график: "нагруженности движка от частоты".
Нагруженность движка линейно зависит от ускорения, поэтому достаточно построить график "ускорения от частоты".
Но у нас же частота равна ускорению!

Т.е. график будет выглядеть так:


ggplot(delta, aes(freq, freq)) +
geom_point() +
scale_x_continuous("Частота, Гц") +
scale_y_continuous("Ускорение (нагрузка на ШД), Гц/сек") +
ggtitle("Delta PLC, нагрузка на ШД при разгоне от 1кГц до 10кГц")


26650

О чём это говорит? Кто догадался -- молодец.
Кто не догадался -- расскажу.

Возьмём график крутящего момента от скорости вращения для какого-нибудь ШД. Не абы какого, а такого, который у прибориста.
На самом деле, у всех ШД этот график примерно одинаково выглядит, но проще оперировать реальными цифрами, а не мифическими.

Собственно, ШД ES-MH33480
График:

26651

Видно, что на малых оборотах движок может развить силу больше 8 Н*м, а с увеличением скорости его сила падает.
Иными словами, дёрнуть с места он может хорошо, а как раскрутится его "тяга" ослабевает.

Т.е. для эффективного использования мощности этого движка, нужно начинать с большого ускорения (задействовать мощный крутящий момент в начале), а потом сбавлять это самое ускорение, чтобы нагрузка на вал не превышала максимальный крутящий момент движка.

Собственно на картинке:
26653

Какие отсюда можно сделать выводы:
1) В самом экспоненциальном разгоне смысла мало. Видно что красная кривая ("кривая дельты") упирается в скорость 10 rpm. И эту скорость никак не превысить. Разумеется, конкретная скорость зависит от конкретных цифр, но не суть. Я говорю, что "нет простого способа" сказать дельте "перестань увеличивать ускорение".
Конечно, можно начать играться с количеством ступенек, то при перескоке с одной на другую могут быть неприятные дёрганья -- большие ускорения, а значит, возможны и выходы за кривую возможностей движка.

Конечно, ещё есть вариант делать "составное движение", но если его для этого и будут использовать, то не от хорошей жизни, а от безысходности. Честно говоря, мне лень проверять, но, скорее всего, составное движение в случае дельты не поможет, т.к. движение от 1кГц до 5кГц шагами по 1Гц + движение от 5кГц до 10кГц шагами по 1Гц по факту будут выглядеть точно так же, как и движение от 1кГц сразу до 10кГц этими же шагами по 1Гц. Я просто не исключаю того факта, что в дельте-таки может быть какой-нибудь извратный способ разогнать ШД и при этом не наращивать ускорение при самом разгоне.

2) Кривая с постоянным ускорением тоже рано или поздно упирается в предел движка. Т.е. на определённых оборотах движок уже не может поддерживать нужное ускорение.
Но если реально нужны большие обороты, то можно просто с самого начала указать более маленькое ускорение.
Да, время выхода на режим увеличится, но на режим выйдет.

3) Крутящий момент нужно измерять на "максимально необходимых для данной установки оборотах". Разумеется, указывать нужно не то значение, при котором начали возникать пропуски импульсов, а с неким запасом.

4) Если говорить про "пропуски импульсов", то более важно "сглаживать" не начало пути, а конец -- тот момент, где тяга у движка ослабевает, и нужно снижать нагрузку.

5) В случае "идеальной" кривой (ну, когда сначала ускорение плавно растёт, а потом уменьшается), конечно, по-полной используются возможности движка, но есть шанс, что "горб"-таки выйдет за границы возможностей.
Как отлаживать S-кривую, чтобы она не выходила за границы допустимых нагрузок -- фиг знает.
С каким-нибудь регистратором реального крутящего момента (нагрузки на движок) было бы, конечно, удобнее, но сомневаюсь, что их массово используют.

Скорее всего, нужно делать некое подобие "с плавным выходом на постоянное ускорение", а потом "с плавным переходом на нулевое ускорение == на равномерное движение". Но тут эти самые "плавные выходы", скорее, не для пропуска импульсов будут служить, а для того, чтобы уменьшить толчки оборудования.


Та же самая дельта генерирует большой толчок в конце разгона. У неё ускорение на протяжении всего разгона растёт, а потом сразу меняется на нулевое.

[Владимир Ситников]

А что задать?
Я пытался как мог, все работает. (Описал вроде ранее)
Либо скорость большая и на выходе ошибка.
Вариантов то немного))
Можешь ещё эксперимент провести: поставить малое ускорение разгона, и попытаться раскрутить до большой скорости?

Просто у ШД крутящий момент падает с увеличением скорости вращения (см последнюю картинку (http://www.owen.ru/forum/showthread.php?t=22169&p=221700&viewfull=1#post221700)), а мой блок сейчас выдаёт константное ускорение.
Т.е. если нужно достичь большей скорости нужно ставить меньшее ускорение.

Тут, скорее, из спортивного интереса. В спецификации энкодера сказано, что он до 200кГц, и "слова упирается в 23-25кГц" звучат странно.

[Newcomer]

Насколько я понял все более менее нормально. Но для полноценных испытаний нужен именно ШД и драйвер к нему. У сервопривода драйвер более совершенен и менее требователен к качеству сигнала подаваемого на вход Step.

Дмитрий Артюховский, может вы подсобите в этом вопросе. У вас есть железо для проведения полноценных испытаний, и опыта у вас ого-го-го сколько. Надо отбросить амбиции и подключиться к общему делу.

[Newcomer]

По хорошему проверить бы количество передаваемых импульсов (для меня критично, потому что в итоге может накапливаться ошибка)Но осциллографа нет, проверить нечем.

Тут не надо никакого осциллографа. Запомните положение вала двигателя. Подайте на драйвер столько импульсов чтобы вал двигателя повернулся ровно на 1 оборот и посмотрите результат. Еще лучше подать столько импульсов чтобы вал повернулся ровно на 10 или 100 оборотов. Если возникнет существенная ошибка в угле поворота вала, то это визуально будет видно.

[BETEP]

Но для полноценных испытаний нужен именно ШД и драйвер к нему.
https://www.google.ru/search?tbm=isch&q=A4988&gws_rd=ssl
Полноценный драйвер, стоит недорого, есть аналог с более высоким дроблением шага.
если совсем лень паять обвес из кондёра, сопротивлений и перемычек, можно взять комплект.
https://ru.aliexpress.com/item/Free-shipping-New-cnc-shield-v3-engraving-machine-3D-Printer-4pcs-A4988-driver-expansion-board/32700553372.html?spm=2114.13010608.0.116.74Vk0X
Цеплял этот драйвер к обычному контроллеру от омрона.


Полноценный мелкий шаговик вроде этого:
https://ru.aliexpress.com/item/2-4-35-0-9-20/32677700359.html?spm=2114.13010608.0.124.74Vk0X
можно найти в старом струйнике от эпсона, причём вместе с железяками для линейного перемещения, т.е. нагрузку можно менять и визуально наблюдать за работой.
На побаловаться можно взять шаговик от сидюка, но от драйвера по ссылке ток сложно для него настроить при питании от 12В.


посмотреть протестированный код на тему рампы можно здесь
https://github.com/grbl/grbl
искать выполнение команды G00, там же можно глянуть поиск исходного положения.
в файле gcode.c разбор поступивших команд и вызов функций




есть ещё один пример, простой и не совсем допиленный.
http://www.pjrc.com/teensy/td_libs_AccelStepper.html


Инструкцию от Дельты конечно смотреть нужно, вроде не плохо сделано, у современных даже круговая интерполяция есть.
Но в Омроне всё таки управление шаговиком намного удобнее в использовании, и в отличие от дельты можно налету менять скорость и координаты.
http://www.techtrends.ru/docs/omron/sistemy_avtomatizatsii/programmiruemye_logicheskie_kontrollery/modulnye_pls/modulnye_kontrollery_cj1m/W395-RU2-01_CJ1M_OperManual.pdf


-----------------------
По поводу правильной рампы, думаю пока не стоит заморачиваться.
В омроне кстати разгон тоже ступенькой с интервалом в 4 мс.

[Владимир Ситников]

По поводу правильной рампы, думаю пока не стоит заморачиваться.

Это что значит?
Рампа уже есть, и она линейная. Предлагается передалать на ступенчатую? Смысл?

Возможно, омрон/дельта делают ступенчатые рампы для того, чтобы как-то сэкономить процессорное время.
По факту, у сопроцессора ПЛК110 мощи хватает, а делать ему всё равно больше нечего.
Поэтому можно делать ту рампу, которая нужна без всяких условностей со ступеньками.

[BETEP]

Я имел ввиду что и линейной достаточно

[приборист]

Тут не надо никакого осциллографа. Запомните положение вала двигателя. Подайте на драйвер столько импульсов чтобы вал двигателя повернулся ровно на 1 оборот и посмотрите результат. Еще лучше подать столько импульсов чтобы вал повернулся ровно на 10 или 100 оборотов. Если возникнет существенная ошибка в угле поворота вала, то это визуально будет видно.

По мне - это не проверка.
В моем случае такой проверки хватит (из-за специфики объекта), а вот потом другие могут получить интересные результаты :)

[Newcomer]

По мне - это не проверка.
В моем случае такой проверки хватит (из-за специфики объекта), а вот потом другие могут получить интересные результаты :)

Это отличная проверка. Не поленись и сделай. Задай как можно больше полных оборотов вала двигателя и посмотри результат. Таким образом будет проверено правильно ли ФБ формирует заданное количество импульсов.

Можно в ПЛК написать тестовую программу, которая даст ФБ 10 заданий повернуть вал на 10 оборотов (итого будет 100 оборотов).
Каждый раз будет разгон и торможение. Получится отличная проверка.

[Дмитрий Артюховский]

Совсем не гложит ничего ))) применяйте, я ж не запрещаю, но вы же просили оценку )))

[BETEP]

Возможно, омрон/дельта делают ступенчатые рампы для того, чтобы как-то сэкономить процессорное время.
По факту, у сопроцессора ПЛК110 мощи хватает, а делать ему всё равно больше нечего.
Поэтому можно делать ту рампу, которая нужна без всяких условностей со ступеньками.
Вполне возможно что для экономии времени. Ведь иногда приходится одновременно крутить две-четыре оси, считать несколько энкодеров, и не забывать о прерываниях по входам. Т.е. как будет Ваш FB сочетаться с другими подобными?

-------------
ИМХО, покрутить несколькими осями шаговиков можно и через rs232 и ардуину, причём даже с интерполяцией.
(Если думаете что ардуина не надёжна, спорте с секреткой в моей машине)

[Владимир Ситников]

Вполне возможно что для экономии времени. Ведь иногда приходится одновременно крутить две-четыре оси, считать несколько энкодеров, и не забывать о прерываниях по входам. Т.е. как будет Ваш FB сочетаться с другими подобными?
Вычисление рампы на частоте выхода 100кГц занимает примерно 2-3% времени PRU ядра (http://www.owen.ru/forum/showthread.php?t=22169&page=30&p=221401&viewfull=1#post221401). Всё остальное время процессор и делает, что "опрашивает входы".
В ПЛК110 М02 этих ядер два.

В этом самом ПЛК110 М02 быстрых выходов всего 4 штуки. И быстрых входа тоже всего 4.
Т.е. ресурсов хоть отбавляй. Наверняка можно управлять и 4мя ШД от текущего ПЛК110. По 2 ШД на ядро не является большой проблемой.

Ещё раз повторюсь: кроме отработки быстрых входов/выходов эти PRU ядра вообще ничем больше не занимаются.

Вот если бы ОВЕН распаяли все 60 быстрых выходов, которыми могут рулить PRU ядра, тогда совсем другой разговор был бы. А так как выходов всего 4 штуки, то не вижу смысла заморачиваться с оптимизацией чего бы то ни было.

Мы же не рассматриваем случай использования какого-нибудь мультиплексирования для того, чтобы по одному-двум проводам передавать команды на десяток ШД?


ИМХО, покрутить несколькими осями шаговиков можно и через rs232 и ардуину, причём даже с интерполяцией.
(Если думаете что ардуина не надёжна, спорте с секреткой в моей машине)
В ПЛК110 заявлена поддержка 100кГц. Поэтому, использование ПЛК110 как для простой автоматики, так и для управления ШД/энкодерами может вполне неплохо смотреться.

Конечно, сейчас ПЛК110 сам по себе не умеет управлять ШД. Т.е. если ШД нужен, то, возможно, и ПЛК110 в проекте не возникнет.
С другой стороны, если в ПЛК110 будет возможность управлять ШД, то это вполне может склонить чашу весов в пользу ПЛК110, т.к. для конечного пользователя снимется вопрос "как скрещивать, программировать и т.п. ардуину".


Про "использования ардуины в промышленности" меня спрашивать бесполезно, но лично я бы не стал делать смешанную "ПЛК110+ардуино" систему себе (в квартиру). Для меня ПЛК110 проще в установке/настройке, чем обвешивание конденсаторами и прочей хренью. Ну, реально. Я могу понять конденсаторы, но это не моё.

[BETEP]

vladimirisitnikov я не пытаюсь Вас критиковать, скорее даю совет забить на правильность рампы и думать дальше.
Пытаюсь намекнуть что одной оси недостаточно.

В этом самом ПЛК110 М02 быстрых выходов всего 4 штуки вообще то почти достаточно для четырёх осей, на сигнал смены направления один фиг задержка для шаговика нужна, инерция однако.

Т.е. управление одним ШД, это только начало.

Вычисление рампы на частоте выхода 100кГц занимает примерно 2-3% времени PRU ядра. Всё остальное время процессор и делает, что "опрашивает входы". А если дойдёте до варианта со сменой скорости и координат "на лету" одновременно для двух осей?

Может Вы себе задачу не правильно поставили?

[Дмитрий Артюховский]

Не хорошо делать голословные заявления. Вы лично протестируйте этот "нехороший" ФБ, у вас же для этого все есть. Не уж-то вам не интересно ? Может действительно что-то нароете и нам всем расскажите.

Приборист вот протестировал и остался очень доволен.

он не "нехороший" - он просто не отвечает концепции промышленного контроллера вообще и предложенному овеном формату, поэтому какой смысл в играх с этим "черным ящиком"? а для собственного применения у меня есть блоки


вообще то почти достаточно для четырёх осей, на сигнал смены направления один фиг задержка для шаговика нужна, инерция однако.

способ реализации остальных "небыстрых" выходов ПЛК110 у овена такой, что установленное значение появится на выводе с не прогнозируемой задержкой, достигающей в максимуме 50 мс, поэтому на DIR приходится расходовать "быстрый" выход. А реверсирование ШД в синхронном режиме возможно в следующем такте... ну да при разгонах конечно нужно понизить скорость. Кстати, при разгонах - "ступеньки" (т.е. несколько шагов на одной частоте) не имеют смысла - изменение производится с каждым шагом.

[Владимир Ситников]

vladimirisitnikov я не пытаюсь Вас критиковать, скорее даю совет забить на правильность рампы и думать дальше.
Нее. Норм. Всё в точку было. На grbl и ардуиновскую библиотеку AccelStepper я натыкался когда изучал "имеющиеся работы в области ШД".
Просто вас в теме не видно было, и я предположил, что сообщение #293 (про графики cpu%) и т.п. могли просто не увидеть.

Да, про "забить на правильность рампы" я понял. На рампу я смотрел, скорее из чувства прекрасного. Ну и того, что, якобы, внезапное изменение ускорения плохо сказывается на исполнительных механизмах ( рывок(кинематика) (https://ru.wikipedia.org/wiki/%D0%A0%D1%8B%D0%B2%D0%BE%D0%BA_(%D0%BA%D0%B8%D0%BD %D0%B5%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B0)) и т.п. )

Графики дельтовской рампы делал как для того, чтобы самому получше понять "как там у них", так и для того, чтобы некоторые (не будем показывать пальцем) поняли, что в документации дельта действительно косяк.


Может Вы себе задачу не правильно поставили?

Тут тоже в точку.
У меня ШД нет, и не особо предвидится. Поэтому постановка задачи оказалась "из того, что просили".
Просили "передвижение на указанное количество импульсов" -- сделал.

"Управление несколькими осями" / "изменение плана на ходу" я отдалённо понимаю, но:
1) Пока не просили
2) Хорошо бы всё-таки видеть конкретный сценарий использования. Особенно непонятно каким образом программа поймёт, что пора менять скорость? Т.е. мы запланировали движение "на 5 см влево", а тут, фигак, и "нее, надо на 6 на самом деле было". Как так?

Я ещё могу понять случай "автоматического поиска крайних положений", но и там это должно быть не "внезапное изменение скорости", а "программа поиска крайнего положения" -- т.е. программа должна понимать "что она делает".

В общем, будет потребность -- могу сделать.


Т.е. управление одним ШД, это только начало.
А если дойдёте до варианта со сменой скорости и координат "на лету" одновременно для двух осей?

Зависит от. В том числе, и от ОВЕН. Одна из проблем -- компания ОВЕН не разрешает и не запрещает составление PRU программ (см #196 (http://www.owen.ru/forum/showthread.php?t=22169&page=20&p=220452&viewfull=1#post220452)).
Это какая-то печаль.
Своего не делают. Стороннее не разрешают.

На КДС сторонние программы делать разрешают, а для PRU сторонние программы делать не разрешают. Беда-печаль.

[Дмитрий Артюховский]

Трение не может влиять на разгон. Подумайте и поймёте почему.

На всех применениях где имеется необходимость разгона ШД, ОБЯЗАТЕЛЬНО установлены маховик, для обеспечения необходимого момента инерции, а так же демпфирующее звено выполненное в виде регулируемого по усилию тормоза трения....


что ШД выполняет лишь 10 шагов в секунду при условии, что на него идёт 10'000 импульсов в секнуду,

если ШД сорвался из режима синхронизации при разгоне - он будет стоять на месте а не выполнять редкие импульсы... обратная связь ставиться для определения этого а также для диагностики заклинивания механизма при синхронном вращении

[capzap]

Шалят нервишки? :D

нет нисколько, просто интуиция подсказывает что где то что то идет не так
Например по поводу марсиан, так же решил построить график, результат на видео, он намного ближе к расчетам дельты, единственный вопрос к ним по поводу миллисекунд, вроде не там они знак поставили

[Владимир Ситников]

На всех применениях где имеется необходимость разгона ШД, ОБЯЗАТЕЛЬНО установлены маховик, для обеспечения необходимого момента инерции, а так же демпфирующее звено выполненное в виде регулируемого по усилию тормоза трения....
Всё правильно пишете, но это как-то лишь подтверждает то, что "трение не может влиять на запланированный в программе график разгона"



если ШД сорвался из режима синхронизации при разгоне - он будет стоять на месте а не выполнять редкие импульсы... обратная связь ставиться для определения этого а также для диагностики заклинивания механизма при синхронном вращении
Тут вы путаете ШД и серво. Если есть обратная связь, то это уже серво система. У простого ШД обратной связи нет, и если он пропускает импульсы, то никто никогда не заметит.



Дмитрий, можете поделиться примером хоть какого работающего файла PRU1.prg?
ПЛК в моём случае пишет такое:

Retain init
Slave Retain loaded
EEPROM init
PRU0 user programm loaded
Dublicate PRU programm
PRU1 user prg not loaded!

И я не пойму. То ли в прошивке дело, то ли в PRU1.prg

[BETEP]

2) Хорошо бы всё-таки видеть конкретный сценарий использования. Особенно непонятно каким образом программа поймёт, что пора менять скорость? Т.е. мы запланировали движение "на 5 см влево", а тут, фигак, и "нее, надо на 6 на самом деле было". Как так?

Там где нет жёсткой связи оси с перемещаемым материалом, металлическая полоса или пруток, перемещаемые валами.
На омроновском контроллере можно читать энкодер на полосе и много раз в секунду изменять конечную координату. Т.е. Компенсировать проскальзывания при перемещении и разгоне.

Люфты и пропуски шагов, энкодер может это поправить.

Задачи вроде "летящего ножа" с корректировкой скорости по внешнему энкодеру на материале, который режем.


У меня ШД нет
Зря.


"автоматического поиска крайних положений"
Поиск не крайнего, а исходного положения, поиск нулевой точки для работы в абсолютных координатах.
т.е. шаговику в некоторых случаях отдают команду не на сколько переместиться, а КУДА переместиться.
Контроллер сам определяет направление и дистанцию, счётчик выхода доступен в программе.

[Владимир Ситников]

Там где нет жёсткой связи оси с перемещаемым материалом, металлическая полоса или пруток, перемещаемые валами.
Да, логично.


На омроновском контроллере можно читать энкодер на полосе и много раз в секунду изменять конечную координату. Т.е. Компенсировать проскальзывания при перемещении и разгоне.
Т.е. мы заводим шарманку "переместить на 10 метров", потом по ходу видим, что "было проскальзывание на 0.5м" и правим программу "на самом деле, нужно 10.5м" чтобы в итоге полоса-таки на 10 переместилась?

Да, выглядит забавным.

[Newcomer]

Чем спорить лучше подумать как основательно протестировать ФБ. То что сделал Приборист на сервоприводе это не то. ЩД устроен совсем по другому нежели сервомотор. ШД труднее разогнать до требуемой частоты без пропуска импульсов. При тестировании ФБ на ШД могут возникнуть проблемы.

[Newcomer]

Боюсь, вы не понимаете чем мы с Прибористом занимаемся.

Прибористу нужны не шашечки в виде ШД, а ему нужно ехать.
В конце концов, ему нужно управлять двумя серво-приводами.

И тут либо как-то раскочегарим ПЛК110, либо Приборист поставит ардуину.

Если ПЛК110 победит ардуину, то можно будет ещё один заход в ОВЕН делать.

Я не о том что делает Приборист, а о том будет ли ваш ФБ успешно управлять ШД, для чего собственно он и делался. Еще раз повторю, что сервомотор и ШД - это совершенно разные вещи.

[Newcomer]

Еще один интересный вопрос к В.Ситникову. На каких условиях можно будет использовать ваш ФБ ?

[Владимир Ситников]

Еще один интересный вопрос к В.Ситникову. На каких условиях можно будет использовать ваш ФБ ?

Apache license 2.0: https://www.apache.org/licenses/LICENSE-2.0 (~ http://www.dataved.ru/2011/03/apache-license-2.html )

Если грубо, то:
1) Можно использовать как угодно
2) Слова "(c) Vladimir Sitnikov" удалять нельзя (Вы должны сохранить в Исходной форме любых Производных работ, которые вы распространяете, все авторские права, патенты, торговые марки, а также соответствующие атрибуции из Исходной формы Работы, за исключением тех, что не имеют отношения к какой-либо части Производной работы)
3) Если в код (в том числе pru_stepper.lib) вносятся изменения, то нужно добавлять комментарий "допилено Newcomer'ом..." (Вы должны снабдить все модифицированные файлы явными уведомлениями, что Вы изменили файлы)

[приборист]

Чем спорить лучше подумать как основательно протестировать ФБ. То что сделал Приборист на сервоприводе это не то. ЩД устроен совсем по другому нежели сервомотор. ШД труднее разогнать до требуемой частоты без пропуска импульсов. При тестировании ФБ на ШД могут возникнуть проблемы.


Я не о том что делает Приборист, а о том будет ли ваш ФБ успешно управлять ШД, для чего собственно он и делался. Еще раз повторю, что сервомотор и ШД - это совершенно разные вещи.

;););););););)

Не читать сначала, спорить всю тему, говорить всем что надо делать, а потом прийти к выводу, что все это не то.
Осталось обвинить Ситникова, что он ерунду сделал ;).


ЗЫ
Моя серва работает, за что спасибо Владимиру.
Осталось запустить PRU1 и все уедет на объект.

ЗЫЫ
Пробовал подавать 800 000 импульсов на двигатель (800 импульсов это один оборот)
Останавливается в том же месте.

Понимаю, что на столе это одно, а на оборудовании будет несколько иначе.
Но по факту потом узнаем.

[Newcomer]

Правильно я понял, что использование вашего ФБ для управления ШД будет совершенно бесплатным ?

[Newcomer]

Осталось обвинить Ситникова, что он ерунду сделал.

К В.Ситникову никаких претензий нет.


Пробовал подавать 800 000 импульсов на двигатель (800 импульсов это один оборот)Останавливается в том же месте.

Это подтверждает только то, что ФБ разгоняет двигатель до заданной частоты и правильно отсчитывает заданное количество импульсов.

Еще раз повторю, что сервомотор и ШД - это совершенно разные вещи и при работе с ШД могут возникнуть проблемы.

Надо тестировать ФБ на ШД.

[Владимир Ситников]

Правильно я понял, что использование вашего ФБ для управления ШД будет совершенно бесплатным ?

Неправильно :D

Если очень хочется заплатить, то я никогда не отказываюсь


А так, да, никаких специальных закладок типа "не крутить больше 1000 оборотов" в коде нет. Т.е. файлом PRU0.prg можно пользоваться бесплатно и без s m s на свой страх и риск, с надеждой, что в будущих версиях прошивки ПЛК поддержка файла PRU0.prg останется.

Если посмотреть внутрь pru_pulse_v4.zip (http://www.owen.ru/forum/showthread.php?t=22169&page=37&p=221591&viewfull=1#post221591), то там так и говорится, что "apache license 2.0"

[приборист]

К В.Ситникову никаких претензий нет.



Это подтверждает только то, что ФБ разгоняет двигатель до заданной частоты и правильно отсчитывает заданное количество импульсов.

Еще раз повторю, что сервомотор и ШД - это совершенно разные вещи и при работе с ШД могут возникнуть проблемы.

Надо тестировать ФБ на ШД.

Странно что Вы два месяца к этому шли.
С самого первого сообщения я обращал внимание, что у меня сервопривод а не чистый ШД.

У Вас есть уникальная возможность, взять ШД и потестировать.
Учитывая что сейчас ШД есть в каждом принтере\сканере\приводе, думаю проблем возникнуть не должно.

Для меня изначально задача стояла именно в управлении STEP\DIR.

[Newcomer]

Странно что Вы два месяца к этому шли.
С самого первого сообщения я обращал внимание, что у меня сервопривод а не чистый ШД.

У Вас есть уникальная возможность, взять ШД и потестировать.
Учитывая что сейчас ШД есть в каждом принтере\сканере\приводе, думаю проблем возникнуть не должно.

Для меня изначально задача стояла именно в управлении STEP\DIR.

Что там у вас - это дело десятое. Частично ФБ вы протестировали и хорошо.

Сейчас задача проверить ФБ на ШД. ШД должен быть размером не с гулькин нос, а ватт на 200.

[Newcomer]

Неправильно :D

Если очень хочется заплатить, то я никогда не отказываюсь


А так, да, никаких специальных закладок типа "не крутить больше 1000 оборотов" в коде нет. Т.е. файлом PRU0.prg можно пользоваться бесплатно и без s m s на свой страх и риск, с надеждой, что в будущих версиях прошивки ПЛК поддержка файла PRU0.prg останется.

Если посмотреть внутрь pru_pulse_v4.zip (http://www.owen.ru/forum/showthread.php?t=22169&page=37&p=221591&viewfull=1#post221591), то там так и говорится, что "apache license 2.0"

А где последний релиз вашего ФБ для ШД ?

[capzap]

Ещё раз: у дельты 2606мс, у меня получилось 2.606834 сек. Не вижу смысла искать космические силы (работающий двигатель или ещё какие-то факторы). Число одно и то же. Мои вычисления совпали с теми, что у дельты.
В ваших вычислениях на java проблема в том, что вы считаете, что все ступеньки имеют длину 111 импульсов, а по факту, 10000 импульсов на 111 не делится.

Хватит тупить. Удалите лучше свои сообщения #447, #450 и #455.
да я про веремя и не заикался больше, сообщил что Вы неправильно что то посчитали и забыл, то что не совсем совпало, понятно что правильно надо было поделить в нужном месте.
Про натурные испытания это я про график зависимости от количества импульсов. Например здесь (http://avrdoc.narod.ru/index/0-7) рисунок 2-6, показаны шаги с разной продолжительностью по времени, по расчетам в каждом шаге одинаковое количесвто импульсов, когда мы перенесем эти импульсы на равноудаленные расстояния(чтоб создать график зависимость от количества импульсов), график изменится на кривую которая представлена на картинке у дельты

[Владимир Ситников]

да я про веремя и не заикался больше
Ещё раз прошу. Удалите, пожалуйста свои сообщения #447, #450, #455, #470
Я удалю свои ответы на них. Да, с 2606мс был мой косяк, но я с самого начала и сказал, что "конкретная цифра не важна".

Я почти неделю ждал, пока администраторы меня переименовали.
Не надо осложнять им жизнь.


Про натурные испытания
Я много раз говорил, что "натурные испытания" это добавление лишних сущностей в проблему.
Есть алгоритм -- должен быть график его работы.

Попытка приплести "натурные испытания" для того, чтобы объяснить почему график не соответствует теоретическому описанию это полный бред.



Например здесь (http://avrdoc.narod.ru/index/0-7) рисунок 2-6, показаны шаги с разной продолжительностью по времени, по расчетам в каждом шаге одинаковое количесвто импульсов, когда мы перенесем эти импульсы на равноудаленные расстояния(чтоб создать график зависимость от количества импульсов), график изменится на кривую которая представлена на картинке у дельты

У дельты описана вполне конкретная формула. С чего вы думаете, что "график изменится на кривую которая представлена на картинке у дельты"?
Вот, реально, с чего бы ему измениться?
Каким боком алгоритм "от 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 для задач реального времени (http://www.owen.ru/forum/showthread.php?t=22169)

Я записался на beta тестирование и мне удалось сделать PRU программу, которая выдаёт указанное количество импульсов на быстрый 3-ий выход.

Должно получиться управление четыремя ШД (одновременно только 2). Один ШД на выходы 1 или 2, второй -- на выходы 3 или 4.

Сама тема "использования PRU" программ пока под вопросом -- ОВЕН пока никак не обозначили свою позицию.
Тем не менее, можно надеяться, что PRU0.prg будет работать и в будущих версиях прошивки ПЛК110.

Внимание, для работы нужно подключать библиотеку pruAccessLib.lib, которую берут тут http://www.owen.ru/forum/showthread.php?t=22169&p=180471&viewfull=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 (http://www.owen.ru/forum/showthread.php?t=22169&page=34&p=222251&viewfull=1#post222251))
* Убран выходной параметр "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):


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


max_speed/quantity/accel_ramp/decel_ramp можно менять только в состоянии INIT. Т.е. менять на ходу параметры нельзя.

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 (https://www.apache.org/licenses/LICENSE-2.0)


Тестирование выполнялось как на эмуляторе сопроцессора (https://github.com/vlsi/pru-emulator) (графики выше получены с эмулятора), так и на реальном сервоприводе (http://www.owen.ru/forum/showthread.php?t=22169&p=221906&viewfull=1#post221906).

[Владимир Ситников]

удалять я конечно ни чего не буду, это было мое мнение, я занял такую позицию и несобираюсь этого скрывать, пусть все будут знать как и в чем я был не прав
Понимаю и уважаю это мнение, но, пожалуйста, тема далеко не про вас, не про меня, не про дельту, а про ПЛК110 М02 и его PRU.
Все, кому надо (кто читал тему) уже увидели. Кому не надо -- тому и не надо.


по поводу корня, вернее сперва про график дельты, там нет делений, поэтому кривая это просто выражение того что не прямая линия
Напишите в дельту -- и спросите у них.
По-моему, мы слишком много времени тратим на дельту в теме про ПЛК110.
Ничего нового оно нам не даёт и не даст.

BETEP правильно сказал. Если и смотреть, то в сторону дальнейшего развития: корректировка по ходу работы, больше чем 1 ШД и т.п.

[Филоненко Владислав]

Товарищи, а не кажется ли Вам, что подход к управлению движением в виде 1 ФБ "сделай всё" в корне не верен?
ИМХО, правильнее было бы разделить задачу на:
1. Вычисление кривой движения (делает основной цикл ПЛК)
2. Деление кривой на N отрезков (опять же основной цикл)
3. Выдача импульсов по отрезкам силами PRU

Проводить сложные вычисления с плавающей точкой (или её эмуляциями) внутри PRU - это много лишнего кода и времени.
Код генератор N импульсов с M периодом и подгрузкой нового отрезка по мере выполнения - гораздо проще и гибче.

[Дмитрий Артюховский]

Товарищи, а не кажется ли Вам, что подход к управлению движением в виде 1 ФБ "сделай всё" в корне не верен?
ИМХО, правильнее было бы разделить задачу на:
1. Вычисление кривой движения (делает основной цикл ПЛК)
2. Деление кривой на N отрезков (опять же основной цикл)
3. Выдача импульсов по отрезкам силами PRU

Проводить сложные вычисления с плавающей точкой (или её эмуляциями) внутри PRU - это много лишнего кода и времени.
Код генератор N импульсов с M периодом и подгрузкой нового отрезка по мере выполнения - гораздо проще и гибче.

теоретически конечно так, а на практике нужно будет организовывать кэш в памяти ПРУ ( довольно маленькой!), ибо такт основного цикла в 1 мс не сильно подходит для бесшовной передачи новых блоков... а способ "забирать" подготовленные данные средствами ПРУ, по необходимости, из основной памяти пока не понятен

[Владимир Ситников]

Товарищи, а не кажется ли Вам, что подход к управлению движением в виде 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, конечно, можно, но прямо сейчас для меня это осложнит тестирование.

[Владимир Ситников]

подход к управлению движением

Интересный вопрос -- управление медленными выходами из PRU программы.
Например, выход "направление вращения" вполне можно делать медленным выходом и не "тратить" на него быстрый.
Но при этом, придётся управлять этим самым "выходом для направления" из обычного ПЛК цикла -- т.е. возможны косяки, что цикл ПЛК затянулся, и всё. Что PRU должен делать? Ждать отмашку от HOST'а, что "направление переключилось, можно двигать"?

Проще и менее хрупко смотрелось бы, если бы команды на медленный выход отдавал тот же PRU, и без ожиданий.

Если я правильно понимаю, то в случаях "проскальзываний" это пригодилось бы.
Т.е. мы подали на ШД команду "двигайся на 1000 импульсов". Он, такой, сделал 800, начинает тормозить, а ему говорят: "слушай, надо не 1000, а 850". Т.е. по факту, программе придётся затормозить, а потом отъехать назад. Тут было бы проще, если бы сам PRU код понимал и управлял "в какую сторону едем".

[Newcomer]

Товарищи, а не кажется ли Вам, что подход к управлению движением в виде 1 ФБ "сделай всё" в корне не верен?
ИМХО, правильнее было бы разделить задачу на:
1. Вычисление кривой движения (делает основной цикл ПЛК)
2. Деление кривой на N отрезков (опять же основной цикл)
3. Выдача импульсов по отрезкам силами PRU

Проводить сложные вычисления с плавающей точкой (или её эмуляциями) внутри PRU - это много лишнего кода и времени.
Код генератор N импульсов с M периодом и подгрузкой нового отрезка по мере выполнения - гораздо проще и гибче.

А Владимир Ситников все уже сделал, быстро и качественно. ;) Зачем в основной программе делать первые два пункта ума не приложу. Чем такое предлагать вы бы лучше оказали Владимиру Ситникову системную поддержку чтобы он мог двигаться дальше. Вот что от вас давно ждут.

[dima64]

ПЛК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Гц для ШД это неудобная частота и как правило проблему решают просто стартом с большей частоты.

[Newcomer]

Нее. Скорее всего, это решится добавлением параметра стартовой скорости.

По крайней мере, в теории все пишут, что 200Гц для ШД это неудобная частота и как правило проблему решают просто стартом с большей частоты.

Обратите внимание на фразу Компенсация резонанса. Все качественные драйвера это делают. Если задать большую стартовую скорость, то ШД может вообще не стартовать.

[dima64]

Ускорения ставил разные, результат один. Все это происходит в самом начале разгона и в конце торможения.

[Newcomer]

Ускорения ставил разные, результат один. Все это происходит в самом начале разгона и в конце торможения.

А заданное количество импульсов ШД правильно отрабатывает ? Запомните положение вала ШД, задайте такое количество импульсов чтобы вал сделал 100 оборотов (это 20 000 импульсов, если нет дробления шага) и посмотрите положение вала. Дробление шага пробовали делать ?

[dima64]

Без разгона и торможения отрабатывает правильно и 100 и 1000 об.
Владимир, что можете сказать по поводу: При заливке в ПЛК PRU0.prg перестают работать первые 4 входа (все время включены), при удалении PRU0.prg входа работают нормально.
26739

[Newcomer]

Без разгона и торможения отрабатывает правильно и 100 и 1000 об.

А частота максимальная при этом какая была ? 10 кГц задавали ?

[dima64]

Максимум 1100, потом срывается. Без дробления.

[Дмитрий Артюховский]

Без разгона и торможения отрабатывает правильно и 100 и 1000 об.
Владимир, что можете сказать по поводу: При заливке в ПЛК PRU0.prg перестают работать первые 4 входа (все время включены), при удалении PRU0.prg входа работают нормально.
26739

Так и должно быть. Заливаемая программа вытесняет программу по умолчанию. Если они нужны в основной программе - программа PRU должна их передавать туда.


Максимум 1100, потом срывается. Без дробления.

Без специально подготовленного ШД - 1100 Гц - приличный результат

[dima64]

У меня ПЛК110-32. У него 2 быстрых входа, 3 и 4 обычные входа. Но не работают первые 4 (ВСЕ время включены).

[BETEP]

.......... при подаче команды ENABLE ШД делает один шаг. ................. при подаче команды ENABLE ШД делает два шага.
Обычное явление, при подаче напруги в обмотки ротор встаёт в ближайшее "устойчивое" положение. Одна из причин почему во время позиционирования ENABLE никогда не снимают, драйвер должен уметь держать движок половинным током, чтобы нагрев уменьшить.

Судя по видео Ваш движок с драйвером в полном шаге на низкой скорости работать не может (масса ротора). Включите полушаг, пожалуй это самый оптимальный режим для движка.

И кстати да, желательно чтобы у рампы присутствовала стартовая и стоповая частота.

[Newcomer]

Максимум 1100, потом срывается. Без дробления.

Все правильно. Без разгона до больших частот ШД не разогнать. Надо В.Ситникову подумать о кривой разгона. Линейное ускорение при разгоне и торможении не дает хорошего результата. В ПЛК Delta не зря сделано нелинейное ускорение.

[Филоненко Владислав]

Всё равно входа через PRU. И да, они работать не будут, их обслуживает программа PRU. Тут или обычная программа или PRU0.prg

[Владимир Ситников]

Обычное явление, при подаче напруги в обмотки ротор встаёт в ближайшее "устойчивое" положение. Одна из причин почему во время позиционирования ENABLE никогда не снимают, драйвер должен уметь держать движок половинным током, чтобы нагрев уменьшить.
Ну, ещё в программе присутствовал фрагмент "IF quantity<=2...".
Вынесу случай quantity=0 отдельно.

[Филоненко Владислав]

Вышел патч.
Теперь compilator.exe правильно генерит программу для 1-го PRU.

[Newcomer]

Обычное явление, при подаче напруги в обмотки ротор встаёт в ближайшее "устойчивое" положение. Одна из причин почему во время позиционирования ENABLE никогда не снимают, драйвер должен уметь держать движок половинным током, чтобы нагрев уменьшить.

Это не тот ENABLE, который у драйвера ЩД. В ФБ ENABLE - это VAR_INPUT , который дает разрешение на начало формирования импульсов. У В.Ситникова тут глюк.

[BETEP]

Подобный движок от http://electroprivod.ru/ использовал для перемещения винтом маленького штампа (гидравлика).
полушаг, скорость максимально возможная, разон с торможением линейные (ступеньки по 4 mc), стартовая и стоповая частота не нулевые.
Был и режим от кнопок, когда медленно перемещался.

[dima64]

Да, я имел в виду ENABLE функционального блока.
Владимир можете добавить в PRU чтение входов?

[Владимир Ситников]

Пробуем pru_pulse_v5.zip (http://www.owen.ru/forum/showthread.php?t=22169&page=30&p=221928&viewfull=1#post221928)
PRU1 должна залиться, но управлять fast output'ом она не сможет. Надо ещё программу поправить.



Да, я имел в виду ENABLE функционального блока.
Владимир можете добавить в PRU чтение входов?

Да, чтение добавить можно, но тут вопрос: что именно читать, какая фильтрация, и импульсы какой минимальной длительности планируется ловить?

Если вопрос "как сделать так, чтобы "не быстрые" discrete inputs заработали в конфигураторе, то тут вопрос к Владиславу.
Если он расскажет (хотя бы мне лично) как из PRU программы передавать данные в КДС программу (я имею ввиду не pruAccessLib, а "передавать данные в plcconfiguration") -- сделаю.

[dima64]

Ну, в лучшем случае, как в конфигураторе. Что бы можно было задавать фильтрацию для конкретной задачи.
Я правильно понимаю, что если залиты PRU, то ни быстрые счетчики, ни быстрый энкодер уже работать не будет?

[Владимир Ситников]

Я правильно понимаю, что если залиты PRU, то ни быстрые счетчики, ни быстрый энкодер уже работать не будет?

И да и нет.

В PRU программе можно любую программу писать.
Хоть счётчик, хоть энкодер, хоть декодер UART, хоть что.

[dima64]

Я понял. Имел в виду в конфигураторе.

[Вольд]

Тему сильно почикали и перемещают туда-сюда. Что за странная возня ?

[Владимир Ситников]

Тему сильно почикали и перемещают туда-сюда. Что за странная возня ?
Важно ли это?

Важно то, что PRU1 не заводилось не из-за того, что "моя заводилка не концептуальна", а из-за того, что "beta-версия ОВЕН компилятора физически не поддерживала PRU1".

[dima64]

А чем v5 отличается от v4
Сейчас PRU1.prg не подхватывается . Или только подхват PRU1?
Завтра попробую.

[Филоненко Владислав]

Важно ли это?

Важно то, что PRU1 не заводилось не из-за того, что "моя заводилка не концептуальна", а из-за того, что "beta-версия ОВЕН компилятора физически не поддерживала PRU1".
Странно от добровольца-тестера слышать такие слова. Бета-тест для того и создан, чтобы были баги. Пока 1 штука :) Работайте интенсивнее :cool:

[rovki]

Добровольно -значит бесплатно :cool:
Тестер? А я думал разработчик ...:confused:

[Филоненко Владислав]

Добровольно -значит бесплатно :cool:
Тестер? А я думал разработчик ...:confused:

Вот Вы,rovki, тоже начинали у нас как тестер.
А теперь уважаемый разработчик макросов, и у нас появляетесь часто, и новинки получаете в первых рядах и т.п.

Если человек сам выразил желание потестить углублённо - зачем ему мешать.

[dima64]

Итак pru_pulse_v5.zip.
PRU1.prg подхватывается:

................................................
Retain init
Slave Retain loaded
EEPROM init
PRU0 user programm loaded
PRU1 user programm loaded

Но двигатель ШД не работает (генерации нет, при любом состоянии OUT_NUM: BYTE; (* 1, 2, 3 или 4 *).
При подаче команды ENABLE FB переходит в состояние STATE=2 (без разгона) и остается в этом режиме даже при снятии ENABLE.
Выход только перезагрузкой.
При удалении из ПЛК PRU1 функциональный блок начинает работать, как положено.
Исправлено поведение при quantity=0, 1 (т.е. выдаётся 0 и 1 импульс) все четко.
Вот так ведет себя ШД при частотах от 145 до 175 Гц: https://yadi.sk/i/KcUtVLhhvvBme

[rovki]

Вот Вы,rovki, тоже начинали у нас как тестер.
А теперь уважаемый разработчик макросов, и у нас появляетесь часто, и новинки получаете в первых рядах и т.п.

Если человек сам выразил желание потестить углублённо - зачем ему мешать.
Это вы так для себя считали ,а я себя так не ощущал -тестером. Я творил ,что нравится и заодно баги выявлял.. И Ситникова тестером не считаю ...

[Newcomer]

Итак pru_pulse_v5.zip.
PRU1.prg подхватывается:

Но двигатель ШД не работает (генерации нет, при любом состоянии OUT_NUM: BYTE; (* 1, 2, 3 или 4 *).
При подаче команды ENABLE FB переходит в состояние STATE=2 (без разгона) и остается в этом режиме даже при снятии ENABLE.
Выход только перезагрузкой.
При удалении из ПЛК PRU1 функциональный блок начинает работать, как положено.
Исправлено поведение при quantity=0, 1 (т.е. выдаётся 0 и 1 импульс) все четко.
Вот так ведет себя ШД при частотах от 145 до 175 Гц: https://yadi.sk/i/KcUtVLhhvvBme

Что-то я не пойму удалось ли разогнать ШД до высоких частот, например 10 кГц, без дробления шага.

[Newcomer]

Вот так ведет себя ШД при частотах от 145 до 175 Гц.

На низких частотах надо пробовать запускать без разгона или ставить высокое ускорение.

[dima64]

Нет, максимум 1100 Гц. Надо стартовать с не нулевой скорости.
Вот характеристика драйвера:
26758

[Newcomer]

В.Ситников, что скажите про невозможность разгона ШД до высокой частоты ?

[Newcomer]

Нет, максимум 1100 Гц. Надо стартовать с не нулевой скорости.
Вот характеристика драйвера:
26758

ШД с этим драйвером можно разогнать максимум до 2000 Гц. Вопрос к В.Ситникову частично снимается. Остается вопрос с разгоном.

[Newcomer]

Нет, максимум 1100 Гц. Надо стартовать с не нулевой скорости.
Вот характеристика драйвера:
26758

Драйвер каким напряжением питаете ?

[dima64]

Генерация идет нормально. Сегодня подключал сервопривод PRONET. Скорость задавал 200 кГц. Играл с разгоном/торможением - все работает. Заданное кол-во импульсов отрабатывает четко. Один нюанс: серво имеет 10000 имп/об., поэтому при 200 кГц должен вращаться со скоростью 1200 об/мин. На дисплее сервопривода высвечивается скорость 1590 об/мин.
Драйвер запитываю от 24. На графике драйвера кривые 12В и 48В перепутаны местами.

[Newcomer]

Генерация идет нормально. Сегодня подключал сервопривод PRONET. Скорость задавал 200 кГц. Играл с разгоном/торможением - все работает. Заданное кол-во импульсов отрабатывает четко. Один нюанс: серво имеет 10000 имп/об., поэтому при 200 кГц должен вращаться со скоростью 1200 об/мин. На дисплее сервопривода высвечивается скорость 1590 об/мин.
Драйвер запитываю от 24.

С сервоприводом проще, это очень качественная вещь. Там главное подать на вход Step нужное количество импульсов и все будет ОК. С ШД сложнее, его труднее разогнать до высоких частот. В случае с ШД надо менять частоту импульсов на входе Step драйвера по определенному закону.

[Newcomer]

Генерация идет нормально. Сегодня подключал сервопривод PRONET. Скорость задавал 200 кГц. Играл с разгоном/торможением - все работает. Заданное кол-во импульсов отрабатывает четко. Один нюанс: серво имеет 10000 имп/об., поэтому при 200 кГц должен вращаться со скоростью 1200 об/мин. На дисплее сервопривода высвечивается скорость 1590 об/мин.

Это интересно. Есть сомнения, что ФБ выдает на выходе действительно 200 кГц. Надо смотреть осциллографом, что на самом деле на быстром выходе ПЛК110.

[Newcomer]

Возможно, нам "счастье привалило", и PRU работает не на частоте 150MHz, а на частоте 200Mhz =)

Похоже что так. У dima64 скорость завышена на 32,5%, а 200 больше 150 на 33,3%.

[Newcomer]

Еще надо узнать у В.Филоненко какой генератор используется для тактирования PRU, кварцованный или нет. Если кварцованный, то ПЛК110М[02] можно смело использовать для управления сервоприводами.

[Newcomer]

Вниманию В.Ситникова.

Задал такой вопрос на сайте конторы, которая делает драйверы ШД: По какому закону должна меняться частота импульсов на входе Step драйвера, чтобы ШД разогнался до 1000 об/мин ?

Получил такой ответ: Обычно по линейному, но можно по обратноквадратичному - сначала быстрее, потом медленней.

[dima64]

6 версия не работает. Контроллер уходит в перезагрузку.

[Владимир Ситников]

Похоже что так. У dima64 скорость завышена на 32,5%, а 200 больше 150 на 33,3%.



http://www.epd-ee.eu/print.php?id=7756: They are clocked at half the frequency of the ARM core. The zero-stage pipeline on the instruction memory allows the PRU to execute all commands in a single cycle. So, if the ARM core is clocked at 456MHz, each PRU will run at 228MHz, which corresponds to a command cycle time of only

AM1808 бывает 375 MHz и 456 MHz

Т.е. у PRU частота либо 187.5 MHz либо 228 Mhz

1590.0/228*150==1046 <-- похоже на правду, но всё равно многовато
1590.0/187.5*150==1272

Если 1590 это верное значение, то, похоже, PRU работает на частоте 1590/1200*150=198.75 MHz -- какая-то странная частота.

Если частота PRU 228 MHz, то должно было отображаться 1000*228/150.0 = 1520 об/мин

[dima64]

7 так же не идет. перезагрузка.

[Дмитрий Артюховский]

Я понимаю, что в каждой программе могут быть ошибки.
Но постоянно говорить "в чём проблемы?", и при этом _заставлять_ пользоваться линкером, который для PRU1 ни разу не тестировали это, по меньшей мере, некрасиво. Это даже не ответ "у нас всё работает". И уж точно не ответ "вот такой пример работает".

ну, вы выкладываете людям код который даже не загружаете в контроллер! по причине - "лень провода колхозить" ))) так что строить какие либо планы с учетом такого специалиста по меньшей мере неосторожно )))

а так конечно пожелаю вам удачи в выполнении пожеланий пользователей чтобы
чтобы ШД разогнался до 1000 об/мин - это вааще в гранит!!!

[Newcomer]

а так конечно пожелаю вам удачи в выполнении пожеланий пользователей чтобы 1000 об/мин - это вааще в гранит!!!


Если вам не приходилось работать с такими ШД и драйверами к ним, то это не значит, что такие не существуют.

Мне вот очень скоро предстоит работать с такими.

[dima64]

По поводу частоты, что скажут представители OWEN.
Привод конечно китайский, но все таки.

[приборист]

Попробовал 7,8,9
Не работает PRU1 - ребут.
И не работает PRU0, STATE = 1.

[Филоненко Владислав]

Еще надо узнать у В.Филоненко какой генератор используется для тактирования PRU, кварцованный или нет. Если кварцованный, то ПЛК110М[02] можно смело использовать для управления сервоприводами.

Генератор тот же, что и для основного ядра процессора. Используйте смело.
Однако тов. Ситников мало уделяет внимания стабильности цикла управления в коде.Возможен сильный джиттер в зависимости от пути выполнения кода.
И записывать входа/опрашивать выхода лучше всегда в одном и том же месте программы - в начале, после срабатывания счётчика команд.
Это гарантирует стабильность скважности.

[Филоненко Владислав]

Частота PRU 150МГц.
Бета тест и был задуман для тестов. А не для обид от найденных ошибок. Как, нам дали сырой продукт!

[приборист]

Какие Ваши предложения?
Осваивать ASM?
И писать все самим?
Мне например сейчас нужно ШД, управление (EN\DIR) сделаю в основной логике ПЛК.

А Владимир поэтому и предлагает сделать все через черепаху, чтобы ему спалось лучше :)

[rovki]

FBD спасет Мир ;)

[dima64]

Для меня этот вопрос уже возникал. Как быть, если нужно что то изменить для конкретно моей задачи (абстрактно).
Дальше, при снятии ENABLE двигатель тормозит с заданным параметром, а мне кажется должен останавливаться немедленно.
Владислав, вам нужно прийти к консенсусу с Владимиром и делать общее дело. Озвучте тех. задание и работайте вместе.
А сейчас этого нет. Толи мы не понимаем друг друга, то ли еще что то. Дело то нужное.

[Newcomer]

При снятии ENABLE двигатель тормозит с заданным параметром, а мне кажется должен останавливаться немедленно..

Ну и какие проблемы ? Можно же задавать ускорение при торможении. Задайте максимально возможное ускорение торможения и будет вам счастье.

[dima64]

Я имел в виду при аварийном снятии сигнала. Когда дв. крутится и вдруг авария, стоп. (помимо других способов безопасности).

[Владимир Ситников]

А такой вопрос: кто-нибудь может с удалённым ПЛК подсобить? <-- вопрос решён, приборист дал доступ к ПЛК110М02

Ну, чтобы можно было программу позаливать и посмотреть на поведение.

[Atman]

А такой вопрос: кто-нибудь может с удалённым ПЛК подсобить?

Ну, чтобы можно было программу позаливать и посмотреть на поведение.
Владимир, могу к ПЛК-150 дать доступ, но пока в командировке, когда приеду , то могу дать возможность поработать с ПЛК.

[capzap]

Владимир, могу к ПЛК-150 дать доступ, но пока в командировке, когда приеду , то могу дать возможность поработать с ПЛК.

К сожалению, тема про конкретную модель плк

[Владимир Ситников]

С другой стороны: USB хватит для того, чтобы подключиться КСД'ом и залить PRU0.prg?

Или нужно RS232/Ethernet провод искать?

[приборист]

С другой стороны: USB хватит для того, чтобы подключиться КСД'ом и залить PRU0.prg?

Или нужно RS232/Ethernet провод искать?

Залить хватит, вылетает иногда.
Могу дать TV до ноута и ПЛК поставить (дома есть ПЛК)

В принципе могу через TV вообще круглосуточный доступ предоставить к ПЛК, но это теперь только в понедельник.

[Дмитрий Артюховский]

1. Для перезаливки модуля ПРУ нужен физический доступ к контроллеру - грубо говоря питание передергивать, ну или рычаг переключать.

2. Дополнительные фокусы возникнут при отладке фазировок сигналов - на драйвер нужно подавать сигналы в вполне определенной последовательности, иначе не будут точно отрабатываться скажем импульсы при смене знака - поэтому весьма рекомендуется осциллограф - двухканальный, желательно с памятью - кроме того он снимет кучу вопросов по частоте.

3. Неплохо бы разобраться пользователям что они называют ШД и что для него надо, и что такое сервопривод, и в чем там особенности. При похожести интерфейса (STEP/DIR) там идеологические отличия.

Ну и главное: то что делает Ситников - он делает для себя!! - он "продает" свою среду разработки, а не "пилит" вам модули на халяву! Эти модули вы не сможете модифицировать без его среды и понимания ее устройства, а он, при всех достоинствах, не знает устройства ПЛК, поэтому и эффективно поддержать его не сможет. Из того что я здесь вижу - его платформа - "малинка" (Raspberry) - вот там его подход вполне оправдан.

Овен, по моему мнению, не будет поддерживать эту штуку - потому что, как я уже писал, она противоречит концепции ПЛК в принципе - в ней не реализован стабильный цикл (и даже наоборот - время цикла спецом меняется в угоду алгоритму) и возможность параллельного, независимого исполнения нескольких модулей. Поднимался уже вопрос, а куда собственно делись быстрые входи и как их получить обратно... ПЛК110 - это все же не АРДУИНА и не универсальный компьютер.

[Вольд]

Овен, по моему мнению, не будет поддерживать эту штуку - потому что, как я уже писал, она противоречит концепции ПЛК в принципе - в ней не реализован стабильный цикл (и даже наоборот - время цикла спецом меняется в угоду алгоритму) и возможность параллельного, независимого исполнения нескольких модулей.

В связи с этим спорным заявлением возникли такие вопросы к В.Ситникову:
1) от чего в ФБ осуществляется синхронизация при формировании выходного сигнала;
2) нет ли джиттера частоты (фазовое дрожание);
3) стабильна ли частота на дискретном выходе ПЛК.

Для проверки всего этого нужен осциллограф. Может ли кто-то из форумчан это проверить ?

[Newcomer]

Спасение утопающих - дело рук самих утопающих.;) Надеяться на то, что специалисты фирмы "ОВЕН" в обозримом будущем сделают свой канонический ФБ для управления ШД не приходится. Надо общими усилиями форума решить эту задачу. Есть В.Ситников, который сделал этот самый ФБ. У В.Ситникова кроме ПЛК110[М02] больше ничего нет. Но нашлись уже два человека, у которых есть железо для стендовых испытаний. Есть ли еще заинтересованные лица, готовые подключиться к процессу. Я этим заняться не могу, так как в настоящее время не имею всего необходимого, но могу выложить схему простейшего стенда для проведения испытаний. ШД и драйвер ШД могут быть другими, это не суть важно. При проведении испытаний очень желательно иметь цифровой осциллограф или цифровой частотомер.

[Владимир Ситников]

В связи с этим спорным заявлением возникли такие вопросы к В.Ситникову:
1) от чего в ФБ осуществляется синхронизация при формировании выходного сигнала;
От тактовой частоты PRU.
TI заявляет, что все команды выполняются за 1 такт (работа с памятью дольше, но тоже, якобы, гарантирована длительность).
В процессоре есть регистр -- счётчик выполненных команд. По сути, он и отражает текущее время в виде "количества выполненных тактов".

Если этот регистр врёт, то, конечно, беда-печаль.

Логика моей PRU программы следующая:
1) Вычисляем "какая должна быть длина импульса" <-- это вычисление может занимать разное время, но оно всегда быстрее, чем нужная длина импульса
2) Ждём пока счётчик выполненных команд накрутится до нужного значения <-- в этом же ожидании происходит обмен host-pru-host
3) Обнуляем счётчик выполненных команд (он, собака, перестаёт работать секунд через 20-30 при достижении FFffFFff, поэтому приходится постоянно обнулять)
4) Пишем выход

В итоге, запись выходов происходит в ровно запланированное время.
Тов. Филоненко, конечно, пишет противоположное, но, полагаю, он либо не читал код моей программы (http://www.owen.ru/forum/showthread.php?t=22169&page=8&p=219907&viewfull=1#post219907), либо читал невнимательно.

Спецификация TI на длительность работы команд памяти немного мутная, поэтому возможны погрешности на 2-4 такта, но это всё ерунда (+-0.03 мкс), и эти погрешности плавать не будут. Да и сами команды работы с памятью редко используются -- в основном мы "сверяемся со счётчиком команд", а он, надеюсь, показывает правду.

И спецификация умалчивает что будет, если обнулить счётчик выполненных команд (учтёт ли он команду обнуления -- фиг знает). Там говорится, что перед обнулением его нужно выключать, но это муторно, и, судя по опытам, работает и без "отключения".



2) нет ли джиттера частоты (фазовое дрожание);
3) стабильна ли частота на дискретном выходе ПЛК.
Я показывал насколько стабильна частота импульсов на выходе: http://www.owen.ru/forum/showthread.php?t=22169&page=8&p=219960&viewfull=1#post219960

По программной части -- частота абсолютно стабильная и полностью предсказуемая.
Надо фронт каждые 200 тактов --- будет каждые 200 тактов.

Плавает ли аппаратная частота (например, вместо кварца неонка какая-нибудь) -- тут без понятия.


Про "неконцептуальность и запретность ОВЕНом" смены "цикла PRU по ходу работы" процитирую классику:

26.08.2016, 08:35: Цикл можно менять, в т.ч. и на ходу, для этого предполагается использовать семейство FB START, START_CONST и START_VAR

[capzap]

мне кажется Филоненко не противоположное Вам говорил, а советовал запись входов сделать в начале программы, а всю обработку делать после для следующего такта, так было бы больше гарантий стабильности, не получается верить что у со процессора нет более высоких прерываний, которые внесут незначительную задержку перед записью

[Владимир Ситников]

мне кажется Филоненко не противоположное Вам говорил, а советовал запись входов сделать в начале программы, а всю обработку делать после для следующего такта, так было бы больше гарантий стабильности, не получается верить что у со процессора нет более высоких прерываний, которые внесут незначительную задержку перед записью

Креститься надо когда кажется. Я гарантирую задержку с точностью до такта PRU. Куда уж точнее? Какая такая волшебная технология сделает "большую гарантию стабильности"?

"не получается верить". Ещё раз: не хотите учиться -- молчите и слушайте умных людей.
Я спецификацию TI AM1808 PRU читал, и знаю, что прерывания в PRU приходят установкой "флага в спец регистре". Никакого насильного перехода на обработчик прерывания там нет. Если PRUграмма не следит за спецфлагом, то она запросто может игнорировать "прерывание".

Вот что писал Владислав:

Генератор тот же, что и для основного ядра процессора. Используйте смело.
Однако тов. Ситников мало уделяет внимания стабильности цикла управления в коде.Возможен сильный джиттер в зависимости от пути выполнения кода.

Владислав пишет, что "возможен сильные джиттер", а я утверждаю, что программа задержку выдерживает ровно, и никакого дрожания там не будет.

Владислав не прав.
Мои утверждения подкрепляются эмулятором PRU. Найдётся осциллограф -- измерим и осциллографом.

[Newcomer]

Вот так ведет себя ШД при частотах от 145 до 175 Гц: https://yadi.sk/i/KcUtVLhhvvBme

С разгоном ШД в ФБ проблемы. Постоянное ускорение вероятно не катит.


Генерация идет нормально. Сегодня подключал сервопривод PRONET. Скорость задавал 200 кГц. Играл с разгоном/торможением - все работает. Заданное кол-во импульсов отрабатывает четко. Один нюанс: серво имеет 10000 имп/об., поэтому при 200 кГц должен вращаться со скоростью 1200 об/мин. На дисплее сервопривода высвечивается скорость 1590 об/мин.

Я подозреваю, что частота импульсов в ФБ генерируется не верно. Может синхронизироваться не от счетчика команд, а по прерываниям таймера. Зарядить таймер на 1мкс и формировать и отсчитывать периоды. Тогда все будет железно.

Что касается возможного джиттера, то он не страшен. ШД небольшое колебание фазы импульсов просто не заметит.

Может сделать два ФБ, один для ШД, другой для сервопривода. Дело в том, что ШД более капризная вещь, его труднее разогнать.

[Владимир Ситников]

Разгони свой ПЛК110 М02 бесплатно и без S M S.

10-ая версия pru_stepper_v10.zip (http://www.owen.ru/forum/showthread.php?t=22169&page=29&p=221928&highlight=pru_stepper#post221928)
Теперь-то уж наверняка должны заработать 2 ШД: выходы осциллографом не смотрел, но в КДС блоки работают как надо.

* Помним, что одновременно могут работать следующие комбинации выходов: 1 и 3, 1 и 4, 2 и 3, 2 и 4.
* За частоту PRU взята 200MHz (совпадает с тестами dima64 (http://www.owen.ru/forum/showthread.php?t=22169&page=34&p=222251&viewfull=1#post222251))
* Убран выходной параметр "READY". Вместо него стоит проверять STATE=STOP_STEPPER.
* Добавлен выходной параметр "CURRENT_SPEED : REAL"
* Изменён тип параметра "STATE" на enum PRU_STEPPER_STATE


Спасибо прибористу за ПЛК -- нашёл причину неработоспособности прошлых версий программы.
Причин несколько:
1) Похоже, PRU0.prg/PRU1.prg не поддерживают программы более 2048 байт. Это большая печаль, т.к. в спецификации TI написано, что процессор поддерживает программы до 4096 байт. Как я добавил в программу обсчёт минимальной скорости, то программа стала чуть больше 2048 и, соответственно, работать не работала.

Можно смеяться, можно плакать, но если в *.prg формате действительно ограничение на 2048 байт, то это ещё одна грабля, про которую Владислав ничего не сказал.
Блин. Ну был бы описан формат *.prg -- было бы наверняка понятно, что "больше 2048 в него не влезет".
А так получается, я методом тыка исследую и догадываюсь, что всё дело в размере программы.

Я немного упростил программу, добавил небольшую оптимизацию в компилятор, и программа стала занимать 1964 байта.

2) Как оказалось, в PRU1 регистр счётчика выполненных команд находится по адресу 0x780C, а не по адресу 0x7800.
Я про эту догадку уже говорил:


И, да, если покажете пример хоть какой-нибудь программы для PRU1, то скажу большое спасибо. Я пробовал читать "регистр счётчика выполненных команд по адресу 0x7800+0xC", но почему-то не работает. У PRU0 счётчик команд находится по адресу 0x7000 + 0xC, а у PRU1 должен (вроде как) быть в 0x7800+0xC.

но потом Владислав уверил меня, что в документации TI ошибка, а регистр у каждого PRU находится по адресу 0x7800

Как оказалось, документация TI говорит правду, и регистр находится по своему адресу у каждого PRU.
Т.е. для PRU0 и PRU1 должны быть разные программы.



После того, как разобрались с проблемами, давайте разгоним наш ПЛК.
Осциллографом до прибориста я не дотянусь, но я сделал замер "средней скорости генерации импульсов" через TIME().
PRU программа возвращает количество сделанных импульсов, а мы делим на "время генерации" и получаем фактическую частоту.
Вот демонстрация: http://recordit.co/XLaOe3LOYE (то же самое в виде анимированного gif: http://g.recordit.co/XLaOe3LOYE.gif )

По факту, частота немного отличается от заданной. Например, вместо 500'000 показывает где-то 495'126 Гц. Но тут, возможно у меня ошибка. Например я могу неправильно учитывать то, сколько тактов работают команды с памятью. Ещё, возможно, задержки в самом TIME() или чём-то таком.

За частоту PRU я выбрал 200МГц. Надо всё-таки перепроверить это хозяйство осциллографом.

По факту, ПЛК разогнался до 2'200'000 Гц, что, на мой взгляд, хорошее достижение, с учётом того, что ОВЕН пишет 100кГц.
Сколько из этих 2МГц смогут передаться через быстрые выходы, конечно, вопрос открытый.

[Newcomer]

За частоту PRU я выбрал 200МГц. Надо всё-таки перепроверить это хозяйство осциллографом.

Но В.Филоненко заявил, что тактовая частота PRU 150 мГц.

Чтобы окончательно разобраться в этой непонятной ситуации нужен цифровой осциллограф или цифровой частотомер, иначе получается гадание на кофейной гуще.

А вообще позиция программистов фирмы "ОВЕН" просто удивляет.

[Newcomer]

Давайте всё-таки попросим товарища протестировать в режиме "min_speed=500" ?
Я когда теорию читал, то много где написано, что ШД лучше стартовать со скорости большей чем 200, т.к. на ней резонанс.

У разных ШД резонанс может наступить на своей частоте. Вы предлагаете стартовать на частоте выше резонансной. А что если в конкретном случае потребуется работать на частоте ниже резонансной ?

[Newcomer]

Вопрос о том правильно ли формируется на выходе ФБ заданная частота остается открытым. То ли ошибка в ФБ, то ли PRU тактируется не той частотой что заявлена. В этой связи нужны тестировщики, у которых есть ПЛК110[М02] + цифровой осциллограф или цифровой частотомер. Задача простая: надо "залить" в ПЛК ФБ, разработанный В.Ситниковым, задавать разные частоты и мерить частоту сигнала на быстром выходе ПЛК.

[Newcomer]

Владимир, у вас описание (РЭ) всего того, что вы сделали для программирования PRU есть ?

[Владимир Ситников]

Посмотрел как ведёт себя ПЛК при обращении с регистром "счётчика команд" -- врагу не пожелаешь.
В точности воспроизвести в эмуляторе пока не смог, но приближаюсь.

Доработанный эмулятор стал показывать, что при уставке 500 кГц на выходе 495050 (т.е. похоже на то, что наблюдалось на реальном ПЛК -- там было 495126).
Поправил программу (http://www.owen.ru/forum/showthread.php?t=22169&page=29&p=221928#post221928) -- теперь частота уж совсем хорошая должна быть.

Кстати, по поводу генерации частоты: сейчас длина каждого импульса одинаковая. Т.е. на высоких частотах (напр. 200кГц) длина периода это где-то 1000 тактов. 1001 такт это уже 199800Гц. Возможно, на больших частотах стоит какого-нибудь брезенхема прикрутить, чтобы длины тактов немного варьировались, а в среднем получалось нужное значение.

[capzap]

В точности воспроизвести в эмуляторе пока не смог, но приближаюсь.
а зачем свой, у TI же есть эмуляторы и среда CCS?

[Вольд]

а зачем свой, у TI же есть эмуляторы и среда CCS?

CCS стоит немалых денег.

[dima64]

pru_stepper_v12.zip
Работают два привода, на разных каналах со своими частотами.
Смотри фото по частотам: 26801,26802, 26803, 26804.
Осциллограф С1-118А (какой есть).
При QUANTITY отличном от 0 и MAX_SPEAD=0, при подаче команды ENABLE выдается один импульс, см. 26805.
Количество выдаваемых импульсов плавает и зависит от частоты и от заданного количества импульсов:
• MAX_SPEAD = 148500 Гц ± 3…30 имп.
• MAX_SPEAD > 148500 Гц - 3…300 имп.
• MAX_SPEAD < 148500 Гц + 3…30 имп.
Хотя PULSES_GENERATED= заданное значение.

[dima64]

Это показания с дисплея сервопривода, да и визуально вал двигателя останавливается в разных местах.

[dima64]

ACC 0 0 0
DEC 0 0 0
MIN_S 0 0 0
MAX_S 200000 100000 10000
QUANTITY 300000 300000 30000
ФАКТ QUANTITY 297685 300044 30000
ФАКТ QUANTITY 297434 300045 30010
ФАКТ QUANTITY 297488 300040 30012
Насколько точно можно судить по картинке?.....

[Newcomer]

ACC 0 0 0
DEC 0 0 0
MIN_S 0 0 0
MAX_S 200000 100000 10000
QUANTITY 300000 300000 30000
ФАКТ QUANTITY 297685 300044 30000
ФАКТ QUANTITY 297434 300045 30010
ФАКТ QUANTITY 297488 300040 30012
Насколько точно можно судить по картинке?.....

Мерить частоту аналоговым осциллографом бесполезно, точность будет +/- три лаптя.

[dima64]

Померял частоту цифровой (китайской) Ц-шкой.
задано---- Ц-ка
1000Гц---999,7 Гц
10кГц----9,997 кГц
100кГц---99,97кГц
200кГц---199,9кГц

[Newcomer]

Померял частоту цифровой (китайской) Ц-шкой.
задано---- Ц-ка
1000Гц---999,7 Гц
10кГц----9,997 кГц
100кГц---99,97кГц
200кГц---199,9кГц

А твой тестер число импульсов посчитать не может ?

[dima64]

Нет, этого нет.

[Newcomer]

Померял частоту цифровой (китайской) Ц-шкой.
задано---- Ц-ка
1000Гц---999,7 Гц
10кГц----9,997 кГц
100кГц---99,97кГц
200кГц---199,9кГц

Относительная погрешность во всех случаях - 0,03 %

Хороший результат.

[rovki]

Относительная погрешность во всех случаях - 0,03 %

Хороший результат.
На метре 0,3мм многовато хоть для станка ,хоть для принтера ...

[dima64]

У цешки погрешность 1,5%.
А сколько накопленной ошибки будет???

[Newcomer]

Нет, этого нет.

Тогда надо воспользоваться простым методом. Сделай из проволоки, можно взять канцелярскую скрепку, стрелку и жестко закрепи ее на валу ШД. Сделай простенький циферблат из картона с одной меткой и укрепи его не корпусе ШД. Установи стрелку напротив метки на циферблате. Задай в ФБ побольше импульсов чтобы вал сделал полное количество оборотов. Например задай 20 000 импульсов. Шаг не дроби. Запусти программу и посмотри где остановилась стрелка.

[rovki]

Относительная погрешность во всех случаях - 0,03 %

Хороший результат.
На метре 0,3мм многовато хоть для станка ,хоть для принтера ...и это без реальной динамической нагрузки .У меня на планшетном принтере на 2метрах не более 10имп прыгает при 200000 на входе под нагрузкой ,а если ШД без нагрузки ,то может один и то наврядли ..

[Вольд]

На метре 0,3мм многовато хоть для станка ,хоть для принтера ...и это без реальной динамической нагрузки .У меня на планшетном принтере на 2метрах не более 10имп прыгает при 200000 на входе под нагрузкой ,а если ШД без нагрузки ,то может один и то наврядли ..

Для ШД главное чтобы ФБ сформировал заданное количество импульсов. На какой частоте будет сформировано это количество не принципиально. Бороться с моментом на валу ШД - это не задача ФБ, а задача драйвера ШД.

Еще немного, еще чуть-чуть и В.Ситников будет принимать поздравления. ;)

[rovki]

Тогда о каких потерях импульсов вообще речь?

[Вольд]

Тогда о каких потерях импульсов вообще речь?

ФБ из-за ошибки в коде может неправильно отсчитывать заданное количество импульсов, но это поправимо.

ШД может делать пропуск импульсов при разгоне и торможении. Чтобы этого не было надо делать разгон и торможения ШД по определенной траектории. Сформировать правильную траекторию достаточно сложно.

[dima64]

Похоже глючит серво. Провел эксперимент. Делал по 5 шагов для ШД и СЕРВО (ШАГ: MIN_SPEED:=200, MAX_SPEED:=1000, ACCEL_RAMP:=DECEL_RAMP:=0, QUANTITY:=20000).
ШД приехал метка в метку. Серво на каждом шаге прибавлял 8-10 имп.

[Newcomer]

Похоже глючит серво. Провел эксперимент. Делал по 5 шагов для ШД и СЕРВО (ШАГ: MIN_SPEED:=200, MAX_SPEED:=1000, ACCEL_RAMP:=DECEL_RAMP:=0, QUANTITY:=20000).
ШД приехал метка в метку. Серво на каждом шаге прибавлял 8-10 имп.

Серво не бось китайский ? ;) А вот ПЛК110 и ФБ к нему - Made in Russia.

Поиграй, пожалуйста, с частотой, разгоном и торможением. Посмотри что твориться с ШД.

[dima64]

А чей же еще. У сервы есть настройка:
Pn006.3: настройка фильтра для имп. сигнала типа откр. коллектор при подаче сигнала на дифференциальный вход сервопривод принимает имп. сигнал с частотой:
[0] <=700 кГц при Pn840.0=3/4/5
[1] <=200 кГц при Pn840.0=3/4/5
[2] <=60 кГц при Pn840.0=3/4/5
У меня стояла [1], серво принимал сигнал до 200 кГц с враньем.
Поставил [2] стал отрабатывать импульсы, сколько задано, но выше 70 кГц не воспринимает.
Хотя по CANOpen нормально работает.

[dima64]

Серво не бось китайский ? ;) А вот ПЛК110 и ФБ к нему - Made in Russia.

Поиграй, пожалуйста, с частотой, разгоном и торможением. Посмотри что твориться с ШД.

Что именно посмотреть?

[Newcomer]

А чей же еще. У сервы есть настройка:
Pn006.3: настройка фильтра для имп. сигнала типа откр. коллектор при подаче сигнала на дифференциальный вход сервопривод принимает имп. сигнал с частотой:
[0] <=700 кГц при Pn840.0=3/4/5
[1] <=200 кГц при Pn840.0=3/4/5
[2] <=60 кГц при Pn840.0=3/4/5
У меня стояла [1], серво принимал сигнал до 200 кГц с враньем.
Поставил [2] стал отрабатывать импульсы, сколько задано, но выше 70 кГц не воспринимает.

Задай в ФБ для серво большое полное количество оборотов и посмотри результат при разных заданных частотах и ускорениях.

[Newcomer]

Что именно посмотреть?

Как вал ШД поворачивается. Правильно ли отрабатывает целое число оборотов.

[Newcomer]

Если сервоприводом управлять через интерфейс STEP/DIR и в качестве датчика обратной связи использовать энкодер, то главное как и для ШД сформировать точное количество импульсов. Тогда вал сервомотора повернется на заданный угол с погрешностью, прописанной в паспорте на сервопривод. Погрешность 0,03% в формировании заданной частоты никакой роли в точности позиционирования не играет. От заданной частоты зависит только время поворота вала двигателя на заданный угол.

Если ФБ, разработанный Владимиром Ситниковым правильно отсчитывает заданное количество импульсов (плюс куча всяких прибамбасов), то задача управления ШД и сервомотором в ПЛК110[М02] решена и я первым его с этим поздравляю. ;)

[dima64]

QUANTITY:=2000000
MAX_SPEED:=1000 Гц (2000 оборотов, 200имп/об) ШД.
MAX_SPEED:=60000 Гц (200 оборотов, 10000имп/об) СЕРВО.
Оба привода отработали четко.
На сегодня все, рабочий день уже 2 часа, как закончился. До завтра.

[Владимир Ситников]

Если ФБ, разработанный Владимиром Ситниковым правильно отсчитывает заданное количество импульсов (плюс куча всяких прибамбасов), то задача управления ШД и сервомотором в ПЛК110[М02] решена и я первым его с этим поздравляю. ;)

Спасибо, конечно, но я ещё попробую добавить параметр "скважность".
Сейчас оба импульса 0 и 1 выдаются одинаковой длительности, а, возможно, стоит делать 0 длиннее или 1 длиннее.

Возможно, это решит проблему "неработоспособности частот выше 70кГц".
Если не решит, то будет план Б: эту же самую программу можно будет использовать как ШИМ генератор на быстрых выходах.


PS. Получается, что частота PRU это всё-таки 200МГц

[dima64]

Я думаю 0 длиннее. Кстати, по поводу слова "скважность" на меня тут наезжали, правильно говорить заполнение. Ну это лирика. От частоты зависит только скорость. Но если ПЛК выдаёт 1000 ими. (условно), а серво принимает 995 или 1010, то тут виноват серво. Форма импульсов видна на фото, и видно там собака порылась.

[Вольд]

Спасибо, конечно, но я ещё попробую добавить параметр "скважность".
Сейчас оба импульса 0 и 1 выдаются одинаковой длительности, а, возможно, стоит делать 0 длиннее или 1 длиннее.

Возможно, это решит проблему "неработоспособности частот выше 70кГц".
Если не решит, то будет план Б: эту же самую программу можно будет использовать как ШИМ генератор на быстрых выходах.


PS. Получается, что частота PRU это всё-таки 200МГц

Менять скважность импульсов по моему бесполезно.

[Newcomer]

QUANTITY:=2000000
MAX_SPEED:=1000 Гц (2000 оборотов, 200имп/об) ШД.
MAX_SPEED:=60000 Гц (200 оборотов, 10000имп/об) СЕРВО.
Оба привода отработали четко.

А время разгона и торможения какие были. Если эти времена были нулевые, то это не дело.

[dima64]

По серво: Нагрузил выход ПЛК резистором 1 кОм, форма импульсов улучшилась радикально. Стало возможным крутить серво с частотой 500 кГц (3000 об/мин) и четкой отработкой заданного количества импульсов.

[Владимир Ситников]

По серво: Нагрузил выход ПЛК резистором 1 кОм, форма импульсов улучшилась радикально. Стало возможным крутить серво с частотой 500 кГц (3000 об/мин) и четкой отработкой заданного количества импульсов.

А для ШД "ненулевая начальная скорость" помогла?

[dima64]

По ШД: С нулевым разгоном ШД крутится на 1400 Гц. С ACC=DEC=30-500 ШД раскручивается до 1600Гц, далее срывается.
Далее такой момент: ACC, DEC, MIN_SPEAD не нулевые. Подаем команду ENABLE, двигатель начинает вращение. Снимаем команду ENABLE двигатель начинает торможение.
Теперь, если в момент приближения скорости к MIN_SPEAD снова включить ENABLE, то двигатель будет крутиться со скоростью MIN_SPEAD. (Пока не наберет заданное количество импульсов или до перезагрузки, если бесконечное движение) Команда ENABLE уже ни на что не влияет.
MIN_SPEAD помогла. поставил 300Гц. При 200Гц при старте слышен резонанс и есть пропуск шагов.

[Newcomer]

По серво: Нагрузил выход ПЛК резистором 1 кОм, форма импульсов улучшилась радикально.

А раньше как было ?

Я схему подключения для ШД в посте #358 приводил. Для твоего ProNet подключение надо делать аналогично.

Кстати, как ты драйвер ШД к ПЛК110 подключил ?

[dima64]

Так же, как и ты. Только без резисторов. Возможно управление 24В.
На серво подтянул +24 к DO.

[Newcomer]

А для ШД "ненулевая начальная скорость" помогла?

А какая она ненулевая начальная скорость ? А с нулевой начальной скоростью есть возможность работать ?

[Владимир Ситников]

Снимаем команду ENABLE двигатель начинает торможение.
Теперь, если в момент приближения скорости к MIN_SPEED снова включить ENABLE, то двигатель будет крутиться со скоростью MIN_SPEED. (Пока не наберет заданное количество импульсов или до перезагрузки, если бесконечное движение) Команда ENABLE уже ни на что не влияет.

А вообще режим "сбавить скорость и продолжить на минимальной" нужен?
В конкретном, случае, конечно, ошибка (не предусмотрен вариант моргания enable").

[Newcomer]

Так же, как и ты. Только без резисторов.

Как это без резисторов ? Это грубая ошибка. А чем входная цепь драйвера ШД питаться будет ? Надо сделать как у меня на картинке в посте #358.

[Владимир Ситников]

А какая она ненулевая начальная скорость ? А с нулевой начальной скоростью есть возможность работать ?

Понятия "нулевая начальная скорость" не существует. Равно как и "нулевая начальная частота".
ШД двигается импульсами.

Ну невозможно подавать импульсы с нулевой частотой. Хоть тресни, но с нулевой частотой невозможно.

Вот вопрос: какая скорость в момент подачи первого импульса?

С технической точки зрения, интервал между первыми фронтами (первым и вторым) импульсов в случае 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Гц

[Newcomer]

Посмотрел ФБ PRU_STEPPER. Не понял почему PULSES_GENERATED объявлен как DWORD.

[Newcomer]

Понятия "нулевая начальная скорость" не существует.

Значит не нулевая начальная частота. Зачем тогда в ФБ введены обозначения MIN_SPEED и MAX_SPEED ? Разьве SPEED это не скорость ?

[Владимир Ситников]

Посмотрел ФБ PRU_STEPPER. Не понял почему PULSES_GENERATED объявлен как DWORD.

QUANTITY : DWORD;
PULSES_GENERATED: DWORD

Л- логика, не?

Какого типа ещё может быть PULSES_GENERATED?

[Newcomer]

QUANTITY : DWORD;
PULSES_GENERATED: DWORD

Л- логика, не?

Какого типа ещё может быть PULSES_GENERATED?

А что такое PULSES_GENERATED ? Где то, что подается на быстрый дискретный выход ПЛК ?

[Владимир Ситников]

Значит не нулевая начальная частота. Зачем тогда в ФБ введены обозначения MIN_SPEED и MAX_SPEED ? Разьве SPEED это не скорость ?

Как зачем?
Для плавного запуска/останова и для избегания резонанса ШД.

Разумеется, физически невозможно выдрежать min_speed=0. Хоть ты тресни, но генерировать импульсы с частотой 0 Гц невозможно.
Тем не менее, ШД подаёт импульсы так, что фактический закон вращения вала ШД становится близким к "идеальному равноускоренному движению из 0 частоты".

Посмотрите на график разгона от 0 до 5кГц (http://www.owen.ru/forum/showthread.php?t=22169&page=16&p=221401&viewfull=1#post221401) (1-ая картинка)
Там видно, что в начале скорость меняется ступеньками. Ступеньками т.к. большие интервалы между импульсами. Т.е. каждая ступенька это отдельный импульс.

[Newcomer]

Переименуйте MIN_SPEED и MAX_SPEED в MIN_FREQ и MAX_FREQ чтобы не сбивать людей с толку.

[Владимир Ситников]

А что такое PULSES_GENERATED ?
PULSES_GENERATED это количество фактически сгенерированных импульсов.


Где то, что подается на быстрый дискретный выход ПЛК ?
Как где?
Внутри программы. Если вы не поняли, то у меня "самодостаточная программа". Т.е. заливаем PRU0.prg/PRU1.prg и всё. Можно управлять ШД.
Номер выхода задаётся через OUT_NUM: BYTE; (* 1, 2, 3, or 4 *)

Какой смысл делать выходной параметр "OUT", если вы его всё равно ни к чему подключить не сможете?
Не в основном же цикле собрались переключать быстрые выходы?

И, да, ОВЕН не разрешает создавать *.prg файлы из hardella, а адаптировать ШД программу "под ОВЕНовский beta-формат PRU ФБ" я смысла не вижу.

С одной стороны, просто смысла нет. Ну кто реально будет через КДС и bat'ники создавать программы?! Есть желающие? Поднимайте руки! Только помните, что для сложения двух переменных нужен один блок, а для сложения переменной и константы -- другой.
И, с другой стороны, моя ШД программа требует довольно много регистров и это будет тяжело подружить с "ОВЕН beta компилятором", т.к. ОВЕНовский вариант идёт совсем в противоположном направлении: у меня регистры активно переиспользуются по ходу программы, а ОВЕН вариант предполагает, что даже после простого блока PRU_ADD регистры переиспользовать нельзя. Пара ОВЕНовских блоков, и всё, закончились регистры.

Не сказать, что мой блок идеально работает с регистрами, но мой компилятор сам догадывается какие регистры уже не нужны, а какие ещё нужны.

[dima64]

[QUOTE=Newcomer;222645]Как это без резисторов ? Это грубая ошибка. А чем входная цепь драйвера ШД питаться будет ?QUOTE]
26824

[Newcomer]

Все понятно. Вопросов нет. Пока.

[dima64]

А вообще режим "сбавить скорость и продолжить на минимальной" нужен?
В конкретном, случае, конечно, ошибка (не предусмотрен вариант моргания enable").
Я на этот глюк случайно попал. Было бы хорошо скорость на лету менять.

[dima64]

Да. А для серво резистор включил между +24 и выходом DO.

[Дмитрий Артюховский]

а ОВЕН вариант предполагает, что даже после простого блока PRU_ADD регистры переиспользовать нельзя. Пара ОВЕНовских блоков, и всё, закончились регистры.

Это не правда. Транслятор с фбд вполне себе разбирается с высвобождением и переиспользованием регистров.

[dima64]

PULSES_GENERATED это количество фактически сгенерированных импульсов.


Как где?
Внутри программы. Если вы не поняли, то у меня "самодостаточная программа". Т.е. заливаем PRU0.prg/PRU1.prg и всё. Можно управлять ШД.
Номер выхода задаётся через OUT_NUM: BYTE; (* 1, 2, 3, or 4 *)

Какой смысл делать выходной параметр "OUT", если вы его всё равно ни к чему подключить не сможете?
Не в основном же цикле собрались переключать быстрые выходы?

И, да, ОВЕН не разрешает создавать *.prg файлы из hardella, а адаптировать ШД программу "под ОВЕНовский beta-формат PRU ФБ" я смысла не вижу.

С одной стороны, просто смысла нет. Ну кто реально будет через КДС и bat'ники создавать программы?! Есть желающие? Поднимайте руки! Только помните, что для сложения двух переменных нужен один блок, а для сложения переменной и константы -- другой.
И, с другой стороны, моя ШД программа требует довольно много регистров и это будет тяжело подружить с "ОВЕН beta компилятором", т.к. ОВЕНовский вариант идёт совсем в противоположном направлении: у меня регистры активно переиспользуются по ходу программы, а ОВЕН вариант предполагает, что даже после простого блока PRU_ADD регистры переиспользовать нельзя. Пара ОВЕНовских блоков, и всё, закончились регистры.

Не сказать, что мой блок идеально работает с регистрами, но мой компилятор сам догадывается какие регистры уже не нужны, а какие ещё нужны.

Да, но при таком подходе мы теряем 4 входа и 2 или 1 (без PRU1) выхода. А вариантов задач может быть миллион. На каждую задачу придется свои PRU делать.

[Владимир Ситников]

Это не правда. Транслятор с фбд вполне себе разбирается с высвобождением и переиспользованием регистров.

Проверяли? Если честно, я не проверял, а лишь "как обычно", поверил Владиславу на слово:

Концепция с принудительным хранением результатов работы каждого ФБ в ОЗУ или регистровой памяти (этого вообще в компиляторе с ST нет) лишена проблем с организацией и предсказуемостью обратных связей и циклов. И при этом добавление ещё одного ФБ в программу в любом месте не нарушает работу остальных ФБ. Чего нельзя сказать о монолитном коде.

Как ещё можно понять слова "принудительным хранением результатов работы каждого ФБ в ОЗУ или регистровой памяти"?

[dima64]

Не пойму как у тебя серво без резисторов работал.

А вход у серво какой использовал PPI или PULS+ ? смотри картинку:
26828

[dima64]

все верно. см.26831

[dima64]

Да никакой там ток не течет, если транзистор закрыт. Резистор является нагрузкой для ПЛК и включен он параллельно оптрону. А вот форма импульсов улучшилась кардинально. 2кОм можно поставить, не спорю. Хотя и при 1 нагрузка на выход ПЛК 25 мА. (допустимая 400 мА).

[dima64]

конкретно что Вы имеете ввиду, перестать управляться должны только быстрые входа/выхода, их захватила конкретная программа ПРУ, а простые у Вас тоже что ли ни на что не реагируют? Не заливайти ни чего в ПРУ и быстрые входа/выхода останутся в Вашем распоряжении
Перестают управляться 2 быстрых (ПЛК-110.32) и первые 2 простых входов. 26835
Не заливать, конечно можно, но и генерировать нечем будет. Нафига тогда эти PRU предложили?

[Newcomer]

Перестают управляться 2 быстрых (ПЛК-110.32) и первые 2 простых входов. 26835
Не заливать, конечно можно, но и генерировать нечем будет. Нафига тогда эти 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 плохой", а к тому, что это моя аргументация почему я не могу просто взять и оформить свою ШД программу "по правилам ОВЕН". Тут не только моё субъективное "не хочу тратить время", но и вполне конкретная техническая проблема.

[dima64]

Откуда тут земля нарисовалась? Посмотри картинку PRONET1.

[Newcomer]

Откуда тут земля нарисовалась? Посмотри картинку PRONET1.

Я ошибся. при закрытом транзисторе ток через светодиод вообще не течет.

[Владимир Ситников]

как ему вернуть управление быстрыми входами/выходами в конфигуратор

На этот вопрос (можно ли выводить результаты PRU программы в "plc configuration") тов. Филоненко говорит решительное нет. Ну, что, якобы, адреса памяти КДС назначает произвольно, что это в концепцию ПЛК110 не укладывается и т.п.

С моей точки зрения, звучит, конечно, неубедительно. Свои fast encoder/fast counter программы в ОВЕН как-то сделали и в конфигуратор сумели вывести? Значит и для PRU программ такая возможность может быть. Да, возможно, это потребует доработку прошивки, но fast encoder же как-то сделали модулем в plc configuration?

Тем не менее, над конкретно этим вопросом предлагаю не заострять внимание, а воспринимать его как "данность свыше".

Обмен только через pruaccesslib.lib? Ну, ок.

Конечно, и в части "обмена host-pru" можно сделать более удобные механизмы, но нет никакого смысла тратить время и силы на обсуждение механизмов обмена данными и plc configuration, если ОВЕН молчит про саму возможность составлять PRU программы.

[capzap]

нет,я не про это, протестил конечный пользователь работу пру и перешел к повседневным делам. как ему вернуть контроль, если залитая программа в пру до сих пор крутится, как от нее избавиться?

[Владимир Ситников]

нет,я не про это, протестил конечный пользователь работу пру и перешел к повседневным делам. как ему вернуть контроль, если залитая программа в пру до сих пор крутится, как от нее избавиться?

Отступать нельзя -- позади Москва.

Можно залить пустой файл -- тогда всё вренётся к обычному режиму.

[capzap]

Вы так пробовали? Судя по скрину заблокированы и два обычных входа, в Вашем коде вряд ли они используются и тем не менее заняты, чем это будет отличаться от пустого файла?

[Владимир Ситников]

Вы так пробовали? Судя по скрину заблокированы и два обычных входа, в Вашем коде вряд ли они используются и тем не менее заняты, чем это будет отличаться от пустого файла?

Тем, что в "конфигуратор" быстрые входы попадают через "программу PRU по умолчанию".

Если PRU*.prg не залиты, то входы-выходы работают как обычно.
Если PRU*.prg залиты, то входы-выходы работают согласно залитой программе. В текущей моей "программе ШД" входы никак не обрабатываются, поэтому Дима и пишет, что "перестают работать входы".


Другое дело, что всем нужно одновременно и ШД крутить, и со входов информацию получать.
Для этого есть 2 варианта:
1) Звонить в ОВЕН
2) Просить меня, чтобы расширить "программу ШД" и добавить туда какую-нибудь обработку входов

[dima64]

нет,я не про это, протестил конечный пользователь работу пру и перешел к повседневным делам. как ему вернуть контроль, если залитая программа в пру до сих пор крутится, как от нее избавиться?

Я просто удаляю PRU0, PRU1 из ПЛК-браузер, перегружаю, и все ПЛК чист, как из коробки.
Кстати, если PRU1 не загружен, то первые 2 быстрых выхода работают из конфигуратора.

[Дмитрий Артюховский]

Вердикт: эксперимент показывает, что регистры _не_ переиспользуются. Тут всё ровно так, как и говорил Владислав.

Дмитрий, я требую извинений.



Вот пример: 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 плохой", а к тому, что это моя аргументация почему я не могу просто взять и оформить свою ШД программу "по правилам ОВЕН". Тут не только моё субъективное "не хочу тратить время", но и вполне конкретная техническая проблема.

в этом примере дело не в "анд"-ах а в 4-х кратном размещении "pru_host". в том виде как он сделан в библиотеке - он читает 1 фиксированный регистр

кстати, продам наблюдение - "подход овена" - это по сути локализация (русификация с извращениями) соответствующего инструмента TI, т.е. достаточно широко используемого инструмента.... Ну конечно "черепаха" круче всего мирового опыта программирования - тут без сомнений. Керниган, Ричи и Кнут плачут горькими слезами ))))

[Владимир Ситников]

В ПЛК Delta не зря сделано нелинейное ускорение.

На всякий пожарный, поддержка Дельты ответила, что "тот самый документ" давным-давно устарел и нужно смотреть новые функции.
В новой документации у них линейное ускорение, но возможностью активации режима "s кривой" (про этот режим ни слова более не сказано).

26849

[Дмитрий Артюховский]

Тем, что в "конфигуратор" быстрые входы попадают через "программу PRU по умолчанию".

Если PRU*.prg не залиты, то входы-выходы работают как обычно.
Если PRU*.prg залиты, то входы-выходы работают согласно залитой программе. В текущей моей "программе ШД" входы никак не обрабатываются, поэтому Дима и пишет, что "перестают работать входы".


Другое дело, что всем нужно одновременно и ШД крутить, и со входов информацию получать.
Для этого есть 2 варианта:
1) Звонить в ОВЕН
2) Просить меня, чтобы расширить "программу ШД" и добавить туда какую-нибудь обработку входов

ну или делать на совместимость с блоками овена - тогда любой может нарисовать нужную ему картинку )))

[Владимир Ситников]

в этом примере дело не в "анд"-ах а в 4-х кратном размещении "pru_host". в том виде как он сделан в библиотеке - он читает 1 фиксированный регистр

Вот вариант с 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 -- уже никак.
И как с этим работать?

[capzap]

Я просто удаляю PRU0, PRU1 из ПЛК-браузер, перегружаю, и все ПЛК чист, как из коробки.
Кстати, если PRU1 не загружен, то первые 2 быстрых выхода работают из конфигуратора.

надеюсь к загрузочному проекту это не относится, просто наличие файлов в плк имеет значение

[capzap]

Тем, что в "конфигуратор" быстрые входы попадают через "программу PRU по умолчанию".
на скрине и со слов автора скрина влияние программа ПРУ оказывает и на два обычных входа или же четыре входа, четыре выхода, не зависимо от того какой у них тип

[Владимир Ситников]

В чём проблема на этот раз?
26850

Забавы ради сделал такую же программу в черепахе (https://github.com/vlsi/ide61131).
Выглядит, конечно, не супер, но я сделал так, чтобы было сравнение 1 в 1. Точно такой же ФБ PRU_AND.

Если кратко, то черепахе оказалось достаточно 4 байт для "FROM HOST" и 5 временных байт (т.е. хватило всего 9 байт регистровой памяти)
"линкер от ОВЕН" не смог скомпилировать эту программу и с помощью 20-и байт регистровой памяти.



Само по себе использование ФБ для компилятора сложнее (чем "встроенные" функции AND), т.к. у ФБ значения выходов нельзя терять. Например, если они на каком-то цикле значения не передавались (а был просто вызов ФБ), то нужно использовать "прошлые" значения входов.
Т.е. самый простой вариант -- всегда выделять отдельные регистры для каждого входа и выхода, но это порождает "потенциально лишнее копирование из одной переменной в другую" и потенциальный перерасход регистров. Я так понял, Владислав пропагандирует именно такой способ.
Как видим, 15 AND'ов скомпилировать таким подходом уже проблема. По-моему, это слишком высокая плата за мнимую "надёжность (http://www.owen.ru/forum/showthread.php?t=22169&page=9&p=220119&viewfull=1#post220119)".

26851

Я сделал PRU_AND2 как "полноценный блок".
Блок-то он отдельный, но компилятор "видит его насквозь" и понимает суть происходящего. Мой компилятор понимает, что ассемблерная инструкция AND всегда записывает выходную переменную, т.е. компилятор догадывается, что для этого блока статичный выходной регистр не нужен.

Результирующий код использует следующие регистры:
R1 -- 4 байта для PRU_FROM_HOST
R2 и R3.b0 -- 5 временных байт.

Да, сама программа получилась не супер -- 31 инструкция (если отбросить HOST/OUT и т.п. обёртку), т.к. осталась часть команд "присвоения входов-выходов" для блоков PRU_AND2.
26852

Под конец только AND'ы идут, т.е. прямо "идеальный код":
26853


Но мы же на ST пишем?
Что мешает сделать IF (AND AND) THEN?
Ничего. Немного копипасты и получается такое:
26854

Тут ассемблерный код получается куда лаконичнее. Компилятор просто использует "условные переходы" и прерывает выполнение на первом же FALSE.
26855
Тут вообще ни одного дополнительного регистра не понадобилось. Просто кучка условных переходов.

Ценность вышеобозначенных примеров, конечно, невелика, но если компилятор без проблем работает с "упоротым" кодом, то и нормально написанный он нормально будет компилировать.

[dima64]

надеюсь к загрузочному проекту это не относится, просто наличие файлов в плк имеет значение

Совершенно верно.

[Филоненко Владислав]

Во-первых, я уже писал почему это сделать невозможно.

А во вторых, ещё причина: блоки ОВЕН поддерживают _только_ байтовые входы-выходы. Хотите WORD/DWORD -- уже никак.
И как с этим работать?

Это не так. Вам ли, как имеющему расширенный пакет с исходниками ФБ это не знать.
Конкретная реализация библиотеки сейчас имеет только байтовый I/O.
Полноценный редактор будет иметь полиморфизм I/O (выбор типа по необходимости)

[Филоненко Владислав]

что конкретно? Например появился такой вопрос к Ситникову, если человеку надоело играться с программой для ШД, как ему вернуть управление быстрыми входами/выходами в конфигуратор, есть empty блок который освободит работу ПРУ
Стереть файл PRUx.prg

[Филоненко Владислав]

Похоже ОВЕН отстранился от этой темы.
ОВЕН не устранился от темы, а устранился от пути, по которому Акела ведёт стаю.

[Филоненко Владислав]

Вердикт: эксперимент показывает, что регистры _не_ переиспользуются. Тут всё ровно так, как и говорил Владислав.


Регистры не переиспользуются и не должны.
Исключения т.н. макросы (сборки из блоков без внутренней памяти с однозначным потоком исполнения без циклов, например комплексный 4ANDNOT из 3-х AND и NOT).

Концепция сверхжёсткого реального времени с 100% гарантией исполнения алгоритма не позволяет переиспользовать ресурсы. Результаты промежуточных вычислений (с т.з. процедурного подхода) не являются промежуточными.
По аналогии, если бы некая цифровая схема по мере прохождения сигнала по лог. элементам переставляла бы проводники (регистры) с входов лог. элемента на выходы. Для экономии меди в стране.
Пока у нас однозначный поток данных - так делать можно (теоретически).
Как только есть кольца, ячейки памяти, линии задержки и пр. - такой подход бы приводил к неопределённости поведения и часть линий пришлось бы сделать "запретными".

Например в Овен Лоджик блок расчёта таких "запретных" линий, где надо делать промежуточную ячейку памяти занимает немалую часть логики среды разработки и даже после годов отладки иногда бывают "особые ситуации".

На самом деле при байтовом I/O PRU уже имеет до 28*4 только регистровых переменых. А битовых в 8 раз больше. + куча ОЗУ.
Для логики RT управления дискретными I/O этого более чем достаточно.
А вот если всякие S-кривые в плавающей точке вычислять 1000000 раз в секунду - тут надо подход изменять, а не brute forсe-ом ломится.

[Филоненко Владислав]

На этот вопрос (можно ли выводить результаты PRU программы в "plc configuration") тов. Филоненко говорит решительное нет. Ну, что, якобы, адреса памяти КДС назначает произвольно, что это в концепцию ПЛК110 не укладывается и т.п.

С моей точки зрения, звучит, конечно, неубедительно. Свои fast encoder/fast counter программы в ОВЕН как-то сделали и в конфигуратор сумели вывести?


Вот через pruaccesslib.lib и работает. Другим способом получить синхронизацию без остановки PRU и без неопределённого по времени доступа из PRU в основное ОЗУ (от десятков до тысяч тактов, если крайне не повезёт с моментом обмена) нельзя.

Но, конечно, всегда есть путь Илона Маска.

[Владимир Ситников]

Концепция сверхжёсткого реального времени с 100% гарантией исполнения алгоритма не позволяет переиспользовать ресурсы
1) На самом деле, позволяет. Например, для умножения WORD'ов достаточно сделать 16 итераций цикла. На этих итерациях можно переиспользовать переменные. Никто не пострадает. Можно всегда крутить все 16 итераций и время выполнения вообще константным будет. А можно и выходить из цикла пораньше (если числа маленькие) -- тогда останется время на другие задачи.
2) Для большинства типичных случаев сверхжёсткий realtime и не нужен. Ну на кой нужен этот самый realtime, если мы ШД крутим?



Например в Овен Лоджик блок расчёта таких "запретных" линий, где надо делать промежуточную ячейку памяти занимает немалую часть логики среды разработки и даже после годов отладки иногда бывают "особые ситуации".

Раз говорите, что "обратную связь" (линию задержки) сделать сложно, то не буду голословным, а просто возьму и сделаю.

Вот ФБ для "линии задержки":
26857

Вот программа с его использованием. Надеюсь, вы понимаете, что FBD программы в такой ST код переводятся в режиме "что вижу, то пою"?
Для преобразования FBD в такой ST код нужно лишь объявить переменные с ФБ и присвоить входные-выходные значения.
Да, топологическую сортировку FBD, конечно, сделать придётся, но это вовсе не вопрос "где нужна доп ячейка, а где не нужна".

И, да, я ни строчки кода в компиляторе не менял. Просто добавил ФБ и создал программу с его участием.
26858

Вот результирующий ассемблер:

26859

"промежуточная" ячейка образовалась сама собой. R1.b1 (для первой обратной связи) и R1.b2 (для второй).

Ну, я, конечно, понимаю, что "с первого раза никогда ни одна программа не получается", но не вижу никаких сложностей с обратными связями. Честное слово не вижу.
Вот я написал простой ST, и он сразу заработал. В чём реально проблема?

Мой план -- FBD программы преобразовывать в ST, а потом обрабатывать уже имеющимся ST компилятором.
И наглядность FBD сохранится, и всегда можно будет проверить "во что оно превратилось" / "на каком этапе косяк".

На всякий случай, я использую следующие ключевые слова: dataflow analysis (https://en.wikipedia.org/wiki/Data-flow_analysis), live variable analysis (https://en.wikipedia.org/wiki/Live_variable_analysis), linear scan register allocation (http://web.cs.ucla.edu/~palsberg/course/cs132/linearscan.pdf). Первые два алгоритма реализовывал не я, а они встроены в среду, на которой я пишу Hardella.


И, да, сейчас в ОЛ поведение "если есть цикл в программе, то разрывать его и где-то автоматически делать обратную связь", но, на мой взгляд, это нехорошее поведение. Если делать FBD в Hadrella, то я хотел запретить явные циклы, и всегда требовать от пользователя указания где именно связь с задержкой на такт.

[Владимир Ситников]

Вот через pruaccesslib.lib и работает
Таки есть возможность выудить данные через pruaccesslib, и запулить их в "plc configuration" уже средствами host'а?

Да, складывать из PRU в ОЗУ, конечно, расточительно. Разве что одно из PRU ядер "потратить" на обмен с DDR памятью, но это стрёмный путь

[Владимир Ситников]

На текущий момент 4 (ЧЕТЫРЕ) человека вообще проявили какой-либо интерес к технологии и соизвоили хотя бы письмо мне написать, чтобы получить пакет тестировщика. Четыре, Карл!

Но зато уже двое провели натурные испытания программы ШД на ШД и servo.
И это при том, что ОВЕН нигде не объявлял о "поддержке ШД в ПЛК110", и при том, что сарафанное радио ещё не особо сработало.
И при том, что вокруг PRUграммирования царит туман неизвестности (ОВЕН свои планы не озвучивает, а чужие разработки отрицает).

Объявите на сайте/в рассылках не о "пакете тестировщика PRU программ", а о "поддержке ШД/серво в ПЛК110".
И посмотрим сколько будет желающих.

Вариант "заливаем PRU0.prg через КДС" и используем PRU_STEPPER(MAX_FREQ:=10000, QUANTITY:=1234, OUT_NUM:=1) понятен даже домохозяйке.
Ошибиться можно разве что в схеме подключения ШД.



Разумеется, "готовых PRUx.prg" на все случаи не напасёшься, и в реальности понадобится либо конфигуратор, либо среда программирования.
Но для первой версии достаточно и простой PRUx.prg программы.

[Дмитрий Артюховский]

Вот через pruaccesslib.lib и работает. Другим способом получить синхронизацию без остановки PRU и без неопределённого по времени доступа из PRU в основное ОЗУ (от десятков до тысяч тактов, если крайне не повезёт с моментом обмена) нельзя.

Но, конечно, всегда есть путь Илона Маска.


COUNT_DUBL_POINT := PRU_DRAM + OFFSET;
COUNT_DUBL_POINT^ := 16#01020304;

>>>>
LBCO &R28, CONST_PRUDRAM, 128, 4 // временно - считать 4 байта и положить в 28 рег дл_ тестирования проброса - работает
>>>>

понятно что не синхронно, но для некоторых применений прокатит...

[Владимир Ситников]

COUNT_DUBL_POINT := PRU_DRAM + OFFSET;
COUNT_DUBL_POINT^ := 16#01020304;

>>>>
LBCO &R28, CONST_PRUDRAM, 128, 4 // временно - считать 4 байта и положить в 28 рег дл_ тестирования проброса - работает
>>>>

понятно что не синхронно, но для некоторых применений прокатит...
Шайтан. Это же вообще огонь-технология!
Если надо синхронность, то просто делаем WHILE COUNT_DUBL_POINT^ ... END_WHILE; и всего делов.

Может, ещё и структуру/массив можно разместить по адресу PRU_DRAM?
Если такое применить, то вообще огонь будет. Не то, чтобы "немного не по правилам", а "вообще не по правилам" )

Ну и нужно будет к Вольду обратиться. Он очень метко эпитеты подбирает.

[Newcomer]

Тут было сообщение, что при заливке ФБ для управления ШД в PRU перестают работать 2 быстрых и 2 обычных дискретных входа ПЛК110[М02]. Это косяк, который будет исправлен или все так и останется ?

[Владимир Ситников]

Тут было сообщение, что при заливке ФБ для управления ШД в PRU перестают работать 2 быстрых и 2 обычных дискретных входа ПЛК110[М02]. Это косяк, который будет исправлен или все так и останется ?

Основной вопрос -- "останется ли вообще хоть что-нибудь от PRU0.prg".

[Дмитрий Артюховский]

Господа из фирмы "ОВЕН" ведут себя как-то по детски - удаляют посты на злобу дня, упорно игнорируют свершившиеся факты.

Повторю вопрос к В.Филоненко и К. Какова дальнейшая судьба ФБ для управления ШД и сервомотором, разработанного В.Ситниковым, которому (ФБ) на сегодня нет альтернативы ? Я думаю, форум будет удовлетворен если представители "ОВЕН" публично возьмут на себя обязательства не строить козни и не препятствовать использованию этого ФБ.

а кто вам мешает его использовать? ... вот только вопросов не задавайте овеновцам почему с этим блоком у нас не работает то-то и то-то и вообще контроллер чудит )))
Сторонние разработчики, скажем за сертификат "windows compatible" денег платят, ну а второй способ распространения - выкладывание открытого кода.... ну и напомню, что блок Ситникова не соответствует концепции ПЛК (в принципе, а не только овеновским хотелкам) на стабильное время цикла выполнения...
кстати! ничто в этом мире не мешает нашему уважаемому разработчику переписать блок на соответствие стандартам овена и тогда я не вижу никаких проблем с включением данного блока в библиотеку, распространяемую овеном )))

[Вольд]

а кто вам мешает его использовать?

Спецы из "ОВЕН" могут сделать так, что этот ФБ в один прекрасный, нет ужасный, день перестанет загружаться в PRU. Читай пост #456.

[Дмитрий Артюховский]

Спецы из "ОВЕН" могут сделать так, что этот ФБ в один прекрасный, нет ужасный, день перестанет загружаться в PRU. Читай пост #456.

Для этого они должны будут закрыть этот проект в принципе, и кстати, поменять процессор, переразвести плату и пр. )))) потому что если этот чип останется в составе ПЛК - никто не может помешать загрузить свою программу в ПРУ и выполнить ее )))) Понятно что нужно выбирать либо функции конфигуратора - либо самописные решения.

Ну и я не понял мысль из поста 456.

[Филоненко Владислав]

COUNT_DUBL_POINT := PRU_DRAM + OFFSET;
COUNT_DUBL_POINT^ := 16#01020304;

>>>>
LBCO &R28, CONST_PRUDRAM, 128, 4 // временно - считать 4 байта и положить в 28 рег дл_ тестирования проброса - работает
>>>>

понятно что не синхронно, но для некоторых применений прокатит...

Это крайне медленно и внутренняя шина может быть в этот момент занята обменом с чем-нибудь другим => непредсказуемая задержка.

[Вольд]

На текущий момент 4 (ЧЕТЫРЕ) человека вообще проявили какой-либо интерес к технологии и соизвоили хотя бы письмо мне написать, чтобы получить пакет тестировщика. Четыре, Карл!

Вы очень сильно заблуждаетесь. Судя по количеству постов в этой теме (море постов еще было удалено) эта технология вызывает огромный интерес у пользователей продукции фирмы "ОВЕН".

[Владимир Ситников]

Ну и я не понял мысль из поста 456.
Мысль была всё-таки про цивилизованные методы. Если честно, я и не думал, что настолько просто стенки поднимаются.
Честное слово, мыслил исключительно в добропорядочном направлении, поэтому и долбился как баран в стенку PRUx.prg и pruAccessLib.lib.

Расшифрую: сейчас всё держится на том факте, что прошивка ПЛК110 загружает PRU0.prg и PRU1.prg файлы, если считает их "правильно оформленными".
Предстоит, например, Newcomer'у проект с ШД. У него есть выбор: PRU0.prg или ардуино/дельта/далее по списку.

Если он сейчас в проект заложит, что "управлять ШД будет через PRU0.prg", а через полгода ОВЕН обновит прошивку ПЛК и перестанет загружать файл PRU0.prg, то управление ШД у Newcomer'а накроется веткой сакуры.

Тут не вопрос того, чтобы ОВЕН кровью подписались, что никогда ни при каких условиях PRU0.prg не сломается. Разумеется, таких подписей никто не требует.
Вопрос в том, могут ли они публично заявить, что специально ломать поддержку PRU0.prg программ не будут.


никто не может помешать загрузить свою программу в ПРУ и выполнить ее ))))
Если имеется ввиду подход "остановить PRU, залить новую программу через 0x01C3, запустить", это, конечно, интересно, и даже может работать первое время.
И, похоже, этот подход может даже обойти ограничение 2048 байт в PRU0.prg.

Но, повторюсь, может выйти обновление HOST прошивки, которое станет периодически проверять "содержимое PRU instruction ram", и, если увидит "вражескую программу", то остановит PRU под предлогом "в логике работы замечена ошибка, мы перевели выходы в безопасное состояние".
Не хотелось бы играть с разработчиками ОВЕН в Бой в памяти (https://ru.wikipedia.org/wiki/%D0%91%D0%BE%D0%B9_%D0%B2_%D0%BF%D0%B0%D0%BC%D1%8F %D1%82%D0%B8)

[Дмитрий Артюховский]

Мысль была всё-таки про цивилизованные методы. Если честно, я и не думал, что настолько просто стенки поднимаются.
Честное слово, мыслил исключительно в добропорядочном направлении, поэтому и долбился как баран в стенку PRUx.prg и pruAccessLib.lib.

Расшифрую: сейчас всё держится на том факте, что прошивка ПЛК110 загружает PRU0.prg и PRU1.prg файлы, если считает их "правильно оформленными".
Предстоит, например, Newcomer'у проект с ШД. У него есть выбор: PRU0.prg или ардуино/дельта/далее по списку.

Если он сейчас в проект заложит, что "управлять ШД будет через PRU0.prg", а через полгода ОВЕН обновит прошивку ПЛК и перестанет загружать файл PRU0.prg, то управление ШД у Newcomer'а накроется веткой сакуры.

Тут не вопрос того, чтобы ОВЕН кровью подписались, что никогда ни при каких условиях PRU0.prg не сломается. Разумеется, таких подписей никто не требует.
Вопрос в том, могут ли они публично заявить, что специально ломать поддержку PRU0.prg программ не будут.


Если имеется ввиду подход "остановить PRU, залить новую программу через 0x01C3, запустить", это, конечно, интересно, и даже может работать первое время.
И, похоже, этот подход может даже обойти ограничение 2048 байт в PRU0.prg.

Но, повторюсь, может выйти обновление HOST прошивки, которое станет периодически проверять "содержимое PRU instruction ram", и, если увидит "вражескую программу", то остановит PRU под предлогом "в логике работы замечена ошибка, мы перевели выходы в безопасное состояние".
Не хотелось бы играть с разработчиками ОВЕН в Бой в памяти (https://ru.wikipedia.org/wiki/%D0%91%D0%BE%D0%B9_%D0%B2_%D0%BF%D0%B0%D0%BC%D1%8F %D1%82%D0%B8)

А зачем вам обновлять прошивку ПЛК в работающей установке? То же самое можно сказать про новые контроллеры - всегда можно "откатить" на работающую прошивку. Мало того это приходится делать и в настоящее время, лично я использую прошивку 2.10.9. В мир меняется... и куча программ написанная в XP не будет работать в WIN10 - хорошо или нет - это так....

[Владимир Ситников]

Подскажите по вопросу "быстрых входов" как правильнее делать фильтрацию дребезга?

Норм, если будет такой вариант?

3. Методом подсчета времени устойчивого состояния (https://ru.wikipedia.org/wiki/%D0%94%D1%80%D0%B5%D0%B1%D0%B5%D0%B7%D0%B3_%D0%BA% D0%BE%D0%BD%D1%82%D0%B0%D0%BA%D1%82%D0%BE%D0%B2#.D 0.A1.D0.BF.D0.BE.D1.81.D0.BE.D0.B1.D1.8B_.D1.83.D1 .81.D1.82.D1.80.D0.B0.D0.BD.D0.B5.D0.BD.D0.B8.D1.8 F_.D0.BD.D0.B5.D0.B6.D0.B5.D0.BB.D0.B0.D1.82.D0.B5 .D0.BB.D1.8C.D0.BD.D0.BE.D0.B3.D0.BE_.D0.B2.D0.BB. D0.B8.D1.8F.D0.BD.D0.B8.D1.8F_.D0.B4.D1.80.D0.B5.D 0.B1.D0.B5.D0.B7.D0.B3.D0.B0) - программа в течении заданного времени многократно считывает состояние контакта. Если в течении заданного времени не обнаружено ни одного изменения состояния на противоположное, то контакт считается устойчиво замкнутым. В противном случае, если было обнаружено изменение состояния в течении заданного времени, то подсчет времени прерывается (или продолжается, но с установкой флага или подсчетом количества изменений состояния для оценки физического состояния механических контактов) и контакт считается разомкнутым или с неустойчивым состоянием (если такая информация используется в программе).

Подсчёт времени устойчивого состояния, сделать проще, чем "медианную фильтрацию" или что-то подобное.
Вопрос в том достаточно ли будет просто следить за постоянством сигнала на протяжении заданного времени?

[Newcomer]

Подскажите по вопросу "быстрых входов" как правильнее делать фильтрацию дребезга?

Норм, если будет такой вариант?


Подсчёт времени устойчивого состояния, сделать проще, чем "медианную фильтрацию" или что-то подобное.
Вопрос в том достаточно ли будет просто следить за постоянством сигнала на протяжении заданного времени?

Быстрые входа фильтровать не надо, иначе это будут не быстрые входы. К быстрым входам механические контактные группы не подключают, поэтому дребезга контактов бояться не надо.

[Владимир Ситников]

Быстрые входа фильтровать не надо, иначе это будут не быстрые входы. К быстрым входам механические контактные группы не подключают, поэтому дребезга контактов бояться не надо.

Во-первых, даже в ОВЕНовском конфигураторе на быстрых входах настраивается "Time of filtration, in mks". В том числе, в режиме "Fast encoder".

Во-вторых, если вход использовать как простой (ну, чтобы 4 входа не пропадали), то их могут использовать и как обычные, и, значит, фильтрация нужна.

[Newcomer]

Во-первых, даже в ОВЕНовском конфигураторе на быстрых входах настраивается "Time of filtration, in mks". В том числе, в режиме "Fast encoder".

Во-вторых, если вход использовать как простой (ну, чтобы 4 входа не пропадали), то их могут использовать и как обычные, и, значит, фильтрация нужна.

В таком случае можно фильтровать так как это делает "ОВЕН". Как он это делает написано в РЭ на ПЛК.

[Newcomer]

2.1.1. Параметр «Время фильтрации» (Time of filtration)
Фильтрация применяется главным образом для подавления «дребезга»
контактов.
Время фильтрации – это период опроса состояния одного
дискретного входа, задается в сотнях микросекунд (1 ед. = 100 мкс, 10 ед. = 1
мс).

Принцип действия фильтрации:
• в сдвиговом регистре в драйвере каждого дискретного входа
накапливаются значения восьми последних состояний, полученных в
18
результате опроса с периодом, заданным в параметре «Время
фильтрации»;
• если состояние битового канала дискретного входа равно 1
(TRUE), а количество единиц в сдвиговом регистре менее двух, то
битовый канал переключается на 0 (FALSE);
• если состояние битового канала равно 0 (FALSE), а количество
единиц в сдвиговом регистре больше пяти, то битовый канал
переключается на 1 (TRUE);
• если количество единиц в сдвиговом регистре от 2 до 5, то
состояние битового канала дискретного входа не меняется.

Режим фильтрации может быть отключен установлением в параметре
значения, равного «?1». Отключение фильтрации необходимо при работе с
подчиненными модулями энкодеров для того, чтобы не пропускать
высокочастотные сигналы, а также в тех случаях, когда ПЛК функционирует
без ограничения цикла по частоте, т.е. на максимально возможной частоте.

[kir2]

Реализую проект в составе ПЛК110 (М02) - панель СП307 через RS485 MODBUS RTU - привод STEPDRIVE 2 ф. OMRON с управлением STEP/DIR через быстрые выходы. И что выяснилось - при инициализации таймерного прерывания в ПЛК обмен с панелью тормозится т.о., что время восприятия нажатия клавиши составляет 2...3 секунды. Причем уменьшение частоты прерываний с 20 до 200мкс практически не сказалось на скорости обмена, только исключение «SetIRQ» привело к приемлемой реакции на клавиши ~0.5сек.
Выводы:
1. Использование быстрых выходов для задач позиционирования в нынешнем виде делает практически невозможной работу с панелью оператора, тормозит обмен по RS485. Предлагаемое в теме В.Филоненко использование PRU исключит данную проблему и д. б. быстро реализовано в виде стандартного решения для ОВЕН.

2. Для разгона-торможения STEPDRIVE 2 (при отсутствии оного имели место ударные нагрузки) пришлось городить массив данных:
ar : ARRAY [1..32] OF DWORD :=2#11111111111111111111111111111110,
2#11111111111111101111111111111110,
2#11111111110111111111011111111101,
2#11111110111111101111111011111110,
2#11111110111111011111011111011110,
2#11111011111011110111101111011110,
2#11110111101111011110111011101110,
2#11101110111011101110111011101110,
2#11101110111011101110110110110110,
2#11101110110110110110110110110110,
2#11011011011011011011011011011010,
2#11011011011011011011011010101010,
2#11011011011010101010101010101010,
2#11011010101010101010101010101010,
2#10101010101010101010101010101010,
2#10101010101010101010101010101010,
2#10101010101010101010101010101010,
2#10101010101010101010101010010010,
2#10101010101010101010101010100100,
2#10101010101010101010100100100100,
2#10101010101010100100100100100100,
2#10101010100100100100100100100100,
2#10100100100100100100100100100100,
2#10010010010010010010010001000100,
2#10010010010010010001000100010000,
2#10001000100010001001000100010000,
2#10001000010000100001000001000000,
2#10000100000100000100000010000000,
2#10000010000000100000001000000000,
2#10000000001000000000100000000000,
2#10000000000000001000000000000000,
2#10000000000000000000000000000000;
и реализовать это в ограниченном по времени таймерном прерывании.
Будь в наличии ФБ управления ШД типа предложенного в теме В. Ситниковым - задача радикально упростилась бы.

3. В настоящее время SIEMENS снял с производства применяемые в нашей продукции ШД 1FL и приводы STEPDRIVE. Взамен их предлагается контроллер S7-1200 и привод SINAMICS V90 c управлением STEP/DIR. Однако в STEP7 для S7-1200 нет STL (список инструкций), что усложняет адаптацию ПО к новому HARDу. По этой же причине при выборе контроллера не был применен плк ОМРОНа, с реализацией только языка РКС. Если кто помнит, то при появлении контроллеров (1980-е годы) языки РКС и FBD предполагалось использовать только для упрощения перехода в существующих установках с управлением на реле и с комбинационными схемами на ИМС соответственно. В дальнейшем предполагалось их отмирание как неудобных для реализации алгоритмов управления. Однако, как мы видим, нет ничего более постоянного, чем временное решение. Инженерный корпус освоив РКС счёл его достаточным для всех приложений (а скорее не желая осваивать новое) и масса производителей плк ограничивается реализацией только РКС (LD, STL).
Т.о. будь у ОВНА реализация быстрых выходов/входов с частотой до 1МГц (без подавления RS485) и библиотеки с функцией разгона-торможения, ПЛК110 М02 стал бы достойной заменой мировых аналогов, в том числе благодаря использованию КДС с представлениями IL и ST.

[Владимир Ситников]

1. Использование быстрых выходов для задач позиционирования в нынешнем виде делает практически невозможной работу с панелью оператора, тормозит обмен по RS485. Предлагаемое в теме В.Филоненко использование PRU исключит данную проблему и д. б. быстро реализовано в виде стандартного решения для ОВЕН.
Можно по-подробнее про "задачу позиционирования"?
В чём именно задача?



Будь в наличии ФБ управления ШД типа предложенного в теме В. Ситниковым - задача радикально упростилась бы.
Так есть же блок ШД с разгоном-торможением (http://www.owen.ru/forum/showthread.php?t=22169&page=29&p=221928&viewfull=1#post221928). Пробовали?
Или проект уже сделан/сдан?

[kir2]

Можно по-подробнее про "задачу позиционирования"?
В чём именно задача?

Стандартная задача по перемещению механизма из текущей позиции в заданную с необходимой скоростью (без интерполяции (связи) с другими осями). Так же необходима оцифровка оси позиционирования (привязка перемещаемого механизма к базе),для чего используется перемещение с фиксированной скоростью с определением положения по фронту сигнала конечного выключателя или нулевой метки (Z) датчика положения.

Так есть же блок ШД с разгоном-торможением (http://www.owen.ru/forum/showthread.php?t=22169&page=29&p=221928&viewfull=1#post221928). Пробовали?
Или проект уже сделан/сдан?

Проект сделан ещё в августе, но ещё не сдан. Поэтому если будет время на тестирование Вашего блока и доступ к объекту (сейчас он в удалённом от меня месте), то о результате сообщу.

[Владимир Ситников]

В соседней теме сделал программу для энкодера (http://www.owen.ru/forum/showthread.php?t=23600&page=11&p=223074&viewfull=1#post223074)

Кто-нибудь может покрутить энкодер -- посмотреть правильно ли считаются импульсы?

[Дмитрий Артюховский]

а чего его крутить - на малых скоростях и на реверсировании возможно появление и накопление ошибок счета...

[Владимир Ситников]

а чего его крутить - на малых скоростях
Речь про дребезг? Или про ошибку в логике?


на реверсировании возможно появление и накопление ошибок счета...
Из-за чего бы?

[rovki]

Из-за смены фаз А и В при реверсе и алгоритме обработки их .

[Владимир Ситников]

Из-за смены фаз А и В при реверсе и алгоритме обработки их .

Можете на пальцах объяснить?

Попозже добавлю тест, который будет случайным образом крутить фазы A/B (ну, в смысле, виртуальный энкодер будет крутиться в случайных направлениях, и его ABZ будут подаваться на вход тестируемому блоку) и проверять, что распознаётся правильно.

Такой тест работает:


abz.setA(cpu, 1); // A: 0 -> 1
executeBlock(cpu);
assertEquals(abz.getCounter(cpu), 1, "counter");
assertEquals(abz.getPosition(cpu), ((-1) & 0xffff), "position");
assertEquals(abz.getZeroDetected(cpu), 0, "zero detected");

executeBlock(cpu); // Если входы не менялись, выходы меняться не должны
assertEquals(abz.getCounter(cpu), 1, "counter");
assertEquals(abz.getPosition(cpu), ((-1) & 0xffff), "position");
assertEquals(abz.getZeroDetected(cpu), 0, "zero detected");

abz.setB(cpu, 1); // B: 0 -> 1
executeBlock(cpu);
assertEquals(abz.getCounter(cpu), 2, "counter");
assertEquals(abz.getPosition(cpu), ((-2) & 0xffff), "position");
assertEquals(abz.getZeroDetected(cpu), 0, "zero detected");

abz.setA(cpu, 0); // A: 1 -> 0
executeBlock(cpu);
assertEquals(abz.getCounter(cpu), 3, "counter");
assertEquals(abz.getPosition(cpu), ((-3) & 0xffff), "position");
assertEquals(abz.getZeroDetected(cpu), 0, "zero detected");

// Теперь крутим обратно
abz.setA(cpu, 1); // A: 0 -> 1
executeBlock(cpu);
assertEquals(abz.getCounter(cpu), 4, "counter");
assertEquals(abz.getPosition(cpu), ((-2) & 0xffff), "position");
assertEquals(abz.getZeroDetected(cpu), 0, "zero detected");

abz.setB(cpu, 0); // B: 1 -> 0
executeBlock(cpu); // Если входы не менялись, выходы меняться не должны
assertEquals(abz.getCounter(cpu), 5, "counter");
assertEquals(abz.getPosition(cpu), ((-1) & 0xffff), "position");
assertEquals(abz.getZeroDetected(cpu), 0, "zero detected");

// Теперь снова меняем направление

abz.setB(cpu, 1); // B: 0 -> 1
executeBlock(cpu); // Если входы не менялись, выходы меняться не должны
assertEquals(abz.getCounter(cpu), 6, "counter");
assertEquals(abz.getPosition(cpu), ((-2) & 0xffff), "position");
assertEquals(abz.getZeroDetected(cpu), 0, "zero detected");

abz.setA(cpu, 0); // A: 1 -> 0
executeBlock(cpu);
assertEquals(abz.getCounter(cpu), 7, "counter");
assertEquals(abz.getPosition(cpu), ((-3) & 0xffff), "position");
assertEquals(abz.getZeroDetected(cpu), 0, "zero detected");

[Scream]

Владимир, объясните на пальцах как java даёт команды в плк110?
Через сеть?

[Владимир Ситников]

Владимир, объясните на пальцах как java даёт команды в плк110?
Через сеть?

Объясню: пока ещё никак.
Код выше работает на эмуляторе PRU сопроцессора (https://github.com/vlsi/pru-emulator).

Эмулятор повторяет логику процессора (регистры, память, IO), поэтому мне не нужен ПЛК, чтобы тестировать логику ФБ. Тем не менее, тут тестируется почти тот же самый бинарный код, который будет загружен в ПЛК.

До тестирования "в железе" ещё доберёмся, но попозже

[rovki]

Можете на пальцах объяснить?

]
Приходит фаза А ,а В сигнала еще нет ...и приходит команда на реверс или есть А и В и приходит команда не реверс ...То есть может потеряться импульс с энкодера при реверсе ...

[Владимир Ситников]

Приходит фаза А ,а В сигнала еще нет ...и приходит команда на реверс

Начальные состояния: 0,0.



// Приходит фаза A; B ещё нет
abz.setA(cpu, 1); executeBlock(cpu);
System.out.println("position = " + (short)(abz.getPosition(cpu)) + ", counter = " + abz.getCounter(cpu));

// Реверс -- фаза A пропала, B тоже молчит
abz.setA(cpu, 0); executeBlock(cpu);
System.out.println("position = " + (short)(abz.getPosition(cpu)) + ", counter = " + abz.getCounter(cpu));

Вывод:

position = -1, counter = 1
position = 0, counter = 2

Если при исходных нулях моргнёт и пропадёт фаза B, то будет такой вывод:
position = 1, counter = 1
position = 0, counter = 2


Импульсы не пропали. Сначала один посчитался как -1, потом рервес и он учёлся как +1 -- в итоге 0.



есть А и В и приходит команда не реверс ...То есть может потеряться импульс с энкодера при реверсе ...
Тут немного непонятно. Что значит "есть A и B и команда на реверс". В каком порядке должны мигать A/B?

[rovki]

26924Команда на реверс может придти в любое время (00,10,11,01,00 или 00,01,11,10,00) ..однозначно можно судить ,что это не помеха ,в момент +- импульс .-то есть ловим задний фронт А или В на одном и потенциал "1" на другом входе В или А .

[Владимир Ситников]

26924Команда на реверс может придти в любое время (00,10,11,01,00 или 00,01,11,10,00) ..однозначно можно судить ,что это не помеха ,в момент +- импульс .-то есть ловим задний фронт А или В на одном и потенциал "1" на другом входе В или А .

Предлагается ловить только 1 фронт одной фазы? (при одном направлении вращения)
Это же в 4 раза снижает точность получаемых данных.

Можно же ловить все фронты (и передние и задние обоих сингалов) и тем самым повысить получаемую точность.

И, да, в моём алгоритме все переходы между 00,10,11,01,00 будут правильно обрабатываться. Грубо говоря: мы знаем прошлое состояние, мы видим какой фронт пришёл, и можем понять в какую сторону крутили.

О каких потерях идёт речь -- не могу понять.

[rovki]

Фронты по алгоритму ловятся все ,а не один ,но кроме фронта нужного я еще всегда анализирую потенциал на противоположном входе ,что бы уменьшить влияние помех .

[Владимир Ситников]

Фронты по алгоритму ловятся все ,а не один ,но кроме фронта нужного я еще всегда анализирую потенциал на противоположном входе ,что бы уменьшить влияние помех .

Рад за вас и ваш алгоритм. Но в моей PRU программе используется не ваш алгоритм.

Как и обещал, проверил на случайном вращении "виртуального энкодера".
Забегая вперёд скажу, что проблем не нашлось. Т.е. программа работает верно.

Иными словами, вращение из любого состояния в любом направлении будет отрабатывать правильно.

10'000'000 импульсов эмулируются за 2-4 секунды.

Собственно, класс "эталонного энкодера". Это тот, который выдаёт эталонные A-B импульсы.


package com.github.vlsi.pru;

import static com.github.vlsi.pru.VirtualAbEncoder.EncoderState. S01;
import static com.github.vlsi.pru.VirtualAbEncoder.EncoderState. S10;
import static com.github.vlsi.pru.VirtualAbEncoder.EncoderState. S11;

public class VirtualAbEncoder {
private final static EncoderState[] ENCODER_STATES = EncoderState.values();

enum EncoderState {
S00,
S01,
S11,
S10,
}

private EncoderState state = EncoderState.S00;
private int count;
private int position;

public boolean getA() {
return state == S10 || state == S11;
}

public boolean getB() {
return state == S01 || state == S11;
}

public void reset() {
state = EncoderState.S00;
count = 0;
position = 0;
}

public void left() {
step(true);
}

public void right() {
step(false);
}

public void step(boolean left) {
count++;
int diff = left ? 1 : -1;
position += diff;
state = getStateByOrdinal(state.ordinal() + diff);
}

private EncoderState getStateByOrdinal(int i) {
int length = ENCODER_STATES.length;
return ENCODER_STATES[(i + length) % length];
}

public int getPosition() {
return position;
}

public int getCount() {
return count;
}
}


Теперь натравливаем рандомное вращение на исходную PRU программу:



@Test
public void drunkEncoder() {
PRU_ABZ_ENCODER_CodeGenerator abz = new PRU_ABZ_ENCODER_CodeGenerator();

Pru cpu = new Pru();
CodeEmitter ce = new CodeEmitter();
abz.accept(ce);
cpu.setCode(ce.visitEnd());

VirtualAbEncoder encoder = new VirtualAbEncoder();

ThreadLocalRandom random = ThreadLocalRandom.current();
for(int i = 0; i < 10_000_000; i++) {
encoder.step(random.nextBoolean());

abz.setA(cpu, encoder.getA() ? 1 : 0);
abz.setB(cpu, encoder.getB() ? 1 : 0);
executeBlock(cpu);
assertEquals(abz.getCounter(cpu), encoder.getCount() & 0xffff, "counter");
assertEquals(abz.getPosition(cpu), encoder.getPosition() & 0xffff, "position");
}
}


Ничего особенного не происходит, всё отрабатывает верно.

[rovki]

Вы попробуйте менять направление вращения случайным и независимым генератором (ГСЧ) , чтобы он попадал в разные моменты и не был синхронизован в выполнением основной программы .Кроме того ,хороший алгоритм должен исходить из того что могут быть высокочастотные помехи ,которые сравнимы по длительности с фронтами и которые сглаживать фильтром нельзя ,что бы не потерять основные импульсы с энкодера при больших скоростях .

[Владимир Ситников]

В общем, если у кого-нибудь есть энкодер -- прошу протестировать программу энкодера (http://www.owen.ru/forum/showthread.php?t=23600&page=11&p=223074&viewfull=1#post223074).
Теоретически, программа должна успешно ловить импульсы вплоть до 1 мкс (~1 МГц)

Казалось бы, зачем нужна ещё одна программа обработки энкодера, если в прошивке ПЛК и так энкодер уже обрабатывается?
Отвечаю: когда PRUграммирование станет доступно для всех, то модуль энкодера уже будет в базовой поставке.

[Владимир Ситников]

Попробовал "облагородить" обмен данными между PRU и основной программой -- столкнулся с тем, что мне не хватает задач.

Ещё есть кандидаты на PRU программы?
Надо кому-нибудь что-нибудь на тему "быстрого управления"?

Поясню, что мне не нравится в моём текущем подходе.
Вот фрагмент программы, которая следит за энкодером и выключает двигатель как только энкодер отсчитает нужное количество импульсов:

26943

Несложно заметить, что обмен данными сделан ассемблерными командами.

ASM
SBCO (* записываем переменную в память *) cutter.state, 3 (* тут всегда 3 *), 60 (* это адрес куда писать *) , 1 (* 1 байт *)
SBCO cutter.offset, 3, 64, 4
SBCO abz.zeroDetected, 3, 68, 1
SBCO abz.position, 3, 72, 2
SBCO abz.counter, 3, 76, 2
END_ASM

На КДС стороне эти данные принимаются по соответствующим адресам


VAR
TMP: DWORD;
END_VAR

PRU_FB_GetParameter(pru_num:=0, index:=15 (* == 60/4 == cutter.state *), value:=ADR(TMP));
PRU_FB_GetParameter(pru_num:=0, index:=16 (* == 64/4 == cutter.offset *), value:=ADR(OFFSET));


Нормально?
Готовы так PRUграммировать?

Мне не нравится, что приходится следить за адресами и соответствием PRU кода и КДС кода.
Хочется чего-то автоматического, чтобы адреса выбирались сами собой, и чтобы КДС обёртка генерировалась одновременно с PRUграммой.
Мне-то подобная работа с памятью ещё более-менее, но, думаю, для обывателя это сложновато.

Моя проблема в том, что пары имеющихся у меня программ маловато, чтобы "обобщить опыт"

Думаю пока в таком направлении: в "основной" PRUграмме отмечаем спец флагом те блоки/переменные, которые нужно передавать между КДС и PRU.

Например, так:
26945

Ключевое слово @Export указывает имя ФБ на КДС стороне и перечень переменных, которые нужно передавать из/в КДС.
В примере выше, Hardella создаст не только PRUграмму, но и КДС блоки PRU_ABZ_ENC/PRU_FAST_INPUTS, входы-выходы которых будут обмениваться с PRU.


Как придумается адекватный подход, можно будет запускать PRUграммирование в массы.

[Scream]

Попробовал "облагородить" обмен данными между PRU и основной программой -- столкнулся с тем, что мне не хватает задач.

Ещё есть кандидаты на PRU программы?
Надо кому-нибудь что-нибудь на тему "быстрого управления"?



Да, я жду плк110 М02, задача стоит в управлении ШД с ускорением и замедлением и обратная связь от энкодера.
Я так понимаю PRU мне как раз должна помочь в этом?
В прошлом году задача решена была на плк160 + драйвер onitex, управление по rs485 (modbus), теперь хочу исключить onitex.
На плк siemens (очень старом и очень давно) эти задачи решались 'мышкой' и работают по сей день, овен не очень хочет видимо делать просто и доступно.

[Newcomer]

А как решен вопрос с утилизацией быстрых дискретных входов в программе PRU для управления ШД, которые в самом ФБ не используются ?

Мне видится такие возможности их использования:
1) подключение двух энкодеров (фазы А, В без нулевой метки);
2) подключение одного энкодера (фазы А, В и нулевая метка) + один свободный вход для других нужд;
3) 4 быстрых входа для других нужд.

Во всех случаях надо предусмотреть фильтрацию входов.

[Владимир Ситников]

Да, я жду плк110 М02, задача стоит в управлении ШД с ускорением и замедлением и обратная связь от энкодера.
Я так понимаю PRU мне как раз должна помочь в этом?

Да, верно. Можно задачу по-подробнее?



В прошлом году задача решена была на плк160 + драйвер onitex, управление по rs485 (modbus), теперь хочу исключить onitex.
Вот смотрите: у вас и так и сяк ОВЕН ПЛК. Какой смысл "париться" ОВЕНу по вопросу PRU, если от этого всё равно не зависит ничего?

[Владимир Ситников]

А как решен вопрос с утилизацией быстрых дискретных входов в программе PRU для управления ШД, которые в самом ФБ не используются ?

Мне видится такие возможности их использования:
1) подключение двух энкодеров (фазы А, В без нулевой метки);
26953


2) подключение одного энкодера (фазы А, В и нулевая метка) + один свободный вход для других нужд;
26951


3) 4 быстрых входа для других нужд.
26952


Во всех случаях надо предусмотреть фильтрацию входов.
Фильтрация, это, наверное, либо параметр ФБ PRU_INPUTS, либо ещё один блок.

[Newcomer]

26953


26951


26952


Фильтрация, это, наверное, либо параметр ФБ PRU_INPUTS, либо ещё один блок.

Фантастика. Все решается быстро и просто. Hardella IDE рулит. ;) А.Приходько и В.Филоненко, а вы что скажите ? Может вам объединить свои усилия с В.Ситниковым ? От этого выиграют все и это главное о чем надо думать.

[Дмитрий Артюховский]

Фантастика. Все решается быстро и просто. Hardella IDE рулит. ;) А.Приходько и В.Филоненко, а вы что скажите ? Может вам объединить свои усилия с В.Ситниковым ? От этого выиграют все и это главное о чем надо думать.

да, но не забывайте, что время реакции на входы будет связано с текущей частотой выдачи импульсов ШД ))

[Владимир Ситников]

да, но не забывайте, что время реакции на входы будет связано с текущей частотой выдачи импульсов ШД ))

Это смотря как программу написать )

Раз уж вы, Дмитрий, Ящик Пандоры раскрыли, то теперь PRUграммирование это дело техники, и вопрос PRU0.prg/pruAccessLib больше не стоит.

[Scream]

Да, верно. Можно задачу по-подробнее?

У нас фасовочный аппарат, объёмное дозирование. Пневмоцилиндр тягает поршень (в котором продукт) и упирается в ограничитель, который и двигает ШД.
Позиция энкодера 0 ~ 3 кг продукта
Позиция энкодера 850 ~ 1.5 кг продукта и т.д.
Мне скорость не так важна как точность, так как цена одного оборота = 3 грамма продукта, ошибся на несколько оборотов = брак
Ускорение и замедление делал как раз для точности.
Машина выдаёт продукт, затем тара попадает на весы и если вес нужно подкорректировать, то ПЛК крутит в нужную сторону ШД на рассчитанное кол-во импульсов, таким образом получаем аппарат розлива с автоматической корректировкой веса.

[Дмитрий Артюховский]

Это смотря как программу написать )

Раз уж вы, Дмитрий, Ящик Пандоры раскрыли, то теперь PRUграммирование это дело техники, и вопрос PRU0.prg/pruAccessLib больше не стоит.

ну, тогда останется только ассемблерный блок уложить в обертку овена и счастливые пользователи получат блоки энкодера и шд в виде картинок FBD )))

[Владимир Ситников]

Машина выдаёт продукт, затем тара попадает на весы и если вес нужно подкорректировать, то ПЛК крутит
Ясно. Буду делать @Export. Вроде, и для вашего случая подходит.

[Филоненко Владислав]

Это смотря как программу написать )

Раз уж вы, Дмитрий, Ящик Пандоры раскрыли, то теперь PRUграммирование это дело техники, и вопрос PRU0.prg/pruAccessLib больше не стоит.

1.Если компилятор не заточен под константное выполнение кода по времени - джиттер всегда будет. И подсчитать время исполнения при всех вариантах входных и промежуточных значениях параметров и переменных (не говоря о проверке корректности исполнения) - задача для компьютера с альфа-центавры. даже 100 бинарных переменных дают 2^100 вариантов. "Подождите, HArdella проводит тестирование кода, осталось 9999 лет 4 месяца 3 дня 5 мкс. Приятного Вам отдыха."
2. Обмен данными не используя механизм pruAccessLib, тем более более 1 регистра за раз - это гарантированные проблемы с реактивностью системы и когерентностью данных в обновляемых структурах.
Крайне трудно отлавливаемые. Это ЖЖ неспроста.
Видимый мною код Владимира об правила синхронизации просто вытирает ноги.

[Владимир Ситников]

Если компилятор не заточен под константное выполнение кода по времени - джиттер всегда будет
Есть рабочая программа ШД.
Там джиттер есть?
Я, конечно, понимаю ваш скептицизм и лень смотреть код/проводить испытания, если "и так видно, что код написан не по правилам". Но, уверяю вас, я не на пустом месте уверен в правильности кода (как минимум в части джиттера), поэтому, пожалуйста, лучше прямо говорите где именно джиттер вы там нашли.
Если джиттер реально найдётся, то поправлю эту ошибку. Но беда в том, что разговоров о джиттерах было много, а на практике их пока в моих программах никто не нашел.

Скоро будет и общедоступный механизм PRUграммирования. Вполне возможно, что это случится уже в этом году.

[Вольд]

Джиттер можно легко рассмотреть на хорошем осциллографе. В.Филоненко, дайте вашим тестировщикам задание капитально проверить ФБ для ШД, разработанный В.Ситниковым, и всем спорам конец. Во многих практических случаях, например при управлении ШД, джиттер не страшен, что и подтвердилось при натурных испытаниях.

В.Филоненко, а когда появится ваш правильный ФБ для управления ШД ?

[Дмитрий Артюховский]

Джиттер можно легко рассмотреть на хорошем осциллографе. В.Филоненко, дайте вашим тестировщикам задание капитально проверить ФБ для ШД, разработанный В.Ситниковым, и всем спорам конец. Во многих практических случаях, например при управлении ШД, джиттер не страшен, что и подтвердилось при натурных испытаниях.

В.Филоненко, а когда появится ваш правильный ФБ для управления ШД ?

а что тут исследовать? Ситников прямо написал что время цикла выполнения зависит от текущей частоты выдачи шага, плюс язык высокого уровня принципиально не будет выравнивать время выполнения разных ветвей алгоритма... исследовать имеет смысл наличие случайной составляющей, а при заявленной принципиальной несовместимости - о чем речь? Поэтому использовать можно все что угодно, но не забывая что там внутри и чем это грозит в случае вроде бы применения в аналогичном случае.

[Владимир Ситников]

дайте вашим тестировщикам задание капитально проверить ФБ для ШД, разработанный В.Ситниковым, и всем спорам конец


а при заявленной принципиальной несовместимости - о чем речь?

Предлагаю на это не отвлекаться. Уже все поняли, что Владислав и Дмитрий считают, что джиттер обязан быть.
Считают -- их право.

Интереснее обсуждать как должно выглядеть "task configuration" в случае PRU.
Есть идеи/предложения?