LabVIEW Portal

Иногда требуется расширить функциональные возможности программного обеспечения, когда оно уже скомпилировано и установлено. В этом случае часто используется архитектура Plug-in, которая позволяет добавление функциональных блоков в виде plug-in-ов.

Прикрепленная презентация описывает plug-in архитектуру с использованием packed project библиотек. Такие библиотеки позволяют передавать коды в скомпилированном виде, без блок диаграмм. Таким образом возможно добавить новые функции в ПО, только передавая библиотеку plug-in-ов.

Меня интересует эта тема давно, где простейший пример посмотреть? Используя в своих проектах Actor Framework, при всей скорости создания новых классов, наследуя большинство функционала от родителя, мне все равно приходится перекомпилировать весь проект. Так же до сих пор интересует этот вопрос

taras_33 писал(а):Меня интересует эта тема давно, где простейший пример посмотреть?

Посмотрите ссылки здесь - https://forums.ni.com/t5/Mass-Compilers ... -p/3490662, последний ответ в той теме. Мне оттуда пример https://forums.ni.com/t5/LabVIEW-Develo ... -p/3514395 помог был.
Насчет вопроса удаления дочерних классов при Factor Pattern - вполне возможно, что ситуация так и не поменялась; так что прошлые ссылки валидны - такие, как https://lavag.org/topic/17726-factory-p ... om-memory/.
Но вот я подумал - при использовании классов типа GOOP, что работают через Memory Reference - для них есть метод Destoy. Может он "униичтожает" ссылку на класс, а значит, и освобождает память? Вы пробовали играться с GOOP-ными классами?

Спасибо за ссылки, полезная информация. Заинтересовался примером PluginArchitecture_withMessageQueuesAndSubPanels скачал архив, перекомпилировал под версию LV2014. Все работает, только не совсем понял что делать с этим файлом в библиотеку он не включен, нигде не вызывается.. назначение его понятно, не понятно как использовать (см картинку)

Далее попытаюсь прикрутить к нему Actor Framework, посмотрю что из этого выйдет, придвижу много "граблей".

taras_33,

taras_33 писал(а):Все работает, только не совсем понял что делать с этим файлом в библиотеку он не включен, нигде не вызывается.. назначение его понятно, не понятно как использовать (см картинку)

Далее попытаюсь прикрутить к нему Actor Framework, посмотрю что из этого выйдет, придвижу много "граблей".

Это ведь Post Build Action,
http://www.labviewportal.org/viewtopic.php?f=84&t=9034
Если правильно помню, в это случае он удаляет "лишние" виайки после компиляции; чтобы не было конфликта при загрузке плагинов.

Спасибо, буду знать. В который раз убеждаюсь в верности пословицы "Век живи, век учись, а дурнем здохнешь"

Вообщем попытки прикрутить Actor Framework и работать с PPL архитектурой принесли свои плоды. После трехдневных экспериментов и хождений по форумам от NI кое что получилось. Вот пара ссылок (ссылка раз, ссылка два), где люди описывают хождения по граблям и возможные решения
Если в двух словах, то:
первое - делать библиотеку Actor Framework.lvlibp из библиотеки Actor Framework.lvlib , нужно в проекте ссылаясь на source где эта библиотека расположена при установке LabVIEW , в моем случае это C:\Program Files (x86)\National Instruments\LabVIEW 2016\vi.lib\ActorFramework\Actor Framework.lvlibp , если скопировать в другое место и скомпилировать то message maker не работает - выскакивает ошибка 1448.
Второе это заменить Actor Framework.lvlib на Actor Framework.lvlibp по упамянутому выше адресу, а также щелкнуть правой кнопкой в Dependencies (Project Explorer) на Actor Framework.lvlib и в выпадающем меню выбрать "replace with Actor Framework.lvlibp" кажется так называется.
Все!!! Можно пользоваться, работает на ура.

taras_33, a у Вас есть простенький пример, как именно с акторами сделать плагин для ран-тайма? Если есть, можете поделиться, пожалуйста? Т.к. плагин с просто классами - получается сделать, все работает. А с акторами не могу понять, что и как билдить... Каждый актор отдельно в свою ppl? С другой стороны, в исходном коде не хотелось бы использовать ppl вообще, т.к. тогда будут проблемы, если серьезно в ней что-то менять + если менять версию LabVIEW. В случае просто классов, я делаю Source Distribution классов, и включаю это в exe; то же хотелось бы сделать и для либы актора...
Заранее спасибо за любой ответ

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

