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

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

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

[приборист]

На данный момент меня интересует возможность работы 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?

[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

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