Problem with Serial Comms using VISA

[DPS]

Am currently having trouble with a VI designed to read in data from the serial port. We have PIC chip outputting data every 1ms to the serial port, but the VI should only read the data when necessary - essentially it should read the 'current' data output by the PIC. The problem we are having is that there seems to be a buffer in the way so the data is buffered between the PIC output and the VI input and this is introducing an unknown delay into the equation. I have tried setting the buffer size using the provided VI but this doesn't seem to make a difference. To complicate matters further, the problem only seems to manifest using Labview 7 running under Win XP. Version 6.1 under Win 2K seems to work fine, so it's all a bit of myster
y.

Any help or advice much appreciated.

Thanks

[Dan_Mondrik]

Sounds more like a timing problem. Setting the buffer size isn't an absolute thing, as it's more like a minimum size. VISA and the OS are allowed to use a larger buffer size. For example, if you ask for 4000 bytes, it is very reasonable for the actual buffer to end up being 4096, which is 1 page.

There have been a lot of other discussions both on this zone and on info-labview regarding serial instruments that send unprompted data. Basically you need to clear out the receive buffer (viFlush from C or VISA Flush from LabVIEW) and then you'll start reading the next set of data that the instrument sends. The only hard part about this is that you might discard during the middle of a buffer, and end up with a partial buffer anyway. You'll need some way to
figure that out yourself, unfortunately, based on the protocol or the allowable sequence of bytes that your instrument defines.

Dan Mondrik
National Instruments

[Chris_Rake]

Starting with 7 serial communication goes through NI-VISA. Thus if you were using the "native" vi's in 6.1, you're now using VISA. There are multiple buffers between the physical COM port and your application: hardware FIFO, driver buffer, and VISA's buffer. Have you tried the Flush I/O buffer command? This should wipe out VISA's buffer which will contain the bulk of the data.

[DPS]

Tried this and it seemed to improve matters (although still being tested) thanks for the advice 🙂

[dsbuxi]

Hello! Ive had the same problem, and when I use the Flush I/O command, i do not seem to get any data back.

Is this because Ive placed the Flush I/O buffer at a wrong place? Ive tried placing it before the write VISA or after Read Visa palette.

Message Edited by dsbuxi on 06-06-2005 08:18 AM

[LuI]

---

@dsbuxi wrote:
Hello! Ive had the same problem, and when I use the Flush I/O command, i do not seem to get any data back.

Is this because Ive placed the Flush I/O buffer at a wrong place? Ive tried placing it before the write VISA or after Read Visa palette.

dsbuxi,

'Flush I/O buffer.vi' does clear everything that's already in the buffer. Old data, probably overwritten several times, bulk. Use this vi after having configured your port and before trying to read any reasonable data. In plain semicode:
* configure port
* clear shift register
* Flush buffer
* While not finished do
+ N = Bytes at serial port
+ if N > 0 VISA read N bytes, append to shift register
+ detect any complete messages in the shift register,
+ remove such complete messages (and delete their predecessing bytes)
+ send complete messages to an 'independend processing loop' (by a named queue or whatever you like)
+ Check finish condition, wait some ms if unfinished
While end
* stop the 'independend processing loop'
* release the serial port

* In the 'independend processing loop', read and process your complete messages

This is just a raw idea, but it should work.
The important points are:
1. Flush just once at startup
2. Have one process or loop receiving data and sorting out complete messages
3. Have na eindependent process or loop processing your messages
4. Have an apropriate wait in both processes or loops to give the other some CPU cycles.

HTH and Greetings from Germany!
--
Uwe

[dsbuxi]

Hi Lul!

Many thanks for your reply!

Ive tried using the flush I/O at the beginning of the program, but to no avail.

This is because, the cause probably lies somewhere else, either

1. the appliance that Im trying to connect to the VISA palette
2. the windows buffer.

I used a hyperterminal program to check communication, where i saw the same delay i.e. each time a handshaking is done between the PC and the appliance, the appliance replies, but with a value from 5-6 seconds ago.

Maybe you have dealt with this problem before? 😃

Thanks!

Dilpreet from Aachen

[Tarun]

Hi DPS,

I seem to be experiencing the same problem.

Thing is, this problem seems to port to a RT platform too. As long as its a WinXP host with LabVIEW 7.0 or 7.1.

Any help would be appreciated thanks.

[Tarun]

My post:
http://forums.ni.com/ni/board/message?board.id=140&message.id=9416

It seems to be a delay in transition between Read an Write operation on WinXP.

[JLS]

Hello,

A delay on the order of seconds is strange, unless it is inherent in the device responding with data. Another factor that affects how quickly you receive data from a serial port is the UART Receive FIFO size. An interrupt is generated whenever the buffer fills past a setting (which you can access from device manager in Windows XP) so that it can be transferred to RAM and clear the FIFO on the UART to receive other data (this is all to avoid over-writing the data in the FIFOs of course). The idea is that for small transfers, such as 5 bytes, setting the FIFO size to be, say, 8 would cause a delay because the interrupt would not be triggered by the reception of data, rather the regular polling mechanism which services the serial port interrupts (this happens periodically about every 5ms or so I believe). In any event, if you set the FIFO size to something small, even 1, then the interrupt will cause that data to be transferred as quickly as possible to RAM and made available in your application. Of course, if you are receiving lots of data, setting the FIFO size to 1 will cause many interrupts, which can slow down overall processing time since the processor is handling serial interrupts relatively frequently.

Here is a document describing this more:

http://ae.natinst.com/operations/ae/public.nsf/web/searchinternal/2d5f972cd550bbc386256f0b005e9a63?OpenDocument

Here is a document which shows how to modify the FIFO sizes: (linked in the one above as well)

http://ae.natinst.com/operations/ae/public.nsf/web/searchinternal/2d5f972cd550bbc386256f0b005e9a63?OpenDocument

Repost if you are still having trouble or have any more information!

Thank you,

JLS