1 从论坛里下载的程序,运行时出现这个 - LabVIEW论坛 - 电子技术论坛 - 广受欢迎的专业电子论坛! - 德赢Vwin官网
发 帖  

从论坛里下载的程序,运行时出现这个

2583 数据库

lvanlys.png (30 KB, 下载次数: 5)

lvanlys.png
已退回10积分
2020-3-6 14:58:27   7 评论 分享淘帖 邀请回答 举报
7 条评论
  • 2020-3-7 14:38

    As a troubleshooting step, let's try setting an environmental variable.  Create the following:



    MKL_DEBUG_CPU_TYPE=4



    Once you've done that, restart LabVIEW and see if the behavior continues.  If that clears up the behavior, I've got a pretty good idea of what we're looking at.  If not, it'll likely require more work.  In that case, you'll probably want to open a service request to get more focused help.这个是ni官网上的采纳回答,但是我看不懂

  • 2020-3-7 15:26

    打包的项目库是构建的应用程序。因此,所有依赖项都被拉入生成,包括任何非系统dll。这与构建其他生成规范(如共享库或可执行文件)时发生的相同过程。在Windows中,应用程序只能从一个位置加载一次同名的DLL。如果LabVIEW.exe或生成的应用程序已将lvanlys.dll加载到内存中,则用户在加载其PPL时将收到一个加载冲突警告,这也取决于其自身的lvanlys.dll副本。不过,这并不是PPLs独有的问题。如果LabVIEW构建了依赖于lvanlys.dll的dll,则会发生相同的行为。我以lvanlys.dll为例,因为它是我调查中最常用的dll。



    好消息是有办法避免这种冲突。避免此问题的最简单方法是在构建压缩库时向所有依赖项添加前缀。这将确保dll与LabVIEW附带的dll具有不同的名称。实际上,我们对使用lvanlys.dll的构建也做了同样的事情。

  • 2020-3-7 15:28

    如果一个项目中要有多个ppl,可以确保将它们构建到同一目录中。如果所有ppl的前缀名称相同,那么它们将共享公共依赖项。这将有助于将磁盘和内存中的项目总数保持在最低限度。下面的图片显示了一个包含3个依赖于lvanlys.dll的PPL的项目。所有这些ppl都构建在同一位置,因此它们将共享dll。它还带有前缀,因此不会与LabVIEW附带的lvanlys.dll冲突。请参阅共享依赖项ZIP文件中的示例。

  • 2020-3-7 15:39

    我将DLL lvanlys.DLL调用重命名为“C:\程序文件(x86)\国家仪器\LabVIEW 2014\resource\lvanlys.*”
    它删除了我在依赖项中的一个lvanlys.dll。
    我希望这对你们任何人都有帮助。

  • 2020-3-7 16:50

    我也有同样的问题,从2015年的SP1升级到2016年,当我的VI现在执行时,它给了我在RT上的错误。
    似乎依赖关系是由niu AALBase.lvlib:Mean.vi和niu AALBase.lvlib:Median.vi引起的(在我的例子中),它们是在那个DLL中实现的,因此DLL试图在看起来没有实现那个函数的RT上加载ADVAPI。
    编辑:
    我想我发现了这个问题,以前,在生成RT构建时,有一个名为data的子文件夹是作为构建过程的一部分生成的,我曾经将构建的应用程序部署为llb,我也在交付data文件夹。
    但是,如果您查看RT,系统目录中有一个lvanlys.dll,如果您将其复制(ftp)到您的PC并查看导入部分(以及大小),您可以看到labview构建过程打包的文件与数据文件夹中的文件不同,特别是可以看到,data文件夹中的一个具有advapi32依赖关系,而RT system文件夹中的一个不具有这种依赖关系。
    为了解决这个问题,我从数据文件夹中删除了lvanlys.dll,这个文件夹是我在RT上用.llb部署的,现在它正在无错误地执行。
    看起来RT的PE(可移植可执行文件)加载程序优先使用位于./data文件夹中的dll的本地副本,而不是系统副本(如果导入条目具有本地匹配项,则MS-Windows PE加载程序也会这样做,但清单中引入的一些新功能除外),如果找不到./data版本,则会返回到系统文件夹一。

  • 2020-3-7 17:03

    在构建RT可执行文件期间,不应将DLL复制到数据文件夹的分析很可能是正确的。
      lvanlys.dll以两种方式存在的原因与以下事实有关:除了最简单的dll外,现在必须构建两个不同的dll,用于Windows和用于LabVIEW RT的Pharlap ETS系统,尽管Pharlap基本上实现了与Windows兼容的加载程序。原因是,Pharlap API支持大多停留在Windows NT 4.0所提供的水平(缺少一些在RT系统上实现的功能)。如果你使用一个现代的C编译器,它只会创建一个不再在Pharlap ETS上加载的动态链接库,除非你通过循环和循环将其链接到一个定制的C运行库,这和拔掉所有牙齿一样有趣。但是,用一个旧的编译器为现代的Windows版本编译也不再是一个好主意。
       很明显,创建运行时可执行文件的生成组件在2016年发生了更改,并且由于目标上的RT系统已经提供了lvanlys.dll,因此不应将其包含在RT可执行文件的生成中。相反,它将通常用于Windows生成的lvanlys.dll复制到生成目标中。

  • 2020-3-7 17:06

    我想分享一些关于这个特定dll的想法。
    RT构建规范不会故意部署某些库,即使它们可能包含在构建中。当使用LabVIEW开发环境进行部署时,部署会检查是否有RT系统已经使用的启动库,并从部署中删除这些库。
    lvanlys.dll就是这些库之一。就像所有人提到的,RT目标上有一个版本,专门为RT编译。RT dll安装在RT OS上。生成时附带的dll是Windows版本。
    如果RT构建规范是从LabVIEW项目部署的,则dll不应复制到RT目标。我在2015年、2016年和2017年的LabVIEW中对此进行了验证。在LabVIEW 2017中,dll根本不包含在生成中。
    如果使用2016并手动将dll复制(如FTP)到c/ni rt/startup/data文件夹,则会看到systemfunction错误消息。不管出于什么原因,2016版本包含systemfunction036,而PharLap不支持它。它不应该阻止RT-EXE正确执行。看看这个知识库。它附带了一个可执行文件,您可以验证一个dll是否可以在PharLap中使用。如果在生成时附带的2016版dll上运行,则systemfunction036将显示为错误导入。

