Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

USB RS232 type sensor with Labview to read and record data on laptop computer

I am trying to build a package unit with one sensor that will be read by a stand alone labview program.  I am looking at using a laptop to read the sensor and most laptops only have USB ports.  The problem comes in since most of the basic sensors have a RS 232 type digital output.  I don't want a multi-channel USB daq device since I want to keep things simple and cheap and I only need one channel.  I was hoping I could just connect the sensor with a USB cable but after reading up on USB I gather that is not possible.  Does anyone know of an easy way to read the data?  I was thinking of using an RS232 to USB converter and somehow modifying it so I could use the power that is available from the USB port.  I also found some boards like the ActiveWire-USB but I am unsure of how that would communicate with Labview.  (www.http://www.activewireinc.com/).  I want to keep things simple and cheap.
 
The other question I had was the Labview stand alone executable.  Currently I have Labview 6.1 and will need to upgrade.  If I want to create stand alone executable GUI program to read and record the data from the sensor on a number of computeres what version of Labview do I need?  I need to read the pressure and do a couple of simple calculations display and record the results.
 
Additional sensor data:
Communication parameters:
Voltage - 5,0 V TTL
Transmission Rate - 38400 bauds
Parity - None
Data bits - 8
Stop bit - 1
There are other cheap OEM sensors out there with similar RS232 communications.  The sensor is an absolute pressure sensor with digital output.
 
0 Kudos
Message 1 of 23
(11,075 Views)
Fantester,

there are several  USB-RS232 converters that do the job, while others dont.
As a trend you may assume that the cheaper ones have more problems...
I have had luck with converters from Keyspan, Sunix and Moxa. 
Those converters provide virtual serial ports that are accessed by LabVIEW (just as physical serial ports).

Any LabVIEW version that run on your machine will do the job as long as you have the ability to create executables - you need the application builder package. There's one for your version 6.1, but I am not sure if NI still sells it.
The current version of LabVIEW is 8.01, which is the only version that is beeing sold. Check NIs site at ni.com.

HTH   and
Greetings from Germany!
--
Uwe

0 Kudos
Message 2 of 23
(11,064 Views)

I was able to find a USB sensor that the computer reads as a comm port.  Now I am haveing trouble reading the data faster than 2 Hz.

The sensor is made by http://www.spectresensors.com

 

0 Kudos
Message 3 of 23
(10,948 Views)
Fantester,

I had a look at the website and found the 9510U series. Its data sheet states a baud rate of 9600, which typically converts to about  1kB/s. As those devices data protocol is not provided, I am lost in speculation. The device provides temperature and pressure with high resolution. Assume a kind of ASCII datat transfer protocol with tempaerture as absolute temperature with 1/2 degrees resolution and separation byte and 4 bytes of units, you need at least 10 Bytes for temperature. As the pressure resolutin is 0.05% and pressure range is at least 1000 psi, you need at least 11 bytes for it. Now ad some message header and footer and CRC and you'll easily end up with about 30 Bytes per message. With 10kB/s, your protocol _can_ not transfer much more than about 33 messages per second.
I am not familiar with the measuring principle of that device; maybe this is the cause of the slow transfer rate. OR your LabVIEW code dismisses most of the messages?
If you need more specific hints than you need to provide more specific data...

Greetings from Germany!
--
Uwe

0 Kudos
Message 4 of 23
(10,939 Views)
I requested some information about how many bytes are sent.  I get a little confused with bytes and bits so if you have any questions I should be asking let me know.  I  believe the sensor uses a bridge circuit.  
In hyperterminal when you enter in a. it will continually output the digital data in hex and text like this
25.4 C 30-> 0xd37d 0x24c4 0x0e37  14.13 PSI
I am only interested in the first hex number.
In my vi I open the visa com port then I write the a. command to start getting the data.  The only way I got all the data was when I wired in a value of 46 to the read visa byte count terminal.  I tried using the "bytes at serial" vi but it only gives me 0 so I went back to using 46.  If I use a number lower than 46 the data gets cut off.  46 is also the number the the VISA read vi outputs at the return count terminal.  Am I missing some of the data?
Here is a picture of the vi.
 
0 Kudos
Message 5 of 23
(10,927 Views)
Fantester,

