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

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

Добрый день, коллеги!
Наша команда завершила этап разработки новой технологии для наших ПЛК и готова презентовать её для Вас и пригласить на бета-тестирование.

Все Вы уже знаете, я надеюсь, что у нас появился новый ПЛК 110-хх.
При его разработке мы заложили возможность его использования для управления процессами, требующими высокой скорости и стабильности реакции.
Для этого в ПЛК есть 2(4) быстрых входа и 4 быстрых выхода (которые способны воспринять или сформировать импульсы от 0,5 мкс длительностью) и 2 специализированых сопроцессора, PRU, которые подключены непосредственно к этим I/O и могут обрабатывать данные и управлять отдельно от основного цикла ПЛК.


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

При запуске ПЛК проверяет наличие файла и если он есть, загружает его в ПЛК и запускает выполнение программы.
Для обмена данными между PRU и основным циклом существует специальная библиотека, PruAccessLib.lib и если обмен с основным циклом требуется, то при помощи этой библиотеки и соответствующих ФБ в программе можно его организовать.

Мы подготовили небольшой "стартовый набор".
Для его использования надо его распаковать, перепрошить через заводской загрузчик ПЛК прошивкой M02, загрузить в ПЛК программу для PRU "PRU0.prg", перезапустить ПЛК и загрузить на него тестовую программу login.pro (с учётом модификации ПЛК у Вас).

Дя создания своих программ воспользуйтесь примером simple5.pro, из которого надо экспортировать код программы (project->export->выбрать только PLC_PRG->OK)
При редактировании программы можно использовать только ФБ из библиотеки present_lib.lib

Полученный файл ".exp" необходимо обработать сначала бат-файлом EDIT_PRES.bat. а затем MAKE_PRES.bat. (не забудьте поправить имена файлов)

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

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

Инструкция по работе с заводским загрузчиком:
1. Нежно разберите прибор, получив доступ к верхней плате.
2. Замкните перемычку XP2.
3. Подключите ПЛК кабелем КС14 или КС15 к ПК
4. Отредактируйте номер Com-порта в bat-файле
5. Запустите bat-файл
6. Включите ПЛК
7. Дождитесь завершения прошивки
8. Удалите перемычку XP2
9. Перезапустите ПЛК

[Yegor]

Как и будет ли вообще оно отлаживаться?

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

Как и будет ли вообще оно отлаживаться?
Предполагается симулятор. Сейчас можно попробовать в режиме симуляции Кодесиса, библиотеку я делал с этой возможностью.

[Ser_y]

Поставил прошивку 0.3.42 на ПЛК110.24-30-Р-М (М01)
Встала без проблем только пришлось IP настраивать по новой.
Пока работает без проблем, правда есть одна проблема непонятные показания в модуле статистики.
Он показывает время цикла одинаковое с настройками параметров модуля, при этом время простоя тоже показывает установленное время цикла в параметрах модуля,
пробовал менять параметры модуля, все без изменения. Может данная прошивка не подходит для этого ПЛК?

[Вольд]

Добрый день, коллеги!
Наша команда завершила этап разработки новой технологии для наших ПЛК и готова презентовать её для Вас и пригласить на бета-тестирование.

Все Вы уже знаете, я надеюсь, что у нас появился новый ПЛК 110-хх.
При его разработке мы заложили возможность его использования для управления процессами, требующими высокой скорости и стабильности реакции.
Для этого в ПЛК есть 2(4) быстрых входа и 4 быстрых выхода (которые способны воспринять или сформировать импульсы от 0,5 мкс длительностью) и 2 специализированых сопроцессора, PRU, которые подключены непосредственно к этим I/O и могут обрабатывать данные и управлять отдельно от основного цикла ПЛК.

А какую максимальную частоту импульсов можно будет получить на быстром выходе без ущерба работы основной программы ?

[Newcomer]

Добрый день.

Меня тоже интересует данная тема. Уважаемый В. Филоненко, дайте, пожалуйста, более подробную информацию по использованию новой технологии для обновленного ПЛК110, о которой вы писали в первом посте этой темы. Может уже есть подробное руководство ?

В частности не понятен смысл фрагмента из вашего текст:

Мы подготовили небольшой "стартовый набор".
Для его использования надо его распаковать, перепрошить через заводской загрузчик ПЛК прошивкой M02, загрузить в ПЛК программу для PRU "PRU0.prg", перезапустить ПЛК и загрузить на него тестовую программу login.pro (с учётом модификации ПЛК у Вас).

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

Добрый день.

Мы подготовили небольшой "стартовый набор".
Для его использования надо его распаковать, перепрошить через заводской загрузчик ПЛК прошивкой M02

Когда появилась эта тема - М02 ещё не продавались и чтобы прошить М01-выполнялись нижеописанные действия. Если есть М02 или М01 с прошивкой от
М02 - этого делать уже не надо.

Ну а далее заливаем на ПЛК файл примера и пробуем.
Технология на стадии беты.
А откликов от пользователей нет. Поэтому если Вы не проявите активность (в этой теме) и других - технология так бетой и останется.
Более подробного описания нет, т.к. бета.

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

1. Программы на PRU выполняются отдельно, и никак не влияют на цикл ПЛК и др. функционал.
2. В примере цикл PRU - 1 мкс (0,5МГц частота импульсов), на 1 МГц рассчитывалась схемотехника быстрых I/O.
3. Для примера при цикле 1 мкс можно выполнить приблизительно 20-50 пользовательских лог. блоков (в зависимости от их сложности). Цикл можно менять как в меньшую, так и в большую сторону, в т.ч. динамически.

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

Сама концепция предполагает среду разработки аля OwenLogic - графическое программирование из готовых блоков.
Блоки пишутся на спецассемблере и их создание (потенциально) доступно для системных интеграторов.
Возможности программы (блока), в принципе, ограничены лишь размером кода и ОЗУ, все ресурсы системы доступны, размер кода достаточен для таких вещей как доп. программные UART/SPI, управление приводами, высокоскоростная логика и т.п.

Концепция предполагает жёсткое реальное время с точностью и детерминированностью управления до 1 такта PRU (150МГц) еще на этапе составления программы.

Далее составление программы, её компиляция и загрузка в ПЛК.
В примере как временное решение использована среда разработки CoDeSys (её редактор), однако наработки по OwenLogic планируем использовать в OwenLogicRT.

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

[Newcomer]

Я глянул библиотеку present_lib.lib и насчитал там 17 ФБ для PRU.

Уважаемый В.Филоненко, а нет ли возможности добавить в эту библиотеку ФБ PRU_BLINK ?

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

Мне кажется, если вы доведете до ума эту новую технологию для ПЛК110, то клиентов у фирмы "ОВЕН" станет значительно больше.

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

1. в 110 сильно не хватает модуля "генератор", в идеале заточенного под шаговый двигатель, с разгоном и замедлением. а если их еще будет и пара! )))
2. думаю многим понравится "диммер" с синхронизаций на ноль сети по входу
3. пару раз использовал пропорциональные исполнительные машинки, с 10 мс шим

... а кому позвонить чтобы "записаться" в полубога-системного интегратора? ))

[Newcomer]

Мне нужен такой ФБ для PRU (см вложение).

Генерация импульсов должна начинаться по фронту ENABLE, а заканчиваться либо после формирования заданного количества импульсов, либо если ENABLE перейдет в ноль. READY устанавливается в TRUE по окончанию формирования пачки импульсов и сбрасывается в FALSE по фронту ENABLE.

[Малышев Олег]

TIME - на входе не прокатит
разрешение TIME - миллисекунды
Я бы сделал

Вход DWORD с наносекундами.
И выход x_complete

Для задания пачек импульсов прямо можно сделать последовательность


blik1(enable:=start,....);SR1(s:=blink1.x_compete, r:=blink2.x_complete);
blik2(enable:=SR1.out,...);SR2(s:=blink2.x_compete ,r:=blink3.x_complete);

[Newcomer]

TIME - на входе не прокатит
разрешение TIME - миллисекунды
Я бы сделал

Вход DWORD с наносекундами.
И выход x_complete

Для задания пачек импульсов прямо можно сделать последовательность


blik1(enable:=start,....);SR1(s:=blink1.x_compete, r:=blink2.x_complete);
blik2(enable:=SR1.out,...);SR2(s:=blink2.x_compete ,r:=blink3.x_complete);

Что такое выход x_complete ?

Зачем делать это:

blik1(enable:=start,....);SR1(s:=blink1.x_compete, r:=blink2.x_complete);
blik2(enable:=SR1.out,...);SR2(s:=blink2.x_compete ,r:=blink3.x_complete);


если все может сделать ФБ для PRU.

[Малышев Олег]

А вообще, Влад. Я бы сделал ФБ с управлением ШД - обрати внимание - http://vt-tech.eu/articles/cnc/50-stepper-motors.html

[приборист]

Мне нужен такой ФБ для PRU (см вложение).

Генерация импульсов должна начинаться по фронту ENABLE, а заканчиваться либо после формирования заданного количества импульсов, либо если ENABLE перейдет в ноль. READY устанавливается в TRUE по окончанию формирования пачки импульсов и сбрасывается в FALSE по фронту ENABLE.

Владислав, подскажите - будет ли такой блок?
Нужно управлять двумя сервоприводами.
Хочется попробовать это дело на ПЛК110М02, но нужно быстродействие.

P.S.
Сервопривод HBS2206
В документе написано так:
For reliable response, pulse width should be longer than 2.5uS(200K bandwidth)or 1uS(500K bandwidth)
В данный момент управляется с контроллера Дельта (тот по характеристикам выдает до 200кГц на выходе)
Может пытаться не стоит и ПЛК110 не вытянет?

[приборист]

Все же попробовал запустить сервопривод.
Использовал блок CLK_PULSE от OSCAT.
Если выставлять 2 ms, вращается, но нужно быстрее.
При выставлении 1ms стоит на месте и выход горит (Цикл 1ms, оно и понятно)

При выборе выходов как ШИМ - дрыгается как раненый :)

Попробовал через PRU0:
Программа простая
http://www.owen.ru/forum/attachment.php?attachmentid=24452&stc=1
Думал так - подаем на 1 вход TRUE - имеем генератор на 1 выходе с максимальной частотой
подаем на 4 вход TRUE - просто включаем выход 2.

По итогу - включается выход 3 и выход 4.
Лампочка постоянно горит, подключал к серводвигателю - импульсов нет.

Проверил на CFC в эмуляторе эту схему - импульсы генерируются.
Что я делаю не так?

Кстати в библиотеках лишь два выхода (PRU_OUT1 и PRU_OUT2, которые как оказались соответствуют выходу 3 и 4, куда делись еще два выхода?)
Попробовал использовать PRU_TO_HOST - матюгнулась EDIT_PRES на него и ПЛК уходил в вечный ребут.



unknown ID 0 in PRU_TO_HOST_22 element
PRU_TO_HOST заработал, когда подключил все входы.

[Newcomer]

Владислав, подскажите - будет ли такой блок?
Нужно управлять двумя сервоприводами.
Хочется попробовать это дело на ПЛК110М02, но нужно быстродействие.

P.S.
Сервопривод HBS2206
В документе написано так:
For reliable response, pulse width should be longer than 2.5uS(200K bandwidth)or 1uS(500K bandwidth)
В данный момент управляется с контроллера Дельта (тот по характеристикам выдает до 200кГц на выходе)
Может пытаться не стоит и ПЛК110 не вытянет?

Драйвером ШД собрался управлять от обновленного ПЛК110 ОВЕН ? И какую максимальную частоту собираешься получить ? Как собираешься разгонять ШД ?

[приборист]

Драйвером ШД собрался управлять от обновленного ПЛК110 ОВЕН ? И какую максимальную частоту собираешься получить ? Как собираешься разгонять ШД ?

Я надеялся на ФБ для ШД.
Сейчас подключал через STEP\DIR.
Я так понял можно подключить через CW\CCW и поставить множитель.
Мне точность нужна +- 1-3 см (на расстоянии до 6 метров)
Я думал попробовать на заявленных 100 кГц, но что-то плохо получается ;)
Скорость максимальная тоже не нужна (у драйвера 2 настройки до 200 кГц и до 500 кГц).

Сейчас все реализовано на Delta DVP EH, но мне нравится Codesys :)
Поэтому пока есть на руках драйвер+сервопривод+М02 хотелось бы попробовать.

P.S.
Решил подключить ПЛК110-30 old, и попробовать на hi_timer и уперся в прошивку (в ребут улетает ПЛК)
Пишут нужна 2.10.9, но на сайте её нет для 110-30.
А теперь ПЛК пишет - Выбранный ПЛК не соответствует профилю.
Бубен нужен ко всему....

[Newcomer]

Попробуй через прямое управление быстрыми выходами по прерыванию таймера 20 мкс. Сделай прерывание с периодом 40 мкс, получишь частоту на входе Step драйвера ШД 12,5 кГц. Больше не выжмешь. Если сделать прерывание с периодом 20 мкс, то прерывания будут забивать основную программу. В п/п прерывания считай импульсы. Я так делаю.

Что-то В.Филоненко забыл про свои обещания по PRU.

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

для генерации RTIG не нужен. Просто ANDNOT А затем делитель для получения более низких частот.

P.S. 3 запроса в теме в раз в 3 месяца ну никак не показывают важность и "рыночность" OwenLogicRT и не стимулирует выделять деньги на разработку.

[приборист]

для генерации RTIG не нужен. Просто ANDNOT А затем делитель для получения более низких частот.

P.S. 3 запроса в теме в раз в 3 месяца ну никак не показывают важность и "рыночность" OwenLogicRT и не стимулирует выделять деньги на разработку.

Пример можно?
Я сразу и попробую :)

P.S.
С таким подходом корову вы не продадите.
Все прекрасно знают, что ПЛК ОВЕН не может работать с ШД и с ШИМом тоже проблемы.
Вы изобретаете М02, говорите вот вам до 100 кГц.
Я купил М02, хочу 100 кГц а Вы мне в ответ - спроса нет, результата нет, 100 кГц нет.

И как это называется?

[приборист]

Попробуй через прямое управление быстрыми выходами по прерыванию таймера 20 мкс. Сделай прерывание с периодом 40 мкс, получишь частоту на входе Step драйвера ШД 12,5 кГц. Больше не выжмешь. Если сделать прерывание с периодом 20 мкс, то прерывания будут забивать основную программу. В п/п прерывания считай импульсы. Я так делаю.

На М02?
На старом я попробовал - на 20мкс не работает (прошивка 2.15.8), понизить прошивку до 2.10.9 не могу - ибо нет её на сайте для 110-30.
На этой прошивке - раз залил программу - и подключиться возможности нет, пишет несоответствие таргета.

[Newcomer]

С энкодером на высоких частотах в М02 тоже проблемы. Заявленных 100 кГц и в помине нет.

Во вложении простой пример для ШД. Только вряд ли у тебя ШД закрутится если ты на драйвер сразу подашь 12,5 кГц. Однако попробуй и напиши, что получилось. Вообще ШД надо разгонять по специальному алгоритму.

[приборист]

С энкодером на высоких частотах в М02 тоже проблемы. Заявленных 100 кГц и в помине нет.

Во вложении простой пример для ШД.

ПЛК уходит в ребут.
Изменяем SetIRQ до 60, тогда работает.
Залил в ПЛК - не работает.
Сервопривод стоит, на драйвере задания нет.

[Newcomer]

Импульсы на первом дискретном выходе ПЛК есть ? Надо смотреть куда у вас подключены входы Step, Dir, Enable драйвера.

Что такое задание драйвера ? Не знаю такого понятия.

[Newcomer]

Приборист, что получилось ?

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

С энкодером на высоких частотах в М02 тоже проблемы. Заявленных 100 кГц и в помине нет.

Во вложении простой пример для ШД. Только вряд ли у тебя ШД закрутится если ты на драйвер сразу подашь 12,5 кГц. Однако попробуй и напиши, что получилось. Вообще ШД надо разгонять по специальному алгоритму.
У Вас то энкодер есть, чтобы такое заявлять? Наши тестеры долго пытались заставить энкодер не работать на 100кГц. Не получилось.

[Newcomer]

У Вас то энкодер есть, чтобы такое заявлять? Наши тестеры долго пытались заставить энкодер не работать на 100кГц. Не получилось.

Импульсы 100 кГц может и считаются, но счетчик чаще чем раз в 1 мс (цикл программы) опросить не возможно. А за 1 мс счетчик может насчитать лишних 100 импульсов. Или я не прав ? ;)

[приборист]

Приборист, что получилось ?

Что получилось?
Я повторяю - проблема в прошивке.
Завтра если не забуду - запрошу в саппорте старую прошивку на ПЛК110-30.
И тогда попробую.

[приборист]

У Вас то энкодер есть, чтобы такое заявлять? Наши тестеры долго пытались заставить энкодер не работать на 100кГц. Не получилось.

Владислав, может я чего то не понимаю, но в OwenLogicRT все ФБ работают с BOOL.
Как считать и задавать импульсы?
Откройте уже тайну.

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

не с bool, а с байтами. каждая линия - это байт. Этот режим был выбран как оптимальный для демки.

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

Импульсы 100 кГц может и считаются, но счетчик чаще чем раз в 1 мс (цикл программы) опросить не возможно. А за 1 мс счетчик может насчитать лишних 100 импульсов. Или я не прав ? ;)
Не лишних,а просто 100 импульсов. Дело в требуемой скорости реакции.

[Newcomer]

Не лишних,а просто 100 импульсов. Дело в требуемой скорости реакции.

А вот с реакцией как раз и проблема. Использовать модуль Fast Encoder на частоте 100 кГц не получится. Можно набрать лишних 100 импульсов. Не так ли ?;)

[приборист]

не с bool, а с байтами. каждая линия - это байт. Этот режим был выбран как оптимальный для демки.

Про линии не понял.
Попробовал сделать вот так:
http://www.owen.ru/forum/attachment.php?attachmentid=24489&stc=1
Причем при ust=10 драйвер уходит в ошибку.
При ust=50 очень быстро крутит.
Ну при 255 крутит медленно.

Меня скорость устраивает, буду пробовать из имеющихся блоков придумать что-то и проверить на точность (придется наверное использовать счетчик на входе счетчика, т.к. вход BYTE).

Владислав, а блок PRU_CTU_CONST чем отличается от PRU_CTU?
И почему всего два выхода PRU_OUT1 и PRU_OUT2, которые работают как DO3 и DO4?

[capzap]

Про линии не понял.
Попробовал сделать вот так:
http://www.owen.ru/forum/attachment.php?attachmentid=24489&stc=1
Причем при ust=10 драйвер уходит в ошибку.
При ust=50 очень быстро крутит.
Ну при 255 крутит медленно.

Меня скорость устраивает, буду пробовать из имеющихся блоков придумать что-то и проверить на точность (придется наверное использовать счетчик на входе счетчика, т.к. вход BYTE).

Владислав, а блок PRU_CTU_CONST чем отличается от PRU_CTU?
И почему всего два выхода PRU_OUT1 и PRU_OUT2, которые работают как DO3 и DO4?

дико извиняюсь, а порядок следования блоков здесь не должен быть выставлен или такая задумка специально

[приборист]

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

[Newcomer]

Приборист, какую частоту на входе Step драйвера ШД удалось получить ?

[приборист]

Приборист, какую частоту на входе Step драйвера ШД удалось получить ?

Чем её измерить, я не знаю (кроме осциллографа, которого у меня нет).
Драйвер понимает до 200кГц и до 500кГц (Два режима).
Про ошибки я написал, вечером попробую переключить в 500кГц, может м02 импульсы дает быстрее, чем 200кГц :)

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

Про линии не понял.
Попробовал сделать вот так:
http://www.owen.ru/forum/attachment.php?attachmentid=24489&stc=1
Причем при ust=10 драйвер уходит в ошибку.
При ust=50 очень быстро крутит.
Ну при 255 крутит медленно.

Меня скорость устраивает, буду пробовать из имеющихся блоков придумать что-то и проверить на точность (придется наверное использовать счетчик на входе счетчика, т.к. вход BYTE).

Владислав, а блок PRU_CTU_CONST чем отличается от PRU_CTU?
И почему всего два выхода PRU_OUT1 и PRU_OUT2, которые работают как DO3 и DO4?

