Issues with basic serial ports under VISA

[IanR99]

Trouble with bytes_at_port and serial interfaces

One of the first projects I had to develop in LV (8.6) involved reading multiple serial ports. As a new programmer I wanted to write a re-entrant port handler but was worried about 2 things: would the Visa READ.VI be re-entrant (or would using it in one place hold up all other reads till the timeout kicked in if no data there) and how to deal with stopping a running VI when it was waiting for a read with a long (10 secs) timeout. The answer to both problems seemed to be the Bytes_at_port (BAP) property - with this I could avoid any delays for 'reads/timeouts' and organise my own 'timeout'.

The mechanism seemed simple - in a loop (terminated from oppo control) see if there is any input; if bytes there then read the specific no of bytes; merge with bytes already read; check for end of line; pass on any complete lines (LV QUEUE mechanism) use any remaining chars to start next input. Obviously the loop would need 'sensible' delays (100ms) between BAP calls and a timeout check.

For many years this mechanism seemed to serve me well and as well as the main project I have developed several utilites based on this mechanism.

However recently the wheels seem to have come off the wagon. When testing a serial transmission system using one utility (sort of my version of HyperTerminal) I noticed data was missing - initially I blamed the TX system but in the end did two things: I used HyperTerminal and I plugged the serial data source straight into my utility. Using Hyperterminal the data was perfect (well once I applied the Hotfix from KB 274261 - but that is another story), while even with data going 'straight in' my utility 'missed' data.

The source of the serial data is a GPS receiver outputting a timestamp every second at 38400,None,8,1 No flow control ( below the '58' is status - ignore):

UTC 12.04.11 08:34:35 58<CR><LF>

UTC 12.04.11 08:34:36 58<CR><LF>

and so on.

I then developed the origins of the test VI attached here - which was a basic test of the above mechanism (and does a bit of data testing as well) which showed the same error so I added the switch to select between the BAP mechanism and a straight READ waiting for LF (RWLF) (see code). This works so why does the BAP mechanism not work I have found docs 3BE87GW3 and 3O7F94LZ and taken their info on board I shortened the FIFO on my COM port – but it did not resolve the BAP issue. I also added the Set I/O buffer to stop the read flush mentioned in 3O7F94LZ (why on earth flush after a read?), which seemed to have no obvious effect either way on either read.

Here is an example of the type of mis-read when using the BAP mechanism. Note it is the leading characters that are missing.

UTC 12.04.11 08:45:30 58    1.0   1016

UTC 12.04.11 08:45:31 58    1.0   1000

45:32 58    0.0      0

UTC 12.04.11 08:45:33 58    2.0   1938

Generally the BAP will show corrupt data after 20 or 30 seconds while the RWLF was still going strong at 5,000 reads.

All the above was using the built in port on the mother board – when I switch to using a port on an 8 port expander card (a Startech unit sorry NI) both BAP and RWLF ran reliably for counts into the thousands. I can only presume that such a card hard better buffering than the basic port and so helps the data flow.

Further I tried running the VI in the Instrument I/O execution system but that had no effect.

So my questions are:

• The BAP mechanism seems unreliable on built in ports (similar problems on my Tosh Laptop) am I using it correctly? Remember HyperTerminal OK.
• Is there any parameter in VISA which I can change to help

As HyperTerminal can handle the basic port surely VISA should cope better than it does, reading 26 chars every second hardly seems demanding – however I chose to handle it.

I attach my test VI and a VI that parses the input - do not worry about the double underline that is my peculiarity. Oh and I forgot to remove a cople of blocks that generate test patterns but do nothing with them - ignore.

Many thanks to anyone dedicated enough to have read to the end of this missive and kind enough to consider and reply, Ian

[TrottM]

Hey Ian 

I have read you post and if im honest alot of this is beyond my experience of VISA.

As the onboard is not working via this machanism and the expansion card is this suggests to me that the buffering is possibly this issue.

I am not aware of how hyperterminal deals with serial reads but it may well be that this has some sort of software buffering that is enabling this for it too work.

Have you thought about building some sort of FIFO buffer into your mechanism to get around this?

[Albert.Geven]

just asking: don't you get overrun errors?

[JasonSmith]

Albert is right, you should be receiving errors from VISA if you are actually losing data due to an overrun.

I don't think this is the case, because the data is read from the hardware the same way in either of your cases. Serial drivers on Windows don't actually care if anyone wants the data, they read it in the background and will fill a driver buffer if nobody is asking for data yet. If it can read the data fast enough in the normal case, then it should be able to work with the Bytes at Port case as well.

I would recommend that you review your code for any cases where you might accidentally discard a chunk of data without appending it to your input. If you don't find anything it would be useful to run NI I/O Trace (Previously NI-Spy) while you reproduce the failure. You should be able to tell from this capture whether the data was ever passed to LabVIEW from VISA, or if the data was actually lost at the driver or VISA layer.

-Jason Smith

[IanR99]

Thanks to those who have replied -

I do not get over run errors.

I am fairly sure my code does not drop data - copy available in original post.

Confession 1 - I did try the VISA on interrupt mechanism (Interrupt when char at port) and sometimes got the over run error from there but have abandoned that feature and do not use it at all, in my opinion it is the work of the devil - see 34BE13V4 'Timeout on VISA wait on event even though the event has occured' - separate thread really.

Confession 2 - Really close examination of the HyperTerminal log files reveals that in at least one instance even HyperTerminal loses data occasionally (1 char in the thousands say every half hour) - the instance in question being when I run it on my Toshiba laptop (the built in port), Note in this instance my LV code loses chars every ~30s). However HyperTerminal does not lose data with the same inputs on my rack mount PC (likewise the built in port) where my code does (again approx corruptions every 30s).

Just to be sure I have also tried another GPS reciever (Trimble) with no noticable difference to corruption - so I cannot believe the data source is the issue.

Thanks to those showing an interest - Ian