LabView data acquisition for DAQ cards made by vendors other than NI

[Waqar123]

Hi,

I am a beginner in LabView Programming. I have a 32 channel PCI based DAQ Card (i.e PCI-1602 from the manufacturer ICPDAS) and i want to interface it with Labview 8.5.

 
So how to interface DAQ cards to Labview 8.5 that are made by vendors other that NI? Do i need DAQmx (or some other driver) for this?

What are the other drivers/components required to access the PCI-1602 DAQ card (device) from LabView 8.5?

(The driver for card PCI-1602 are installed in my win XP and dispalyed in Device Manager).

Please provide some tutorial for the above mentioned interfacing issue.

Please guide me in this regard. Thanks

[Ray.R · Accepted solution]

---

@Waqar123 wrote:

Hi,

I am a beginner in LabView Programming. I have a 32 channel PCI based DAQ Card (i.e PCI-1602 from the manufacturer ICPDAS) and i want to interface it with Labview 8.5.

 
So how to interface DAQ cards to Labview 8.5 that are made by vendors other that NI? Do i need DAQmx (or some other driver) for this? You will need the drivers from the manufacturer of the board.  In your case, "ICPDAS".

What are the other drivers/components required to access the PCI-1602 DAQ card (device) from LabView 8.5? Same as above.

(The driver for card PCI-1602 are installed in my win XP and dispalyed in Device Manager). That's good.  So you did take care of my 2 answers above. 🙂

Please provide some tutorial for the above mentioned interfacing issue. To learn more about LabVIEW, I suggest you try looking at some of these tutorials.

Please guide me in this regard. Thanks

---

Depending on what you are doing with the DAQ cards, they may do the job well; however, from experience, there were some functions that I could achieve with the NI cards that I could not with 3rd party maufacturers.  This is not to say that it is your case; however, it is worth mentioning as it took me quite a while to figure out why the code worked with one DAQ card (NI) but did not with another (Non-NI).

The drivers that you installed may or may not include VI code and examples.  They may be dll's.  If that is the case, you may want to write LabVIEW "Wrappers" around those functions, as it will simplify your life.  If the drivers are in the form of dll's and there are no LabvIEW examples or VI's available, you will need to read up on Call Library Function Node.

R

[LV_Pro]

As Ray says you if you have no LabVIEW examples from the board's manufacturer you may have to create your own. If they did supply a dll you may have to write a wrapper to use it. If they have supplied examples in another language, such as C, it will help you to see how to make calls to the dll, otherwise you will have to see it the hardware manufacturer will supply that information.

I am not an employee of National Instruments, nor do I currently own any NI stock but I have found in many previous instances that any perceived cost savings from buying other vendors' boards, unless they had functionality not found in an NI version, was usually lost in the time, frustration and effort to get other vendors' hardware to work. I just spent two weeks trying to diagnose why my program would randomly crash to finally trace it down to the hardware (non-NI) vendor's dll. Unfortunately, as I am a consulting engineer, brought in sometimes after much of the hardware is already purchased, I have had to face this type of thing often. Other hardware is often well built, and less expensive to purchase, and in some cases, comes with excellant support, but that is not always the case. In fact, even when the manufacturer claims to have "LabVIEW drivers", try and research this (by asking here for instance) as all too often the drivers were written by people with little or no LabVIEW experience, as was the case I mentioned before. Although in that case the LabVIEW drivers were just the first problem, the manufacturer's dll was the primary one.

[Ray.R]

Thanks Putnam for the detailed description.

I've been in the same shoes.  Was consulting at a client site and some COOP Student convinced management to buy cheaper (non-NI) DAQ boards, claiming they were identical (so the other mfg claimed).  I was writing automation sw for a R&H Spectrum Analyzer.  We got the boards, and the test sw did not work on the cheaper ones.  After 1 - 2 weeks of debug, we discovered that the cheaper ones were not compatible.  COOP Student leaves and I was left to justify to mngt why the  SW was not working 😠  Fortunately, we could return the boards and purchase NI boards instead.  🙂

Cheap != cheap...

What costs more?  Good board or extra time to make it work (if it does)?

Wish I had NI stocks also..  😉

[Waqar123]

Thanks Ray.R, LV_Pro for detailed answers to my question and sharing your experiences.

You are right that there will be dll and VI files provided by the manufacturer. I browsed the CD and found dlls, a lot of C functions for initiallizing, configuring, reading, writing, A/D, D/A etc. and VIs in it. In these VIs they try to access these C functions to perform the required operation.

Do you have any other reference or book to access C functions and programming tags in LabView.

Thanks.  

[Ray.R]

There are quite a few discussions on the topic within this forum.  Simply do a search and use "dll in LabVIEW" as a search topic.  Or "Library Function Node".

You can also use Context Help.

[using USB data aciquisition]

Hi

I am new to  data acquisition using LabVIEW i am trying with a data card which is not of NI (i.e card specifications USB port using RS485-USB converter) .suggest me weather its possible or not to do with this data card

Thanks

[Dennis_Knutson]

A USB-RS485 converter is not a DAQ device. What do you have connected to it? Make and model?

[using USB data aciquisition]

Hello sir,

 I tried to connect a process and the process descripiton  can be viewed through this site( http://www.apexinnovations.co.in/pc326a.htm) suggest me the suitable data card that can acquire data through NI

[Dennis_Knutson]

It says the USB connection is RS-485 so it seems you have the necessary hardware.