LabVIEW“驱动程序” - 入门
我编写了一个独立的应用程序，通过 RS-232 端口控制设备，一些客户希望能够通过 LabVIEW 使用该设备。 我看到一些帖子描述了学习使用 LabVIEW 时从哪里开始，但我想知道是否有人有为 LabVIEW 编写插件/驱动程序（这个词合适吗？）的经验，也许可以为我指明正确的方向。
现有的应用程序是 GUI，允许人们使用更高级别的概念来控制设备 - 而不必了解串行端口通信内容的语法和协议。 我也想将其抽象化，以便用户可以将某些东西插入LabVIEW，并且我认为它公开了一些动词和方法，允许操作设备并向客户端提供数据。
我认为LabVIEW有一个串行端口接口，但我确信使用该设备的人不想编写代码（解析器等）来与设备通信。
I have written a standalone app that controls a device through RS-232 port and some customers want to be able to use the device with LabVIEW. I have seen some threads describing where to start when learning to use LabVIEW, but I was wondering if anyone has experience with writing a plugin/driver (is that the right word?) for LabVIEW and perhaps point me in the right direction.
The existing app is GUI that allows people to control the device with higher level concepts - rather than have to know the syntax and protocol of the serial port comms stuff. I want to abstract that away as well so that users can just plug something into LabVIEW and I suppose it exposes some verbs and methods that allow the device to be manipulated and also provide data to clients.
I think there is a serial port interface from LabVIEW, but I am sure the people using this device do not want to have to write the code (parsers and etc) to communicate with the device.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
如果您准备花一些时间学习如何在 LabVIEW 中进行编程，可以找到有关如何开发仪器驱动程序的相关信息 此处 和 此处
。
本质上，您应该提供一组 VI（LabVIEW 代码单元）来实现设备支持的各种操作。 LabVIEW程序员将使用VISA资源（即串行端口）和VI应提供的错误输入/输出终端将这些序列链接在一起。 有关示例，请参阅第二个链接。
如果您不想学习如何正确执行此操作（您的第二篇文章建议您不要这样做），那么要么创建一个公开必要函数的 DLL，要么委托 LabVIEW 程序员为您编写驱动程序。 如果您可以提供足够的协议文档，并且不是非常复杂，那么他们应该需要一个下午的时间。 如果您有热衷于 LabVIEW 的用户，那么他们中的一个可能会很乐意以适当的折扣或奖励为您完成这项工作 - 对于任何精通 LabVIEW 的人来说，这确实不难，而且他们已经掌握了这一工作在您的设备上并了解它的作用。 您可能希望首先与其他 LabVIEW 用户一起对结果进行 Beta 测试，因为您无法自行评估他们所做工作的质量。
如果您采用 DLL 路线，则需要检查所需的参数是否与 LabVIEW 数据类型兼容。 我不是 C/C++ 程序员，所以我无法详细告诉您这意味着什么，但是 这可能会有所帮助（Rolf Kalbermatter 是 LabVIEW 与外部代码接口方面的专家）。
如果您想找到一名 LabVIEW 程序员，那么 National Instruments 可以通过他们的联盟计划向您推荐一位。
（编辑添加了有关为 LabVIEW 编写 DLL 的 LAVA 论坛帖子的链接）
If you are prepared to invest a bit of time into learning how to program in LabVIEW, the relevant info on how to develop an instrument driver can be found here and here
.
Essentially you should provide a set of VI's (the unit of LabVIEW code) that implement the various operations supported by your device. LabVIEW programmers will chain a sequence of these together using the VISA resource (i.e. serial port) and error in/out terminals which your VI's should provide. See the second link for an example.
If you don't want to learn how to do this properly - which your second post suggests you don't - then either create a DLL that exposes the necessary functions, or commission a LabVIEW programmer to write the driver for you. If you can supply adequate documentation of your protocol and it's not hideously complicated then it should take them an afternoon. If you have users who are keen on LabVIEW then one of them might be happy to do the job for you for an appropriate discount or incentive - it's really not hard for anyone competent in LabVIEW to do and they are the ones who already have their hands on your device and understand what it does. You might want to beta test the result with your other LabVIEW users first, as you won't be in a position to assess the quality of what they do yourself.
If you go the DLL route you'll need to check that the parameters you require are compatible with LabVIEW data types. I'm not a C/C++ programmer so I can't tell you in detail what this means but this might be helpful (Rolf Kalbermatter is the guru on interfacing LabVIEW with external code).
If you want to find a LabVIEW programmer then National Instruments can refer you to one through their alliance scheme.
(Edited to add link to LAVA forum post on writing DLLs for LabVIEW)
对于您想要执行的操作，有两种选择。
创建一个 DLL，您的设备用户可以从 LabVIEW 调用。
在 LabVIEW 中重写您的应用程序。
为了吸引尽可能多的潜在客户，选项#1 将是您的最佳解决方案。 如果您的客户特别要求 LabVIEW 驱动程序，那么选项 #2 对于该特定客户来说可能是最不麻烦的。 原因是 LabVIEW 在很大程度上是一种小众语言（用于自动化和数据采集），对于许多 LabVIEW 开发人员来说，这是他们唯一了解的语言（或者是他们唯一熟悉的语言）。
There are two options for what you're trying to do.
Create a DLL that users of your device can call from LabVIEW.
Rewrite your application in LabVIEW.
To reach the largest possible number of potential customers, option #1 would be the best solution for you. If your customers are specifically asking for a LabVIEW driver then option #2 would probably be the least hassle for that specific customer. The reason for this is that LabVIEW is very much a niche language (for automation and data acquisition), and for many LabVIEW developers it's the only language they know (or the only one they know well).
LabVIEW 可以轻松处理 RS232 通信 - 您只需向客户提供设备使用的命令和语法列表，或许还可以提供一个具有基本功能的小型框架或示例 VI。
我赞赏您想要提供一个更强大的驱动程序，不需要用户解析自己的命令； 大多数供应商通常所说的 LabVIEW“驱动程序”只不过是捆绑在一个简单 GUI 中的一些命令（“init”、“read”）。
您不必重新构建完整的应用程序，只需为它们提供足够的资源即可自行开始 =)
首先，您可能需要使用 LabVIEW 中的 VISA。
LabVIEW can handle RS232 communication with little problems - you just need to provide the customer with a list of the commands and syntax that the device uses, and perhaps a small framework or example VI with basic functionality.
I applaud you for wanting to provide a more robust driver that doesn't require the user to parse their own commands; what is usually called a LabVIEW 'driver' by most vendors is little more than a few commands ('init','read') bundled up in a simple GUI.
You don't have to rebuild your complete application, just give them enough to get started on their own =)
To get started, you will probably want to use VISA in LabVIEW.
LabVIEW 程序员的最佳资源是National Instruments 知识库。 由于 LabVIEW 仅在一小部分人中流行，因此没有很多其他 Web 资源。
我在 LabVIEW 编程时读过的一本书是 LabVIEW Power 编程。 它有很多很好的示例代码，如果我没记错的话，它向您展示了如何使用用 C++ 编写的第 3 方 DLL。 不过，它绝对不会向您展示如何编写这些 DLL。
The best resource for LabVIEW programmers is National Instruments Knowledge Base. Since LabVIEW is only popular in such a small segment, there aren't a lot of other web resources out there.
One book that I read back when I programmed in LabVIEW was LabVIEW Power Programming. It has a lot of good example code, and if I remember correctly, it shows you how to use 3rd party DLLs written in C++. What it definitely doesn't show you is how to write those DLLs, though.
您的客户希望在 LabVIEW 中使用您的代码。 这并不意味着您必须编写 LabVIEW 代码。
LabVIEW 可以与 DLL 交互。 这里的技巧是避免更复杂的数据结构。 如果您继续按基本数据类型的值传递，就不会有问题。 LabVIEW 也可以使用数组与 DLL 进行交互。 避免使用指向指针或结构体的指针。
LabVIEW 还可以与.NET 程序集交互。
也没有什么可以阻止您使用 TCP/IP 上的客户端/服务器模型。
Your customer wants to use your code with LabVIEW. This doesn't mean you have to write LabVIEW code.
LabVIEW can interact with DLLs. The trick here is to avoid the more complicated data structures. If you keep to pass by value of basic data types you will have no problem. LabVIEW can work with arrays to and from DLLs as well. Avoid pointers to pointers or pointers to structs.
LabVIEW can also interact with .NET assemblies.
There is also nothing to stop you from using a client/server model over TCP/IP.
为 LabVIEW 编写良好的驱动程序时遵循的策略很大程度上取决于您想要使用该驱动程序的框架或测试应用程序。
在我看来，驱动程序应该始终在模块化范围内编写。 这意味着驱动程序基本上不依赖于最终实现它的测试应用程序或框架。
此外，您还应该考虑驱动程序的未来范围。 您只想创建 RS232 / VISA 驱动程序，还是还计划将来编写 TCP/IP 或 Modbus(TCP) 驱动程序。 如果是这样，面向对象的驱动程序可能允许您重用大量代码。 但那样的话编程复杂度就会上升很多。
启动驱动程序有多种可能性。 我之前的同事已经指出，有一个 VISA 驱动程序，您可以使用它通过 RS232 轻松连接。 如果您想创建一个客户可以轻松实现与设备相关的驱动程序，以下一些想法可以帮助您：
- 使用 lvlibs： 始终将每个驱动程序存储在不同的库中（*.lvlib）。 lvlib）。 这样您就可以轻松地将它们包裹起来并移动它们。 此外，您还可以利用自己的命名空间。 这意味着如果您将来有两个驱动程序都有一个名为 init.vi 的 VI，那么它们可以在一个项目中共存。 LabVIEW 只需将库名称作为前缀添加到文件名中，例如 driver.lvlib:init.vi
- 提供 API： API 是展示驱动程序中最重要的 VI 的好方法，应由客户使用。 您甚至可以将这些VI链接到多态VI中，这样选择起来就容易得多。 然后，该 API 应包含一个 init.vi，它允许进行基本配置（如波特率和 COM 端口）并启动配置
-提供示例： 将一个 VI 添加到库中，演示简单的配置应用程序
-将连接引用存储在全局或FGV中：如果您的客户仅使用该设备的一个实例，那么如果在init.vi中连接后将VISA引用存储在全局中，那么应用程序会变得更加容易然后在每个命令中读取
- 提供随时可用的命令和查询：将您的设备能够在单独的VI中处理的所有命令包装起来，这些VI已经包含所有格式，转换和RS232命令
-基本VI结构：作为开始，我建议您提供以下VI：
- 文档： 确保为每个 VI 编写可通过上下文帮助阅读的文档，以便您的客户更轻松地使用
- 考虑 PackedLibs： 它可以从该库构建一个 PackedLib 是有意义的。 这有很多好处，例如更少的构建时间、简单的部署以及客户无法更改您的代码。 但它也有一个缺点，那就是它总是必须使用正确的 Labview 版本来构建。
希望有帮助！
The strategy you follow when writing good drivers for LabVIEW is greatly depending on the framework or test application where you want to use that driver.
In my opinion a driver should always be written in a modular scope. This means that the driver is basically not having any dependencies to the test application or framework where it is finally implemented.
In addition you should think about the future scope of your drivers. Do you only want to create an RS232 / VISA driver, or do you also plan to write a TCP/IP or Modbus(TCP) driver in future aswell. If so an object oriented driver might allow you to reuse a lot of code. But in that case programming complexity will rise a lot.
There are many possibilities to start a driver. The colleagues before me already pointed out, that there is a VISA driver that you can use to easily connect via RS232. If you want to create a driver that your customer can implement quite easily in relation to the device some of the following ideas could help you:
- Use lvlibs: Always store each driver in a different library (*.lvlib). That way you can easily wrap them up and move them. In addition you also take advantage of an own namespace. This means that if you have two drivers in the future that have a VI called init.vi, then these can coexist in one project. LabVIEW simply adds the library name as a prefix to the filename, such as driver.lvlib:init.vi
- provide an API: An API is a good way to present the most important VIs of your driver that should be used by the customer. You can even link those VIs in a polymorphic VI where selection is much easier. This API should then contain e.g. a init.vi that allows basic config (like baud-rate and COM-Port) and also starts configuration
- provide an example: Add a VI to the library that demonstrates an easy application
- store connection ref in global or FGV: If your customer only uses one instance of that device it could make application much easier, if the VISA ref is stored in a global after connecting in init.vi that is then read in each command
- provide ready-to-use commands and queries: wrap up all the commands that youre device is able to handle in separate VIs that already contain all the formatting, conversion and the RS232 command
- basic VI structure: As a start I would recommend you to provide the following VIs:
- documentation: Make sure to write a documentation for each VI that can be read via context help, to make it easier for your customer to use
- think about packedLibs: it could make sense to build a packedLib from that library. This has many benefits like less building time, simple deployment and that the customer cannot make changes to your code. But it also has the downside that it always has to be built with the right labview version.
Hope that helps!