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

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

А что такое PULSES_GENERATED ?

PULSES_GENERATED это количество фактически сгенерированных импульсов.

Где то, что подается на быстрый дискретный выход ПЛК ?

Как где?
Внутри программы. Если вы не поняли, то у меня "самодостаточная программа". Т.е. заливаем PRU0.prg/PRU1.prg и всё. Можно управлять ШД.
Номер выхода задаётся через OUT_NUM: BYTE; (* 1, 2, 3, or 4 *)

Какой смысл делать выходной параметр "OUT", если вы его всё равно ни к чему подключить не сможете?
Не в основном же цикле собрались переключать быстрые выходы?

И, да, ОВЕН не разрешает создавать *.prg файлы из hardella, а адаптировать ШД программу "под ОВЕНовский beta-формат PRU ФБ" я смысла не вижу.

С одной стороны, просто смысла нет. Ну кто реально будет через КДС и bat'ники создавать программы?! Есть желающие? Поднимайте руки! Только помните, что для сложения двух переменных нужен один блок, а для сложения переменной и константы -- другой.
И, с другой стороны, моя ШД программа требует довольно много регистров и это будет тяжело подружить с "ОВЕН beta компилятором", т.к. ОВЕНовский вариант идёт совсем в противоположном направлении: у меня регистры активно переиспользуются по ходу программы, а ОВЕН вариант предполагает, что даже после простого блока PRU_ADD регистры переиспользовать нельзя. Пара ОВЕНовских блоков, и всё, закончились регистры.

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

[dima64]

PULSES_GENERATED это количество фактически сгенерированных импульсов.


Как где?
Внутри программы. Если вы не поняли, то у меня "самодостаточная программа". Т.е. заливаем PRU0.prg/PRU1.prg и всё. Можно управлять ШД.
Номер выхода задаётся через OUT_NUM: BYTE; (* 1, 2, 3, or 4 *)

Какой смысл делать выходной параметр "OUT", если вы его всё равно ни к чему подключить не сможете?
Не в основном же цикле собрались переключать быстрые выходы?

И, да, ОВЕН не разрешает создавать *.prg файлы из hardella, а адаптировать ШД программу "под ОВЕНовский beta-формат PRU ФБ" я смысла не вижу.

С одной стороны, просто смысла нет. Ну кто реально будет через КДС и bat'ники создавать программы?! Есть желающие? Поднимайте руки! Только помните, что для сложения двух переменных нужен один блок, а для сложения переменной и константы -- другой.
И, с другой стороны, моя ШД программа требует довольно много регистров и это будет тяжело подружить с "ОВЕН beta компилятором", т.к. ОВЕНовский вариант идёт совсем в противоположном направлении: у меня регистры активно переиспользуются по ходу программы, а ОВЕН вариант предполагает, что даже после простого блока PRU_ADD регистры переиспользовать нельзя. Пара ОВЕНовских блоков, и всё, закончились регистры.

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

Да, но при таком подходе мы теряем 4 входа и 2 или 1 (без PRU1) выхода. А вариантов задач может быть миллион. На каждую задачу придется свои PRU делать.

[dima64]

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

Перестают управляться 2 быстрых (ПЛК-110.32) и первые 2 простых входов. Входы.jpg
Не заливать, конечно можно, но и генерировать нечем будет. Нафига тогда эти PRU предложили?

[Newcomer]

Перестают управляться 2 быстрых (ПЛК-110.32) и первые 2 простых входов. Входы.jpg
Не заливать, конечно можно, но и генерировать нечем будет. Нафига тогда эти PRU предложили?

Это проблемы роста.

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

как ему вернуть управление быстрыми входами/выходами в конфигуратор

На этот вопрос (можно ли выводить результаты PRU программы в "plc configuration") тов. Филоненко говорит решительное нет. Ну, что, якобы, адреса памяти КДС назначает произвольно, что это в концепцию ПЛК110 не укладывается и т.п.

С моей точки зрения, звучит, конечно, неубедительно. Свои fast encoder/fast counter программы в ОВЕН как-то сделали и в конфигуратор сумели вывести? Значит и для PRU программ такая возможность может быть. Да, возможно, это потребует доработку прошивки, но fast encoder же как-то сделали модулем в plc configuration?

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

Обмен только через pruaccesslib.lib? Ну, ок.

Конечно, и в части "обмена host-pru" можно сделать более удобные механизмы, но нет никакого смысла тратить время и силы на обсуждение механизмов обмена данными и plc configuration, если ОВЕН молчит про саму возможность составлять PRU программы.

[Филоненко Владислав]

На этот вопрос (можно ли выводить результаты PRU программы в "plc configuration") тов. Филоненко говорит решительное нет. Ну, что, якобы, адреса памяти КДС назначает произвольно, что это в концепцию ПЛК110 не укладывается и т.п.

С моей точки зрения, звучит, конечно, неубедительно. Свои fast encoder/fast counter программы в ОВЕН как-то сделали и в конфигуратор сумели вывести?

Вот через pruaccesslib.lib и работает. Другим способом получить синхронизацию без остановки PRU и без неопределённого по времени доступа из PRU в основное ОЗУ (от десятков до тысяч тактов, если крайне не повезёт с моментом обмена) нельзя.

Но, конечно, всегда есть путь Илона Маска.

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

Вот через pruaccesslib.lib и работает

Таки есть возможность выудить данные через pruaccesslib, и запулить их в "plc configuration" уже средствами host'а?

Да, складывать из PRU в ОЗУ, конечно, расточительно. Разве что одно из PRU ядер "потратить" на обмен с DDR памятью, но это стрёмный путь

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

Вот через pruaccesslib.lib и работает. Другим способом получить синхронизацию без остановки PRU и без неопределённого по времени доступа из PRU в основное ОЗУ (от десятков до тысяч тактов, если крайне не повезёт с моментом обмена) нельзя.

Но, конечно, всегда есть путь Илона Маска.

COUNT_DUBL_POINT := PRU_DRAM + OFFSET;
COUNT_DUBL_POINT^ := 16#01020304;

>>>>
LBCO &R28, CONST_PRUDRAM, 128, 4 // временно - считать 4 байта и положить в 28 рег дл_ тестирования проброса - работает
>>>>

понятно что не синхронно, но для некоторых применений прокатит...

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

COUNT_DUBL_POINT := PRU_DRAM + OFFSET;
COUNT_DUBL_POINT^ := 16#01020304;

>>>>
LBCO &R28, CONST_PRUDRAM, 128, 4 // временно - считать 4 байта и положить в 28 рег дл_ тестирования проброса - работает
>>>>

понятно что не синхронно, но для некоторых применений прокатит...

Шайтан. Это же вообще огонь-технология!
Если надо синхронность, то просто делаем WHILE COUNT_DUBL_POINT^ ... END_WHILE; и всего делов.

Может, ещё и структуру/массив можно разместить по адресу PRU_DRAM?
Если такое применить, то вообще огонь будет. Не то, чтобы "немного не по правилам", а "вообще не по правилам" )

Ну и нужно будет к Вольду обратиться. Он очень метко эпитеты подбирает.

[Филоненко Владислав]

COUNT_DUBL_POINT := PRU_DRAM + OFFSET;
COUNT_DUBL_POINT^ := 16#01020304;

>>>>
LBCO &R28, CONST_PRUDRAM, 128, 4 // временно - считать 4 байта и положить в 28 рег дл_ тестирования проброса - работает
>>>>

понятно что не синхронно, но для некоторых применений прокатит...

Это крайне медленно и внутренняя шина может быть в этот момент занята обменом с чем-нибудь другим => непредсказуемая задержка.