PRU_CTU_CONST чем отличается от PRU_CTU - у первого уставка константная, у второго - можно менять с хоста
соответственно различный расход ОЗУ и поведение
У PRU0 всего 2 выхода. остальные 2 на PRU1. И их вот так развели :(

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

дико извиняюсь, а порядок следования блоков здесь не должен быть выставлен или такая задумка специально

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

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

ПЛК в данном режиме при отсутствии деления выдаёт ровно 500кГц.
А поведение при смене порядка не менялось, т.к. данный алгоритм не меняет поведение при смене порядка. А в других случаях возможно.

[приборист]

PRU_CTU_CONST чем отличается от PRU_CTU - у первого уставка константная, у второго - можно менять с хоста
соответственно различный расход ОЗУ и поведение
У PRU0 всего 2 выхода. остальные 2 на PRU1. И их вот так развели :(
Т.е. PRU1 работает с выходом DO1 и DO2
А PRU0 -работает с выходом DO3 и DO4.
Попробую.

По поводу PRU_CTU_CONST
Вход счетчика так же BYTE?
Его каким образом определять?
Простым входом?

Я пытался его привязать к программе, не пропускает MAKE_PRES, ошибку пишет.

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

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

1. Да, обычным входом, байт. В примере, ЕМНИП, был пример задания константы.
2. Памяти, конечно, не 4 гига, но для достаточно комплексной программы хватит, каскадируйте.
Сейчас в демке представлены самые быстрые варианты ФБ на основе регистровой памяти. Т.к. используются байтовые связи (опять же для скорости), то доступно 25*4 связей.
Связь это выход ФБ или внутренняя переменная, как в ФБ RTRIG и CTU, к примеру.
Они тоже доступны как выходы.
Количество задействованной памяти можно посмотреть в промежуточном текстовом файле со связями.
Первые 2 регистра для временных нужд, отсчёт начинается с 2-го.
Логику можно использовать не только TRUE/FALSE, но и байтовые маски и т.п.

[приборист]

1. Да, обычным входом, байт. В примере, ЕМНИП, был пример задания константы.

Я уже разобрался, но правды ради, где?
http://www.owen.ru/forum/attachment.php?attachmentid=24496&stc=1



2. Памяти, конечно, не 4 гига, но для достаточно комплексной программы хватит, каскадируйте.
Сейчас в демке представлены самые быстрые варианты ФБ на основе регистровой памяти. Т.к. используются байтовые связи (опять же для скорости), то доступно 25*4 связей.
Связь это выход ФБ или внутренняя переменная, как в ФБ RTRIG и CTU, к примеру.
Они тоже доступны как выходы.
Количество задействованной памяти можно посмотреть в промежуточном текстовом файле со связями.
Первые 2 регистра для временных нужд, отсчёт начинается с 2-го.

Описания блоков сильно бы помогли.
Как и примеры.



Логику можно использовать не только TRUE/FALSE, но и байтовые маски и т.п.
Как?
Так не работает:
http://www.owen.ru/forum/attachment.php?attachmentid=24497&stc=1
2#0000_0001 тоже не работает.

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

Пример во вложении.
А AND с константами не работает. Этот вариант

[Sulfur]

Как выполнить сброс счетчика? На блоках я вижу только тактовый вход и уставку, входа сброса нет.
И как быть, если мне нужен формат счета DWORD?
Вообще, хотелось бы иметь такую конструкцию:
24530

Возможно ли?

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

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

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

Товарищи, планирую бета-тест новой версии библиотеки ФБ для PRU.
Требуется Ваша помощь в тестировании.
Требования:
1. знание основ схемотехники (отличать OR от AND)
2. некоторое свободное время для тестирования
3. умение описать ошибку

[Вольд]

Товарищи, планирую бета-тест новой версии библиотеки ФБ для PRU.

А что нового появилось в библиотеке ФБ для PRU ?

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

Множество новых ФБ.

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

Как выполнить сброс счетчика? На блоках я вижу только тактовый вход и уставку, входа сброса нет.
И как быть, если мне нужен формат счета DWORD?
Вообще, хотелось бы иметь такую конструкцию:
24530

Возможно ли?

Вот как раз в новой версии (когда дотестирую)...

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

Нужны добровольцы на:
1. Описать работу ФБ
2. Проверить правильность работы на реальном ПЛК
3. Написать код на языке ST в библиотеке, чтобы можно было использовать симуляцию.

[приборист]

Я готов :)
1. http://www.owen.ru/forum/showthread.php?t=22169&p=197840&viewfull=1#post197840
2. Тоже не проблема
3. До конца не ясно, нужен код для ФБ и п.1? Для проверки его на ПЛК?

[Newcomer]

Множество новых ФБ.

А ФБ для управление ШД (http://www.owen.ru/forum/showthread.php?t=22169&page=3&p=197840&viewfull=1#post197840) сделали ?

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

По п.3 - нужен код на ST, чтобы можно было воспользоваться режимом симуляции кодесиса.
Это сложная задача, требуется реверс-инжиниринг кода с ассемблера в ST.

Все добровольцы присылайте на почту мне свои координаты. plc_prog@owen.ru
На следующей неделе разошлю пакет для тестирования.

Если кто-то видит в себе силы в программировании кода ФБ (ассемблер, машинные коды, метаязык), могут попробовать написать свой ФБ под свои задачи. Укажите это в данных, я пришлю вам расширенный инструментарий

У меня свободного времени практически нет для написания сложных ФБ.

[приборист]

Добрый день!
Подскажите - работы остановились?
Жду библиотеку для ШД.

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

Добрый день!
Подскажите - работы остановились?
Интересно, а есть кто-то кроме меня (ну, кроме сотрудников ОВЕН), кто "работает над PRU"?

0) До августа Владислав в отпуске. Всего неделя осталась. Будем держаться.

Не знаю как у других, а у меня так: я вторую неделю жду договор от юристов Овен. Кирилл Валюнин предупредил, что это дело небыстрое, и, надеюсь, про меня не забыли (а, возможно, ждут Владислава).

1) Владислав прислал пакет с "pru beta 2", но там снова только BOOL функции. Т.е. блоков для работы с INT/WORD нет.
2) В присланных материалах не было инструмента, который позволял бы создавать свои ФБ. Как раз тут ждём юристов.

Мой план пока прежний -- сделать поддержку PRU в Hardella IDE (https://github.com/vlsi/ide61131).


Жду библиотеку для ШД.
А вот можно по-подробнее о том, какие именно функции нужны?
Я видел #30 (http://www.owen.ru/forum/showthread.php?t=22169&p=197840&viewfull=1#post197840) "Генерация импульсов должна начинаться по фронту ENABLE, а заканчиваться либо после формирования заданного количества импульсов, либо если ENABLE перейдет в ноль. READY устанавливается в TRUE по окончанию формирования пачки импульсов и сбрасывается в FALSE по фронту ENABLE..."
Это всё или нужно ещё что-то?

[приборист]

А вот можно по-подробнее о том, какие именно функции нужны?
Я видел #30 (http://www.owen.ru/forum/showthread.php?t=22169&p=197840&viewfull=1#post197840) "Генерация импульсов должна начинаться по фронту ENABLE, а заканчиваться либо после формирования заданного количества импульсов, либо если ENABLE перейдет в ноль. READY устанавливается в TRUE по окончанию формирования пачки импульсов и сбрасывается в FALSE по фронту ENABLE..."
Это всё или нужно ещё что-то?

+ нужно изменять частоту импульсов.

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

Появилась минутка, сделал блок на ST.
Получается, для генерации следующей пачки импульсов нужно передёрнуть вход enable (сделать enable==false, дождаться пока ready перейдёт в false, потом передать enable=true и тогда пойдёт вторая пачка). Это то, что ожидалось?

По поводу изменения частоты импульсов: текущий подход к программированию PRU предполагает, что PRU выполняется своим циклом, поэтому тут я сделал "переключение сигнала out при каждом цикле PRU". Норм? Или делитель какой-то нужен?
Или с такой стороны: нормально ли, если для изменения частоты меандра нужно перезаливать PRU программу?
Нужны ли меандры разной частоты по разным выходам?




FUNCTION_BLOCK PRU_GENER_BURST
VAR_INPUT
enable : BOOL;
quantity : WORD;
END_VAR
VAR_OUTPUT
out : BOOL;
ready : BOOL;
END_VAR
VAR
qtyLeft : WORD;
END_VAR
IF enable THEN
IF qtyLeft > 0 THEN
(* Идёт генерация *)
qtyLeft := qtyLeft - 1;
ELSIF ready THEN
(* Всё сгенерировали, ждём пока передёрнут enable для следующего включения *)
ELSE
(* Поступила команда на включение *)
qtyLeft := quantity * 2;
END_IF;
ELSE
(* Выключаемся *)
qtyLeft := 0;
END_IF;
ready := qtyLeft = 0;
(* Если всё сделали, то out выключится. Если пачка ещё генерируется, то младший бит и есть меандр *)
out := qtyLeft.0;

END_FUNCTION_BLOCK

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

Цикл можно менять, в т.ч. и на ходу, для этого предполагается использовать семейство FB START, START_CONST и START_VAR
Если же период генерации на порядки больше цикла PRU - нужен внешний делитель сигнала тактирования

[Валенок]

Появилась минутка, сделал блок на ST...


FUNCTION_BLOCK PRU_GENER_BURST
VAR_INPUT
enable : BOOL;
quantity : WORD;
END_VAR
VAR_OUTPUT
out : BOOL;
ready : BOOL;
END_VAR
....
1.Отчего то кажется что нехватает period'а
2.А почему низзя изменить quantity пряма на ходу ?
"А куда миня ?" - "В морг"
"А может на процедуры ?" - "Врач сказал в морг, значит в морг"

[Newcomer]

Появилась минутка, сделал блок на ST.
Получается, для генерации следующей пачки импульсов нужно передёрнуть вход enable (сделать enable==false, дождаться пока ready перейдёт в false, потом передать enable=true и тогда пойдёт вторая пачка). Это то, что ожидалось?

По поводу изменения частоты импульсов: текущий подход к программированию PRU предполагает, что PRU выполняется своим циклом, поэтому тут я сделал "переключение сигнала out при каждом цикле PRU". Норм? Или делитель какой-то нужен?
Или с такой стороны: нормально ли, если для изменения частоты меандра нужно перезаливать PRU программу?
Нужны ли меандры разной частоты по разным выходам?


1. Для генерации следующей пачки импульсов нужно вход Enable перевести в false, при этом Ready автоматически должен сброситься в false.
2. Для изменения частоты меандра перезаливать PRU программу конечно не надо, должна быть возможность оперативной смены частоты по входу PERIOD.

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

"А куда миня ?" - "В морг"
"А может на процедуры ?" - "Врач сказал в морг, значит в морг"

В общем, ждём что скажет Владислав.

Собственно, 2 вопроса:
1) Норм ли получился блок (я в почте переслал реализацию на ассемблере)
2) Можно ли мне выкладывать обновлённые библиотеки, или это только через ОВЕН

Я снова в командировках -- пишу "по приборам", вернее, без ПЛК.
Поэтому было бы хорошо, если бы
3) Кто-нибудь попробовал этот самый блок PRU_GENER_BURST
4) Рассказали как тестировать, если в хозяйстве из быстродействующего только ПЛК110 1шт и есть. Осциллографа у меня нет, мультиметра тоже нет, "населена роботами (https://www.youtube.com/watch?v=VtHlgAMEmR0)".
Замыкать быстрый вход на быстрый выход и делать программу, которая сама себя проверяет?
Либо, опять же, нужно чтобы какой-нибудь обладатель "быстрого счётчика импульсов" проверил.

[Вольд]

Сколько стоит "хороший осциллограф" если "без фанатизма"?
В 10'000 р уложится?

Можно наводку какую-нибудь? (ну, я вообще не в теме выбора этих приборов)

Нужен аналоговый осциллограф с полосой пропускания не ниже 50 мГц. За 10 т.р. такой не купить. Проще взять где-нибудь на время. Приличный цифровой осциллограф стоит 20...30 т.р.

[Вольд]

Появилась минутка, сделал блок на ST.

Код для PRU можно писать на ST ?

[Вольд]

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

С щупом для осциллографа все просто. Бери щуп с делителем 1:10.

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

Код для PRU можно писать на ST ?

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

Но
1) ST код нужен и для общего понимания, и для того, чтобы в КДС эмуляция работала
2) Переводить ST на ассемблер проще, чем сразу писать на asm

Примерно так (я исключил половину строк-комментариев, которые нужны для связки PRU-КДС. Привет Владиславу, если можно со спец комментариями выкладывать, то могу и с ними):

.origin 0
.entrypoint __INIT_PROGRAM
;include "standart_classes.m"
#include "Defs.h"

#define enableIn R1.b0
#define quantityIn R1.w0

#define out R1.b0
#define readyOut R1.b0
#define qtyLeft R1.w0


;FB_WORKTIME=9
;FB_NAME=PRU_GENER_BURST


__INIT_PROGRAM:
QBEQ _NEED_STOP, enableIn, 0 //% если сказали выключатьс_, идём выключатьс_
QBEQ _BURST_DONE, qtyLeft, 0 //% если импульсы кончились, идём ждать передёргивани_ enable
SUB qtyLeft, qtyLeft, 1 //% минус импульс
QBA _FINISH_5TICK //%

_BURST_DONE: ; 3-ий такт
QBEQ _FINISH_4TICK, readyOut, 1 //% пока ready не сбросилось, ждём передёргивани_ enable
LSL qtyLeft, quantityIn, 1 //% qtyLeft := quantity * 2
QBA _FINISH_6TICK //%

_NEED_STOP: ; 2-ой такт
LDI qtyLeft, 0 //% останавливаемс_ -- обнул_ем qtyLeft

_FINISH_3TICK: ; 3ий такт
ADD temp, temp, 0 //% NOP

_FINISH_4TICK: ; 4ый такт
ADD temp, temp, 0 //% NOP

_FINISH_5TICK: ; 5ый такт
ADD temp, temp, 0 //% NOP

_FINISH_6TICK: ; 6ый такт
MIN temp.w0, qtyLeft, 1 //% Смотрим, осталось ли что генерировать
XOR readyOut, temp.b0, 0 //% readyOut := MIN(qtyLeft, 1) XOR 1 == qtyLeft = 0
ADD temp.w0, qtyLeft, 0 //% загружаем qtyLeft в регистр, чтобы потом считать младший бит
AND out, temp.b0, 1 //% out := qtyLeft.0

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

Пока ПЛК нет под рукой, решил сделать нехитрый компилятор ST -> PRU.asm.
Так что, +100500 к скорости написания PRU блоков.

Вот так выглядит:
26068

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

Сделал ещё "1 процент": эмулятор PRU процессора.
Останется его скрестить со средой разработки PRU программ, и можно без ПЛК отлаживаться.

https://github.com/vlsi/pru-emulator/blob/master/src/test/java/com/github/vlsi/pru/CpuEmulatorTest.java#L50

[Newcomer]

Появилась минутка, сделал блок на ST.
Получается, для генерации следующей пачки импульсов нужно передёрнуть вход enable (сделать enable==false, дождаться пока ready перейдёт в false, потом передать enable=true и тогда пойдёт вторая пачка). Это то, что ожидалось?

По поводу изменения частоты импульсов: текущий подход к программированию PRU предполагает, что PRU выполняется своим циклом, поэтому тут я сделал "переключение сигнала out при каждом цикле PRU". Норм? Или делитель какой-то нужен?
Или с такой стороны: нормально ли, если для изменения частоты меандра нужно перезаливать PRU программу?
Нужны ли меандры разной частоты по разным выходам?




FUNCTION_BLOCK PRU_GENER_BURST
VAR_INPUT
enable : BOOL;
quantity : WORD;
END_VAR
VAR_OUTPUT
out : BOOL;
ready : BOOL;
END_VAR
VAR
qtyLeft : WORD;
END_VAR
IF enable THEN
IF qtyLeft > 0 THEN
(* Идёт генерация *)
qtyLeft := qtyLeft - 1;
ELSIF ready THEN
(* Всё сгенерировали, ждём пока передёрнут enable для следующего включения *)
ELSE
(* Поступила команда на включение *)
qtyLeft := quantity * 2;
END_IF;
ELSE
(* Выключаемся *)
qtyLeft := 0;
END_IF;
ready := qtyLeft = 0;
(* Если всё сделали, то out выключится. Если пачка ещё генерируется, то младший бит и есть меандр *)
out := qtyLeft.0;

END_FUNCTION_BLOCK


Кажется скоро появится первый приличный ФБ для управления ШД. Если все получится, то следующим шагом, по моему, должно быть разработка более продвинутого ФБ. Я имею ввиду ФБ, в котором осуществляется плавный разгон и торможение ШД. Это реализовано во всех буржуйских ПЛК, которые управляют ШД. Вот ссылка на статью, в которой изложен этот вопрос: http://electroprivod.ru/akseleration.htm

[Newcomer]

Скоро vladimirisitnikov закончит разработку ФБ для управления ШД. Было бы не плохо если фирма "ОВЕН" профинансирует изготовления стенда для натурных испытаний системы управления ШД на базе ПЛК110 М02. Кроме ПЛК понадобятся ШД, драйвер ШД, источник питания на 36 или 48 вольт. Затраты небольшие. Схему электрическую принципиальную + перечень элементов могу представить.

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

Посмотрел-покрутил имеющиеся PRU блоки, и сделал свой компилятор.
В имеющихся блоках мне не понравилось то, что для одного только сложения нужна куча _разных_ блоков: "сложение BYTE+BYTE, WORD+BYTE, WORD+WORD". Но это ещё не всё, ведь, для сложения двух переменных и сложения переменной с константой тоже разные блоки нужны (http://www.owen.ru/forum/showthread.php?t=22169&page=8&p=209411&viewfull=1#post209411). На мой взгляд, это слишком сложно. Если сложение, то должен быть просто блок сложения.

Описывать в своей среде разновидности "PRU_ADD", "PRU_ADD_CONST", "PRU_ADD_BYTE_CONST" и правила выбора это была бы та ещё песня.

Понятно, что какие-то блоки всё равно проще на ассемблере писать (например, чтение входов-выходов, работа с host), поэтому сделал ассемблерные вставки в ST.

Всё нижеупомянутое получается одной кнопкой, без привлечения bat файлов, exe файлов и т.п.

Собственно, до сборки финального PRU0.prg (файла, который заливается в ПЛК) осталось сделать обработку ассемблерных инструкций работы с памятью: LBCO/SBCO и LBBO/SBBO. Там ничего сложного нет, просто нужно немного времени.

Пример программы:
26227

Вот промежуточный ассемблер.
Тут особенность, что команда QBLT label, src, 42 означает "branch to label if 42 < src" (по крайней мере, так говорится в документации на процессор)

26228

PRU, разумеется, с переменными работать не умеет, поэтому назначаем регистры.
26229

И превращаем в java код (ну, чтобы генерировать файл для заливки в ПЛК и/или запускать эмулятор PRU)
26230


Вот, например, блок чтения 1-го входа. Описали 1 раз -- и уже можно использовать в программе.
Присмотрелся -- тут ошибка. Должно, конечно, быть LSR Q, R31.dw, 21 (регистр b0 байтовый и в нём никак 21 бит не влезет). Но сама ошибка не влияет на суть (лень картинки переделывать)
26226


Попробуем что-нибудь посложнее.

Напишем на ST PRU_CTU_WORD (ну, как в стандарте 61131 через RTRIG):
26220

И сделаем цикл, в котором подаём IN1 на вход CTU и младшие 2 бита счётчика выводим на OUT1 и OUT2.
26221

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

Из интересного:
1) Видно, что распределитель регистров (liveness analysis + linear scan register allocation) догадался переиспользовал регистр R1.b3 по ходу программы. Например, в самом конце где записываются OUT1 и OUT2 видно, что сам записываемый бит хранится как раз в R1.b3.

2) Особых оптимизаций сейчас нет. Например, a:=b; может приводить к выделению временного регистра для a (это видно на "бесполезной" команде в начале вызова RTRIG: ADD R2.b0, R1.b3, 0). Но если уж нужны будут оптимизации -- посмотрим потом. Как-никак, а SSA (я про Static single assignment form) за 1-2 дня не сделать.

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

PRU0.prg и PRU1.prg это файлы программ PRU. И да, они, по расширению, совпадают с prg 2-го КоДеСис-а.
prg отлично формируются уже представленным ПО из имеющихся или заново создаваемых ФБ.

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

prg отлично формируются уже представленным ПО из имеющихся или заново создаваемых ФБ.

Проблема в "уже представленном ПО" в том, что для задействования "уже представленного" нужно:
1) Создать схему программы в КДС (неудобно) или в формате КДС_CFC.exp (не реализовано)
2) Очень внимательно следить за использованием ADD vs ADD_CONST vs ADD_WORD_CONST. Вот тут "представленное ПО" крайне тяжело ложится на IDE. Сделать, конечно, всё можно, но я никак не хочу делать 100500 copy-paste'ов, описывающих разновидности ADD/SUB и т.п.

Вот фрагмент моего компилятора, описывающий команды "a := b OP c", где OP это сложение, вычитание и т.п:
26249

26251

И ещё пара блоков (Instruction здесь это объект, описывающий ассемблерную команду. Например, XOR, AND выше это и есть Instruction с аргументами), которые превращают "ассемблер" в нужные вызовы Java:
26250

Тут нет никакого взрыва комбинаций "ADD vs ADD_CONST vs ADD_WORD_CONST".
Вышеупомянутый код без проблем компилирует сложение BYTE/WORD/DWORD.
Конечно, мне хотелось бы уйти от unsigned типов, но я уж лучше сначала сделаю рабочий блок ШД, а заниматься знаковыми типами и т.п. потом.



"Компилировать в формат КДС_CFC.exp" неудобно. Да и у меня нет никакого желания откладывать "обкатку блока ШД" до момента, как я научусь генерировать КДС_CFC.exp формат.

Объективно:
1) Компилировать в бинарный формат PRU я могу уже сейчас. Как-никак, а команды, которые выполняет PRU процессор гораздо ближе к ST, чем к графическому языку
2) Компилировать графический язык в ST гораздо проще, чем наоборот. Поэтому, вариант развития "сначала сделать ST -> PRU0.prg компилятор", потом добавить "графический -> ST" выглядит более понятным и позволит не ждать 2018-го года до первого тестирования ШД.
2) Компилировать в формат КДС диаграмм (из ST или из графического языка -- не так важно) только ради того, чтобы использовать "уже представленное ПО" выглядит как отвлекающей задачей, занимающей много времени без видимого результата. Гораздо проще вызвать команду процессора "условный переход", чем превращать разные ветки в CFC.
3) Некоторые блоки становятся ненужными, если компилировать программу целиком. Например, один и тот же код блока CTU_BYTE будет работать как в случае, когда на вход поступает константа, так и в случае, когда на вход переменная. Сам компилятор выберет необходимую команду процессора, и расход регистров/памяти будет зависеть не от имени блока, а от его фактического использования.
И пользователю просто: не нужно задумываться о множестве однотипных блоков, и при написании этого множества блоков не будет copy-paste ошибок.

