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

[capzap]

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

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

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

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

Если PRU*.prg не залиты, то входы-выходы работают как обычно.
Если PRU*.prg залиты, то входы-выходы работают согласно залитой программе. В текущей моей "программе ШД" входы никак не обрабатываются, поэтому Дима и пишет, что "перестают работать входы".


Другое дело, что всем нужно одновременно и ШД крутить, и со входов информацию получать.
Для этого есть 2 варианта:
1) Звонить в ОВЕН
2) Просить меня, чтобы расширить "программу ШД" и добавить туда какую-нибудь обработку входов

[dima64]

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

Я просто удаляю PRU0, PRU1 из ПЛК-браузер, перегружаю, и все ПЛК чист, как из коробки.
Кстати, если PRU1 не загружен, то первые 2 быстрых выхода работают из конфигуратора.

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

Вердикт: эксперимент показывает, что регистры _не_ переиспользуются. Тут всё ровно так, как и говорил Владислав.

Дмитрий, я требую извинений.



Вот пример: Вложение 26836, Вложение 26834

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

Компилируем и видим такое (в конце):

#defFB PRU_AND2_64 PRU_AND2 
R8.b2 
R8.b3 
R9.b0 

#defFB PRU_AND2_59 PRU_AND2 
R7.b1 
R9.b0 
R9.b1 

#defFB PRU_AND2_65 PRU_AND2 
R5.b2 
R9.b1 
R9.b2

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

Пойдём в target.trg файл, и уменьшим значение REG_END=28 до 8-и. Ну, сделаем вид, что в нашем PRU всего-навсего 8 регистров.

Что нам скажет компилятор?
Он нам скажет "unknown ID 0 in element", и вообще не сможет скомпилировать такое FBD.

Т.е. по факту, компилятору не хватило R2..R8 регистров (7 штук по 4 байта каждый, т.е. 28 байт!).
А по факту, видно, что регистры для "AND" блоков очень быстро становятся ненужными.

По факту, тут 4 "FROM_HOST" блока. Да, 16 байт действительно нужно постоянно хранить (информация с HOST'а обновляется далеко не в каждом PRU цикле). Но остаётся целых 12 байт == 28-16, и линкер всё равно не смог выполнить несколько AND'ов? Что за ерунда?

Поэтому я и говорю, что мой подход и подход ОВЕН в части компиляции существенно отличаются.
Ну это я к чему, не к тому, что "инструмент beta PRU плохой", а к тому, что это моя аргументация почему я не могу просто взять и оформить свою ШД программу "по правилам ОВЕН". Тут не только моё субъективное "не хочу тратить время", но и вполне конкретная техническая проблема.

в этом примере дело не в "анд"-ах а в 4-х кратном размещении "pru_host". в том виде как он сделан в библиотеке - он читает 1 фиксированный регистр

кстати, продам наблюдение - "подход овена" - это по сути локализация (русификация с извращениями) соответствующего инструмента TI, т.е. достаточно широко используемого инструмента.... Ну конечно "черепаха" круче всего мирового опыта программирования - тут без сомнений. Керниган, Ричи и Кнут плачут горькими слезами ))))

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

В ПЛК Delta не зря сделано нелинейное ускорение.

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

delta_reply.png

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

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

Если PRU*.prg не залиты, то входы-выходы работают как обычно.
Если PRU*.prg залиты, то входы-выходы работают согласно залитой программе. В текущей моей "программе ШД" входы никак не обрабатываются, поэтому Дима и пишет, что "перестают работать входы".


Другое дело, что всем нужно одновременно и ШД крутить, и со входов информацию получать.
Для этого есть 2 варианта:
1) Звонить в ОВЕН
2) Просить меня, чтобы расширить "программу ШД" и добавить туда какую-нибудь обработку входов

ну или делать на совместимость с блоками овена - тогда любой может нарисовать нужную ему картинку )))

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

в этом примере дело не в "анд"-ах а в 4-х кратном размещении "pru_host". в том виде как он сделан в библиотеке - он читает 1 фиксированный регистр

Вот вариант с 1 PRU_FROM_HOST.
Всё равно не работает с параметрами REG_START=2, REG_END=6. В прошлый раз я не учёл, что "последний" регистр линкер не использует, т.е. по факту REG_START=2, REG_END=6 это не 4, а 3 регистра для манёвров, но на такую схему 3 регистра вполне должно хватать?
Т.е. регистров R2, R3, R4, R5 ему оказывается мало для того, чтобы сделать AND'ы от одного-единственного PRU_FROM_HOST.

В чём проблема на этот раз?
linker_and_limitation.png

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

ну или делать на совместимость с блоками овена - тогда любой может нарисовать нужную ему картинку )))

Во-первых, я уже писал почему это сделать невозможно.

А во вторых, ещё причина: блоки ОВЕН поддерживают _только_ байтовые входы-выходы. Хотите WORD/DWORD -- уже никак.
И как с этим работать?

[capzap]

Я просто удаляю PRU0, PRU1 из ПЛК-браузер, перегружаю, и все ПЛК чист, как из коробки.
Кстати, если PRU1 не загружен, то первые 2 быстрых выхода работают из конфигуратора.

надеюсь к загрузочному проекту это не относится, просто наличие файлов в плк имеет значение

[capzap]

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

на скрине и со слов автора скрина влияние программа ПРУ оказывает и на два обычных входа или же четыре входа, четыре выхода, не зависимо от того какой у них тип