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.
From LabVIEW Getting Started Window, select Tools»Instrumentation»Create Instrument Driver Project to launch the Instrument Driver Project Wizard. Select New driver from template from the Project Type menu and select the type of instrument from the Source Driver menu. Select Next. Create a Driver Identifier.
Launch LabVIEW. Open NI Instrument Driver Finder by navigating to the Tools tab >> Instrumentation >> Find Instrument Drivers. If you have a connected and powered on instrument, double-click the instrument under Connected Instruments to populate the Manufacturer and Additional Keywords search fields.
In LabVIEW, select Tools»Instrumentation»Import LabWindows/CVI Instrument Driver to display the LabVIEW Instrument Driver Import Wizard dialog box. Select Basic or Advanced depending on how you want to convert the instrument drivers. In the Basic mode, you can specify only the function panel (. fp) file.
In LabVIEW, an instrument driver is a set of VIs that communicate with an instrument using LabVIEW built-in VISA I/O functions. Each VI corresponds to a programmatic operation, such as configuring, reading from, writing to, and triggering an instrument.
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)
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).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With