Поэтому, у меня возник вопрос: "а что, если PRU0.prg генерировать непосредственно из бинарного кода PRU?"

Собственно, вопрос: действительно ли "задействование уже предоставленного ПО" это единственно возможный вариант создания PRU0.prg?
Действительно ли, формат PRU0.prg засекречен, и создание его внешними инструментами недопустимо?

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

Раз PRU0.prg нет, то будем тестировать блок ШД на эмуляторе.

"enable" будем подавать через "fast IN1", а параметры "количество импульсов" и "частоту импульсов" будем подавать через память PRU.

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

Попробую "проверенный" способ: кто-нибудь может пошевелить/поспрашивать ОВЕН на предмет возможности генерации PRU0.prg/PRU1.prg файлов из внешних программ?

Собственно, программа обрабатывающая блок ЩД:
26283

Ничего хитрого.
Из нового -- блок WAIT_TICK, который делает так, чтобы наш блок ШД вызывался не чаще, чем указанный интервал.
LBCO -- команды, загружающие значения из "памяти PRU" в регистр. В эмуляторе берём и "пишем напрямую в память (https://github.com/vlsi/pru-emulator/blob/3da473091c3281959437da6de4afc751e68771df/src/test/java/com/github/vlsi/pru/BurstGeneratorTest.java#L182-L183)". Возможно, HOST_TO_PRU/PRU_TO_HOST немного по-другому будут работать, но на суть это не влияет.

В самом блоке WAIT_TICK использован метод УКП (универсального коэффициента подгона):
26284

Выглядит жутковато, но тесты проходит: https://github.com/vlsi/pru-emulator/blob/3da473091c3281959437da6de4afc751e68771df/src/test/java/com/github/vlsi/pru/CycleWaitBlockTest.java

В тестах проверяется, что "полезная работа" стартует ровно раз в заданное время в комбинациях "cycleTime от 20 до 100" и "длительность тела цикла от 0 до 5".


Собственно берём наш блок ШД и начинаем его испытывать. Заранее скажу, что предыдущая версия блока оказалась неправильной.
Вот исправления, после которых блок начал проходить тесты:

26285


Начинаем с одного импульса и задержки в "35 тактов", и затем после каждой пачки увеличиваем количество импульсов на 1 и длительность тоже на 1.

Т.е. сначала должен получиться 1 импульс длины 35, затем 2 импульса по 36, затем 3 импульса по 37 и так далее.

Для большего разнообразия, вход enable будем активировать после случайной задержки (https://github.com/vlsi/pru-emulator/blob/3da473091c3281959437da6de4afc751e68771df/src/test/java/com/github/vlsi/pru/BurstGeneratorTest.java#L95). Так сказать, попробуем застать блок ШД врасплох.


Собственно, результаты теста. Тут через _/‾ и ‾\_ схематично изображены фронты out сигнала.
_/‾33‾\_ означает, что на выходе out была единица 33 такта.
‾\_36_/‾ означает, что на выходе был ноль 36 тактов.

Самая первая цифра -- это задержка от перевода enable в true до фронта out (т.е. задержка того, пока цикл PRU докрутится и запустит генерацию).
Цифра в пределах ожидаемого

cycle: 35, quantity: 1. _15_/‾33‾\_
cycle: 36, quantity: 2. _46_/‾34‾\_36_/‾36‾\_
cycle: 37, quantity: 3. _27_/‾35‾\_37_/‾37‾\_37_/‾37‾\_
cycle: 38, quantity: 4. _22_/‾36‾\_38_/‾38‾\_38_/‾38‾\_38_/‾38‾\_
cycle: 39, quantity: 5. _30_/‾37‾\_39_/‾39‾\_39_/‾39‾\_39_/‾39‾\_39_/‾39‾\_
cycle: 40, quantity: 6. _17_/‾38‾\_40_/‾40‾\_40_/‾40‾\_40_/‾40‾\_40_/‾40‾\_40_/‾40‾\_
cycle: 41, quantity: 7. _26_/‾39‾\_41_/‾41‾\_41_/‾41‾\_41_/‾41‾\_41_/‾41‾\_41_/‾41‾\_41_/‾41‾\_
cycle: 42, quantity: 8. _48_/‾40‾\_42_/‾42‾\_42_/‾42‾\_42_/‾42‾\_42_/‾42‾\_42_/‾42‾\_42_/‾42‾\_42_/‾42‾\_
cycle: 43, quantity: 9. _50_/‾41‾\_43_/‾43‾\_43_/‾43‾\_43_/‾43‾\_43_/‾43‾\_43_/‾43‾\_43_/‾43‾\_43_/‾43‾\_43_/‾43‾\_
cycle: 44, quantity: 10. _14_/‾42‾\_44_/‾44‾\_44_/‾44‾\_44_/‾44‾\_44_/‾44‾\_44_/‾44‾\_44_/‾44‾\_44_/‾44‾\_44_/‾44‾\_44_/‾44‾\_
cycle: 45, quantity: 11. _38_/‾43‾\_45_/‾45‾\_45_/‾45‾\_45_/‾45‾\_45_/‾45‾\_45_/‾45‾\_45_/‾45‾\_45_/‾45‾\_45_/‾45‾\_45_/‾45‾\_45_/‾45‾\_
cycle: 46, quantity: 12. _20_/‾44‾\_46_/‾46‾\_46_/‾46‾\_46_/‾46‾\_46_/‾46‾\_46_/‾46‾\_46_/‾46‾\_46_/‾46‾\_46_/‾46‾\_46_/‾46‾\_46_/‾46‾\_46_/‾46‾\_

Если присмотреться, то можно заметить, что длина первого импульса почему-то на 2 такта меньше, чем заданная длительность.
Можно, конечно, раскуривать ассемблер и смотреть где там стоит добавить-убрать такт, но нужно ли? Кого реально парят 2 такта?

Минимально стабильная длина цикла для этой программы составляет 33 такта.
Частота PRU где-то 150-200 МГц, т.е. за одну микросекунду PRU выполняет ~200 команд.
Иными словами, данная программа может генерировать пачки импульсов частоты до 1МГц (выходы вряд ли смогут такое, но не суть).


PS Вот так на ассемблере выглядит финальная программа (на один экран не вместилось, поэтому 3 картинки):
26286
26287
26288

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

Не пойму это ваш редактор для чего, для ПЛК что ли или это альтернатива cds?

У меня как дополнение к CDS, так и альтернатива.
С одной стороны, моя среда может генерировать КДС проект (это в случае управления простыми, "медленными" выходами), а с другой, она может генерировать бинарный код для TI PRU процессора (ну, того, что используется в ПЛК110 М02) -- т.е. можно писать программы для быстрых входов/выходов.



В тему про управление фазами. На досуге делаю самодельный ПЧ для своих нужд на микрокантроллере мучую движок пишу на С, что можете предложить про плавный разгон и управление движком однофазным.

Вижу, что вы пытались в ответе написать какой-то код: < spf; i++){delay_us(50);}
Можете поправить ответ, чтобы код стало видно?


Вообще говоря, на PRU нет операций деления и, соответственно, квадратного корня, но есть память.
Поэтому, рабочий подход -- рассчитать табличку ускорений и работать по ней.

Доступ к памяти стоит 2-3 такта, т.е. в процессе управления можно просто читать очередную задержку и всё.

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

Вот, похоже, разумные стати по теме ШД: http://www.embedded.com/design/mcus-processors-and-socs/4006438/Generate-stepper-motor-speed-profiles-in-real-time, http://www.atmel.com/images/doc8017.pdf, https://courses.cs.washington.edu/courses/cse467/08au/pdfs/lectures/11-FixedPointArithmetic.pdf, http://www.orientalmotor.com/products/pdfs/2012-2013/G/usa_tech_calculation.pdf

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

Если задержку делать непосредственно перед записью выходов, то длительности импульсов получаются вообще ровными:
26299

Результат:

cycle: 33, quantity: 2. _56_/‾33‾\_33_/‾33‾\_
cycle: 34, quantity: 3. _24_/‾34‾\_34_/‾34‾\_34_/‾34‾\_
cycle: 35, quantity: 4. _41_/‾35‾\_35_/‾35‾\_35_/‾35‾\_35_/‾35‾\_
cycle: 36, quantity: 5. _47_/‾36‾\_36_/‾36‾\_36_/‾36‾\_36_/‾36‾\_36_/‾36‾\_
cycle: 37, quantity: 6. _43_/‾37‾\_37_/‾37‾\_37_/‾37‾\_37_/‾37‾\_37_/‾37‾\_37_/‾37‾\_
cycle: 38, quantity: 7. _39_/‾38‾\_38_/‾38‾\_38_/‾38‾\_38_/‾38‾\_38_/‾38‾\_38_/‾38‾\_38_/‾38‾\_
cycle: 39, quantity: 8. _55_/‾39‾\_39_/‾39‾\_39_/‾39‾\_39_/‾39‾\_39_/‾39‾\_39_/‾39‾\_39_/‾39‾\_39_/‾39‾\_
cycle: 40, quantity: 9. _46_/‾40‾\_40_/‾40‾\_40_/‾40‾\_40_/‾40‾\_40_/‾40‾\_40_/‾40‾\_40_/‾40‾\_40_/‾40‾\_40_/‾40‾\_
cycle: 41, quantity: 10. _51_/‾41‾\_41_/‾41‾\_41_/‾41‾\_41_/‾41‾\_41_/‾41‾\_41_/‾41‾\_41_/‾41‾\_41_/‾41‾\_41_/‾41‾\_41_/‾41‾\_
cycle: 42, quantity: 11. _54_/‾42‾\_42_/‾42‾\_42_/‾42‾\_42_/‾42‾\_42_/‾42‾\_42_/‾42‾\_42_/‾42‾\_42_/‾42‾\_42_/‾42‾\_42_/‾42‾\_42_/‾42‾\_
cycle: 43, quantity: 12. _51_/‾43‾\_43_/‾43‾\_43_/‾43‾\_43_/‾43‾\_43_/‾43‾\_43_/‾43‾\_43_/‾43‾\_43_/‾43‾\_43_/‾43‾\_43_/‾43‾\_43_/‾43‾\_43_/‾43‾\_
cycle: 44, quantity: 13. _52_/‾44‾\_44_/‾44‾\_44_/‾44‾\_44_/‾44‾\_44_/‾44‾\_44_/‾44‾\_44_/‾44‾\_44_/‾44‾\_44_/‾44‾\_44_/‾44‾\_44_/‾44‾\_

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

Я имею ввиду ФБ, в котором осуществляется плавный разгон и торможение ШД

Нашёл пример Amtel'а.
Статья: http://www.atmel.com/images/doc8017.pdf (вариант на русском, который, кстати, более подробный: http://avrdoc.narod.ru/index/0-7 )
Код (MIT license == проблем нет): https://code.google.com/archive/p/stepper-motor-controller/

Собственно, нужный код рассчёта задержек между импульсами: https://github.com/rob-smallshire/stepper-motor-controller/blob/master/%20stepper-motor-controller%20--username%20plastiv%40gmail.com/code/speed_cntr.c#L77-L127

Там они, кстати, памятью не пользуются, а просто на каждом шаге вычисляют длительность очередного импульса (https://github.com/rob-smallshire/stepper-motor-controller/blob/master/%20stepper-motor-controller%20--username%20plastiv%40gmail.com/code/speed_cntr.c#L190).

По моим прикидкам, подобные вычисления будут занимать 300 тактов, т.е. порядка 2 мкс.
Собственно, вопрос: есть ли смысл заморачиваться с памятью и предвычислением, или достаточно, если минимальный импульс будет 3-4 мкс?

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

Не понятно поведение специалистов фирмы "ОВЕН". vladimirisitnikov делает интересные, я бы даже сказал, революционные предложения. А в ответ тишина. Не говорят ни да ни нет. Владислав Филоненко, вы ведущий специалист. Может вы все таки обозначите свою позицию по тому что предлагает vladimirisitnikov.

Может будет лучше дать vladimirisitnikov полный Carte blanche (полная свобода действий) и он махом разгребет все ваши мнимые и истинные проблемы.
И будет всем нам счастье. ;)

Свежо предание, но:
Писал Владимиру, напишу и тут. Почему мы резко против компиляции из "ST".

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

Это ненадёжно. А значит такое решение нельзя использовать в промышленности, т.к. в результате отказа (а кто за него отвечать будет?) возможны последствия.

С другой стороны, линкер (генератор prg), работающий с набором простых ФБ (с полиморфизмом, уже поддерживается), редактор (пока есть простой от 3S), поддерживающий полиморфизм и ассемблер от TI не теряют в производительности, не имеют скрытых проблем при компиляции сложного взаимосвязанного кода и визуально гораздо удобнее для разработки ПО, чем написание на ST.

Тестирование каждого отдельного ФБ просто в силу их простоты.

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

Тем более, что ST не позволяет без ассемблерных вставок работать с периферией и особыми функциями PRU.

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

Однако, использование компилятора (а точнее транслятора на ASM) с "ST" для генерации кода отдельных ФБ перспективно. Но для генерации кода всей программы – см. вышеописанные проблемы.

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

По поводу ускорений и торможений для блока ШД.
Все эти расчёты, по идее, должны производится основным процессором ПЛК и таблица "команд" загружаться в ФБ ШД.
Иначе PRU будет выполнять ненужную в цикле реального времени работу, что будет тормозить остальные процессы управления.

[Newcomer]

По поводу ускорений и торможений для блока ШД.
Все эти расчёты, по идее, должны производится основным процессором ПЛК и таблица "команд" загружаться в ФБ ШД.
Иначе PRU будет выполнять ненужную в цикле реального времени работу, что будет тормозить остальные процессы управления.

В буржуйских ПЛК в основной программе никаких расчетов по разгону и торможению делать не надо, все делает ФБ.

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

[I][B]Свежо предание, но:
Писал Владимиру, напишу и тут. Почему мы резко против компиляции из "ST"

Вот тут: http://www.owen.ru/forum/showthread.php?t=22169&page=15&p=219796&viewfull=1#post219796 я развёрнуто рассказал, почему текущий инструментарий для создания ФБ PRU неудобен. Скажу честно, я не думал, что так скоро перейду к написанию компилятора и эмулятора процессора. Честное слово, считал, что для "нехитрого" блока ШД мне хватит мозгов написать на ассемблере. Оказалось, что просто глазами отлаживать тяжело. Более того ни в коде на ассемблере, ни в коде на ST никто ошибку не увидел. Всё-таки, без автоматических тестов никуда.


Имеющийся подход не просто неудобен, а неудобен настолько, что мне проще сделать заново (у учётом того, что наработки по Hardella IDE уже были).

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

Я просто говорю, что, в текущих реалиях, доработка Hardella IDE (https://github.com/vlsi/ide61131) для компиляции ST -> PRU ASM оказывается быстрее, и надёжнее.

И это не просто слова, а результат опыта.
1) Я изучил инструмент. Не просто посмотрел одним глазом, а сделал вручную блок ШД на ассемблере. (http://www.owen.ru/forum/showthread.php?t=22169&page=13&p=218704&viewfull=1#post218704) Делал в текстовом редакторе и попутно много общался с Владиславом в почте. Ещё раз подчеркну, что первая версия блока была написана на ассемблере с нуля (ну, под вдохновением ST кода).
Разумеется, в инструментарии остались непонятные для меня места, но, полагаю, они предусмотрены для более сложных случаев.

2) Потом я сделал компилятор ST->ASM в Harderlla IDE. Это не просто слова "будет проще сделать компилятор", а я его реально взял и сделал.

3) Мой опыт разработки Hardella IDE говорит, что тяжело сделать редактор (как ST-подобный, так и графический), делающий так, чтобы для пользователя было удобно использовать имеющийся PRU инструментарий. Тут, конечно, можно остановиться и сказать, что "я не умею делать IDE", или, что "вместо доработки общего счастья я пытаюсь пропихнуть свою Hardella IDE", но ни то ни другое не выдерживает критики. Hardella IDE существует и работает, а альтернативных IDE на горизонте не видно.

Касательно вопросов тестирования: в имеющемся инструментарии непонятно как именно тестировать финальную программу. "линкер (генератор prg)" на вход берёт бинарный код ФБ с метаинформацией и непонятно во что его превращает.
Как при этом тестировать финальную программу -- вообще непонятно. Правильность расстановки "служебных комментариев" вообще никак нельзя узнать. Грубо говоря, забыл указать спец комментарий и всё, один и тот же регистр запросто может использоваться в разных блоках, приводя к самым удивительным последствиям, которые _невозможно_ увидеть, если тестировать блоки отдельно.

В эмулятор сам файл PRU0.prg не загонишь, т.к. непонятен формат файла.
Если у ОВЕН есть инструмент для автоматического тестирования PRU0.prg, что ж, хорошо, но со мной им не делились (надо сказать, я не спрашивал).

Как раз для тестирования, эмулятор PRU процессора (https://github.com/vlsi/pru-emulator) оказался весьма удобным.
Он показал, что в моей исходной реализации блока была пара ошибок.
Да, сейчас приходится запускать эмулятор отдельно от среды разработки ФБ, но даже и это поправимо. Можно будет прямо отлаживать ST код, выполняющийся на эмуляторе. Т.е. выполнять код в Hardella IDE "построчно" и смотреть переменные, при этом в фоне будет выполняться бинарный код в эмуляторе PRU.
Обращу внимание, что это не потребует 100500 моих человеколет. В MPS (https://www.jetbrains.com/mps/) (та среда, с помощью которой я делаю Hardella IDE) уже заложена возможность отладки (https://confluence.jetbrains.com/display/MPSD34/Debugger). Т.е. да, разработка компилятора, отладчика и т.п. это непросто, но я и не предлагаю делать всё с нуля, а я предлагаю переиспользовать опыт MPS/Java. Тут и есть колоссальная экономия времени.


PS Постарался изложить основные моменты. Всё остальное (константное время выполнения, надёжность тестов, сложность компилятора и т.п.) я не забыл, а специально не стал обсуждать, т.к. иначе дискуссия вообще не закончится.

PPS. Да, слова "Также, что чрезвычайно важно, Ваш компилятор сейчас не генерирует код с константным временем исполнения (поправьте, если я ошибаюсь)." были написаны до того, как я показал результаты тестов блока ШД. Но, по факту, мой блок ШД, написанный на ST, выдаёт импульсы одинаковой длительности (http://www.owen.ru/forum/showthread.php?t=22169&page=15&p=219960&viewfull=1#post219960), и эта длительность совпадает с уставкой. Поэтому, давайте сначала всё-таки основное обсудим, а потом в детали пойдём?

[Newcomer]

Каков порядок действий после того, как vladimirisitnikov сделает ФБ для ШД. Т.е. что надо сделать чтобы обратиться к этому ФБ из основной программы ПЛК.

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

Каков порядок действий после того, как vladimirisitnikov сделает ФБ для ШД. Т.е. что надо сделать чтобы обратиться к этому ФБ из основной программы ПЛК.

Предположу следующее. В PruAccessLib.lib (см 1-е сообщение этой темы) есть 2 функции:


FUNCTION PRU_FB_SetParameter : DINT
VAR_INPUT
pru_num:DWORD; (*from 0 to 1*)
index:DWORD; (*from 2 to 31*)
value: POINTER TO DWORD;
END_VAR

и


FUNCTION PRU_FB_GetParameter : DINT
VAR_INPUT
pru_num:DWORD; (*from 0 to 1*)
index:DWORD; (*from 2 to 31*)
value: POINTER TO DWORD;
END_VAR

Судя по названиям параметров и комментариям к ним, эти блоки напрямую позволяют читать/писать значения PRU регистров.

Т.е. в основной программе вызываем PRU_FB_SetParameter и передаём параметры.

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

Поэтому есть 2 варианта:
1) Рабоче-крестьянский: в PRU программе использовать абстрактные "dword_in1, dword_in2, dword_out1, dword_out2" и в ПЛК программе следить за нумерацией этих параметров
2) Прогрессивный: при компиляции PRU программы, автоматически генерировать EXP код, который передаёт IN/OUT параметры "как надо". Ну, автоматически генерировать КДС блок-обёртку, у которого номера уже не перепутаешь.



PS. Есть даже ненулевая вероятность, что можно вызывать PRU_FB_GetParameter в 20мкс таймере (т.е. в отрыве от основного цикла ПЛК).
Грубо говоря, если PRU_FB_GetParameter прямо берёт и обращается к памяти PRU в момент вызова, то можно даже наблюдать актуальные значения.

[Newcomer]

Сложновато как-то.

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

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

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

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

Я совсем в другой области работаю, поэтому у меня вряд ли будут задачи по быстрому управлению и т.п.



Если из всего форума двум-трём людям нужно PRU программирование, из которых один это я, то это может и являться одной из причин скепсиса со стороны ОВЕН.


Сложновато как-то.
Переведу с русского на русский: если из Hardella IDE можно будет создавать PRU0.prg, то Hardella вместе с PRU0.prg сможет создать и КДС.exp с блоком, используемым в основной программе.

Т.е.:
1) Берём "программу ШД" (PRU0_программа_шд.prg), заливаем в PRU.
2) Берём блок_шд_для_управления_pru.exp, импортируем
3) Пользуемся как обычно

