National Instruments Usb-232 Driver Download

[Fonda Stacer]

Thisis a hardware problem. I have a NI USB-232 device that seems to not be working properly on one computer. In MAX, it appears to connect and disconnect repeatedly and it never shows up in the Windows Device Manger. The USB-232 device seems to be working properly as it is recognized by other computers that it is attached to. And other NI USB-232 devices work fine on this computer. Does anyone have any pointers with regards to things I can do to get this device functional on this computer?

This wouldn't happen to be a cheap and crappy FTDI, or Prolific USB to RS232 from China would it? If it is these are usually counterfeit and will usually not work with the latest drivers because they will disable counterfeit hardware.

Make sure the COM port shows up in Device Manager and doesn't have any issues before trying to use it in MAX or LabVIEW. If it doesn't look right there, then there isn't any chance it will work in MAX or LabVIEW.

The fact you say that it's only that particular NI USB-232 on that particular PC but the NI USB-232 works fine in other PCs and other NI USB-232s work fine on that PC seems very strange. If it was one or the other it would narrow it down to a problem with the PC (e.g. USB controller, drivers) or the NI USB-232 (e.g. faulty).

Sorry I do apologize I scanned the first post and missed that too. At the price NI charges I'd hope they aren't counterfeit but I don't have one on hand to test with. The counterfeit ones are usually something like a dollar or two. At my first job someone ordered a large bucket of those USB converters. We had a hard time getting them to work and tried to get a refund, instead the seller sent us another bucket of them for free. I'm not sure what you do with 200 cheaply made USB converters that only work part of the time with one the right drivers.

In the end, I simply swapped it with another usb-232 cable. A less painful solution then continuing to try to diagnose why this cable all of a sudden did not want to work with the current computer. For the record, I spoke with AE about this and got no further.

I'm in the processes of buying a new data acquisition system for my company to use for various projects. At first, it's primary purpose will be to monitor up to 20 thermocouples and control the temperature of a composites oven. However, I also plan on using it to monitor accelerometers, strain gauges, and to act as a signal generator.

I'm going to try to get the same I/O capabilities with different NI hardware for less $ + LabVIEW to see if I can get it for less $. I'd like to see if anyone has any suggestions other than LabVIEW for me.

You might check out the somewhat less expensive Agilent 34970A (and associated cards). It's a great workhorse for different kinds of sensing, and, if I recall correctly, it comes with some basic software.

Second, you don't NEED to use NI hardware with LabView. For thermocouples your best bet is to look into multichannel or multiple single-channel thermocouple units - something that reads from a thermocouple and outputs to something like RS-232, etc. The OMEGABUS Digital Transmitters are an example, but many others exist.

In this way, you need only a breakout card with lots of RS-232 ports and you can grow your system as it needs it. You can still use labview to acquire the data via RS-232 and then display, log, process, etc, it however you like.

Third party signal generators would also work, for example. You can pick up good ones (with GPIB connection) reasonably cheaply and with a GPIB board can integrate it into LabView as well. This if you want something like a function generator, of course (duty cycled pulses, standard sine/triangle/ramp functions, etc). If you're talking about arbitrary signal generation then this remains a reasonably expensive thing to do (if $5000 is our goalpost for "expensive").

This also hinges on what you're needing the signal generation for - if you're thinking for control signals then, again, there may be cheaper and more robust opitons available. For temperature control, for example, separate hardware PID controllers are probably the best bet. This also takes care of your thermocouple problem since PID controllers will typically accept thermocouple inputs as well. In this way you only need one interface (RS-232, for example) to the external PID controller and you have total access in LabView to temperature readings as well as the ability to control setpoints and PID parameters in one unit.

Perhaps if you could elaborate on not just the system components as you've planned them at present, but the ultimaty system functionality, it may be easier to suggest alternatives - not simply alternative hardware, but alternative system design altogether.

