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

[приборист]

Так у 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 Вольда
2) Либо arduino

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


Кстати, есть желающие в имеющийся блок PRU_GENER_BURST добавить поддержку параметра "бесконечное количество повторений" и "раздельного указания длины единичного и нулевого импульса"?
Это 3-я задача, и тут никакого ассемблера не нужно. Достаточно просто ST код поправить.

[приборист]

Понял.

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

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

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

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

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

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

Лучше такой порядок, чтобы можно было к ОВЕН прийти с вариантом (например, с проектом):
1) Либо решаем вопрос #196 Вольда
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 МГц и и примененные опропары не отработают фронты на данной частоте