Куда уж проще-то?

Я, вот, считаю, что реально PRU блоки будут только по праздникам делать, и 99% запросов решатся набором готовых и протестированных PRU0.prg.

Ах, да, проще, если совсем всё делать в Hardella IDE, но это уже другой вопрос.

[Вольд]

Ваша Hardella IDE - это полноценная замена CoDeSys V2.3 или некая надстройка над ней ?

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

Вы все делаете на голом энтузиазме или как-то оформили свои отношения с фирмой "ОВЕН" ?

Сейчас это энтузиазм.


Ваша Hardella IDE - это полноценная замена CoDeSys V2.3 или некая надстройка над ней ?

Если говорить про ПЛК110 в обычном понимании, то Hardella это надстройка, которая генерирует *.exp (pou, plc configuration, и т.п.)
Для того, чтобы заменить КДС, нужно чтобы кто-то написал Ethernet/TCP/RS-232/Modbus/GPIO/файловая система/task scheduler/simulation/on-line visualization и т.п. Грубо говоря, есть голое железо, и откуда-то должен взяться код, который обслуживает файловую систему.

На мой взгляд, неправильно начинать с этого. Я уже говорил (http://www.owen.ru/forum/showthread.php?t=23013&page=19&p=213248&viewfull=1#post213248), что правильнее делать среду для чего-то попроще (http://www.owen.ru/forum/showthread.php?t=24753&page=6&p=214105&viewfull=1#post214105) (ну, чтобы ей уже можно было пользоваться), а потом уже усложнять, если реально есть смысл.

Если же говорить про PRU-программирование, то это полноценная замена. Сейчас можно рисовать PRU программы в КДС CFC, но после этого программу нужно выгрузить в *.exp формате, и прогнать через bat файл.
В случае Hardella IDE ничего никуда прогонять не нужно, а ошибки показываются сразу по ходу написания.

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

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

.. но обсуждаемая тема про другое! жесточайший лимит памяти, суровые команды с не очевидным синтаксисом, ориентированные на максимальное быстродействие - вот что такое PRU. Здесь место "голого ассемблера", даже чистый С будет неэффективно расходовать регистры и постоянно срываться на использование медленной памяти, а уж самописный транслятор...... Поэтому я считаю что тема пошла по неправильному курсу - хочется людям "красивостей", да за ради бога, но лично я не вижу применения этому. Имеющийся материал ужасть какой сырой и нужно прежде всего его обкатывать - три дня на элементарный проброс данных через PRU с помощью существующих блоков - при наличии вроде как рабочего примера - за гранью добра и зла )))

Я пошел по другому пути - ФБ PRU_DIMAS и в нем голый ассемблер с минимальным использованием описателей, лишь бы удовлетворить транслятор, в котором требуемый мне алгоритм не отягощен требованиями на совместимость блоков и выделением регистров на хранение промежуточных результатов... ну и START END по краям, вроде как обязательные... и вот они импульсы в 50 кГц.... как оказалось чуть позже - импульсы в 500 кГц были просто не видны из-за емкости щупов и установленной подтяжки ))

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

кстати, то что "быстрые ВЫХОДЫ" поделены между 2 процессорами по 2 я уже вычитал, а входы как заведены? все 4 в каждое ядро, параллельно???

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

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

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

Да, у меня есть задачи под PRU.
Можете озвучить?

Задачу генерировать "N импульсов нужной частоты" уже сделали.


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

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

Например, компилятор от производителя процессора не любит букву Я (у неё код 255 или что-то типа того). Запросто подобное может быть прошивке ПЛК110. Исследовать методом научного тыка желания нет.



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

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

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


Да и убедиться в этом кстати не долго, просто посмотрев файл в бинарном виде.
Посмотреть -- одно дело, а генерировать -- другое.
1) Декомпилирование и исследование форматов файлов с целью повторения существующего функционала -- это 100% статья про авторские права. Там явно сказано, что нельзя декомпилировать с целью "создания подобного".

2) Я не юрист, и не хочу разбираться будет ли нарушением авторских прав просто попытка переименовать бинарник от официального TI компилятора в название PRU0.prg. Если ОВЕН явно скажут, что "ок", то ок.
Я не хочу рисковать тем, что через неделю придёт ОВЕН с иском о "потерянных миллионах из-за злостной дешифрации формата PRU0.prg".

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

Я не хочу рисковать тем, что через неделю придёт ОВЕН с иском о "потерянных миллионах из-за злостной дешифрации формата PRU0.prg".

В овене работают весьма здравомыслящие люди, а свои возможности "по нанесению вреда", как мне кажется, вы оцениваете не совсем адекватно )))


что нельзя декомпилировать с целью "создания подобного"

угу, и опыты Гальвани с лягушками нельзя повторять, а то вдруг вновь электричество откроет кто-нить ))))

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

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

.. но обсуждаемая тема про другое! жесточайший лимит памяти, суровые команды с не очевидным синтаксисом, ориентированные на максимальное быстродействие - вот что такое PRU. Здесь место "голого ассемблера", даже чистый С будет неэффективно расходовать регистры и постоянно срываться на использование медленной памяти, а уж самописный транслятор...... Поэтому я считаю что тема пошла по неправильному курсу - хочется людям "красивостей", да за ради бога, но лично я не вижу применения этому. Имеющийся материал ужасть какой сырой и нужно прежде всего его обкатывать - три дня на элементарный проброс данных через PRU с помощью существующих блоков - при наличии вроде как рабочего примера - за гранью добра и зла )))

Я пошел по другому пути - ФБ PRU_DIMAS и в нем голый ассемблер с минимальным использованием описателей, лишь бы удовлетворить транслятор, в котором требуемый мне алгоритм не отягощен требованиями на совместимость блоков и выделением регистров на хранение промежуточных результатов... ну и START END по краям, вроде как обязательные... и вот они импульсы в 50 кГц.... как оказалось чуть позже - импульсы в 500 кГц были просто не видны из-за емкости щупов и установленной подтяжки ))

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

кстати, то что "быстрые ВЫХОДЫ" поделены между 2 процессорами по 2 я уже вычитал, а входы как заведены? все 4 в каждое ядро, параллельно???
входа 4 во 2-е PRU. Но можно передавать данные между PRU через память, там очень удобный механизм.

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

Линкер, кстати, Владимиру дали. Так что я вообще не понимаю проблемы!? Делаешь ФБ и вперёд. Запустить пару бат-файлов из Hardell-ы несложно.
Дмитрий Артюховский вот использует.

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

Там не всё так просто, но и не суперсложно
Озвучьте, пожалуйста, что именно сложно.

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

Линкер, кстати, Владимиру дали. Так что я вообще не понимаю проблемы!? Делаешь ФБ и вперёд. Запустить пару бат-файлов из Hardell-ы несложно.
Дмитрий Артюховский вот использует.

А вы посмотрите, что Дмитрий пишет:

Я пошел по другому пути - ФБ PRU_DIMAS и в нем голый ассемблер с минимальным использованием описателей, лишь бы удовлетворить транслятор, в котором требуемый мне алгоритм не отягощен требованиями на совместимость блоков и выделением регистров на хранение промежуточных результатов... ну и START END по краям, вроде как обязательные..

Судя по этим словам, Дмитрий пишет один большой монолитный блок на ассемблере, и использует линкер не потому, что нравится, а потому, что выбора у него нет. И? Этот "ФБ PRU_DIMAS и в нем голый ассемблер с минимальным использованием описателей" надёжнее, чем аналогичный код на ST?

Т.е. не я один пошёл по варианту "неиспользования предоставленных блоков".


Очевидно, что:
1) Для среднего инженера-программиста вариант "написать на ассемблере" недостижим
2) При написании монолитного кода на ассемблере гораздо проще ошибиться, чем при написании того же кода на ST или FBD языке
3) Требование использовать "линкер" только для того, чтобы "использовать" лишь усложняет общую систему, и добавляет нетривиальные проблемы. Кто, например, тестирует сам линкер?
Как тестировать, что ваш линкер правильно слинковал мою конкретную программу? Да и вообще, линкер привязан к windows, что создаёт проблемы при запуске на macos.

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

Давайте есть слона по кусочкам. Сейчас основное ограничение технологии PRU - отсутствие полноценного редактора.
А не написание ФБ на ассемблере.

Давайте. Озвучьте, пожалуйста, сложность документировать формат PRU0/1.prg и разрешить его использование.

[Newcomer]

Много спора из ничего. Все давно уже придумано. У замечательной фирмы Texas Instruments есть фирменная интегрированную среда разработки (IDE) Code Composer Studio, которая поддерживает микроконтроллеры компании TI и встраиваемые процессоры. "Code Composer Studio включает в себя набор инструментов, используемых для разработки и отладки встроенных приложений. Она включает в себя оптимизирующий C / C ++ компилятор, редактор исходного кода, среды сборки проекта, отладчик, профайлер, и многие другие функции" (http://www.ti.com/tool/ccStudio).

Среда эта естественно платная. Можно сделать что-то подобное для микроконтроллера, который используется в ПЛК110 М[02]. Если у фирмы "ОВЕН" есть фирменный инструментарий TI для написания программ для PRU на ассемблере, то можно приобрести все необходимое для написания программ на C/C++ (компилятор, линковщик, проч.).

У vladimirisitnikov есть своя Hardella IDE. Если фирма "ОВЕН" без проволочек передаст все необходимые причиндалы и разрешения, то очень скоро vladimirisitnikov сделает классный инструментарий для разработки PRU приложений. Этот инструментарий будет понятен и доступен широким массам пользователей продукции фирмы "ОВЕН".

Заниматься таким достаточно сложным делом на голом энтузиазме тяжело. Естественно фирма "ОВЕН" должна заключить с vladimirisitnikov договор подряда. К этому договору надо приложить согласованное ТЗ на разработку IDE и вперед к светлому будущему.

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

Озвучьте, пожалуйста, что именно сложно.
Не сложно компилировать харделлой свой код, помещать его в 1 ФБ с 4 входами и 4 выходами (или более, если надо больше данных на обмен с хостом) и, воспользовавшись линкером и имеющейся инфраструктурой делать программы для PRU.

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

Давайте. Озвучьте, пожалуйста, сложность документировать формат PRU0/1.prg и разрешить его использование.
Я не вижу в этом смысла. Если хочется делать монолитный код - метод известен, озвучен и даже использован.
Идея использования монолитного кода порочна в своей сути именно из-за проблем с тестированием. И использовать её как рабочую (промрешение) нет никакого желания.
Не зря контроллеры с программированием на C не получили распространения среди обычных потребителей.
Когда мы объявляли бета-тестирование - там чётко описывались задачи бета-тестеров. Задачи "перевернуть всё и поменять архитектуру ПО, а потом её ещё и поддержать" не было.

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

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

1) "Известный" метод не позволяет сделать мне законченное решение на базе Hardella.
Да, я могу генерировать промежуточный ассемблер, потом подсовывать его TI компилятору, потом ОВЕН линкеру, но тут мир рушится. Получившийся PRU0.prg файл невозможно ни отлаживать, ни тестировать. Его разве что в ПЛК заливать и с осциллографом анализировать.

2) Вы постоянно говорите о "порочности", но при этом игнорируете тот факт, что:
2.1) Есть механизм построчной отладки полученных программ. Надёжность на порядок выше того, что в том же самом ОЛ.
Какой код генерирует ОЛ никому неизвестно, а тут можно посмотреть, понять, и детально проверить.

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

2.2) У того же самого TI есть C компилятор, отладчик и т.п. Говорить "монолитный код порочен" и игноировать опыт индустрии крайне странно


Не зря контроллеры с программированием на C не получили распространения среди обычных потребителей

Надеюсь, вы понимаете, что я на C и не предлагаю программировать?
Зачем тогда говорите?


Я не вижу в этом смысла

Наконец-то! Хоть какой-то ответ.

Т.е. я останавливаю работы по PRU.
Спасибо за внимание.

Тем, кому-таки нужен блок ШД или подобные блоки работы с быстрыми входами-выходами: пишите/звоните в ОВЕН или используйте другие контроллеры.
Как вариант, можно меня подрядить на доработку Hardella IDE, но, сначала нужно согласие ОВЕН.

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

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

Тестируйте введенную пользователем программу в текстве, полагаясь на "божественную непогрешимость" предлагаемого компилятора и линкера (которую кстати никто вроде не оспаривает) )))

[Newcomer]

У меня еще одна простенькая задачка по управлению ШД. Бывает нужно разогнать ШД до требуемой частоты с заданным темпом (за определенное время). В связи с этим требуется такой ФБ для PRU (смотри вложения).

При установке ENABLE в TRUE частота на выходе OUT линейно (возможно по S-кривой) увеличивается до 1/PERIOD за время ACCSEL_TIME. По достижению заданной частоты READY устанавливается в TRUE. Если ENABLE переходит в FALSE, то OUT и READY устанавливаются в FALSE.

[приборист]

Итоги какие то есть?
Еще вчера нужен был ФБ управления сервопроводом.
Сейчас все делаю на Arduino и через RS485 отправляю в него команды.
Но это настолько некрасивое решение (на фоне заявлений ОВЕН о 100кГц на выходе), что я ночами ворочаться начинаю.

Альтернатива есть\будет?

Владимир, если Ваше решение рабочее и работает - готов протестить на оборудовании.
Готов предоставить фото\видео отчет по работе.

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

Линкер, кстати, Владимиру дали. Так что я вообще не понимаю проблемы!? Делаешь ФБ и вперёд. Запустить пару бат-файлов из Hardell-ы несложно.
Дмитрий Артюховский вот использует.

Объясню почему невозможно использовать "линкер".

Жизненный цикл кода (жирным я выделил, собственно, "секретный инструмент"; всё остальное -- общедоступно):

assember + СЕКРЕТНЫЙ ИНСТРУМЕНТ ==> FB_ARRAY.bin
КДС_CFC.EXP + target.trg + editor.exe ==> program.p
program.p + FB_ARRAY.bin + compilator.exe ==> PRU0.prg

КДС_CFC.EXP -- это программа из PRU блоков, составленная в КДС
program.p -- это по сути описание того, какие ФБ вызывать и как они соединены между собой
FB_ARRAY.bin -- содержит код самих блоков и ещё что-то

Я без проблем могу из Hardella сгенерировать всю программу под видом одного ФБ (и, соответственно, program.p будет состоять из одного гордого вызова этого самого ФБ), но это всё равно не позволит мне создавать PRU0.prg из Hardella.

Дело в том, что мой ФБ нужно каким-то образом завернуть в FB_ARRAY.bin файл, а инструмент, который это делает секретный.


Иными словами:
1) Я могу генерировать и публиковать PRU0.prg для законченных программ. Например, я могу опубликовать PRU0.prg для работы с ШД.
2) Я не могу встроить механизм генерации PRU0.prg в Hardella, т.к. для этого придётся публиковать "секретный инструмент создания FB_ARRAY.bin"
3) Если все эти песни пляски вокруг FB_ARRAY.bin сводятся только к тому, чтобы ублажить линкер, подсовывая ему программу из одного-единственного ФБ, то зачем такая сложность? Для повышения надёжности мы в цепочку добавляем 2 лишних звена под названиями FB_ARRAY.bin и program.p?
4) Ещё раз подчеркну, что я работаю в macos, и для меня секретный_инструмент.exe, editor.exe, compilator.exe создают проблему даже сами по себе -- на macos непросто запускать windows программы. Есть желающие проспонсировать развитие Hardella IDE? Подобные же "хоть чучелом, но без *.exe никак" весьма удручают.

[Newcomer]

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

Может обратиться к высшему руководству фирмы "ОВЕН" для разрешения этого конфликта ?

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

Не сделает. По крайней мере в обозримом будущем.
Дмитрий, поменьше слов, побольше дела.


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

Дмитрий, как вы из этой темы заключили, что у меня нет контроллера-то?
Вот контроллер: http://www.owen.ru/forum/showthread.php?t=23013&page=14&p=194290&viewfull=1#post194290
Что, сфотографировать вам модули ввода-вывода, AC4, блок питания, осциллограф?
Или будете говорить, что всё равно, это чужой контроллер и постановочная фотография?

Что ошиблись?
Теперь вернитесь к предыдущему пункту и хорошенько подумайте: "а что, если и в словах 'не сделает' тоже ошибка?".



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

Вы правы, знание глюков исполнительных механизмов бесценно.
Но каким боком это относится к PRU программированию?
Правильно, никаким.

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

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

Иными словами:
1) Я могу генерировать и публиковать PRU0.prg для законченных программ. Например, я могу опубликовать PRU0.prg для работы с ШД.
2) Я не могу встроить механизм генерации PRU0.prg в Hardella, т.к. для этого придётся публиковать "секретный инструмент создания FB_ARRAY.bin"

Прошу провести натурные испытания.
26446

Порядок работы:
1) Заливаем PRU0.prg (как-то)
2) Подключаем ШД на fast output 3
2) Используем блок pru_pulse.lib для работы с ШД
CYCLE_LENGTH задаёт длительность единичного и нулевого значения на выходе. Оно указывается в тактах PRU. Вроде как PRU работает на частоте 150МГц, т.е. значение cycle_length=150 это импульсы по 1мкс.
Параметр CYCLE_LENGTH сейчас WORD, т.е. максимальное значение 65535, и, значит, возможна генерация частот в пределах 1кГц...1МГц
Если нужны более низкие частоты, то придётся перекомпилировать программу, а мне было немного лень, т.к. для этого нужно перезапускать bat'ники.

В pru_pulse один блок:

FUNCTION_BLOCK PRU_PULSE
(* Output will be generated to FAST OUTPUT 3 *)
VAR_INPUT
ENABLE: BOOL;
CYCLE_LENGTH: WORD; (* PRU cycles *)
QUANTITY: DWORD;
END_VAR
VAR_OUTPUT
READY : BOOL;
QUANTITY_LEFT: DWORD; (* for debugging *)
END_VAR


Вышеобозначенное получено "официальным линкером".
Я ему скормил всю-всю программу как один ФБ.

Для примера, вот так выглядит pulse.p -- т.е. просто вызов одного моего ФБ.

;include "target.trg"
FBDECL
#defFB PRU_PULSE PRU_PULSE
/FBDECL

SYNCLIST
IN=R25
IN=R26
IN=R27
OUT=R28
OUT=R29
/SYNCLIST
PROGRAMM
PRU_PULSE
/PROGRAMM


А так выглядит "ассемблерный код" моего ФБ:


.origin 0
.entrypoint __INIT_PROGRAM

;FB_WORKTIME=40
;FB_NAME=PRU_PULSE

__INIT_PROGRAM:

Да, да. Код целиком и полностью сгенерирован в Hardella, а линкеру я скормил пустой файл. Вроде, тот не подавился, и ладно.


Обмен с PRU я сделал так. Тут, к сожалению, сделано наугад в надежде на то, что PRU_FB_GetParameter/PRU_FB_SetParameter будут читать/писать по нужным адресам в PRU памяти.


TMP : DWORD;
...
PRU_FB_GetParameter(pru_num:=0, index:=28, value:=ADR(TMP));
READY := TMP <> 0;
PRU_FB_GetParameter(pru_num:=0, index:=29, value:=ADR(QUANTITY_LEFT));
PRU_FB_SetParameter(pru_num:=0, index:=25, value:=ADR(QUANTITY));
TMP := WORD_TO_DWORD(CYCLE_LENGTH);
PRU_FB_SetParameter(pru_num:=0, index:=26, value:=ADR(TMP));
TMP := SEL(ENABLE, 0, 1);
PRU_FB_SetParameter(pru_num:=0, index:=27, value:=ADR(TMP));

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

Я посмотрю конечно все это, самому интересно, но вот что сразу бросается в глаза : модуль PRU0 физически подключен в выводам 3 и 4, поэтому на выводе 1 (подключенному к PRU1) ничего не будет по определению... т.е. автор не очень внимательно проверял предлагаемый модуль....

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

Посмотрите, пожалуйста, пристально на такой код.
Первая же команда PRU_FB_GetParameter(pru_num:=0, index:=28, value:=ADR(TMP)) уводит ПЛК в перезагрузку.
ADR(TMP) используется нормально?

Вроде, тут POINTER TO DWORD, и ADR я применяю только к DWORD переменным. С выравниванием всё ок? Или нужны какие-то песни-пляски?

Второе подозрение у меня на то, что, возможно, прошивка ПЛК поддерживает только 1 dword на обмен с PRU, а я пытаюсь 5 dword'ов синхронизировать.



FUNCTION_BLOCK PRU_PULSE
VAR_INPUT
ENABLE: BOOL;
CYCLE_LENGTH: WORD; (* PRU cycles *)
QUANTITY: DWORD;
END_VAR
VAR_OUTPUT
READY : BOOL;
QUANTITY_LEFT: DWORD; (* for debugging *)
END_VAR
VAR
TMP: DWORD;
END_VAR
..

