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

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

В чём проблема на этот раз?
Вложение 26850

Забавы ради сделал такую же программу в черепахе.
Выглядит, конечно, не супер, но я сделал так, чтобы было сравнение 1 в 1. Точно такой же ФБ PRU_AND.

Если кратко, то черепахе оказалось достаточно 4 байт для "FROM HOST" и 5 временных байт (т.е. хватило всего 9 байт регистровой памяти)
"линкер от ОВЕН" не смог скомпилировать эту программу и с помощью 20-и байт регистровой памяти.



Само по себе использование ФБ для компилятора сложнее (чем "встроенные" функции AND), т.к. у ФБ значения выходов нельзя терять. Например, если они на каком-то цикле значения не передавались (а был просто вызов ФБ), то нужно использовать "прошлые" значения входов.
Т.е. самый простой вариант -- всегда выделять отдельные регистры для каждого входа и выхода, но это порождает "потенциально лишнее копирование из одной переменной в другую" и потенциальный перерасход регистров. Я так понял, Владислав пропагандирует именно такой способ.
Как видим, 15 AND'ов скомпилировать таким подходом уже проблема. По-моему, это слишком высокая плата за мнимую "надёжность".

Снимок экрана 2016-10-04 в 18.28.36.png

Я сделал PRU_AND2 как "полноценный блок".
Блок-то он отдельный, но компилятор "видит его насквозь" и понимает суть происходящего. Мой компилятор понимает, что ассемблерная инструкция AND всегда записывает выходную переменную, т.е. компилятор догадывается, что для этого блока статичный выходной регистр не нужен.

Результирующий код использует следующие регистры:
R1 -- 4 байта для PRU_FROM_HOST
R2 и R3.b0 -- 5 временных байт.

Да, сама программа получилась не супер -- 31 инструкция (если отбросить HOST/OUT и т.п. обёртку), т.к. осталась часть команд "присвоения входов-выходов" для блоков PRU_AND2.
Снимок экрана 2016-10-04 в 18.33.24.png

Под конец только AND'ы идут, т.е. прямо "идеальный код":
Снимок экрана 2016-10-04 в 19.07.09.png


Но мы же на ST пишем?
Что мешает сделать IF (AND AND) THEN?
Ничего. Немного копипасты и получается такое:
Снимок экрана 2016-10-04 в 19.11.58.png

Тут ассемблерный код получается куда лаконичнее. Компилятор просто использует "условные переходы" и прерывает выполнение на первом же FALSE.
Снимок экрана 2016-10-04 в 19.13.28.png
Тут вообще ни одного дополнительного регистра не понадобилось. Просто кучка условных переходов.

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

[dima64]

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

Совершенно верно.

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

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

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

Это не так. Вам ли, как имеющему расширенный пакет с исходниками ФБ это не знать.
Конкретная реализация библиотеки сейчас имеет только байтовый I/O.
Полноценный редактор будет иметь полиморфизм I/O (выбор типа по необходимости)

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

что конкретно? Например появился такой вопрос к Ситникову, если человеку надоело играться с программой для ШД, как ему вернуть управление быстрыми входами/выходами в конфигуратор, есть empty блок который освободит работу ПРУ

Стереть файл PRUx.prg

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

Похоже ОВЕН отстранился от этой темы.

ОВЕН не устранился от темы, а устранился от пути, по которому Акела ведёт стаю.

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

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

Регистры не переиспользуются и не должны.
Исключения т.н. макросы (сборки из блоков без внутренней памяти с однозначным потоком исполнения без циклов, например комплексный 4ANDNOT из 3-х AND и NOT).

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

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

На самом деле при байтовом I/O PRU уже имеет до 28*4 только регистровых переменых. А битовых в 8 раз больше. + куча ОЗУ.
Для логики RT управления дискретными I/O этого более чем достаточно.
А вот если всякие S-кривые в плавающей точке вычислять 1000000 раз в секунду - тут надо подход изменять, а не brute forсe-ом ломится.

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

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

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

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

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

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

