RS 232 with more than 1000 Hz

[cikl]

I am trying to read out data from a serial port which is given out constantly by a measurement device at a predefined rate (up to 4000 Hz). It is connected via USB which creates a virtual Com-port with a baudrate of 921600. Communication works with the device. In order to transfer these high rates the data stream of the device is set to binary ("$BIN" command). I use the VISA-read to get the data. The problem is that there occur bad (zero) values if I increase the data rate to 1000 Hz or higher. Is Labview not able to handle it? Or is it a buffer problem? Please check the attached VI. Is it possible to transfer the data stream at the given frequency to Labview?

Thank you,

Karsten 

[Joseph_Loo]

Have you checked the capacity of the RS232 data rate.  Generally it has a limitation of 128Kbits/sec. This represents 12 KBytes per sec if you are using 8 bit bytes (y0u must take in account of the 2 stop bits or 1 stop bit plus parity, etc). Thus your data stream at 1 khz has to be a maximum of 12 bytes per transaction. This must include all of your overhead. If you have header bytes for your data, you must include it.

So what is your RS232 data rate set?

[RavensFan]

Don't put the VISA close inside the loop, put it after the loop.  It takes time to close and reopen the VISA connection on every iteration.  And if the device sends data during the time the connection is closed (very likely at a 1000 Hz rate) then those bytes will be lost.

[Joseph_Loo]

I should have read the item a bit better. I think your answer is much better. Since I want to put my foot in my mouth, I think he is talking about rs422/423 interface not a RS232.

[ceties]

This won't probably solve your problem but definitely put the close VISA outside the loop! Edit: Ravens Fan was faster

Message Edited by ceties on 04-11-2008 11:09 AM

[cikl]

Thanks for the mods and comments.
The instrument can be connected by RS232 or USB. The USB connection creates a virtual Com port, so I thought it was equivalent?

I placed the "close visa" inside the loop because I get a buffer overrun else. But it's logical that this takes time 😕

About the transmission format... As far as I see it I only need 4 bytes per transmitted set of data.
I copy a part from the instrument handbook here:

"
8.3 Data telegram format

The CHRocodile E supports RS232 with extended Data rate (921600/sec)
and USB Full speed (12MBit/sec) interface.
The interface does not use hardware or software handshake. The computer
must therefore be able to receive the incoming data flow at any time in order
to correctly receive the acquired data. The possible Baud rate ranges from
9600/sec to 921600/sec, but the highest possible Baud rate should be
preferred in order to be able to use the high measuring rate of up to 4 kHz
which is provided by the CHRocodile E.
The Baud rate is set via the keyboard ([F4] > [F3]…: serial port baud rate).
During normal operation the CHRocodile E continuously sends data
telegrams. The telegram rate is determined by the CCD-Scan rate divided by
the selected average number.
The telegram consists of up to 16 data words, each 16 bits wide. These
words can be transmitted either as numbers represented in ASCII characters
or binary as 2 bytes with the MSB transmitted first.
(...)

ASCII mode

data 0,data 1,....,data N CR/LF
The enabled data words (selected by $SOD command) are output in ASCII
representation, each 5 characters long, ranging from 00000 to 65535,
separated by commas.
The telegram is concluded with carriage return / linefeed.
It should be noted that the ASCII mode does not enable the transmission of
the results at the full measuring speed of 4 kHz due to the inefficiency of the
coding. For high speed data transfer, the binary mode must be used.

Binary mode

Telegram format: (the values between the <> signs mean one transmitted
byte. The prefix 0x indicates hexadecimal notation.)
<SSByte1>,<SSByte2>,<data 0 MSB>,<data 0 LSB>,...,<data N MSB>,<data N LSB>
Each telegram consists of the selected data words, high byte first, and
begins with the synchronisation sequence SSByte1, SSByte2.
This sequence is equal to 0xFF, 0xFF after power up, but it can be changed
by $SSQ-command.
It must be noted that it is not sufficient to wait simply for the occurrence of
this synchronisation sequence since it can occur also in the binary data
stream (like the stop and start bit in continuous serial transmission can be
ambiguous). It is intended that this sequence is used only to synchronise the
entire data flow, not a single telegram. Since the length of the telegram is
known, a transmission once synchronised will stay synchronous and the
synchronisation sequence is only used to prove the state of
synchronisationThere are two ways to achieve synchronisation:
• stop the data flow by sending a command. After completion of the
command the sequence ”ready CR/LF” will be sent and the CHRocodile E
starts with a new telegram.
• when you don’t receive the synchronisation sequence at the expected
place, wait for the synchronisation sequence. This will synchronise the
data flow in a few cycles since the transmitted data words are usually
changing.
Be careful that the chosen combination of Baud rate, Sample rate, Average,
Data format and selected output data permits full telegrams to be sent.
You should calculate 10/Baud rate+1 μsec per byte sent.

Example

This permits for example
1/1000Hz /(10/115200Bd+0.000 001sec) =11,39 ≈ 10 bytes = 2Bytes (synchronisation
sequence) + 4*2 Bytes (Data)
to be transmitted at 1 kHz Data rate in binary mode.
"

For example one transmitted set of data is (decimal notation) "255 255 077 184".

[cikl]

Any suggestions how to remedy the buffer overrun or the loss of data?