PRU_FB_GetParameter(pru_num:=0, index:=28, value:=ADR(TMP));
READY := TMP <> 0;
PRU_FB_GetParameter(pru_num:=0, index:=29, value:=ADR(QUANTITY_LEFT));
PRU_FB_SetParameter(pru_num:=0, index:=25, value:=ADR(QUANTITY));
TMP := WORD_TO_DWORD(CYCLE_LENGTH);
PRU_FB_SetParameter(pru_num:=0, index:=26, value:=ADR(TMP));
TMP := SEL(ENABLE, 0, 1);
PRU_FB_SetParameter(pru_num:=0, index:=27, value:=ADR(TMP));


Собственно, определения функций get/set из pruAccessLib.lib:

FUNCTION PRU_FB_GetParameter : DINT
VAR_INPUT
pru_num:DWORD; (*from 0 to 1*)
index:DWORD; (*from 2 to 31*)
value: POINTER TO DWORD;
END_VAR
VAR
END_VAR


FUNCTION PRU_FB_SetParameter : DINT
VAR_INPUT
pru_num:DWORD; (*from 0 to 1*)
index:DWORD; (*from 2 to 31*)
value: POINTER TO DWORD;
END_VAR
VAR
END_VAR

[capzap]

Посмотрите, пожалуйста, пристально на такой код.
Первая же команда PRU_FB_GetParameter(pru_num:=0, index:=28, value:=ADR(TMP)) уводит ПЛК в перезагрузку.
ADR(TMP) используется нормально?

Вроде, тут POINTER TO DWORD, и ADR я применяю только к DWORD переменным. С выравниванием всё ок? Или нужны какие-то песни-пляски?

Второе подозрение у меня на то, что, возможно, прошивка ПЛК поддерживает только 1 dword на обмен с PRU, а я пытаюсь 5 dword'ов синхронизировать.



FUNCTION_BLOCK PRU_PULSE
VAR_INPUT
ENABLE: BOOL;
CYCLE_LENGTH: WORD; (* PRU cycles *)
QUANTITY: DWORD;
END_VAR
VAR_OUTPUT
READY : BOOL;
QUANTITY_LEFT: DWORD; (* for debugging *)
END_VAR
VAR
TMP: DWORD;
END_VAR
..

PRU_FB_GetParameter(pru_num:=0, index:=28, value:=ADR(TMP));
READY := TMP <> 0;
PRU_FB_GetParameter(pru_num:=0, index:=29, value:=ADR(QUANTITY_LEFT));
PRU_FB_SetParameter(pru_num:=0, index:=25, value:=ADR(QUANTITY));
TMP := WORD_TO_DWORD(CYCLE_LENGTH);
PRU_FB_SetParameter(pru_num:=0, index:=26, value:=ADR(TMP));
TMP := SEL(ENABLE, 0, 1);
PRU_FB_SetParameter(pru_num:=0, index:=27, value:=ADR(TMP));


Собственно, определения функций get/set из pruAccessLib.lib:

FUNCTION PRU_FB_GetParameter : DINT
VAR_INPUT
pru_num:DWORD; (*from 0 to 1*)
index:DWORD; (*from 2 to 31*)
value: POINTER TO DWORD;
END_VAR
VAR
END_VAR


FUNCTION PRU_FB_SetParameter : DINT
VAR_INPUT
pru_num:DWORD; (*from 0 to 1*)
index:DWORD; (*from 2 to 31*)
value: POINTER TO DWORD;
END_VAR
VAR
END_VAR

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

ЗЫ из представленного не ясно, какой срок получения ответа, возможно стоит возвращать результат в переменную и анализировать на равенство нулю например

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

Первая же команда PRU_FB_GetParameter(pru_num:=0, index:=28, value:=ADR(TMP)) уводит ПЛК в перезагрузку.
PRU_FB_GetParameter(pru_num:=0, index:=29, value:=ADR(QUANTITY_LEFT));

а вот определение в программе...

#define in_reg R29
#define out_reg R28

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

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

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

а вот определение в программе...

#define in_reg R29
#define out_reg R28

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

Это всё ерунда.
Я же говорил какая у меня программа:

Для примера, вот так выглядит pulse.p -- т.е. просто вызов одного моего ФБ.

;include "target.trg"
FBDECL
#defFB PRU_PULSE PRU_PULSE
/FBDECL

SYNCLIST
IN=R25
IN=R26
IN=R27
OUT=R28
OUT=R29
/SYNCLIST
PROGRAMM
PRU_PULSE
/PROGRAMM



Я вообще 3 регистра на вход и 2 на выход использую.


Скорее всего, проблема в том, что PRU не даёт отмашку "данные переданы/прочитаны", поэтому на ПЛК стороне операции PRU_FB_SetParameter/PRU_FB_GetParameter зависают (похоже, они ждут) и в конце концов ПЛК перегружается по watchdog'у.

Поправлю программу, чтобы были отмашки, и, наверняка заработает.

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

Поправил обмен данными между PRU и ПЛК.

26458

Теперь-то уж наверняка заработает.

Итого:


FUNCTION_BLOCK PRU_PULSE
(* Output will be generated to FAST OUTPUT 3 *)
VAR_INPUT
ENABLE: BOOL;
CYCLE_LENGTH: WORD; (* PRU cycles: 40...65486 == 65486-50; 40 == 0.27us, 65486 == 436 us *)
QUANTITY: DWORD; (* 0..2147483647 == (2<<30)-1 *)
END_VAR
VAR_OUTPUT
READY : BOOL;
QUANTITY_LEFT: DWORD; (* for debugging *)
END_VAR

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

Прошу провести натурные испытания.

Обмен с PRU так не работает. смотрим ФБ END_1_1 и понимаем 2 номера регистра, по которым идёт обмен.
Если надо больше - модифицируем ФБ соответственно.

Сама библиотека работает с любым номером регистра, если он задаётся и поддерживается ФБ END и опредёлен в программе в разделе
SYNCLIST

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

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

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

Я составляю *.p программу сам, и никаких PRU_START/PRU_END никуда не добавляется.



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

Дмитрий:
1) Я проверяю код на эмуляторе. На PRU процессор есть документация -- я его эмулирую. На pruAccessLib.lib документации нет -- приходится гадать и проводить натурные эксперименты.
2) У меня нет проводов для соединения ПЛК
3) Можете проверить? Ну, реально. Если у вас "расчехлён ПЛК", то проверить должно быть недолго.

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

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

У меня вопрос про HOST составляющую.
Библиотека pruAccessLib.lib, похоже, не просто "пишет в память", а ещё и ждёт того, как PRU обработает данные. Вот этот момент ни в "писании" не сказан, ни из исходных кодов тоже не считывается.

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

Спасибо прибористу за тестирование.

Собственно, лучше не скажешь:

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

Шах и мат?


Собственно, программа:


PROGRAM PRU_PULSE_GENERATOR
variables:
burst : PRU_GENER_BURST;
enable : BOOL;
cycleLength : WORD;
quantity : DWORD;
ready : BOOL;
qtyLeft : DWORD;
dataReady : BOOL;
controlRegisterAddress : DWORD;
currentCycles : WORD;

body:
(* безопасные значения *)
enable := FALSE;
cycleLength := 100;
quantity := 0;
WHILE TRUE DO
(* собственно полезная работа *)
burst(enable := enable, quantity := quantity);

controlRegisterAddress := 16#700C;
(* Пока есть время, передаём-принимаем данные *)
REPEAT
ASM
LBCO dataReady, 3, 0, 1
END_ASM

IF dataReady THEN
(* Приём *)
ASM
LBCO quantity, 3, 100, 4
LBCO cycleLength, 3, 104, 2
LBCO enable, 3, 108, 1
END_ASM

(* Передача *)
ready := burst.ready;
ASM
SBCO ready, 3, 112, 1
END_ASM
qtyLeft := burst.qtyLeft;
ASM
SBCO qtyLeft, 3, 116, 4
END_ASM

dataReady := FALSE;
ASM
SBCO dataReady, 3, 0, 1
END_ASM
END_IF;

ASM
LBBO currentCycles, controlRegisterAddress, 0, 2
END_ASM
currentCycles := currentCycles + 40;
UNTIL currentCycles < cycleLength
END_REPEAT;
(* Остаток задержки ждём более точно, без приёма-передачи *)
WAIT_TICK(pruCycleLength := cycleLength);

PRU_OUT1(Q := burst.out);
END_WHILE;
END_PROGRAM


FUNCTION_BLOCK PRU_GENER_BURST
variables:
input enable : BOOL;
input quantity : DWORD;
output out : BOOL;
output ready : BOOL;
retain output qtyLeft : DWORD;

body:
IF enable THEN
IF qtyLeft > 0 THEN
(* Идёт генерация *)
qtyLeft := qtyLeft - 1;
ELSIF ready THEN
(* Всё сгенерировали, ждём пока передёрнут enable для следующего включения *)
ELSE
(* Поступила команда на включение *)
qtyLeft := SHL(quantity, 1);
qtyLeft := qtyLeft - 1;
END_IF;
ready := qtyLeft = 0;
ELSE
(* Выключаемся *)
qtyLeft := 0;
ready := FALSE;
END_IF;
(* Если всё сделали, то out выключится. Если пачка ещё генерируется, то младший бит и есть меандр *)
out := qtyLeft.0;


FUNCTION_BLOCK WAIT_TICK
variables:
input pruCycleLength : WORD;
cyclesLeft : WORD;
currentCycles : WORD;
controlRegisterAddress : DWORD;

body:
(* 0x00007000..0x00007FFF -- PRU0 Control Registers, 0xC -- cycle count register *)
controlRegisterAddress := 16#700C;
ASM
LBBO currentCycles, controlRegisterAddress, 0, 2 ; Load cycle count, 1+wdcnt*1==2 cycles
END_ASM
currentCycles := currentCycles + 8;
IF pruCycleLength > currentCycles THEN
cyclesLeft := pruCycleLength - currentCycles;
cyclesLeft := cyclesLeft XOR 0;
IF cyclesLeft.0 THEN
cyclesLeft := cyclesLeft XOR 1;
END_IF;
WHILE cyclesLeft <> 0 DO
cyclesLeft := cyclesLeft - 2;
END_WHILE;
ELSE
cyclesLeft := 0;
END_IF;
ASM
SBBO cyclesLeft, controlRegisterAddress, 0, 2 ; Load cycle count, 1+wdcnt*1==2 cycles
END_ASM

[Newcomer]

Вот и славненько. Мои искренние поздравления Владимиру Ситникову !

Теперь вопросы.

С какой прошивкой должен быть ПЛК110 [М02] ?

Будет ли в ФБ реализован разгон ШД ?

Будет ли сделан ФБ о котором я писал в посте 197.

И самое главное. Будут ли подвижки в позиции программистов фирмы "ОВЕН" к тому, что делает и предлагает Владимир Ситников ?

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

С какой прошивкой должен быть ПЛК110 [М02] ?
Без понятия. Ждём прибориста.



Будет ли в ФБ реализован разгон ШД ?
Сделаю.
Я читал что есть по S-кривым, но с ними всё сложно. Сделаю трапецию.


Будет ли сделан ФБ о котором я писал в посте 197.
А какая длительность работы того блока нужна?
Как вариант -- выставить "quantity=230-1". Такого количества шагов хватит?


И самое главное. Будут ли подвижки в позиции программистов фирмы "ОВЕН" к тому, что делает и предлагает Владимир Ситников ?
Почему самый главный вопрос стоит последним по списку? Непорядок...

[Newcomer]

А какая длительность работы того блока нужна?
Как вариант -- выставить "quantity=232-1". Такого количества шагов хватит?.

После разгона до номинальной частоты ШД может работать неограниченно долгое время.

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

После разгона до номинальной частоты ШД может работать неограниченно долгое время.

Сутки?
Месяц?
Или сколько?

230-1 это 2147483647 импульсов (да, реальное ограничение 230-1, а не 232-1 как я говорил ранее)
Если считать 1000имп/оборот (с запасом на дробление), то это 2'147'483 оборотов
Если оно крутится со скоростью 100 оборотов/сек (у кого-то реально так крутит?), то это 21'400 сек == 5 часов

Мне не сложно сделать параметр "не останавливаться", просто пытаюсь тех процесс понять

[Newcomer]

Обычно ШД имеют 200 импульсов на оборот если нет дробления шага. Если есть возможность сделать параметр "не останавливаться", то это и надо сделать. Т.е. надо разогнать ШД до номинальный частоты и он должен работать пока сигнал ENABLE не перейдет в FALSE. В посте 197 я все подробно описал. Только бы надо еще чтобы ШД затормозился не резко, а с отрицательным ускорением.

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

У меня вопрос про HOST составляющую.
Библиотека pruAccessLib.lib, похоже, не просто "пишет в память", а ещё и ждёт того, как PRU обработает данные. Вот этот момент ни в "писании" не сказан, ни из исходных кодов тоже не считывается.

Смотрим ФБ END

[приборист]

Итак, спасибо Владимиру.
Блок протестировал - все работает.
Прошивка ПЛК - последняя с сайта.
Проверял на 3 выходе.

Скорость на лету меняет.
Количество импульсов на лету не меняет (пока острой необходимости в этом не вижу)

Пожелания:
в ФБ добавить настройку выхода (т.е. настраивать DO1-DO4)
Сделать плавный разгон торможение (количество импульсов старт\стоп и делитель для скорости)
Сделать возможность использования 2 таких блоков на разные выхода (независимые). С 4 выходами видимо будет проблема? С двумя думаю проблем не должно возникнуть - использовать 2 PRU/

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

Итак, спасибо Валерию.
Я Владимир, но не суть.


Сделать плавный разгон торможение (количество импульсов старт\стоп и делитель для скорости)
Делитель это что? Настройка шаг-полушаг? Или ещё что-то?

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


Пожелания:
в ФБ добавить настройку выхода (т.е. настраивать DO1-DO4)
Сделать возможность использования 2 таких блоков на разные выхода (независимые). С 4 выходами видимо будет проблема? С двумя думаю проблем не должно возникнуть - использовать 2 PRU/
Два блока параллельно на одном PRU с разными частотами действительно сложнее, чем один. Но вполне может получиться.
Разгон требует вычислительных ресурсов (~1 деление, которое будет около 200 тактов занимать. Два блока на разгон будут потреблять ~400 тактов, т.е. 3мкс, но и это вполне укладывается в требуемую скорость.

Да, выбор выхода это правильно.


Собственно, вопрос к Владиславу: где можно найти файл target.trg для PRU1?

[приборист]

Я Владимир, но не суть.

Прошу прощения, заработался совсем.



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


Я думал что для режима замедления заданную скорость просто делить на коэффициент (занижать в 2-3-10 раз)
Если равноускоренный разгон - вообще шикарно, но думаю более трудоемко.

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

аппаратные таймеры заняты

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

аппаратные таймеры заняты

А "target.trg для PRU1" будет?

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

Вы же не используете архитектуру ОВЕН? Зачем тогда таргет?

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

Вы же не используете архитектуру ОВЕН? Зачем тогда таргет?

Что вы понимаете под словами "не используете архитектуру ОВЕН"?


Ещё раз поясню как я получил PRU0.prg:

1) Создал бинарный код для PRU в Hardella -- pru_pulse.bin. Тут целиком моя работа. На всякий случай, я скомпилировал ассемблер через pasm.exe -- результат совпал полностью.
2) Создал пустой файл pru_pulse.asm, применил к нему "секретный инструмент", и получил PRU_PULSE.fb с моим кодом
3) Создал pulse.p с одним единственным вызовом моего блока, и вызовом Compilator.exe pulse.p PRU_PULSE.fb PRU0.prg получил PRU0.prg

Мне, конечно, не нравится, что сейчас нет возможности пропустить шаги 2 и 3 с "секретным инструментом, обрабатывающим пустой файл".
Более того, сама необходимость шага №2 + подписанный "договор о неразглашении" запрещают встраивать вызов "секретного инструмента" в Hardella IDE.

Да, я агитирую всех, кому нужно 100кГц писать/звонить в ОВЕН и (прилично!) спрашивать "появился/изменился ли ответ на сообщение #196 (http://www.owen.ru/forum/showthread.php?t=22169&p=220452&viewfull=1#post220452)?".

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

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

Можно, конечно, о такого типа PRU программирования помечтать 26492

Но:
1) Сначала я хотел бы хоть несколько реальных программ увидеть, чтобы понять какие по сути функции требуются от PRU
Переводя с русского на русский, сначала ШД с разгоном, а потом уже FBD и т.п.

2) Кучу времени потратили на выяснение "можно ли из Hardella генерировать PRU0.prg и PRU1.prg". Это прямо реально вопрос тысячелетия. Сначала заставляют договор о неразглашении подписывать, а потом удивление, что я его добросовестно соблюдаю.

3) Пока неясно ясно как на FBD скрещивать "два блока ШД, которые разгоняют каждый свой выход, и каждый хочет разный интервал цикла".
Простой вариант, конечно, просто сделать фиксированную гранулярность цикла с делителями
Что-нибудь в духе "PRU цикл по 1мкс". Но на частотах 100кГц гранулярность "каждую микросекунду" может быть маловато.

4) Очень может оказаться, что ШД это единственное для чего нужен PRU. Ну, возможно, что-нибудь с энкодерами будет. Для ШД, как уже было видно, достаточно просто сделать PRU0.prg и соответствующую библиотеку. Народ будет просто заливать PRU0.prg и всего делов. Т.е. блок ШД как блок никому не нужен. Нужна законченная программа.

Кстати, тут вопрос про обновление прошивки самого ПЛК.
Если я правильно понимаю, то мою PRU программу (ШД) можно встроить в прошивку ПЛК, и прямо в КДС конфигураторе вместо fast output выбирать "stepper motor". Ну, по крайней мере, наверняка технически есть такая возможность, и вопрос переходит в организационную плоскость.

[приборист]

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

Без этой возможности придется возвращаться к Arduino.

[приборист]

Переименовать файл в PRU1.prg пробовали? (ну и в pru_pulse.lib использовать pru_num:=1)

Если повезёт, то будет на 1-ом или 2-ом выходе сигнал.
Если заработает, то и 2 одновременно работать должны.

Пробовал,
Оставлял один PRU1.prg
И pru_num менял.
ПЛК в ребут уходит при запуске программы.

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

Пробовал,
Оставлял один PRU1.prg
И pru_num менял.
ПЛК в ребут уходит при запуске программы.

Одна PRU1.prg сама по себе работать не будет.

Пробовали одновременно и PRU0.prg и PRU1.prg?

[Newcomer]

4) Очень может оказаться, что ШД это единственное для чего нужен PRU. Ну, возможно, что-нибудь с энкодерами будет. Для ШД, как уже было видно, достаточно просто сделать PRU0.prg и соответствующую библиотеку. Народ будет просто заливать PRU0.prg и всего делов. Т.е. блок ШД как блок никому не нужен. Нужна законченная программа.

Можно еще ФБ BLINK сделать. Штатный более 500 Гц не выдает.

Что там программисты "ОВЕН" говорят о дальнейших перспективах ?

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

Переживать не надо, работа по написанию ФБ для PRU найдется. Надо программистов "ОВЕН" расшевелить. Пусть дадут добро на разработку нормальной среды для написания ФБ для PRU.

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

Можно еще ФБ BLINK сделать. Штатный более 500 Гц не выдает.
Чем не подходит штатный PWM режим для быстрых выходов?

[IVM]

Чем не подходит штатный PWM режим для быстрых выходов?

Там на выходе меандр, а у BLINK можно отдельно задавать длительность импульса и паузы.

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

Там на выходе меандр, а у BLINK можно отдельно задавать длительность импульса и паузы.

Так у PWM тоже можно указывать какую часть времени единица, а какую ноль.

Процитирю:

PWM [Slot] (* *) {
channels:
<no variable> AT %QW2.0 WORD (* PWM 1 power *)
<no variable> AT %QW2.1 WORD (* PWM 2 power *)
<no variable> AT %QW2.2 WORD (* PWM 3 power *)
<no variable> AT %QW2.3 WORD (* PWM 4 power *)
<no variable> AT %QD2.4 DWORD (* PWM 1 period, in mks *)
<no variable> AT %QD2.5 DWORD (* PWM 2 period, in mks *)
<no variable> AT %QD2.6 DWORD (* PWM 3 period, in mks *)
<no variable> AT %QD2.7 DWORD (* PWM 4 period, in mks *)
}

Т.е. в режиме PWM, каждый выход управляется двумя параметрами.

[приборист]

Так у PWM тоже можно указывать какую часть времени единица, а какую ноль.

Процитирю:

PWM [Slot] (* *) {
channels:
<no variable=""> AT %QW2.0 WORD (* PWM 1 power *)
<no variable=""> AT %QW2.1 WORD (* PWM 2 power *)
<no variable=""> AT %QW2.2 WORD (* PWM 3 power *)
<no variable=""> AT %QW2.3 WORD (* PWM 4 power *)
<no variable=""> AT %QD2.4 DWORD (* PWM 1 period, in mks *)
<no variable=""> AT %QD2.5 DWORD (* PWM 2 period, in mks *)
<no variable=""> AT %QD2.6 DWORD (* PWM 3 period, in mks *)
<no variable=""> AT %QD2.7 DWORD (* PWM 4 period, in mks *)
}

Т.е. в режиме PWM, каждый выход управляется двумя параметрами.

Этот режим работает медленнее чем обычный CLK_PULSE от OSCAT.</no></no></no></no></no></no></no></no>

[IVM]

Так у PWM тоже можно указывать какую часть времени единица, а какую ноль.

Процитирю:

