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

[приборист]

Понял.

Думаю, понимаете, сделать "рабочий" 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.
Вообще ситуация до безобразия комична.
ОВЕН выпускает прибор, заявляет параметры, но они не работают, а пользователи клещами тянут информацию, чтобы САМИМ все доделать за ОВЕН.

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

"Правильный" шим это что?

Это 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.

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

Мне интересен ... 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".