8

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.

Swinders
  • 2,261
  • 4
  • 29
  • 43
Tim
  • 20,184
  • 24
  • 117
  • 214

6 Answers6

8

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)

nekomatic
  • 5,988
  • 1
  • 20
  • 27
  • Thanks. I will definitely do it the right way when we have time to get to it. I just assumed it would be fairly straightforward to get this working. – Tim Oct 28 '08 at 04:21
3

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).

Bill the Lizard
  • 398,270
  • 210
  • 566
  • 880
3

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.

Swinders
  • 2,261
  • 4
  • 29
  • 43
  • thanks - I understand about LV having rs232 support, and like you said, I want to make using the device very simple. (I am not the device mnfgr - just a developer filling a (tiny) need) – Tim Oct 23 '08 at 23:48
2

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.

Bill the Lizard
  • 398,270
  • 210
  • 566
  • 880
  • Yeah - that is the trouble I have found. I will try looking for more info on that site. – Tim Oct 23 '08 at 01:09
0

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.

jeffry7
  • 67
  • 2
  • Hallo Jeffry, do you know how to write Siemens S7 telegram header through TCP/IP, would it be just for example in labview open TCP/IP and write the S7 Fetch/Write telegram and send it? The whole Fetch or Write header include data will be the ADU(application data unit)? or there are more headers before send throught tcp/IP? Appreciate, sincerely. – Fuevo Feb 01 '19 at 14:30
0

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:

  • init.vi (configuration and connection start)
  • deinit.vi (disconnect)
  • global.vi (stores connection reference and e.g. connection state)
  • common VISA read and write vi (bind them into one VI so that you can do some changes e.g. because of timing issues to all commands at once)
  • various commands (they use the common VISA read and write vi that you created before)

- 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!

Jensolo
  • 49
  • 6