taras_33, a у Вас есть простенький пример, как именно с акторами сделать плагин для ран-тайма? Если есть, можете поделиться, пожалуйста? Т.к. плагин с просто классами - получается сделать, все работает. А с акторами не могу понять, что и как билдить...

Проникся просьбой, нашел время, так как простенького примера небыло, пришлось сделать. Разархивируем и видим папку с проектами. Открываем проект PPL и запускаем Launcher. В выпадающем меню выбираем какой плагин (Actor) загрузить(запустить). Появится предупреждение -> нажимаем Add. Появятся куча предупреждений в Dependencies - игнорируем. В исполняемом файле никаких предупреждений нет. Народ борется с этим, я приводил ссылку в предыдущем посте. Собственно поиграйтесь поймете.

Ну вот поигрались, теперь скопируем папку Actor C из папки To Add в папку Plugins. Запустим Launcher - теперь дополнительно в двум Аctor-ам появился третий. Вот именно в этом вся красота. Независимо от главной программы скомпилировали библиотеку, положили ее в нужную папку и все. Программа подхватит ее при старте.

Теперь насчет build. Когда будете билдить не забывайте удалять дубликаты, либо пользуйтесь Post Build Action, если надоест удалять вручную. На примере: Открываем проект Actor A который лежит в LV_Test_PPL\PPL_Projects\Actor A. Чего то там меняем и билдим. В папке LV_Test_PPL\Plugins\Actor_A (если пути билда не менялись) помимо Actor_A.lvlibp Появятся еще две либы Actor Framework.lvlibp и Abstract.lvlibp вот собственно их и нужно удалить. Они уже есть и лежат в LV_Test_PPL\LIB\Abstract.
Если посмотрите иеархию класов (после добавления их в main), то увидите, что актеры A, В и С потомки класса Abstract, из чего следует вывод что у них должет быть общий интерфейс.

taras_33, спасибо! Прошлую неделю и эту был вне работы, так что буду клацать сейчас...

Пожалуйста. Когда архивировал, забыл удалить папку Actor C из папки Plugins так что ничего копировать из папки To Add не нужно, он уже скопирован. Можно наоборот удалить и увидеть что он также пропадает из меню выбора.

Интерестный пример, спасибо! Я попробывал, все работает. Но разрешите еще один вопрос. В коде, Вы сразу используете уже забилденные либы, или вначале используете их в исходном состоянии. Я о чем - если в основном приложении использовать функции из lvlibp, то тогда при каждой модификации интерфейса плагина нужно будет ребилдить либу. Не очень удобно... Если переходить на lvlibp в конце проекта, когда уже все сделано и работает - тогда шансов на правку меньше. Вы так делаете, или?..
Но если уже перейти на lvlibp, то тогда сложнее переделать все опять под исходный код - например, если нужно будет переходить на другую версию LabVIEW. Ведь lvlibp не подгрузится в другой LV версии.
Или же, имеет смысл делать плагинами только те акторы, которые полностью самостоятельные, и с ними никто "напрямую" не общается, не посылает сообщения? Ведь тогда даже метод посылки сообщения будет в составе lvlibp... Если актор работает сам по себе, как мини-отдельная аппликация, то тогда проблем я не вижу, там будет все проще - нужно будет поменять метод вызова актора, и можно будет вызывать либо из lvlibp, либо из исходной либы. Но, наверное, если общаться с тем актором через сообщения, то функции посылки сообщений будут в составе lvlibp, и тогда в случае чего, нужно будет все менять руками... Я прав?
Заранее спасибо за ответ!

Забилденные. В либу Actor Framework.lvlibp нечего вообще лазить, только если четко понимаешь что делаешь. А в приведенном примере либа Abstract.lvlibp, вернее содержащийся в ней клас вообще пустой, посмотрите в папке PPL_Projects->Abctract. Он служит в роли родителя и должен быть включен в главную программу на этапе компиляции. Иначе что подавать на вход target class, функции To More Specific Class? Именно поэтому все плагины, читай дети, должны быть наследованны от этого класса, даже если он не содержит ни каких данных и ни одного метода. Нет, конечно он может содержать методы, которыми будут пользоваться его потомки, тут уж Ваши желания и фантазия будут решать... По поводу переноса на другие версии, тут да, затык. Нужно пересобирать все заново. Да и зачем собственно полностью переходить на эту архитектуру? Я ее использую, когда мне постоянно нужно менять Front Panel, и что самое важное, я не знаю какая она понадобится завтра или через неделю. Так вот что бы исключить постоянное перекомпилирование всего проекта я пользуюсь этой архитектурой.