PWM [Slot] (* *) {
channels:
<no variable> AT %QW2.0 WORD (* PWM 1 power *)
<no variable> AT %QW2.1 WORD (* PWM 2 power *)
<no variable> AT %QW2.2 WORD (* PWM 3 power *)
<no variable> AT %QW2.3 WORD (* PWM 4 power *)
<no variable> AT %QD2.4 DWORD (* PWM 1 period, in mks *)
<no variable> AT %QD2.5 DWORD (* PWM 2 period, in mks *)
<no variable> AT %QD2.6 DWORD (* PWM 3 period, in mks *)
<no variable> AT %QD2.7 DWORD (* PWM 4 period, in mks *)
}

Т.е. в режиме PWM, каждый выход управляется двумя параметрами.

А какую максимальную частоту в режиме PWM можно получить ? Прерываться по таймеру 20 мкс не очень хорошо для основной программы. Могут возникнуть проблемы при обмене по последовательному порту.

[приборист]

Если я правильно понимаю, то этот модуль работает на основе PRU программы, т.е. он не имеет никакого отношения к 20мкс.

Судя по комментарию, "period in mks". Можно попробовать поставить power=50 (или 32767 -- возможно, под power понимается число от 0 до 65535), period=2 мкс и посмотреть сможет ли оно выдать меандр с шириной 1мкс.

У меня максимальная скорость работы сервопривода при настройках power 500 и period 6000
При значениях 499 6000
Либо 501 6000 уже не работает.

Пробовал делать 50 и 60000, вообще рывками медленно двигается.

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

У меня максимальная скорость работы сервопривода при настройках power 500 и period 6000
При значениях 499 6000
Либо 501 6000 уже не работает.

Пробовал делать 50 и 60000, вообще рывками медленно двигается.
Понял.

Думаю, понимаете, сделать "рабочий" PWM/BLINK сложности не составляет?

В использовании PRU0.prg/PRU1.prg некий плюс в том, что для разработки/исправления ошибок не нужно ждать ответа ОВЕН.

Форум это не лучше средство отслеживания задач, но на текущий момент:
1) ШД с разгоном-торможением
2) 2 ШД одновременно (PRU0 и PRU1)
3) "правильный" шим

В каком порядке нужны?

Лучше такой порядок, чтобы можно было к ОВЕН прийти с вариантом (например, с проектом):
1) Либо решаем вопрос #196 Вольда (http://www.owen.ru/forum/showthread.php?t=22169&page=20&p=220452&viewfull=1#post220452)
2) Либо arduino

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


Кстати, есть желающие в имеющийся блок PRU_GENER_BURST (http://www.owen.ru/forum/showthread.php?t=22169&page=23&p=220878&viewfull=1#post220878) добавить поддержку параметра "бесконечное количество повторений" и "раздельного указания длины единичного и нулевого импульса"?
Это 3-я задача, и тут никакого ассемблера не нужно. Достаточно просто ST код поправить.

[приборист]

Понял.

Думаю, понимаете, сделать "рабочий" PWM/BLINK сложности не составляет?

Понимаю, при наличии инструментария и неких навыков (либо времени, чтобы разобраться)



В использовании PRU0.prg/PRU1.prg некий плюс в том, что для разработки/исправления ошибок не нужно ждать ответа ОВЕН.

Форум это не лучше средство отслеживания задач, но на текущий момент:
1) ШД с разгоном-торможением
2) 2 ШД одновременно (PRU0 и PRU1)
3) "правильный" шим

В каком порядке нужны?

Мне интересен разгон\торможение и 2 ШД.
"Правильный" шим это что?


Лучше такой порядок, чтобы можно было к ОВЕН прийти с вариантом (например, с проектом):
1) Либо решаем вопрос #196 Вольда (http://www.owen.ru/forum/showthread.php?t=22169&page=20&p=220452&viewfull=1#post220452)
2) Либо arduino

Мне кажется диалог с ОВЕН будет +- таким:
Мы: Мы блок сделали, все работает, хотим знать секрет, чтобы делать его проще и быстрее.
ОВЕН: Сделали, молодцы, работайте. Зачем вам быстрее, если итак все работает?


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

А поддерживается ли сейчас PRU1.prg на уровне прошивки? :)
Может не думали, что пытливые умы заинтересуются, сделали PRU0.prg и забили.


P.S.
Вообще ситуация до безобразия комична.
ОВЕН выпускает прибор, заявляет параметры, но они не работают, а пользователи клещами тянут информацию, чтобы САМИМ все доделать за ОВЕН.
:(

[IVM]

А какая нужна?

Если делать на PRU программе, то можно сделать импульсы шириной до 0.3..0.7 мкс
Сможет ли схемотехника пропустить эти мегагерцы -- не знаю, но должно получиться.
Где-то видел картинку, как TI показывает снимок осциллографа "переключение входа-выхода за 5нс".

Я думаю 1 мГц вполне хватит.

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

"Правильный" шим это что?
Это BLINK, который выдаёт бесконечное количество импульсов 0 1 0 1 с указанными длительностями 0 и 1. Если штатный "fast PWM из конфигуратора" не работает, можно сделать свой, рабочий.


Понимаю, при наличии инструментария и неких навыков (либо времени, чтобы разобраться)
Ок, скажу прямо: я без проблем сделаю и могу сделать среду, что "любой, кто смыслит в ST или FBD" сможет сделать свой BLINK.
Но нужно чтобы кто-то выбил это из ОВЕНа.


Мне кажется диалог с ОВЕН будет +- таким:
Мы: Мы блок сделали, все работает, хотим знать секрет, чтобы делать его проще и быстрее.
ОВЕН: Сделали, молодцы, работайте. Зачем вам быстрее, если итак все работает?

1) Тут не только "знать секрет" нужно, а получить хоть какое-то подтверждение, что ОВЕН хотя бы "будет стараться не ломать" этот механизм в будущих прошивках.
Да и вообще: случись что со мной. И что? "Секрет дамасской стали" утерян?

Ну, с одной стороны, единожды написанную программу PRU0.prg менять не нужно.
Но, блин, крайне шаткая позиция.

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

Сейчас всё держится на несущей зубочистке.

2) Тем не менее, Владислав изначально заявлял, что не видит смысла в моём варианте PRU программирования (по разным причинам). Здесь наличие реально работающей программы легко послужит "контрпримером". Т.е. не просто "доказана возможность писать для PRU на нормальном ST / FBD", а прямо реальный проект.
Как-никак, это аргумент, и оспаривать его словами в духе "такая концепция программирования неконцептуальна" крайне тяжело.


А поддерживается ли сейчас PRU1.prg на уровне прошивки? :)
Может не думали, что пытливые умы заинтересуются, сделали PRU0.prg и забили.
Ну, быстрый энкодер-то работает? Он цепляется на быстрые входы, а все быстрые входы разведены на PRU1, значит управление двумя PRU хоть в каком-то виде должно работать.
Возможно, не работает "прямое общение HOST-PRU1", но это можно обойти, если пересылать данные с помощью PRU0.

[приборист]

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

ОВЕН идут от противного - мало запросов => задачу в конец очереди.
Хотя мое мнение другое - т.к. ОВЕН раньше не делал ПЛК для управления ШД и Сервоприводами - никто и не смотрит в их сторону при таких задачах.
А если бы предоставили готовое решение - запросов стало бы больше.
"Жираф большой, ему виднее" (с)

Лично мне - нравится CDS, есть на руках Дельта, которая из коробки может 200кГц на выходах и готовые блоки.
Но система программирования....

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

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

вы главного упорно не видите, в приведенном выше коде - 90% ассемблерные вставки и тратить время на разработку среды для "обертывания" их в одиночный repeat - until даже с выделением цветом ключевых слов смысл не великий... кому нравится эстетствовать - в добрый путь, а для нормальной работы там есть еще много сырых мест которые и надо допиливать не отвлекаясь на разноцветные флажки и гирлянды )))

кстати, входы заведены на PRU0 и при необходимости передаются в PRU1 через память


Если делать на PRU программе, то можно сделать импульсы шириной до 0.3..0.7 мкс

не получится принципиально, по двум причинам: код не выполниться чаще чем 1 МГц и и примененные опропары не отработают фронты на данной частоте

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

вы главного упорно не видите, в приведенном выше коде - 90% ассемблерные вставки и тратить время на разработку среды для "обертывания" их в одиночный repeat - until даже с выделением цветом ключевых слов смысл не великий... кому нравится эстетствовать - в добрый путь,
Дмитрий.
1) А, давайте, покажите, где там 90% ассемблерных вставок.
Не надо бросаться голословными утверждениями.

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

Вот, реально. Найдите хоть одну ассемблерную инструкцию в самом блоке генератора импульсов.
Или найдите ассемблерную инструкцию в коде, который генерирует задержку.
Да хоть где.

Я без проблем могу завернуть оставшиеся LBCO/SBCO в нормальный ST код, но именно здесь я не хочу тратить время, т.к. здесь и сейчас именно эти 2 инструкции никому не мешают.

А вы увидели "asm" и давай говорить "смысл не великий".


2) Сейчас обсуждается не подкраска синтаксиса. Сейчас обсуждается вообще возможность PRU программирования, т.е. сама возможность задействования быстрых входов-выходов.
Если вы до сих пор не поняли, что ОВЕН никак не хочет разрешать работу с быстрыми входами-выходами, то я не знаю как ещё объяснить.


а для нормальной работы там есть еще много сырых мест которые и надо допиливать не отвлекаясь на разноцветные флажки и гирлянды )))
Каждый считает своим долгом сказать, что "ничего у вас не получится".
Давайте с другой стороны: у вас получился блок управления ШД? (ну или что вы там делали?) Покажете?
У Филоненко получился блок управления ШД?
Ещё у кого-нибудь получился?

Почитайте выше -- пишут, что даже просто fast PWM не работает как надо. Я уж не говорю про ШД с разгоном.

У меня -- ШД получился. Если считаете, что "можно было просто на ассемблере сделать, и не парить мозг с разработкой среды", то продолжайте так считать.
Но есть одно но: очень много кто считает, что "можно просто на ассемблере было написать", а как доходит до дела, то все сдуваются. Прямо реально, страна советов. Все только и делают, что советуют "как надо". А, если реально сделать, то всё. Сразу "да на один только ОЛ 5 человеколет ушло", да и вообще "разработка компилятора это 50 человеколет".

Почему-то никто из скептиков не учитывает, что среда УЖЕ есть. В ней УЖЕ можно писать программы, и не просто абы какие, а прямо те, которые давным-давно нужны на проектах: ШД, серво, вот это всё.


не получится принципиально, по двум причинам: код не выполниться чаще чем 1 МГц
Это откуда взяли?
Код выполняется с частотой 150МГц -- это частота PRU ядра. Почти все команды занимают 1 такт.
Можно хоть 50МГц на быстрый выход выводить программой из двух команд "вкл-выкл-goto start".


1 МГц и и примененные опропары не отработают фронты на данной частоте
Тут без понятия.

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

кстати, входы заведены на PRU0 и при необходимости передаются в PRU1 через память
Если знаток PRU1, то, может, расскажете как pruAccessLib.lib взаимодействует с PRU1?
Ну, какие адреса памяти используются для обмена?

Понятно, что можно сделать host-PRU0-PRU1, но всё-таки, лучше сделать независимый обмен, чтобы не нагружать PRU0 лишней работой по пересылке данных туда-сюда.

[Newcomer]

не получится принципиально, по двум причинам: код не выполниться чаще чем 1 МГц и и примененные опропары не отработают фронты на данной частоте

Вот что в первом посте этой темы написал В.Филоненко: Для этого в ПЛК есть 2(4) быстрых входа и 4 быстрых выхода (которые способны воспринять или сформировать импульсы от 0,5 мкс длительностью) и 2 специализированых сопроцессора, PRU, которые подключены непосредственно к этим I/O и могут обрабатывать данные и управлять отдельно от основного цикла ПЛК.

Дмитрий, что вообще вы такое пишите. Откуда у вас столько пессими́зма ? Вы что древний старик ?

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

Мне интересен ... 2 ШД.

Пробуйте такую комбинацию PRU0.prg (такая же как раньше) и PRU1.prg (немного другая): 26506

Добавил параметр -- "номер выхода":

VAR_INPUT
ENABLE: BOOL;
CYCLE_LENGTH: WORD; (* PRU cycles *)
QUANTITY: DWORD;
OUT_NUM: BYTE; (* 1, 2, 3, or 4 *)
END_VAR


Но реально он пока только для выбора между "PRU0 vs PRU1":

IF OUT_NUM >= 3 THEN
pru_num := 0;
ELSE
pru_num := 1;
END_IF;

Владислав пишет, что pruAccessLib работает "одинаково для каждого PRU".

[capzap]

Вот что в первом посте этой темы написал В.Филоненко: Для этого в ПЛК есть 2(4) быстрых входа и 4 быстрых выхода (которые способны воспринять или сформировать импульсы от 0,5 мкс длительностью) и 2 специализированых сопроцессора, PRU, которые подключены непосредственно к этим I/O и могут обрабатывать данные и управлять отдельно от основного цикла ПЛК.

Дмитрий, что вообще вы такое пишите. Откуда у вас столько пессими́зма ? Вы что древний старик ?

в чем конкретно противоречие у Дмитрия с этим текстом? Частота следования импульсов начинается с 1мкс, мне кажется это один мегагерц. Минимальная длительность в 0.5мкс это как раз возможности железа распознать переход состояния, вроде все как говорит Дмитрий и без всякого пессимизма

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

Все Вы уже знаете, я надеюсь, что у нас появился новый ПЛК 110-хх.
При его разработке мы заложили возможность его использования для управления процессами, требующими высокой скорости и стабильности реакции.
Для этого в ПЛК есть 2(4) быстрых входа и 4 быстрых выхода (которые способны воспринять или сформировать импульсы от 0,5 мкс длительностью) и 2 специализированых сопроцессора, PRU, которые подключены непосредственно к этим I/O и могут обрабатывать данные и управлять отдельно от основного цикла ПЛК.

А такой вопрос: есть ли возможность управлять "обычными" входами как быстрыми из PRU программы?
Вроде, PRU может работать с глобальной памятью, и через McASP (например) управлять всеми подряд входами-выходами.

Было бы забавно простые входы превратить в быстрые, и прицепить 5 быстрых ABZ энкодеров на один ПЛК110 М02.
Ну, мне просто забавно, а кому-то очень даже и полезно.

Понятно, что при управлении через память задержка больше, но 50-100кГц наверняка сделать можно, даже если через память работать с ножками.

Собственно, статья: http://international.electronica-azi.ro/2011/09/26/implementing-industrial-interfaces-with-the-programmable-realtime-core-in-the-texas-instruments-am1808-armtm-microprocessor/


The PRUs feature 30 inputs and 32 outputs, which are addressed directly using registers. These inputs and outputs are tapped over the microprocessor pins after pin multiplexing for external signals has been configured in the AM1808. This allows each PRU to switch external signals within just a few nanoseconds and react to external signal changes with service routines.


Ну и пример, где на схожем процессоре (AM335x) получают 100ns задержки на переключение "через память": http://stackoverflow.com/questions/17804759/beaglebone-gpio-output-synchronization-with-pru-ti-am335x

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

Я думаю так, если есть процессор в ПЛК то и работать с нем нужно в родной среде без всяких там cds и подобных. Упрощение среды для программирования накладывает ограничение для самого плк.

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

Плохо что данная тема от поиска, обсуждения и устранения текущих косяков скатилась к обсуждению "планов на пятилетку", причем не своих собственных...

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

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

Проверял на двух вариантах: разгон до 5кГц и до 100кГц.
В обоих случаях время разгона 0.25 сек. Я, конечно, понимаю, что в реальности до 100кГц за 0.25сек мало кто будет разгоняться, но тут во-первых нужно проверить точность вычислений, а во-вторых, на высоких скоростях "лишнего времени нет" -- надо проверить сколько времени будет занимать "вычисление следующей длительности".

Собственно, графики. Повторюсь, графики получены из эмулятора PRU, и абсолютно всё вычисление сделано в PRU (включая квадратный корень в начале работы).
Ни один float не пострадал: в PRU нет float'ов, и там даже просто умножения нет.

Разгон до 5кГц
В целом, норм, расчётная частота 5кГц достигается не в 0.25 с, а в 0.2477 секунду. Погрешность 1% по-моему, норм.
26574

Частота 5кГц для нашего процессора, разумеется, никаких проблем составлять не должна, ведь PRU работает на 150МГц.
Видно, что пик загруженности процессора составляет целых 0.2%
26575


Попробуем зарядить 100кГц
Тоже норм. Расчётная частота 100кГц достигается не на 0.25 с, а в 0.2512 секунду. Погрешность снова укладывается в 1%
26576


А не слишком ли сложные вычисления для 100кГц?
Да, 100кГц это более сложная задача, но и она занимает лишь 2.5% в пике.

26578


На графиках не учтена работа "внешнего цикла" и "обмен данными", но очевидно, что:
1) 100кГц ШД не составляет никакой проблемы для PRU ядра
2) Вычисления можно делать прямо в PRU. Такой подход оказывается проще в тестировании, т.к. на вход тестируемому блоку даём сразу понятные величины типа "разгонись до 5кГц за 3 секунды", и в имеющемся эмуляторе смотрим что да как.
3) Вполне может получиться и вычисление "экстренной остановки", когда PRU выполнит расчёт замедления на основе текущей скорости и требуемого времени замедления

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

Потом можно будет прикрутить "плавный выход на расчётную скорость" (ну, чтобы не было разрыва ускорения при переходе от равноускоренного к равномерному движению). Будет вообще шикарно.

[Вольд]

Все прекрасно сделано. Только вряд ли получится разогнать ШД до 5 и тем более до 100 кГц за столь короткое время. Тут времена будут не менее 1 сек.

Нужен стенд для натурных испытаний.

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

Все прекрасно сделано. Только вряд ли получится разогнать ШД до 5 и тем более до 100 кГц за столь короткое время. Тут времена будут не менее 1 сек.

Нужен стенд для натурных испытаний.

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

Вот графики для "100кГц за 20 секунд". На каждом графике тут 1'200'000 точек (частота большая, и длительность 20 секунд):
26579

26580

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

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

Сделал вычисление разгона-торможения.

Всё основывается на четырёх параметрах:

input quantity : DWORD; (* Общее количество импульсов *)
input accel_ramp : DWORD; (* Ускорение имп/сек^2 *)
input decel_ramp : DWORD; (* Замедление имп/сек^2 *)
input max_speed : DWORD; (* Максимально допустимая скорость имп/сек *)

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

Текущее ограничение -- разгон до макс скорости должен укладываться в 232-1.
По-моему, этого должно хватать на все разумные случаи.
Например:
1) если макс скорость составляет 100кГц, то разгон нужно выполнить не дольше, чем за 11 часов (==((1<<32)-1)/100000/3600).
2) если макс скорость составляет 10кГц, то разгон нужно выполнить не дольше, чем за 119 часов (==((1<<32)-1)/10000/3600).

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

3500 импульсов, разгон 500 имп/сек2, торможение 1000 имп/сек2
26582

CPU %:
На этом графике видно, что "подготовка" действительно занимает какое-то время.
Тут это было 768 тактов, т.е. целых 5.1 мкс. Не исключено, что можно соптимизировать, но деления-умножения там делать приходится.
Первый генерируемый импульс составляет 42.7 мс, и все вычисления просто немного сокращают длительность "ожидания".
26583

2250000 импульсов, разгон 5000 имп/сек2, торможение 6666 имп/сек2
26584

CPU %:
Тут подготовка была 867, т.е. 5.8 мкс.
26588

А теперь сделаем короткое передвижение (так, что максимальная скорость не достигается).
1000 импульсов, разгон 500 имп/сек2, торможение 1000 имп/сек2

26587


Теперь осталось:
1) добавить "общий цикл", который будет моргать выходом и передавать параметры
2) добавить "экстренное торможение" (если enable переходит в false раньше времени, то вычислить торможение и начать это самое торможение)

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

Программирование PRU - это прежде всего реальное, детерминированное время выполнения. Трансляция кода с ЯВР никогда не покажет предсказуемого времени выполнения алгоритма, при наличии хотя бы одного ветвления. Для систем реального времени - это фатально.

Кроме того не забываем что время выполнения даже чистого С (лучших трансляторов) увеличено в 2 -2.5 раза по сравнению с ассемблерным кодом (не оптимизированным по ухищрениям! там разница еще больше). Для близкого к данной теме примера - код написанный на ST выполняется раза в 3 медленнее описания алгоритма на IL, оптимизировал для быстрого таймера поэтому натрахался с этой темой вволю.

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

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

Есть концепция овена, которая предлагает именно РЕАЛЬНОЕ ВРЕМЯ и стыкуется с системами программирования логических контроллеров. Данная тема заведена разработчиками для тестирования предложенной технологии, отладки и доведения до уровня беспроблемного применения. То что происходит - злобный оффтопик ))))

Если кому-то интересно что именно я делаю - решаю вопросы своей работы )) В текущий момент - это и модуль энкодера и шаговый двигатель, синхронизированный с энкодерам по плавающему алгоритму. В настоящий момент с уверенностью могу заявить что PRU это круто и за ним будущее! Будет свободное время - формализую модуль по стандартам модулей овена.

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

Программирование PRU - это прежде всего реальное, детерминированное время выполнения. Трансляция кода с ЯВР никогда не покажет предсказуемого времени выполнения алгоритма, при наличии хотя бы одного ветвления. Для систем реального времени - это фатально.