Have a look at Omega CNi8C22-C24 and CNiS8C24-C24 units -> these are temperature and strain DIN PID units which will take inputs from your thermocouples and strain gauges, process the inputs into proper measurements, and communicate with LabView (or anything else) via RS-232.

This isn't necessarily a software answer, but if you want low cost data aquisition, you might want to look at the labjack. It's basically a microcontroller & usb interface wrapped in a nice box (like an arduino (Atmel AVR + USB-Serial converter) but closed source) with a lot of drivers and functions for various languages, including labview.

Reading a thermocouple can be tough because microvolts are significant, so you either need a high resolution A/D or an amplifier on the input. I think NI may sell a specialized digitizer for thermocouple readings, but again you'll pay.

As far as the software answer, labview will work nicely with almost any hardware you choose -- e.g. I built my own temperature controller based on an arduino (with an AD7780) wrote a little interface using serial commands and then talked with it using labview. But if you're willing to pay a premium for a guaranteed to work out of the box solution, you can't go wrong with labview and an NI part.

LabWindows CVI is NI's C IDE, with good integration with their instrument libraries and drivers. If you're willing to write C code, maybe you could get by with the base version of LabWindows CVI, versus having to buy a higher-end LabView version that has the functionality you need. LabWindows CVI and LabView are priced identically for the base versions, sothat may not be much of an advantage.

Given the range of measurement types you plan to make and the fact that you want colleagues to be able to use this, I would suggest LabVIEW is a good choice - it will support everything you want to do and make it straightforward to put a decent GUI on it. Assuming you're on Windows then the base package should be adequate and if you want to build stand-alone applications, either to deploy on other PCs or to make a particular setup as simple as possible for your colleagues, you can buy the application builder separately later.

As for the DAQ hardware, you can certainly save money - e.g. Measurement Computing have a low cost 8-channel USB thermocouple input device - but that may cost you in setup time or be less robust to repeated changes in your hardware configuration for different tests.

A few thousand dollars is not a lot of money for process monitoring and control systems. If you do a cost/benefit analysis, you will very quickly recover your development costs if the scope of the system is right and if it does the job it is intended to do.

If you go down the route of serial instruments, another piece of hardware that might be useful is a serial terminal (example). These allow you to connect arbitrary numbers of devices to your network. You computers can then use them as though they were physical COM ports.

LabVIEW is a great visual programming environment. In terms if we want to drag,drop and visualize our system. NI Hardware also comes with the NIDAQmx Library which can be accessed through our code. Probably a feasible solution for you would be to import the libraries into another programming language and write code for all the activities which otherwise you were going to perform using LabVIEW. Though other overheads like code optimization would be the users responsibility, you are free to tweak the normal method flow, by introducing your own improvements at suitable junctures in the DAQ process.

At the time, where GPIB was the main physical communication interface, remote control applications communicated directly with GPIB hardware drivers. Later, the RS-232 serial interface was introduced as a cheaper alternative to GPIB. Here too, applications communicated directly with RS-232 hardware drivers.

The situation got even more complex as LAN interface has become the standard in the computer industry. Test & Measurement instrument vendors have realized the potential LAN interface can bring to the connectivity options for their instruments. However, using a third software interface for the LAN-connected instruments would bring even more incopatibility for the measurement applications.

Out of the motivation to unify the software interface, VXIplug&play Alliance introduced VISA standard (Virtual Instrument Software Architecture). The current maintananer of VISA is IVI Foundation. For the LAN interface, the TCP/IP-based protocol was named VXI-11. Later, came its improved version called HiSLIP (High Speed LAN Instrument Protocol). The last addition was support for the USB interface. The USB class of devices natively supported by VISA are called USB-TMC (Test and Measurement Class).

VISA implementations come from different vendors, but they all must abide to the same VISA interface standard. In the following chapters we present VISA and VISA Tools from Rohde & Schwarz and National Instruments.

3a8082e126