I have reviewed your code.
It is OK so far, but you either have a limited understanding of whats going on or you mix two ways to get your data.
Let me provide some basic info first:
Using VISA one uses the serial port in an asynchronous way That means one instructs the OS to do some serial comm and sometimes later when one expects the results one asks for them. In your VI, you instruct your OS to send the string 'a.' to your sensor.  This will happen while your LV code is continuing and will take at least about 2 ms (2 characters at 9600 baud are about 1 ms/char = 2ms). As your sensor is physically connected via USB and a virtual serial port, this adds some more delay depending on the system driver for that virtual serial port. In fact, this can add to some 100ms!
Your sensor receives the command, processes it and starts sending its data. Each data set is 46 Bytes, which will take about 46 ms alone to transmit via the serial port. The virtual serial port driver may add some more delay again. Than VISA receives them and LabVIEW can read them or return 'Bytes at serial port'.

As you wrote, the command 'a.' is needed just once, I'd suggest to move it before the While loop. And than you have two different solutions:
1. 'Polling': You insert a small wait (wait_ms with, say, 10) in the loop before you ask for 'Bytes_at_serial_port'. Afterwards you read  the number of availabel bytes and ignore all warnings. Append the result to a shift register and search the result for the string 'PSI'. If you find it, you have at least one complete data set in your shift register string. Remove the part before 'PSI' and the 'PSI' and proces it  Feed the string after that to the shift register again and continue.
This way your Loop will just add up the readings until it has accumulated a whole result string. AND the wait_ms in the loop frees enough time to run other processes.
2. VISA operation: Just ignore all that stuff! In your While loop, just read 46 Bytes with a timeout of, say, 2000 ms (default timeout). Ignore warnings. This way VISA waits up to 2000 ms to receive  those 46 Bytes Than you can process your data. You might also set the character 'I' (the last one of your data string) as stop character.

Polling is more flexible - you can easily handle missing or corrupted bytes and different message lengths. But it takes much more programming and adjusting effort in order to get the code robust. The VISA way is much easier, but has some problems with corrupted mesages. If you choose this way you should use a termination character!

Just another note: Make sure to check if Hyperterminal auto-inserts CR and/or LF (0x0d and/or 0x0a) and if your sensor returns those. LabVIEW does not auto-do such! If the sensor needs such, you have to do it yourself.

Greetings from Germany!
--
Uwe

0 Kudos
Message 6 of 23
(10,909 Views)

If I do the polling I have a few questions.  1. How do I determine the actual data acquisition rate?  Should I append the string to an array?

2. How do I determine if Hyperterminal adds a line return?  When I enter commands in hyperterminal the data starts after I type the period.  I do not press the "enter" key. 

3. Where do I add the termination character?  In the VISA configuration vi?

It may be the hardware because I noticed that I had to insert the set visa i/o Buffer size vi into my code like mentioned in "Error 1073807298 on VISA write" before my vi would work. 

Here is the info from the other message

+++++

In order to work around a serial device that doesn't support the Windows flush command try inserting a VISA Set I/O Buffer Size VI directly after the VISA Open for any COM port. Please make sure that you set the mask to 48 and the size to at least 4k or the maximum number of bytes that you will ever write or read. That should cause the VISA Writes to not call the Windows flush command and allow the writes to execute without problems if my assumptions are correct.

+++++

I am still waiting on a response from the vendor.  I may have to call them when I get some time.


 

0 Kudos
Message 7 of 23
(10,873 Views)

Well I found out that the device I am using has a CP210X USB to UART Bridge controller.  Would it be possible to use labview/max to produce the drivers and increase the baud rate?  I still need to find out what communicates to the CP210X.  It may be what is so slow. 

0 Kudos
Message 8 of 23
(10,593 Views)
Fantester,

You should not need to write a driver to increase the baud rate of the CP210X. The VISA Configure Serial Port function allows you to set the baud rate as required.

Still, if the
CP210X specs does not allow a baud rate over 9600 there is not much you can do to force the issue.

-- Michael --

| Michael K | Project Manager | LabVIEW R&D | National Instruments |

0 Kudos
Message 9 of 23
(10,557 Views)

Hello,

I am starting to use LabVIEW and the transducer from www.spectresensors.com (9510U).

What do you recommend to have knowledge on how to program a GUI to get information from the USB-transducer?

Thanks a lot!

JeanPi

0 Kudos
Message 10 of 23
(9,278 Views)