Концепция сверхжёсткого реального времени с 100% гарантией исполнения алгоритма не позволяет переиспользовать ресурсы

1) На самом деле, позволяет. Например, для умножения WORD'ов достаточно сделать 16 итераций цикла. На этих итерациях можно переиспользовать переменные. Никто не пострадает. Можно всегда крутить все 16 итераций и время выполнения вообще константным будет. А можно и выходить из цикла пораньше (если числа маленькие) -- тогда останется время на другие задачи.
2) Для большинства типичных случаев сверхжёсткий realtime и не нужен. Ну на кой нужен этот самый realtime, если мы ШД крутим?

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

Раз говорите, что "обратную связь" (линию задержки) сделать сложно, то не буду голословным, а просто возьму и сделаю.

Вот ФБ для "линии задержки":
Снимок экрана 2016-10-04 в 20.29.51.png

Вот программа с его использованием. Надеюсь, вы понимаете, что FBD программы в такой ST код переводятся в режиме "что вижу, то пою"?
Для преобразования FBD в такой ST код нужно лишь объявить переменные с ФБ и присвоить входные-выходные значения.
Да, топологическую сортировку FBD, конечно, сделать придётся, но это вовсе не вопрос "где нужна доп ячейка, а где не нужна".

И, да, я ни строчки кода в компиляторе не менял. Просто добавил ФБ и создал программу с его участием.
Снимок экрана 2016-10-04 в 20.38.11.png

Вот результирующий ассемблер:

Снимок экрана 2016-10-04 в 20.38.49.png

"промежуточная" ячейка образовалась сама собой. R1.b1 (для первой обратной связи) и R1.b2 (для второй).

Ну, я, конечно, понимаю, что "с первого раза никогда ни одна программа не получается", но не вижу никаких сложностей с обратными связями. Честное слово не вижу.
Вот я написал простой ST, и он сразу заработал. В чём реально проблема?

Мой план -- FBD программы преобразовывать в ST, а потом обрабатывать уже имеющимся ST компилятором.
И наглядность FBD сохранится, и всегда можно будет проверить "во что оно превратилось" / "на каком этапе косяк".

На всякий случай, я использую следующие ключевые слова: dataflow analysis, live variable analysis, linear scan register allocation. Первые два алгоритма реализовывал не я, а они встроены в среду, на которой я пишу Hardella.


И, да, сейчас в ОЛ поведение "если есть цикл в программе, то разрывать его и где-то автоматически делать обратную связь", но, на мой взгляд, это нехорошее поведение. Если делать FBD в Hadrella, то я хотел запретить явные циклы, и всегда требовать от пользователя указания где именно связь с задержкой на такт.

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

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

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

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

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

На текущий момент 4 (ЧЕТЫРЕ) человека вообще проявили какой-либо интерес к технологии и соизвоили хотя бы письмо мне написать, чтобы получить пакет тестировщика. Четыре, Карл!

Но зато уже двое провели натурные испытания программы ШД на ШД и servo.
И это при том, что ОВЕН нигде не объявлял о "поддержке ШД в ПЛК110", и при том, что сарафанное радио ещё не особо сработало.
И при том, что вокруг PRUграммирования царит туман неизвестности (ОВЕН свои планы не озвучивает, а чужие разработки отрицает).

Объявите на сайте/в рассылках не о "пакете тестировщика PRU программ", а о "поддержке ШД/серво в ПЛК110".
И посмотрим сколько будет желающих.

Вариант "заливаем PRU0.prg через КДС" и используем PRU_STEPPER(MAX_FREQ:=10000, QUANTITY:=1234, OUT_NUM:=1) понятен даже домохозяйке.
Ошибиться можно разве что в схеме подключения ШД.



Разумеется, "готовых PRUx.prg" на все случаи не напасёшься, и в реальности понадобится либо конфигуратор, либо среда программирования.
Но для первой версии достаточно и простой PRUx.prg программы.