Добрый день!
Есть вопрос по структуре проекта. Хочется получить на выходе скомпилированный EXE и некий набор подключаемых библиотек. Всё проектируется на LabVIEW. В процессе разработки основной программы и библиотек, необходимо запускать в режиме отладки до получения исполняемого файла, но так что бы VI которые будут импортироваться из библиотеки, импортировались именно из библиотеки, а не из VI из папки нахождения. Другими словами, как правильно реализовать проект с трёх-уровневой (иерархической) вложенностью (основное приложение тянет код из библиотеки, библиотека тянет код из более низкоуровневой библиотеки ) и при этом не терять возможность с оперативным изменением кода на всех уровнях?
Предполагаю, я не первый и люди сталкивались с такими задачами.
За ранее спасибо
Модель среднего проекта
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 127 раз
- Контактная информация:
Re: Модель среднего проекта
titan, под библиотекой вы lvlib или llb имеете в виду? После компиляции все будут зашиты в тело основного exe. Вас интересует структура подключаемых плагинов, которая бы также работала и с экзешником, т.е. можно было бы менять модули отдельно от основного файла? Или же вы хотите обеспечить модульность в режиме отладки/написания кода? И как у вас сделано все это сейчас (имею в виду динамическую загрузку )?
-
- interested
- Сообщения: 6
- Зарегистрирован: 25 мар 2015, 19:01
- Версия LabVIEW: 2013
- Контактная информация:
Re: Модель среднего проекта
на сколько я понял, lvlib - это что-то вроде конфигурационного файла со ссылками на внешнии VI и в себе VI не содержит;
далее, llb - имеет похожие свойства от dll, правда после того как её соберёшь через builder;
с dll в LabVIEW пока ещё не игрался, возможно это мой вариант решения задачи, то есть в данный момент занимаюсь поиском модели и пытаюсь отрабатывать в виде малонаполненного проекта как заготовку
После компиляции надо иметь exe и набор динамически подключаемых модулей и плагинов (на данный момент не определился, llb или dll мож ещё что-то). Чудок поясню терминологию так как я её понимаю: модуль это динамически подгружаемая библиотека, а плагин - маленькое исполняемое какую-то небольшую задачу приложение(на примере компилятора, линковщика и т.д. в IDE).
Сейчас, Я столкнулся со следующей проблемой, проект содержит несколько классов работы с внешним устройством по TCP/IP(базовый и наследник от него), есть заготовка для плагина которую я хочу вынести из основного EXE, но этот плагин должен получить объект наследника класса, и рефереренсы на модульные приборы для последующей работы. Плагин использует один метод из класса, а при сборке llb, LabVIEW запихивает весь класс наследника и базового прицепом что тоже не правильно на мой взгляд и надо сформировать в отдельную библиотеку которая будет подключаться и к EXE и к плагину.
Плагин запускаю через Open VI Reference -> Start Asynchronous Call из llb. На данный момент как-то так.
Попутный вопрос: возможно ли в LabVIEW собрать библиотеку из класса с возможностями наследования?
далее, llb - имеет похожие свойства от dll, правда после того как её соберёшь через builder;
с dll в LabVIEW пока ещё не игрался, возможно это мой вариант решения задачи, то есть в данный момент занимаюсь поиском модели и пытаюсь отрабатывать в виде малонаполненного проекта как заготовку
После компиляции надо иметь exe и набор динамически подключаемых модулей и плагинов (на данный момент не определился, llb или dll мож ещё что-то). Чудок поясню терминологию так как я её понимаю: модуль это динамически подгружаемая библиотека, а плагин - маленькое исполняемое какую-то небольшую задачу приложение(на примере компилятора, линковщика и т.д. в IDE).
Сейчас, Я столкнулся со следующей проблемой, проект содержит несколько классов работы с внешним устройством по TCP/IP(базовый и наследник от него), есть заготовка для плагина которую я хочу вынести из основного EXE, но этот плагин должен получить объект наследника класса, и рефереренсы на модульные приборы для последующей работы. Плагин использует один метод из класса, а при сборке llb, LabVIEW запихивает весь класс наследника и базового прицепом что тоже не правильно на мой взгляд и надо сформировать в отдельную библиотеку которая будет подключаться и к EXE и к плагину.
Плагин запускаю через Open VI Reference -> Start Asynchronous Call из llb. На данный момент как-то так.
Попутный вопрос: возможно ли в LabVIEW собрать библиотеку из класса с возможностями наследования?
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 127 раз
- Контактная информация:
Re: Модель среднего проекта
titan, посмотрите пока что эти ссылки:
https://decibel.ni.com/content/docs/DOC-19176
https://decibel.ni.com/content/docs/DOC-33364
https://decibel.ni.com/content/groups/l ... pplication
и наберите в гугле "labview plugin architecture", выпадет много информации о плагинах.
Думаю, что DLL в этом случае использовать не стоит, они не для этого. Вы же работаете в рамках только одной IDE - LabVIEW - так что вам проще будет использовать те форматы данные, что лучше всего воспринимаются самой средой. Тем более что сложные типы данных и в особенности классы вы внутрь DLL не запихнёте, и если вызывать DLL, созданную в , прямо из , то будет большой проигрыш в эффективности - двойная конвертация параметров из нативных типов данных и обратно при передаче на стек.
https://decibel.ni.com/content/docs/DOC-19176
https://decibel.ni.com/content/docs/DOC-33364
https://decibel.ni.com/content/groups/l ... pplication
и наберите в гугле "labview plugin architecture", выпадет много информации о плагинах.
Думаю, что DLL в этом случае использовать не стоит, они не для этого. Вы же работаете в рамках только одной IDE - LabVIEW - так что вам проще будет использовать те форматы данные, что лучше всего воспринимаются самой средой. Тем более что сложные типы данных и в особенности классы вы внутрь DLL не запихнёте, и если вызывать DLL, созданную в , прямо из , то будет большой проигрыш в эффективности - двойная конвертация параметров из нативных типов данных и обратно при передаче на стек.
-
- Похожие темы
- Ответы
- Просмотры
- Последнее сообщение