6个回答
2020-3-6 16:47:04 1 评论

举报

1 条评论
  • 2020-3-6 17:28

    这个文件夹下是有这个dll文件的,但是我打开所有的调用库函数的例子,都显示这个错误,可不可以具体一点,有偿

2020-3-6 16:57:46 3 评论

举报

3 条评论

lvanlys.png (30 KB, 下载次数: 9)

lvanlys.png
2020-3-6 17:58:51 评论

举报

2020-3-6 18:10:56 评论

举报

2020-3-6 22:30:17 2 评论

举报

2 条评论
  • 2020-3-6 23:10

    大神用的什么版本的,我想把这个正常的dll文件复制进去看有没有用,ni官网上有人用这个方法成功过

    徐立翔 回复 wode答案: 2020-3-7 19:28

    我安装的是labview2018 32bit英文版,没有出现你这个问题,除了需要在ODBC中进行数据源设置外,其他运行正常

数据库数据显示.zip

1.59 MB , 下载次数: 33

2020-3-7 12:26:34 评论

举报

撰写答案

你正在撰写答案

如果你是对答案或其他答案精选点评或询问,请使用“评论”功能。

您需要登录后才可以回帖 登录/注册

声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表德赢Vwin官网 网立场。文章及其配图仅供工程师学习之用,如有内容图片侵权或者其他问题,请联系本站作侵删。 侵权投诉
快速回复 返回顶部 返回列表
关注微信公众号

德赢Vwin官网 网

德赢Vwin官网 论坛

社区合作
刘勇
联系电话:15994832713
邮箱地址:liuyong@huaqiu.com
社区管理
elecfans短短
微信:elecfans_666
邮箱:users@huaqiu.com
关闭

站长推荐 上一条 /6 下一条

快速回复 返回顶部 返回列表