NI_MAPro lvlib

[jane_wild]

Короткая предыстория. Со слов человека, попросившего о помощи. На машине была установлена лицензионная LabVIEW предыдущей версии 2011. После удаления старого NI MAX (я так поняла и всех связанных с ним программ) и установки DAQmx 2020 она стала нелицензионной. Решили обновить всю систему. Купили новый компьтер, купили и установили LabVIEW 2021. Скопировали папку с проектом на новую систему и при открытии наблюдают вот такую картинку. Ребята, может нужны какие нибудь тулкиты доустановить? Что это за библиотека и почему она нелицензионная?
Возможно ли как то вернуть лицензию на старую LabVIEW? Спасибо.

[Borjomy_1]

Надо лезть в менеджер управления лицензиями

[AndreyDmitriev]

Рискну предположить, что это LabVIEW Advanced Signal Processing Toolkit.
https://www.ni.com/ru-ru/support/downlo ... tml#411230

[taras_33]

Со слов человека, попросившего о помощи.
NI_MAPro...

Я бы уточнил у этого человека какая лицензия была куплена и была ли вообще. Как бы ошибка прямо указывает на то, что лицензия какая то неправильная. Попросите его прислать скриншот Ni Licenses Manager, открытого на вкладке Local Licenses. Должно быть что типа такого, с зелеными кружочками.

[jane_wild]

Я бы уточнил у этого человека какая лицензия была куплена и была ли вообще.

Из зеленых кружочков только Base Development System.
Хотелось бы убедиться что проблема именно в отсуствии pro лицензии, перед тем как убеждать людей ее купить. А то может получиться так что они купят, а упомянутая ошибка вовсе с этим не связана. Хотя последние буквы названия библиотеки намекают на это.

[IvanLis]

Самый правильный вариант это связаться со службой поддержки и там уточнить.

Ну а если топорно делать, то NI_MAPro.lvlib лежит в папке LabVIEW ****\vi.lib\measure, там же видимо лежит у Вас только файлик NI_MABase.lvlib, что соответствует описанию лицензии, если отталкиваться от названия папки.

https://www.ni.com/ru-ru/shop/labview/s ... ition.html

Контрол непосредственно лежит в библиотеке LabVIEW ****\vi.lib\measure\masml.llb
Хорошо бы знать функцию, которой этого контрола не хватает...

[jane_wild]

Отчитываюсь. Проблема действительно оказалась с лицензией. Поскольку воровать нехорошо, а в здешних краях еще и чревато, исключительно ради эксперемента, буквально на одну минутку стала с Pro лицензией и ошибка сразу же исчезла. Всем спасибо за участие.
После обновления до Pro лицензии, на сей раз официальным путем, все работает. Исключение один VI использует dll библиотеку. Посмотрите на скриншот ошибки.

Я так понимаю что предыдущая версия LabVIEW была 32 разрядной, а они установили 64, поэтому эта ошибка (невозможность сконфигурировать)? Или имеется ввиду что предыдущая Windows была 32, а новая 64? К сожалению какой разрядности была предыдущая система уже неизвестно.
И вообще так сказать для общего развития и dll библиотеки, написанные на других языках обязательно должны совпадать по разрядности?

[dadreamer]

И вообще так сказать для общего развития и dll библиотеки, написанные на других языках обязательно должны совпадать по разрядности?

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

jane_wild, конечно 32-битную версию надо ставить. Если 32 бита, то и все загружаемые в него DLL'ки должны быть 32 бита. Других вариантов не дано, так работает Windows, да и в других системах, насколько я знаю, это справедливо.

[jane_wild]

jane_wild, конечно 32-битную версию надо ставить. Если 32 бита, то и все загружаемые в него DLL'ки должны быть 32 бита. Других вариантов не дано, так работает Windows, да и в других системах, насколько я знаю, это справедливо.

Ну вот полтора года прошло и уже забыла - не получится из меня хорошего програмиста
C LabVIEW разобрались, а как с самой Windows? LabVIEW 32, библиотека 32, а Windows 64 будет работать? По логике да, ведь LabVIEW 32 на Win64 работает же. Правильно?

[AndreyDmitriev]

LabVIEW 32, библиотека 32, а Windows 64 будет работать? По логике да, ведь LabVIEW 32 на Win64 работает же. Правильно?

Да, правильно, 32-х битное приложение будет работать и под Win64.

