Создание DLL в LabVIEW
- duke-kta
- beginner
- Сообщения: 16
- Зарегистрирован: 28 июн 2017, 13:44
- Версия LabVIEW: 13
- Откуда: НиНо
- Контактная информация:
Re: Создание DLL в LabVIEW
dadreamer, скорее всего так и придётся делать.
Странно, что при вызове через Call Library Function Node скомпилированного DLL автоматом не проставляются параметры - приходится врукопашную добавлять. Может, я где-то галочку не поставил или так и должно быть?
Странно, что при вызове через Call Library Function Node скомпилированного DLL автоматом не проставляются параметры - приходится врукопашную добавлять. Может, я где-то галочку не поставил или так и должно быть?
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 127 раз
- Контактная информация:
Re: Создание DLL в LabVIEW
Должно. Откуда программе знать, какие у ваших функций параметры? Они же не экспортируются для cdecl и stdcall соглашений.duke-kta писал(а):Странно, что при вызове через Call Library Function Node скомпилированного DLL автоматом не проставляются параметры - приходится врукопашную добавлять. Может, я где-то галочку не поставил или так и должно быть?
А в чём смысл вызывать из скомпилированную в нём же библиотеку? Не проще ли юзать SubVI?
- duke-kta
- beginner
- Сообщения: 16
- Зарегистрирован: 28 июн 2017, 13:44
- Версия LabVIEW: 13
- Откуда: НиНо
- Контактная информация:
Re: Создание DLL в LabVIEW
На другом, почему-то, знает, но это уже мелочи...Откуда программе знать, какие у ваших функций параметры?
ну, тут сложный момент... Метрология, однако )))А в чём смысл вызывать из скомпилированную в нём же библиотеку? Не проще ли юзать SubVI?
Если кратко, то для аттестации стенда, как измерительного прибора.
Суть, DLL-ки не меняются. В них измерительные функции и они аттестованы вместе со стендом.
Морда программы может меняться как угодно и эти изменения не касаются аттестации, если мы в ней просто вызываем эти самые аттестованные функции.
Кстати, переустановил LV13 (не удаляя, даже) - всё заработало. Причём, в LV15 компиляция тоже осталась.
Здесь http://digital.ni.com/public.nsf/allkb/ ... E800728A7B написано, что LV14 уже правит все эти беды.
Так что, если у кого-то пропадает компиляция DLL в какой-либо версии LV, надо переставить эту версию поверх старой.
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 127 раз
- Контактная информация:
Re: Создание DLL в LabVIEW
На другом ? Единственное место, где прописаны прототипы функций - это заголовочный файл *.h, который создаётся при компиляции DLL. Чтобы создал с уже настроенным блоком CLFN, нужно запустить Мастер импорта (Tools -> Import -> Shared Library) и указать оба файла: *.dll и *.h. Уверены, что не пользовались Мастером и не прописывали ничего вручную?..duke-kta писал(а):На другом, почему-то, знает, но это уже мелочи...
А почему нельзя аттестовать ? У DLL есть какое-то принципиальное преимущество в этом плане?duke-kta писал(а):Суть, DLL-ки не меняются. В них измерительные функции и они аттестованы вместе со стендом.
Я в общем-то вот почему спрашиваю:
Причём, это не мои выдумки. Специалисты на форумах ni.com давно об этом пишут.[b][color=#FF9900]dadreamer[/color][/b] писал(а):Но вообще, по идее, вызывать DLL, созданную в , из самого - это большое извращение, т.к. происходит двойная конвертация параметров при передаче на стек и отсюда возрастают накладные расходы на вызов функции. Создавать DLL в имеет смысл, только когда нужно вызывать её из другой IDE (C/C++, Delphi, VB). А в самом гораздо проще и удобнее создавать SubVI, в том числе и при необходимости подключения разных подпрограмм (плагинов).
- duke-kta
- beginner
- Сообщения: 16
- Зарегистрирован: 28 июн 2017, 13:44
- Версия LabVIEW: 13
- Откуда: НиНо
- Контактная информация:
Re: Создание DLL в LabVIEW
dadreamer,
Ну, где-то я с ним согласен - VI вызывать можно только из LV, а DLL откуда угодно.
То есть, можно эти DLL-ки проверить из любой другой программы - так и аттестовать...
Ну, там мутно всё в этой метрологии.
Ну, хотят так - нате вам так!
Есть у нас "идейный генератор" один, которому не объяснишь, что разницы никакой, почти, а геморроя больше.
И он непосредственно связан с заказчиком...
На другом компе - не знаю что там стояло по умолчанию, но я ничего не прописывал. Возможно, там настроено, искать в той же папке или ещё что - но это ладно, я уже нашёл как сделать и твой совет помог.не пользовались Мастером и не прописывали ничего вручную?
Типа, суть в разделении измериловки и пользовательского интерфейса.А почему нельзя аттестовать
Ну, где-то я с ним согласен - VI вызывать можно только из LV, а DLL откуда угодно.
То есть, можно эти DLL-ки проверить из любой другой программы - так и аттестовать...
Ну, там мутно всё в этой метрологии.
Ну, хотят так - нате вам так!
Абсолютно согласен! Но!Но вообще, по идее, вызывать DLL, созданную в , из самого - это большое извращение
Есть у нас "идейный генератор" один, которому не объяснишь, что разницы никакой, почти, а геморроя больше.
И он непосредственно связан с заказчиком...
-
Vitekkz88
- expert
- Сообщения: 1100
- Зарегистрирован: 21 янв 2014, 15:45
- Награды: 3
- Версия LabVIEW: 12,13,14
- Откуда: Томск
- Контактная информация:
Re: Создание DLL в LabVIEW
duke-kta, ну дк Ваш идейный генератор смотрит наперёд в плане аттестации именно .dll. Наделать и аттестовать SubVI не проблема, но! завтра LabVIEW-шинки разбегутся по другим темам и направлениям, а найти замену будет в десятки раз сложнее, нежели программиста С/С++. Через 2-3 года политика партии поменяется, захочется перейти на рельсы C#, например. Начнут запиливать новый проект и хоба, а функции то в SubVI и другой библиотеки аттестованных функций нет. Сядут в калошу и контора попадёт на бабки папки, чтоб опять же запилить уже нормальную dll-ку с необходимой функциональностью. Ну а пока есть LV со своими сильными сторонами - её и используют, но не уповают по всей видимости.
dadreamer, а почему так происходит? Двойная конвертация параметров и всё такое...я чет Подозреваю, что при создании dll LabVIEW как-то по хитрому данные заворачивает, да?
Вроде как в классике такого нету(вызываем C++/С# dll в VisualStudio на этих же языках)...
dadreamer, а почему так происходит? Двойная конвертация параметров и всё такое...я чет Подозреваю, что при создании dll LabVIEW как-то по хитрому данные заворачивает, да?
Вроде как в классике такого нету(вызываем C++/С# dll в VisualStudio на этих же языках)...
Инженер - это открыто светящийся интеллект, свободный и не обидный юмор, это легкость и широта мысли...Это воспитанность, тонкость вкусов, хорошая речь, плавно согласованная и без сорных словечек...
-А. И. Солженицын
-А. И. Солженицын
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 127 раз
- Контактная информация:
Re: Создание DLL в LabVIEW
Да тут на самом деле всё просто. Что exe, что dll, скомпиленная в , суть загрузчик + llb с ВИайками внутри. Когда вызываем какую-нибудь библиотеку из через CLFN, конвертирует типы данных в C-нотацию для передачи в универсальную обёртку, вызывающую конечную библиотеку (ExtFuncWrapper). Параметры кладутся на стек, вызывается ExtFuncWrapper, загружается библиотека, и либо линкуется к текущему процессу (если написана в той же версии ), либо подгружает свой LVRT Engine и линкуется к нему. Параметры подбираются со стека, конвертируются в -нотацию и передаются в функции (SubVI). Так что получается цепочка " -> C -> " в одну сторону, так же и обратно. Очевидно, что страдает производительность, особенно в случае использования нескольких lvrt в одном процессе, а также при первом вызове библиотеки, когда происходит lazy-загрузка в память.Vitekkz88 писал(а):dadreamer, а почему так происходит? Двойная конвертация параметров и всё такое...я чет
-
- beginner
- Сообщения: 48
- Зарегистрирован: 06 май 2014, 10:30
- Версия LabVIEW: 2011, 2015
- Откуда: Vldr
- Благодарил (а): 1 раз
- Контактная информация:
Re: Создание DLL в LabVIEW
решил поиграться с dll, напишу свои вопросы в этот сабж
2) dll не совместимы друг с другом ни в какую сторону. Если неприязнь 2011 к dll, созданной в 2015, можно понять, то почему обратное также истинно?
3) Если кто-то захочет вызвать мою dll в другой среде - как ему узнать какую runtime ставить?
1)У меня также. Стоит 2 : 2011 32bit и 2015 64bit. Когда создаю dll в 2011 - при загрузке через CLFN, подтягиваются входы-выходы. На 2015 при аналогичных действиях - не подтягиваются. Однако если использовать мастер создания обертки - все нормально. Вопрос: в чем причина? как лечить? перустанавливать на голую? (хотелось бы оставить 2011)
2) dll не совместимы друг с другом ни в какую сторону. Если неприязнь 2011 к dll, созданной в 2015, можно понять, то почему обратное также истинно?
3) Если кто-то захочет вызвать мою dll в другой среде - как ему узнать какую runtime ставить?
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 127 раз
- Контактная информация:
Re: Создание DLL в LabVIEW
Вы так же, как и duke-kta, компилируете DLL в и потом из него же их вызываете?CCCP33 писал(а): ↑01 фев 2023, 20:491)У меня также. Стоит 2 : 2011 32bit и 2015 64bit. Когда создаю dll в 2011 - при загрузке через CLFN, подтягиваются входы-выходы. На 2015 при аналогичных действиях - не подтягиваются. Однако если использовать мастер создания обертки - все нормально. Вопрос: в чем причина? как лечить? перустанавливать на голую? (хотелось бы оставить 2011)
Вероятнее всего, из-за разных разрядностей и DLL (32/64 бита).
Но если вдруг нет, то ещё одна причина - не может найти lvrt подходящей версии. Чтобы библиотека удачно загрузилась в какую-то IDE, надо установить Run-Time Engine соответствующей версии. Кстати, начиная с LV 2017 в параметрах билда есть опция "Allow future versions of the LabVIEW Runtime to run this application", активирующая обратную совместимость ран-таймов версий >=2017.
Нужно ему об этом сообщить :) Либо ему придётся копаться в недрах DLL каким-то редактором ресурсов. Или же можно экспортировать функцию, возвращающую версию RTE (Application.Version).
-
- beginner
- Сообщения: 48
- Зарегистрирован: 06 май 2014, 10:30
- Версия LabVIEW: 2011, 2015
- Откуда: Vldr
- Благодарил (а): 1 раз
- Контактная информация:
Re: Создание DLL в LabVIEW
Верно. Да, как сказано выше, ситуация абсурдна, но все же интересно знать причину.
Утро вечера мудренее. Остается добавить, что и для 64-бит данное утверждение справедливо. Сам выдает сообщение: Всегда считал, что существует односторонняя совместимость 32b приложений на 64b системах. Век живи - век учись...
т.е. для запуска dll/exe начиная с LV 2017 необязательно ставить именно ту версию рантайма, в которой он создан? Например, dll/exe, созданный в LV2017, запустится при установленном runtime 2021?
P.S. в LV2015 обратил внимание на такую опцию: Это не оно ли?
Пардон. В каком виде экспортировать?
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 127 раз
- Контактная информация:
Re: Создание DLL в LabVIEW
К сожалению, не могу здесь помочь, нужны эксперименты на разных версиях . Ни разу не приходилось сталкиваться с задачей подключения подобных библиотек к . У меня на 2021 версии ничего не подхватывается. Да и не видел никогда, чтобы в CLFN параметры автоматом создавались. Если доберусь до 2011, посмотрю.
Есть совместимость для 32-битных экзешников на 64-битной ОС. Это осуществляется через прослойку WOW64, играющую роль виртуальной машины: https://ru.wikipedia.org/wiki/WOW64 Аналогичная штука была и на 32-битных ОС для запуска 16-битных приложений. Но загрузка DLL одной разрядности в память процесса с другой разрядностью - это маленько другое. Размер указателя разный, инструкции для CPU отличаются, лимиты адресуемой памяти разные... Без какого-либо посредника наподобие COM+ или thunking dll скрестить ужа с ежом не получится. Проще перекомпилировать под другую платформу.
Запустится, если разработчик не убрал ту галочку при сборке проекта. По умолчанию она установлена.
Вот тут мне пришлось немного залезть в хэлп, ибо никогда этим не пользовался. Этот переключатель влияет на вид имён функций и параметров при сборке и на экспорт кластера error in/out: https://www.ni.com/docs/en-US/bundle/la ... _page.html
Точно так же, как экспортируются остальные : Хотя, я вот сейчас подумал: это может не сработать. DLL при загрузке в память сразу запросит LVRT, не дав ничего вызвать.
-
- beginner
- Сообщения: 48
- Зарегистрирован: 06 май 2014, 10:30
- Версия LabVIEW: 2011, 2015
- Откуда: Vldr
- Благодарил (а): 1 раз
- Контактная информация:
Re: Создание DLL в LabVIEW
Вот и у меня этот совет вызвал когнитивный диссонанс. Это как оставить теще ключ от квартиры в этой же квартире
Благодарю за экскурсdadreamer писал(а): ↑02 фев 2023, 16:23 Есть совместимость для 32-битных экзешников на 64-битной ОС. Это осуществляется через прослойку WOW64, играющую роль виртуальной машины: https://ru.wikipedia.org/wiki/WOW64 Аналогичная штука была и на 32-битных ОС для запуска 16-битных приложений. Но загрузка DLL одной разрядности в память процесса с другой разрядностью - это маленько другое. Размер указателя разный, инструкции для CPU отличаются, лимиты адресуемой памяти разные... Без какого-либо посредника наподобие COM+ или thunking dll скрестить ужа с ежом не получится. Проще перекомпилировать под другую платформу.
Запустится, если разработчик не убрал ту галочку при сборке проекта. По умолчанию она установлена.
У duke-kta вроде версия даже посвежее была. Может дело в разрядности?
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 127 раз
- Контактная информация:
Re: Создание DLL в LabVIEW
Тут ларчик просто открывается. Надо в настройках билда поставить галочку "Include a type library for TestStand or Call Library Nodes" (появилась в 2015, на скриншоте выше она есть). Тогда внутрь DLL будет помещаться так называемая библиотека типов (typelib), где и будет описан прототип функции. В хэлпе вот что сказано:
Так выглядит typelib внутри dll: А это получившийся IDL файл (при желании можно перекомпилировать прототип без перестроения всего проекта):
Проверял на 2022 (32 и 64 бита), всё работает, естественно, разрядность нужно соблюдать.
То есть, нужно сначала скачать и установить MSDT Build Tools, потом уже генерировать DLL, в противном случае вылезет ошибка при построении. Достаточно даже поставить MSDT_BuildTools.msi из архива, тоже будет работать.Specifies whether to embed a type library when you build shared libraries (DLLs). If you use TestStand or the LabVIEW Call Library Function Node, you must manually enable this option. The TestStand C/C++ DLL Adapter, LabWindows/CVI Adapter, and the LabVIEW Call Library Function Node use the type library to display a list of functions in the shared library, including the parameters and data types for the functions. You must install additional tools to embed a type library. Visit ni.com/info and enter the Info Code DownloadMSDTBuildTools to access the additional tools.
Так выглядит typelib внутри dll: А это получившийся IDL файл (при желании можно перекомпилировать прототип без перестроения всего проекта):
Код: Выделить всё
// Generated .IDL file (by the OLE/COM Object Viewer)
//
// typelib filename: SumLib.dll
[
uuid(CDEF8B4B-B4E7-4FC5-896F-C1C018742F89),
version(0.0),
custom(DE77BA64-517C-11D1-A2DA-0000F8773CE9, 134218331),
custom(DE77BA63-517C-11D1-A2DA-0000F8773CE9, 1676290929),
custom(DE77BA65-517C-11D1-A2DA-0000F8773CE9, Created by MIDL version 8.00.0603 at Mon Feb 13 17:22:09 2023
)
]
library SumLib
{
// TLib : // Forward declare all types defined in this typelib
[
dllname("SumLib.dll")
]
module Sum {
[entry(0x60000000)]
double _cdecl Sum(
[in] double C0ntr0l1,
[in] double C0ntr0l2);
};
};
-
- Похожие темы
- Ответы
- Просмотры
- Последнее сообщение