Подучите теорию. ST это язык низкого уровня (https://ru.wikipedia.org/wiki/%D0%9D%D0%B8%D0%B7%D0%BA%D0%BE%D1%83%D1%80%D0%BE%D 0%B2%D0%BD%D0%B5%D0%B2%D1%8B%D0%B9_%D1%8F%D0%B7%D1 %8B%D0%BA_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0% BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8 %D1%8F). В моих программах используются пока только BYTE/WORD/DWORD, как раз те типы, с которыми PRU процессор работает напрямую. Поэтому, язык на котором я пишу является "языком низкого уровня", хоть в нём и есть "человекопонятные IF/WHILE/CASE/и т.п."
Но, ладно, буду думать, что вы под словами "ЯВР" имели ввиду "не ассемблер".

Вот, уже второй говорит, что "фатально" (первый был Владислав)
Хватит бросаться словами.
Без ветвлений вообще невозможно нормальную программу сделать. Иначе процессор выполнит свои 1024 инструкции и остановится.
Хочешь не хочешь, а ветвление необходимо.

Откройте END_1_1.asm и посмотрите сколько там ветвлений (там есть условные переходы).
Откройте PRU_OUT1.asm и посмотрите сколько там ветвлений (и там есть условные переходы).


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

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


Кроме того не забываем что время выполнения даже чистого С (лучших трансляторов) увеличено в 2 -2.5 раза по сравнению с ассемблерным кодом (не оптимизированным по ухищрениям! там разница еще больше). Для близкого к данной теме примера - код написанный на ST выполняется раза в 3 медленнее описания алгоритма на IL, оптимизировал для быстрого таймера поэтому натрахался с этой темой вволю
Вы сказали, только то, что в КДС плохой компилятор ST. Да, компилятор КДС туп как валенок.
И?

Как "плохой компилятор КДС" влияет на мой компилятор ST?
Правильно, никак.

Если вам нравится "IL вволю" -- я ни коем образом не останавливаю. Но поймите, что "трахаться с IL" равно как "трахаться с PRU ASM" очень мало кому нравится.
Людям нужно реальные задачи решать, а не воевать с ассемблером.


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

Во-первых, не "1 кслов памяти", а 4 килобайта, т.е. 1024 команды.

Алгоритм ШД с разгоном и торможением уже реализован.
Графики разгона-торможения получены с реального алгоритма.

Этот самый блок ШД со всеми квадратными корнями занимает 342 команды.
Ещё немного добавится на обмен с HOST'ом, поэтому пока никаких проблем нет. Если реально будут проблемы с размером кода, то поработаю над этим.



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

Смеётся тот, кто смеётся последним.
SQRT(DWORD): DWORD занимает 16 PRU команд.

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


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

Моя среда, как минимум, позволяет делать полноценную программу для ШД. С разгоном и торможением. С перемещением на ровно указанное количество импульсов.

Hello_world это или нет -- не важно. Важно то, что мой подход позволяет решать реальные задачи на производстве. Вариант "от ОВЕН" -- не позволяет.

Более того, можно даже энкодер и ПИД управление (этим самым ШД) прикрутить, если есть потребность в таком управлении.


Есть концепция овена, которая предлагает именно РЕАЛЬНОЕ ВРЕМЯ и стыкуется с системами программирования логических контроллеров. Данная тема заведена разработчиками для тестирования предложенной технологии, отладки и доведения до уровня беспроблемного применения. То что происходит - злобный оффтопик ))))

Компания ОВЕН свою технологию предоставила.
И компания получила обратную связь. На этой технологии невозможно ни разрабатывать, ни тестировать, ни отлаживать.
Разумеется, на каждую даже самую ужасную технологию найдётся один-два человека, которому именно она в кайф и будет, но в целом, всем стало понятно, что:

1) Есть реальные задачи на применение 100кГц от ПЛК110. Например, управление ШД
2) Предоставленный ОВЕНом инструмент непригоден для общего применения. Блок ШД на инструменте ОВЕН если и можно сделать, то это займёт уйму времени и нервов
4) Упоминаемого "реального времени" пока никому не нужно. Вместо абстрактных слов "реальное время" лучше бы привели пример, где и как это реальное время пригодится на производстве.
Например, задача "ШД с разгоном" понятна всем. Всем понятно почему на простых выходах ПЛК это сделать не получится. А слова "реальное время" это какой-то миф.



Если кому-то интересно что именно я делаю - решаю вопросы своей работы )) В текущий момент - это и модуль энкодера и шаговый двигатель, синхронизированный с энкодерам по плавающему алгоритму. В настоящий момент с уверенностью могу заявить что PRU это круто и за ним будущее! Будет свободное время - формализую модуль по стандартам модулей овена.

Покажете исходный код?
Я уверен, что если просто переписать его на ST, то будет на порядок понятнее, и наверняка более оптимально (по скорости, количеству использованных регистров и всему что только можно).

Я не говорю, что "мой компилятор генерирует код лучше, чем любой рукописный", но я категорически не согласен с тем, что "переписывание на ST замедлит код в 2-3 раза".

И, да, даже, если вдруг замедлит в эти самые 2-3 раза, то частота PRU закрывает это с лихвой. Например, при управлении ШД, процессор простаивает больше 97% времени.
Поэтому на первый план должна выходить не "оптимальность кода", а "сложность поддержки", "возможность отладки" и т.п. Вот у варианта на ассемблере шансов на "исправление ошибки сторонним человеком" никаких нет.

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

[Вольд]

Именно поэтому на такие проекты не нанимают фрилансеров.

Вы отстали от жизни. Полмира так уже работает.

[Newcomer]

Хочу немного подкорректировать интерфейс своего первого ФБ для управления ШД (см. вложение). Дело в том, что существует большое разнообразие ШД и драйверов к ним разных производителей. В каждом конкретном случае потребуется подбор времени разгона и торможения ШД чтобы не было пропуска шагов.
Надо чтобы у пользователя была возможность самостоятельно подобрать эти времена.

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

Хочу немного подкорректировать интерфейс своего первого ФБ для управления ШД (см. вложение). Дело в том, что существует большое разнообразие ШД и драйверов к ним разных производителей. В каждом конкретном случае потребуется подбор времени разгона и торможения ШД чтобы не было пропуска шагов.
Надо чтобы у пользователя была возможность самостоятельно подобрать эти времена.

Почему времена?

Я предлагаю указывать "скорость торможения" и скорость разгона. По-просту говоря, "ускорение", которе измеряется в имп/сек2.

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

[Newcomer]

Почему времена?

Я предлагаю указывать "скорость торможения" и скорость разгона. По-просту говоря, "ускорение", которе измеряется в имп/сек2.

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

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

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

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


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

Да что значит "более понятно" то?

Проблема пропуска импульсов не "во временах разгона", а в том, что у системы есть момент инерции.
Т.е. у каждой связки "ШД-исполнительный механизм" будет какой-то момент инерции, и на его основе можно вычислить предельно допустимое ускорение/замедление.
Вот статья, где с примерами приводятся вычисления допустимых ускорений для разных систем: http://www.orientalmotor.com/products/pdfs/2012-2013/G/usa_tech_calculation.pdf
Считают момент инерции, смотрят на мощность движка и понимают предельно допустимое ускорение.

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

То что предлагаю я -- указывать параметры "разгоняться с ускорением 10кГц/5 секунд==2000 имп/сек2" и "тормозить с ускорением 10кГц/2сек == 5000 имп/сек2".
Что в этом "непонятного"?

Ускорения -- первичны. "времена разгона-торможения" -- вторичны.

[Newcomer]

На практике никто момент инерции считать не будет. Это не тривиальная задача. А будут тупо, методом тыка, подбирать время разгона. Скажите у вас возникнут какие-то принципиальные проблемы, если на входе ФБ будет указано время, а не ускорение.
И как это задать ускорение 10кГц/2сек ? Какое это будет число ? 5 что ли ?

[ASo]

Что в этом "непонятного"?

Ускорения -- первичны. "времена разгона-торможения" -- вторичны.Ээээээ... Вы просто не понимаете, где и для чего применяют шаговый движок. В отличии от линейного.

[Newcomer]

можно подумать что у современных ЦП (МК) нет системы команд ...

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

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

На практике никто момент инерции считать не будет. Это не тривиальная задача. А будут тупо, методом тыка, подбирать время разгона. Скажите у вас возникнут какие-то принципиальные проблемы, если на входе ФБ будет указано время, а не ускорение.
И как это задать ускорение 10кГц/2сек ? Какое это будет число ? 5 что ли ?

Понимаю я, что никто не будет "момент инерции считать".
Но вариант "эта установка до 10кГц разгонится за 10 секунд и не околеет, значит ставим 10000/10=1000" должен быть прост и понятен.

[Newcomer]

Понимаю я, что никто не будет "момент инерции считать".
Но вариант "эта установка до 10кГц разгонится за 10 секунд и не околеет, значит ставим 10000/10=1000" должен быть прост и понятен.

А разве будет не понятнее, если указать вместо 1000 просто 10. Хочу мол чтобы за 10 секунд ШД раскрутился до 10 кГц. Если не получается, то поменяю время разгона. Зачем чего-то делить ?

А вы уж там в своей программе оперируйте какими угодно величинами.

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

А разве будет не понятнее, если указать вместо 1000 просто 10. Хочу мол чтобы за 10 секунд ШД раскрутился до 10 кГц.
А вы уж там в своей программе оперируйте какими угодно величинами.

Нет, понятнее не будет. Уверяю вас.

Объясню на примере: нужно сделать 300 импульсов, предельная скорость 60 импульсов/сек.
Внимание, вопрос: какое время разгона/торможения ставить?

Потом оказывается, что нужно сделать 400 импульсов.
Какое время разгона/торможения ставить?

Уже здесь будет огромная проблема, т.к. даже если есть "время разгона/торможения для 300 импульсов, то совершенно неясно какие времена должны быть для 400"


Скажите у вас возникнут какие-то принципиальные проблемы, если на входе ФБ будет указано время, а не ускорение.

Более того. Вот реальная проблема, которая не позволяет сделать ФБ "по вашему ТЗ".
Допустим, вы указали: "разгон за 5 секунд, торможение за 5 секунд, макс скорость 60 импульсов/сек, всего нужно 300 импульсов".
Внимание, вопрос: как должен действовать ФБ?
Должен ли он за первые 5 секунд пытаться выйти на макс скорость?



Так вот: для каждой конкретной установки, ускорение и замедление -- константы. Т.е. их вообще изменять не нужно. Достаточно либо подобрать (опытным путём), либо методом тыка (поделить 10'000 Гц на желаемую длительность разгона до этой скорости) вычислить и всё.
В итоге, на вход блоку нужно только "количество импульсов".

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


Поэтому, ещё раз повторюсь: если сделать "указание времён", то будут проблемы "200 импульсов отрабатывает нормально, а на 250 пропуски". Будут вечные игры с подбором времени и т.п.

[Newcomer]

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

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

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

Ээээээ... Вы просто не понимаете, где и для чего применяют шаговый движок. В отличии от линейного.

Появится реальный проект на моём алгоритме -- узнаем кто из нас не понимает.
Давайте конкретику.

Если при разгоне за 10 секунд до 10кГц нет проблем, то проблем не будет разогнаться до 3кГц за 3 секунды, до 20кГц за 20 секунд и т.п. (ну, если скорость в пределах допустимого для движка/установки)
Поэтому я и говорю, что первично ускорение (X кГц/сек), а конкретная "длительность разгона" уже вторична.

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

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

Я же говорю: допустимое ускорение подаётся на вход блоку.
Ему передаётся:
enable
количество импульсов
ускорение при разгоне
ускорение при замедлении

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

[Newcomer]

Я же говорю: допустимое ускорение подаётся на вход блоку.
Ему передаётся:
enable
количество импульсов
ускорение при разгоне
ускорение при замедлении

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

Можно задать 10 как говорю я, а можно задать 10000/10 = 1000 как говорите вы и на выходе ФБ получится одинаковый результат. Только в моем случае не надо ничего делить.

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

Можно задать 10 как говорю я, а можно задать 10000/10 = 1000 как говорите вы и не будет никакой разницы. Только в моем случае не надо ничего делить.

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

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

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



Более того, если говорить об S кривых, то вы никогда не сможете вычислить "время разгона" для случая S кривой. Ну, даже если вы и сможете (вдруг?), то среднестатистический пользователь -- точно нет.
Поэтому вынесение параметра "время разгона" будет мешать дальнейшим улучшениям блока. S-кривую уже просто так не получится добавить, т.к. у S-кривой понятие "время разгона" весьма относительно.

[Newcomer]

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

[Newcomer]

Так бы сразу и написали, что у вас проблемы с делением в коде. Я вас про это сразу спросил.

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

Так бы сразу и написали, что у вас проблемы с делением в коде. Я вас про это сразу спросил.

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

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

[Newcomer]

Чувствуется что вы не работали с ШД. Ускорение это более абстрактное понятие чем частота и время. На практике при работе с ШД оперируют временем и частотой импульсов.

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

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

А?
Кто запрещает в коде указать:
stepper(quantity := 300, max_speed := 60, accel_ramp := 10000/10, decel_ramp := 10000/20, enable:=...) ?
Надо 400 импульсов? Вот 400:
stepper(quantity := 400, max_speed := 60, accel_ramp := 10000/10, decel_ramp := 10000/20, enable:=...) ?
Надо 10? Вот 10:
stepper(quantity := 10, max_speed := 60, accel_ramp := 10000/10, decel_ramp := 10000/20, enable:=...) ?

Надо просто раскрутить до 60 имп/сек и пусть фигачит?
stepper(quantity := -1, max_speed := 60, accel_ramp := 10000/10, decel_ramp := 10000/20, enable:=...) ?
Надо раскрутить до 5000имп/сек?
stepper(quantity := -1, max_speed := 5000, accel_ramp := 10000/10, decel_ramp := 10000/20, enable:=...) ?

Надо просто сделать 100 импульсов на частоте 60Гц?
stepper(quantity := 100, max_speed := 60, accel_ramp := 0, decel_ramp := 0, enable:=...) ?


В таком коде можно без проблем менять max_speed, можно без проблем менять quantity.
И никаких вычислений "времени разгона" делать не нужно.
Числа 10000/10, как я говорил, берутся "из пальца, что установка без проблем разгоняется до 10000 за 10 секунд". Хотите того или нет, но подобные числа в любом случае придётся откуда-то брать.
Вы ШД как выбираете? Не по цвету же?

А теперь покажите, как будет выглядеть предлагаемый вами вариант. Хотя бы для случая 300/400 импульсов.

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

Чувствуется что вы не работали с ШД. Ускорение это более абстрактное понятие чем частота и время. На практике при работе с ШД оперируют временем и частотой.

Возможно, вы с какими-то неправильными блоками ШД работали.

[Newcomer]

А теперь покажите, как будет выглядеть предлагаемый вами вариант. Хотя бы для случая 300/400 импульсов.

А что такое 300/400 импульсов ?

[Newcomer]

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

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

А что такое 300/400 импульсов ?

Я привёл варианты кода, которые решают задачи управления ШД (http://www.owen.ru/forum/showthread.php?t=22169&p=221503&viewfull=1#post221503).
Есть установка, у которой предельное ускорение 10'000Гц/10сек, предельное замедление предельное ускорение 10'000Гц/20сек
1) Сделать 300 импульсов, максимальная скорость 60 Гц
2) Сделать 400 импульсов, максимальная скорость 60 Гц
3) Сделать 10 импульсов, максимальная скорость 60 Гц
4) Раскрутиться до 60 имп/сек и продолжить вращение бесконечно
5) Раскрутиться до 5000 имп/сек и продолжить вращение бесконечно
5) Просто сделать 100 импульсов на частоте 60 имп/сек.

Покажите как хотя бы первые 1-2-3 задачи будут решаться, если у ФБ будут такие аргументы, как вы предлагаете (http://www.owen.ru/forum/showthread.php?t=22169&page=33&p=221476&viewfull=1#post221476):
enable, period, quantity, accel_time, decel_time

Я к тому, что "accel_time" и "decel_time" совершенно непонятно как вычислять.


Реально, приведите пару строк, как будет выглядеть использование блока, если аргументы такие, как вы предлагаете. По факту -- аргументов "enable, period, quantity, accel_time, decel_time" недостаточно. Как минимум, нужен аргумент "какая по факту скорость достигается в конце разгона".

[Newcomer]

Я привёл варианты кода, которые решают задачи управления ШД (http://www.owen.ru/forum/showthread.php?t=22169&p=221503&viewfull=1#post221503).
Есть установка, у которой предельное ускорение 10'000Гц/10сек, предельное замедление предельное ускорение 10'000Гц/20сек
1) Сделать 300 импульсов
2) Сделать 400 импульсов
3) Сделать 10 импульсов
4) Раскрутиться до 60 имп/сек и продолжить вращение бесконечно
5) Раскрутиться до 5000 имп/сек и продолжить вращение бесконечно
5) Просто сделать 100 импульсов на частоте 60 имп/сек.

Покажите как хотя бы первые 1-2-3 задачи будут решаться, если у ФБ будут такие аргументы, как вы предлагаете (http://www.owen.ru/forum/showthread.php?t=22169&page=33&p=221476&viewfull=1#post221476):
enable, period, quantity, accel_time, decel_time

Я к тому, что "accel_time" и "decel_time" совершенно непонятно как вычислять.

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

[Newcomer]

Если надо сделать 300 шагов за определенное время, то я прикину какая частота импульсов должна быть чтобы уложиться в заданное время. Далее буду подбирать время разгона и торможения чтобы вал ШД повернулся на заданный угол без пропуска импульсов. И так для любого количества импульсов. Задача вашего ФБ просто, без всякого думоства, исполнить то, что задано на входе.

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

Будут тупо подбирать время разгона/торможения.

Заново подбирать время разгона для каждого значения quantity? Реально так?


Никто на практике не будет вычислять предельное ускорение установки и время разгона/торможения. Пусконаладкой не профессора занимаются. Будут тупо подбирать время разгона/торможения.
Вот реально не могу понять почему вы думаете, что подбирать "время разгона/торможения" для каждого конкретного quantity это легче и проще, чем подобрать это самое время разгона/торможения один раз и потом использовать его для вообще всех значений? Например, если оказалось, что до 1000Гц без проблем разгоняемся за 5 секунд, то так и пишем: accel_time:=1000/5.
Дальше это accel_time уже не трогаем, а ставим quantity/max_speed как нужно

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


Вы же предлагаете, что "пусконаладчики" каким-то мифическим образом подбирают времена.
А, если quantity потом меняется? Что? Все времена переигрывать?
Это реально каменный век.


"ускорение" действительно проще выражать в виде дроби 10'000 Гц/10 сек (по крайней мере мне)
Но в этом и прелесть, что, подобрав один раз эту дробь, можно менять остальные параметры (количество импульсов, предельную скорость) и не возвращаться к подбору "времени разгона".
Эта дробь имеет понятный смысл: за такое-то время мы достигнем такой-то скорости (если понадобится).

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

Если надо сделать 300 шагов за определенное время

О, наконец какой-то похожий на реальность пример. "сделать 300 шагов за 6 секунд и по возможности не насиловать установку".
Над такой задачей подумать можно.
Над временем ускорения/замедления -- нет.

Если хочется -- выбивайте из ОВЕН признания Hardella и делайте свой блок.

Я тов. Филоненко сказал "нет, невозможно пользоваться ОВЕНовским инструментарием", так и вам говорю: "нет, время разгона/торможения делать не буду, т.к. алгоритм делать неудобно и пользоваться тоже неудобно будет".


Если надо сделать 300 шагов за определенное время, то я прикину какая частота импульсов должна быть чтобы уложиться в заданное время. Далее буду подбирать время разгона и торможения чтобы вал ШД повернулся на заданный угол без пропуска импульсов. И так для любого количества импульсов. Задача вашего ФБ просто исполнить то, что задано на входе.

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

Импульс либо есть либо его нет.


Вот пример:
10 импульсов, accel_ramp = 10000/10, decel_ramp = 10000/20, max_speed=60
26605

Вот реально, чему равно "время замедления" и "время ускорения" в этом случае?
Я "скорость" на графике строю как "1/интервал_между_импульсами". Можно долго обсуждать правильно ли это, но это лишь дополняет мутность самого вопроса "длительность разгона"

[Newcomer]

Предельное (минимальное) время разгона ШД от quantity не зависит, а зависит от инерционности системы. После того, как я опытным путем определю предельное время разгона, то я везде и буду подставлять его в качестве формального параметра ФБ.

В который раз повторяю можно выполнить деление 10'000 Гц/10 сек на входе блока, а можно это сделать внутри блока, но результат на выходе блока от этого не изменится.

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

Предельное (минимальное) время разгона ШД от quantity не зависит, а зависит от инерционности системы.
Зависит.
Вот картинка для случая "10 импульсов, 20 импульсов и 100 импульсов":
26609

Видно, что фактическое время разгона и замедления зависит от quantity.


В который раз повторяю можно выполнить деление 10'000 Гц/10 сек на входе блока, а можно это сделать внутри блока, но результат на выходе блока от этого не изменится.

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

[rovki]

И почему в ПЧВ задают время разгона и торможения ,а не количество периодов меняющейся частоты ;) интересно????

[Newcomer]

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

Очень просто все выглядит. Подаю на вход ФБ время разгона, предельную частоту и количество импульсов. Вы в ФБ делите предельную частоту на время разгона, получаете свое любимое ускорение и делаете с ним все что надо. ;)

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

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