[IvanLis]

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

Не знаю, что Вы имеете ввиду, но сталкивался с следующей ситуацией.
Программирую я в LV2015-32bit, ну и компилирую естественно 32bit (Win7-32bit), которая нормально живет и работает в 64bit системе.
Целевая машина Win10-64bit, на ней установлена СУБД MySQL.
Работаю с СУБД посредством драйвера ODBC.
Соответственно при подготовке машины, установили 64bit версию драйвера, соединение проверено через панель Windows "источники данных".

При попытке работать через него вылетает ошибка.
Я удалил этот драйвер и принудительно установил 32bit версию.
В этом случае проверка соединения через панель оканчивается неудачей, но при этом программа (32bit) LabVIEW работает с ней нормально (драйвер 32bit).

[dadreamer]

Не знаю, что Вы имеете ввиду, но сталкивался с следующей ситуацией.

Среда (IDE) - (или скомпилированный экзешник). Библиотеки - .dll/.so/.framework. Только это и имел ввиду. По поводу случая, вроде ничего необычного. Системный драйвер (.sys) - тоже динамическая библиотека, и чтобы с ней работать, даже через различные прослойки в виде других .dll, так же нужно, чтобы разрядности совпадали. Раньше много было подобного софта для всяких принтеров/сканеров/копиров, который только с конкретными версиями дров работал. Да и сейчас такие проги попадаются изредка.

Во времена Windows 95 можно было исхитряться вызывать 16-битные библиотеки из 32-битной среды, например http://netcode.ru/cpp/?artID=5187 Однако аналогичный трюк, но применительно к 32-битным библиотекам в 64-битной среде оказалось выполнить значительно сложнее. Потребовалось бы транслировать каждую команду на ассемблерном уровне, ещё пришлось бы "конвертировать" все указатели. Насколько я знаю, никто так и не заморочился с написанием подобной thunk dll. Ведь намного проще воспользоваться дарами виртуализации в виде VirtualBox, VMware и т.д.

[IvanLis]

Среда (IDE) - (или скомпилированный экзешник)

*.EXE приложение.
Приложение скомпилированное в 32bit системе, в 32bit LabVIEW нормально работает в 64bit системе.

Библиотеки - .dll/.so/.framework. Только это и имел ввиду.

Я сильно не погружался, в устройство этого драйвера, но судя по логике и содержанию папки, он именно в виде dll реализован.

Видимо система понимает, что запустили 32bit приложение. Это приложение обращается к dll, которая тоже должна быть 32bit.
Но например из 32bit приложения не получится обратиться к 64bit библиотеке.

[dadreamer]

Ну вот полтора года прошло

Если у меня с математикой ещё не всё так плохо, то целых два с половиной А вообще, для исключения сомнений в таких вот случаях советую поставить плагин для окна свойств файла ExeProperties. Будет значительно быстрее смотреть битность DLL.

Приложение скомпилированное в 32bit системе, в 32bit LabVIEW нормально работает в 64bit системе.
...
Видимо система понимает, что запустили 32bit приложение. Это приложение обращается к dll, которая тоже должна быть 32bit.
Но например из 32bit приложения не получится обратиться к 64bit библиотеке.

Ну, тут всё в порядке. Для обратной совместимости в 64-битной Windows существует надстройка наподобие виртуальной машины, позволяющая запускать 32-битный код: https://ru.wikipedia.org/wiki/WOW64 Похожая ВМ существовала и в 32-битных Windows для запуска 16-битного кода. В 64-битных ОС её выпилили, возможно, это произойдёт и с WOW64 рано или поздно. На macOS тоже какое-то время можно было запускать 32-битные программы, но потом эту возможность убрали. Но на Linux это до сих пор должно работать, при наличии необходимых пакетов.

[jane_wild]

Если у меня с математикой ещё не всё так плохо, то целых два с половиной А вообще, для исключения сомнений в таких вот случаях советую поставить плагин для окна свойств файла ExeProperties. Будет значительно быстрее смотреть битность DLL.2022-08-03_0-08-43.jpg

Ну вот, еще и считать разучилась
За плагин спасибо, только возникают сомнения в правильности его показаний. Ниже свойства exe файла, скомпилированного в среде 2020, а он почемут считает что это VS

ExeProperties.PNG (8.35 КБ) 803 просмотра