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

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

вы главного упорно не видите, в приведенном выше коде - 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 (немного другая): pru_pulse_v3.zip

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

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...icroprocessor/

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/1...-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% по-моему, норм.
accel_5kHz_output.png

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


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


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

accel_100kHz_cpu_utilization.png


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

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

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

[Вольд]

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

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

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

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

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

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

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

accel_100kHz_20sec_cpu_utilization.png

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