Очень просто все выглядит. Подаю на вход ФБ время разгона, предельную частоту и количество импульсов. Вы в ФБ делите предельную частоту на время разгона, получаете свое любимое ускорение и делаете с ним все что надо.

А как понять "достигается ли эта самая предельная частота"?

Посмотрите на красные и зелёные точки на графике (10 и 20 импульсов). При малых quantity предельная частота не достигается

[Newcomer]

А как понять "достигается ли эта самая предельная частота"?

Посмотрите на красные и зелёные точки на графике (10 и 20 импульсов). При малых quantity предельная частота не достигается

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

[Newcomer]

Владимир, ответьте на простой вопрос. Измениться ли результат на выходе ФБ если в одном случае выполнить деление
10'000 Гц/10 сек на входе блока, а во втором случае сделать это деление внутри блока ?

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

Владимир, ответьте на простой вопрос. Измениться ли результат на выходе ФБ если в одном случае выполнить деление
10'000 Гц/10 сек на входе блока, а во втором случае сделать это деление внутри блока ?

Скажите начала что значит period в вашем варианте параметров (http://www.owen.ru/forum/showthread.php?t=22169&page=33&p=221476&viewfull=1#post221476)
В моём варианте у каждого параметра есть понятный смысл, и параметры accel_ramp, decel_ramp, max_speed являются параметрами конкретной установки.
Т.е. фактичеки, я предлагаю блок, у которого задавать нужно только quantity.

Вы же почему-то упорно хотите заниматься подбором параметров и передавать лишние/недостающие данные.
Зачем -- понять не могу.


Слова "ШД выбран неправильно", конечно, говорить можно, но юстировку и т.п. никто не отменял. Я не хочу добавлять в блок искусственные ограничения на диапазон допустимых quantity. Вариант "блок работает, но quantity меньше 100 не передавать" будет звучать крайне странно.

[Newcomer]

Период у меня означает величину обратную частоте, т.е. T = 1/F. Я же график в одном из постов приводил. Обсуждать остальное сил уже нет, спать хочется.

[Newcomer]

Что-то вы мое ТЗ переиначили на свой лад. Что в результате получится я просто не представляю.

[приборист]

Тестировать есть что-нибудь?)));)

[Newcomer]

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

Для второго ФБ надо задавать частоту до которой должен раскрутиться ШД и ускорение (замедление).

Зачем использовать формат данных REAL ?

Во вложении документ на буржуйский ПЛК. На стр. 92 этого документа подробно расписано как работает функция управления ШД в этом ПЛК. Это примерно то, что я изначально хотел. Если заработает то, что предлагаете вы (задавать ускорение), то это будет круче чем у забугорных друзей.

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

Программа "ШД с разгоном": 26625


Step motor control via AM1808 PRU

FUNCTION_BLOCK PRU_STEPPER
(* Output will be generated to FAST OUTPUT 3 *)
VAR_INPUT
ENABLE: BOOL;
MAX_SPEED: DWORD; (* Гц *)
QUANTITY: DWORD; (* количество импульсов *)
ACCEL_RAMP: DWORD; (* Гц/сек, положительное. Например, 10000Гц/20сек == 500Гц/сек *)
DECEL_RAMP: DWORD; (* Гц/сек, положительное. Например, 10000Гц/10сек == 1000Гц/сек *)
OUT_NUM: BYTE; (* 1, 2, 3 или 4 *)
END_VAR
VAR_OUTPUT
READY : BOOL; (* TRUE: можно запускать ещё раз, FALSE: предыдущие импульсы ещё идут *)
STATE : BYTE; (* 0: INIT, 1: ACCEL, 2: RUN, 3: DECEL, 4: STOP *)
END_VAR

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

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

Если ACCEL_RAMP равно нулю, то ускорения/замедления не происходит, а просто генерируются QUANTITY импульсов с частотой MAX_SPEED

Если QUANTITY равно -1 (16#ffffffff), то генерируется бесконечное количество импульсов. Генератор работает до перевода ENABLE в false.

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

Зачем использовать формат данных REAL ?
Если в двух словах, то для того, чтобы не пришлось править пользовательскую КДС программу при обновлении PRU программы.

Например, если передавать "max_speed" как DWORD в герцах, то уже невозможно задать 100.5 Гц. Либо 100, либо 101.
Конечно, можно договориться, что "max_speed" передаётся как "частота, умноженная на 256" (т.е. вместо 100.5 передавать 25728), но это дичь.

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

Тогда "в следующих версиях блока" можно менять лишь PRU0.prg/stepper.lib, а саму программу, которая подаёт команды менять не придётся. Программа как передавала "частоту в герцах", так и продолжит передавать.

Аналогично, если окажется, что для "ускорений" у dword'а точность низкая, то опять же, можно будет поправить реализацию самой PRU программы, и не трогать пользовательский код.



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

[Newcomer]

Я думаю задавать частоту и ускорение с точностью до 1 будет достаточно. Если меандр будет формироваться для управления ШД, то десятые и сотые доли точно будут не нужны.

Интересные вопросы:
1) с какой точностью будет поддерживаться частота, формируемая ФБ;
2) будет ли эта частота держаться стабильно или будет плавать.

Например, задали частоту 1000,11 Гц. Подключим к выходу ПЛК частотомер и что увидим ?

Если частота сформированного сигнала будет точной и стабильной, то имеет смысл использовать формат REAL.

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

1) с какой точностью будет поддерживаться частота, формируемая ФБ;
Если PRU управляет одним выходом (пока это так), то точность ширины импульса составляет где-то 0.01мкс (один-два такта PRU, частота которого 150МГц)


2) будет ли эта частота держаться стабильно или будет плавать.
С точки зрения алгоритма, плавать не будет. В реальности -- всё зависит от того, насколько точно PRU процессор держит свою частоту 150МГц.

Можно ли от одного PRU запитать сразу 2 ШД -- пока не знаю, надо подумать.


Например, задали частоту 1000,11 Гц. Подключим к выходу ПЛК частотомер и что увидим ?
Сейчас для вычислений используется целое значение частоты.
Например, для 1000Гц импульс будет 75000 тактов единица, потом 75000 тактов ноль.
Для 1000.11 можно было бы сделать 74992 единица, 74992 ноль -- по факту это было бы 1000.1067 Гц == 150e6/(2*74992)

Поэтому я и говорю, что если заложить REAL'ы с самого начала, то потом уже можно подстраиваться.

[Newcomer]

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

[Newcomer]

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

Понял, что Ситников был прав и написал об этом.

А вы про у ускорение забыли.

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

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

И?

Тут "перед вызовом блока" предлагается сделать расчёт времени разгона.
Именно так и просил Newcomer с самого начала -- просил, чтобы на вход блоку давалось "время разгона".

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

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

Насколько сложна интерполяция из 100011 в 74992 чтоб не связываться с реалами. Практически все панели умеют на экране ставить точку после заданного количество знаков, а передавать всё равно целочисленное

Эх, панели, панели.

Я примерно из-за этого и спрашивал "есть ли смысл REAL".
Если реально с REAL'ами очень тяжело, то, возможно, придётся делать "частоту, умноженную на 100" или что-то такое.

[Newcomer]

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

[Newcomer]

Нет в CoDeSys никаких проблем с REAL.

[capzap]

И?

Тут "перед вызовом блока" предлагается сделать расчёт времени разгона.
Именно так и просил Newcomer с самого начала -- просил, чтобы на вход блоку давалось "время разгона".

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

[Newcomer]

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

[Newcomer]

Если задавать ускорение, как предложил В.Ситников, то никакие времена не нужны. Проще один раз для конкретной механической системы с ШД подобрать предельное ускорение чем каждый раз подбирать времена.

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

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

1) Длительность импульса я вычисляю как просто 150'000'000/частота в целых числах. Тут может быть погрешность. Относительная погрешность растёт линейно и составляет 0.15% для частот порядка 100кГц (т.е. 150Гц для 100кГц, и примерно 2Гц погрешности на частотах 10кГц)
Тут повысить точность можно, но я почему-то сразу не думал об этом.

2) "синхронизируюсь" я по выполненным тактам самого процессора. Т.е. считается, что процессор работает на частоте 150МГц, и у него есть счётчик количества выполненных команд. На основе этого счётчика я и делаю задержки. Так сказать, "наматываю счётчик" выполнением пустых команд, пока он не достигнет нужного значения. Конечно, хорошо бы в реальности проверить и измерить частоту.

Плавает ли частота у самого кристалла -- фиг знает.

[Newcomer]

Если для формирования тактовой частоты кристалла используется кварцевый генератор, то частота будет стабильной. Это надо у В.Филоненко узнать стоит у них кварц на PRU или нет.

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

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

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

[Newcomer]

Если на выходе ФБ можно будет иметь кварцованную (высокостабильную) частоту, которую можно менять в широких пределах, то это расширяет область использования этого ФБ. В этом случае для задания частоты имеет смысл вводить формат REAL.

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

А про время там написано? Так то я не к Вам обращался а к оппоненту, но Вы то решили его поддержать только из-за меня?
Там говорится про "количество импульсов на разгон" и про "частоту шага замедления/ускорения".
Это практически то же самое, что и "время разгона". Прямо реально то же самое.


Вот тут было:

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

Мне было непросто переубедить Newcomer'а, но в конце концов мы поняли друг друга. Я понял, что Newcomer мыслил "по дельтавски", а он понял, что мой вариант будет удобнее.


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

Если будет потребность в блоках на "составное движение" (грубо говоря, восьмёрки двумя ШД выписывать), то можно и такое сделать. Но, опять же, там речи о "количесте импульсов на разгон" и/или "времени разгона" не будет.



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

[Newcomer]

ни чуть не сомневался что Вы не прощаете условности только мне, пусть частота и импульсы это реально время, а не частота и импульсы.
Но вот на приведенном скрине, с каждым шагом время уменьшается, согласно тому как они рассчитывают, документ уже закрыл но видел там что и разгон/торможение идет не по линейному закону, на Ваших картинках получается линейно, дельта имеет возможность на практике крутить свои ШД, у Вас его еще нет. Сомнений нет что не спроста у них так задумано?

Разгон и торможение ШД обычно производят по S-образной кривой. Что будет при постоянном ускорении пока не ясно. У Прибориста есть стенд с ШД для проверки ФБ. Вот он погоняет ФБ и все нам расскажет.

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

Разгон и торможение ШД обычно производят по S-образной кривой. Что будет при постоянном ускорении пока не ясно. У Прибориста есть стенд с ШД для проверки ФБ. Вот он погоняет ФБ и все нам расскажет.

Справедливости ради, в дельте S-кривой нет. По крайней мере, то, что описано на стр. 92 и вокруг говорит о том, что дельта делает ступенчатое увеличение скорости.
У меня -- линейное увеличение скорости, а у них ступеньками.
Разумеется, в момент перехода с одной ступеньки на другую могут быть проблемы.

Реальная система не может скачком изменить скорость.

S-кривые это уже про "плавное изменение самого ускорения".


Может показаться, что график внизу 93 страницы "диаграмма, иллюстрирующая выполнение программы" показывает "нелинейное увеличение скорости", но это только на первый взгляд.
По оси X у них не время, а "количество импульсов". Количество импульсов от времени зависит нелинейно, поэтому из самого графика крайне сложно понять "как зависит скорость от времени"
И вообще, возможно, сам график у них неправильный (в смысле, ошибка в самом графике).

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

Авторы дельта неправы. Я сделал так, как надо

это ПЯТЬ!!!! Овен - ретрограды, Дельты - косячат ))) Что осталось?! Омрон да Сименс опустить ))) и на освободившейся поляне ярко засияет восходящая звезда промавтоматики! ))))))

пы.сы Алиенбрадли и Ваго мелко дрожжат от ужос-ужоса! ))))

[Newcomer]

это ПЯТЬ!!!! Овен - ретрограды, Дельты - косячат ))) Что осталось?! Омрон да Сименс опустить ))) и на освободившейся поляне ярко засияет восходящая звезда промавтоматики! ))))))

пы.сы Алиенбрадли и Ваго мелко дрожжат от ужос-ужоса! ))))

Вы в стиле А.Блока пишите. Как это у него ?

Мы на горе всем буржуям
Мировой пожар раздуем

[Newcomer]

По оси X у них не время, а "количество импульсов".

Там два графика.

[capzap]

Надо признать гениально, с такими то допущениями
Это практически то же самое, что и "время разгона" переменная accel_ramp := 10000/10 легко может превратится во два входных аргумента количество импульсов за разгон и частота шага, зато можно говорить что не так как у Дельты

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

Надо признать гениально, с такими то допущениями переменная accel_ramp := 10000/10 легко может превратится во два входных аргумента количество импульсов за разгон и частота шага, зато можно говорить что не так как у Дельты

Молчали бы лучше и не засоряли тему.

Скажите как на дельте решить вот такие задачи: http://www.owen.ru/forum/showthread.php?t=22169&page=35&p=221507#post221507

На моём ФБ они решаются в одну строку (http://www.owen.ru/forum/showthread.php?t=22169&page=35&p=221503&viewfull=1#post221503).
На дельте без пол-литра они не решаются.

Это и подтверждает тот факт, что между блоками есть существенное отличие.

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

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

Цитирую первую задачу №1: Сделать 300 импульсов, максимальная скорость 60 Гц.
Это полный цикл, включая разгон, ход, и замедление. За весь цикл должно быть ровно 300 импульсов.
Сделаете такое на дельте -- тогда и продолжим разговор.


, на 92 стр. обсуждается функция разгона, если прочитать весь апи то найдется и под Ваши ТЗ что нибудь обязательно

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


Newcomer со мной согласился.
И он, похоже, гораздо лучше вас разбирается в дельте.

[Newcomer]

Господа, прекращайте этот спор. Стендовые испытания все покажут. Владимир, когда ваш ФБ будет полностью готов чтобы Приборист смог его как следует погонять ?

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

Господа, прекращайте этот спор. Стендовые испытания все покажут. Владимир, когда ваш ФБ будет полностью готов чтобы Приборист смог его как следует погонять ?

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

Собственно, 4-ая версия ШД-программы: http://www.owen.ru/forum/showthread.php?t=22169&page=37&p=221591&viewfull=1#post221591

Можно добавить минимальную скорость (ну, чтобы стартовало не с нулевой скорости, а, скажем, с 500 Гц).
Ещё нужно придумать как завести PRU1.

Ну и подумать над S-кривой.

[Newcomer]

Ещё нужно придумать как завести PRU1.

Что значит завести PRU1 ?

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

Что значит завести PRU1 ?

В ПЛК110 два сопроцессора PRU0 и PRU1.
Оба работают на частоте 150МГц.

К PRU0 подключены "fast out 3, 4"
К PRU1 подключены "fast out 1, 2" и "fast in 1, 2, 3, 4".

Чтобы задействовать 2 ШД нужно либо в программу для PRU0 встраивать одновременное управление двумя выходами (это сложновато, т.к. каждый выход будет пытаться работать на своей частоте, а цикл общий), либо "просто" запитать ШД1 от PRU0 и ШД2 от PRU1.

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

Тут, я уже говорил, если кто-нибудь покажет хоть какой-нибудь пример PRU1 программы, которая оперирует со счётчиком команд -- будет хорошо.
В примерах "ОВЕН" про PRU1 ни слова.

Кто-нибудь может залить приложенные файлы под именем PRU1.prg? (PRG0.prg тоже должен быть. Как вариант -- можно одновременно файл как PRU0 и PRU1 заливать)

В результате -- один из выходов должен мигать с частотой 10кГц.
26700
Тут внутри 3 разновидности: blink1, blink2, blink3. Они должны делать одно и то же. Собственно, вопрос: какие из программ будут реально мигать выходом (1-ым или 2-ым быстрым выходом)

[Newcomer]

А отец-основатель В.Филоненко что про это говорит ?

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

Чтобы задействовать 2 ШД нужно либо в программу для PRU0 встраивать одновременное управление двумя выходами (это сложновато, т.к. каждый выход будет пытаться работать на своей частоте, а цикл общий), либо "просто" запитать ШД1 от PRU0 и ШД2 от PRU1.


т.е. вы меняете время цикла ПРУ с каждым шагом?

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

т.е. вы меняете время цикла ПРУ с каждым шагом?

Да, а что?

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

А отец-основатель В.Филоненко что про это говорит ?

Переспросил почтой.

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

хотелось бы напомнить что я претендую на превосходство в разбирании АКМ,в объектах в названии которых встречаются пару цифр до буквы Ж и одной цифры после, еще несколько названий обозначающих бескрайние просторы России.

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



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


По поводу задач, да хоть вторую, хоть первую, а что в ней основное? Сколько импульсов будет сам ход, сколько отведено на разгон и торможение, для Вас это абстрактные понятия, ну сколько расчитаем/подберем
В том-то и дело, что:
1) В случае дельты нет простого способа рассчитать "количество импульсов на разгон".
2) Если подбирать, то подбирать придётся для каждого конкретного значения "общего количества импульсов и макс скорости".

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


Ясен пень, что "рано или поздно" можно решить задачу "перемещения на 400 импульсов" на дельте.
Другое дело, что если меняются условия (например, количество импульсов или скорость), то в случае дельты подгонометрией нужно заниматься заново, а в моём случае -- достаточно просто использовать правильный параметр.


а кому то это важно и походу Вы не собираетесь это учитывать, опять получается делаете как Вам вздумается а не для потребителя
Вы уже в который раз показываете своё непонимание физики/математики и их прикладных применений.
С ГСЧ вы бесконечно долго пытались убедить, что "в ПЛК законы математики не действуют".
И тут тоже пытаетесь убедить, что "а не для потребителя".

Хватит тугодумить. Если хотите развиваться, то учитесь думать и слушать других.

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

[приборист]

Разгон и торможение ШД обычно производят по S-образной кривой. Что будет при постоянном ускорении пока не ясно. У Прибориста есть стенд с ШД для проверки ФБ. Вот он погоняет ФБ и все нам расскажет.

Еще раз повторюсь, ШД у меня нет.
У меня драйвер сервопривода Ledshine с сервомотором (+ энкодер в нем).
Завтра притащу второй.

Залил программу в ПЛК.
Работает интересно :)
При отсутствии торможения\разгона - двигатель проворачивался на месте в момент старта и стопа (стоит жопой на полу, ось получается перпендикулярно полу).
Соответственно на оборудовании при таком никому не нужный удар.
При применении торможения\разгона - все плавненько.
По хорошему проверить бы количество передаваемых импульсов (для меня критично, потому что в итоге может накапливаться ошибка)
Но осциллографа нет, проверить нечем.

Скорости более 10000 мне врядли пригодятся (драйвер улетает в ошибку в районе 23000-25000).
Интересно выставляется скорость разгона\торможения. Можно разгонять и за секунду, и за пол-секунды либо сразу с ходу.
Режим без остановки - тоже работает.
В общем респект!
Как это будет работать на реальном объекте - не знаю.
Попробовать смогу лишь при работе двух сервомоторов.

P.S.
ШД в моем понятии не имеет обратной связи в виде энкодера и управляется чисто шагами.
Хотя может разница лишь в энкодере и типе двигателя (у меня трехфазный)

[приборист]

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

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



тогда вопрос а как ЭТО применять остальным на реальном производстве?
Первым - на свой страх и риск.
А далее по отзывам.

[rovki]

Вот так стенд для проверки ШД :confused:

[capzap]

А каким образом вообще это возможно.

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

[rovki]

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

[приборист]

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

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

[capzap]

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

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

[rovki]

Кому нужны вываливания в ошибку ,разве только как защита ...

[приборист]

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

Хотя вот в аналоге драйвера написано - шаговый двигатель с энкодером.
Работает только с трехфазными ШД с энкодером, с ШД без энкодера неработает.

Кто проведет ликбез по ШД?))
Всегда думал что и к ШД идут драйверы, которые управляются по STEP\DIR (точно такими же импульсами 200\500 кГц)

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

Кто проведет ликбез по ШД?))

Давайте я скажу: ШД это просто двигатель, без обратной связи. Сменили ток в обмотках -- он сдвинулся.
Серво -- это система с обратной связью.

Т.е. серво система может быть устроена как "простой ШД + энкодер + ПИД (ну или любой другой) регулятор для отслеживания обратной связи".
Например, этот самый драйвер, может заметить, что "импульс пропущен" и попытаться послать ещё один (или пропустить, если был лишний импульс)


Для серво может быть управление ШИМ сигналом. Грубо говоря, ситуация, когда скважность сигнала задаёт фактический угол, на который должен быть повёрнут вал двигателя.
Например, для управления рулём высоты: подаём ШИМ 50% (импульсы идут, но длительность 1 равна длительности 0) -- руль стоит на середине. Подаём шим 70% (70% времени единица, 30% времени 0) -- руль отклоняется на сколько-то градусов и замирает в новом положении.

Простой ШД без обратной связи так не сможет.

Серво могут управляться по-разному. Как импульсами, так и ШИМ сигналом, аналоговым и т.п.
ШД -- импульсами.

[capzap]

Да, поэтому и тестирую.

Хотя вот в аналоге драйвера написано - шаговый двигатель с энкодером.
Работает только с трехфазными ШД с энкодером, с ШД без энкодера неработает.

Кто проведет ликбез по ШД?))
Всегда думал что и к ШД идут драйверы, которые управляются по STEP\DIR (точно такими же импульсами 200\500 кГц)

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