Wasted day at the track thanks to LV 2011, One more bug...

[JoeQ]

Things were working fairly smooth after my recent upgrade from 2009 SP1 to 2011 SP1. Beside the two bugs I already posted about, I didn't find any other major problems so I upgraded my home PC. At home I was still running 6. My home PCs are running XP 32-bit SP3.

I wrote some new software under 2011 and installed it on my laptop. I use the laptop to collect data when I go to the race track using a Labview program I wrote that interfaces with the logger using RS-232. This software has not changed in a few years and is very solid. It is also a built application, no a VI.

The last time I visted the race track, I go to plug the laptop into the logger and the serial interface no longer works. I spent a few hours trying to get things working had to throw in the towel. The $180 in gas and entry fees is nothing compared to the frustration (which is why I still run version 6).

The basic symptom is the serial communication comes to a crawl. The data is sent fast, the logger responds fast, then the system hangs for about a second. It appears to be related to the timeout. The VISA call does throw a timeout error, but adjusting the timeout effects the delay. Setting the timeout to a very small number does not allow for the same bandwidth as just running a virgin copy of LV 6.

Running the program as a VI had no effect. Running the VI under 2011 had no effect. Uninstalling 2011 did not cause the program to start working. Reloading an image of the hard drive prior to installing 2011 caused the program to start working.

I attempted the running the software on a different laptop prior to installing 2011. It worked. Installed 2011, same bug.

Installing VISA 5.2 had no effect.

I ran several tests with two different desktop PCs and they all worked. Note that these PCs both have true serial ports on the bus.

A friend brought in a small evalulation board that had an USB to serial TTL converter. We tried some test with this board and it worked.

I then used my USB to RS-232 adapter with nothing more than a loopback cable. It failed.

I then tried the following USB RS-232 adapters:

Goldx GXUSB-1200, failed

Staples 18762, failed

Targus PA088, failed

Dyne X DXUBDB9, worked!!!

I am not sure why my friends USB adapter or the Dyne X work.

Not that its of any help, I have attached a simple test program that shows the problem.

If anyone else has ran into this and bought a different USB RS-232 adapter, please add it to the list.

test12.vi

Edited September 5, 2012 by JoeQ

[JoeQ]

The problem does not change if running under 7 76-bit, while running 6.1 or 2011, SP2 with VISA 5.2(when tested with the Staples 18762 adapeter).

Testing with 2009 on 7 64-bit works correctly (when tested with the Staples 18762 adapeter).

While I have 2010 available, I have no desire to reinstall it to test it.

Looking at the VID and PID for all five USB serial adapters they are as follows:

MFG MFG PN VID PID REV

DYNE X DXUBDBP 067B 2303 0300 Prolific Technology, Inc., PL2303 Serial Port

TARGUS PA088 0711 0230 0103 Magic Control Technology Corp.

STAPLES 18762 050D 0109 0102 Belkin Components, F5U109/F5U409 PDA Adapter

GOLDX GXUSB-1200 0711 0230 0102 Magic Control Technology Corp.

FT232RL, FUTURE TECHNOLOGY DEVICES INTERNATIONAL LTD

I would assume that Windows would take care of all the low level communications with the drivers so I am not sure what they are doing with Labview 2011 that broke it. All of my other software that talks to these adapters work as they should. It's unique to 2011 and unfortunantly it appears to break all the older installs.

[asbo]

My money's on the VISA version LV2011 forced to install. You won't be able to go back to your old version without uninstalling LV2011 (and maybe not even then).

[JoeQ]

Running these same tests using LV 2012 with 5.2 VISA on Windows 7 64-bit and the Targus PA088 with latest drivers also fails.

I have opened another service request with NI. Maybe they will actually fix this bug. If you need an adapter, we suspect the following one will work:

http://www.newegg.com/Product/Product.aspx?Item=N82E16812156039

[Rob Calhoun]

Alas, poor LabView 6! I knew him, Horatio: an application of infinite fast launch time, of small memory footprint and most excellent stability! But, one cannot use LabView 6 forever.

I think you have a serial port configuration issues. I am no great fan of VISA, since all I ever need to do is read from a few COM ports and it is horribly bloated for that. VISA's serial port implementation had more than its fair share of bugs over the years, but the more recent versions seem to work pretty well.

I suspect you are encountering something where the default configuration changed, or your code was relying on some bug (such as VISA ignoring what you told it to do) that was fixed in later versions. What properties are you setting on the serial port when you initialize it? I would in particular check flow control and make sure that is correct for your hardware (that it works with some serial ports and not others sounds very much like a CTS/RTS issue).

[Neville D]

I recall reading about USB adapters with the FTDI chipset being the most reliable. Try to get one that has that. I recently bought a USB-RS485 adapter from

http://www.rs232-converters.com/USB_to_serial_adapters/USB_to_rs232_rs485_rs422_ttl_converter.htm

It works fine.

[Val Brown]

I've used the KeySpan 19HS but don't have a URL ready to hand about it. And I agree with Neville D that the TFDI chipset adapters seem to have been the most reliable, if memory serves.

I seem to remember that there was a large in how VISA errors were handled in shifting from 6 to 7, and then again in the shift to 8.x.. Somewhere along the way the "Legacy I/O" VIs went bye bye, but they still did function through, I believe the last version before the release of 2009.

I thought I'd given up serial communications back in the early 80s after implementing a Unix look a like for 4 work stations networked to an old 8086. Oh well.....

[JoeQ]

My first post had a test program which shows how the port is configured. Feel free to change the settings as you wish. Enabling hardware handshake (with hardware handshake) has no effect on the problem. The uploaded program I believe uses 0, but feel free to change it to a constant and select one of the options. None seem to have any effect. Again, I am just testing with a loopback connector now. It acts like someone decided the timeout was to not only be used for a timeout, but to also make it the time between transmits. No errors are reported from VISA.

In LV 6 - 9, the serial communications with all of these adapters has been rock solid. I setup a test recently that LV 9 recorded data from a pressure gauge using on of them and ran for several months continious. Not a big deal. What ever the problem is, it came as a result of 2010 or 11.

Rob, I was all with you until "But, one cannot use LabView 6 forever." ha ha... The only reason I attempted to upgrade at home was because I couldn't find our set of LV7 disks to install so I could port some code. I installed 2010 and it was so bad, I just pulled it back off. I never broke the seal on the 2011 disks until recent because I just assumed it would be no better than 10 was. Funny thing (that I'm sure everyone is aware of) is when you tell 2011 to save for a previous version older than 10, you get 10. Select 9, you get 10 code. I have had very good success with 2009 SP1

[lvb]

I have seen the similar issues creep up also. Non-FTDI serial interfaces became unreliable after an upgrade from 2010 to 2011.

I am very interested to see if your support request can get to the root cause.

[ned]

Funny thing (that I'm sure everyone is aware of) is when you tell 2011 to save for a previous version older than 10, you get 10. Select 9, you get 10 code. I have had very good success with 2009 SP1

I've never seen or heard of this. In fact, just this morning I just saved some code from 2011 back to 2009 with no problems.

[Neville D]

Just took a look at your code. Some comments (though they may not relate to the strange behaviour you are experiencing):

1 There is no VISA Close Session. If you run this code a number of times, I am not sure it will behave stably. Add VISA close at the end. This will also allow you to access that serial port with something like HyperTerminal if desired.

2 Usually Serial reads are accomplished by polling "Bytes at Serial Port" in a reasonably slow loop and then reading the required number of bytes with the VISA Read.

See attached.

3 I am not sure why you have a VISA Asynchronous Write.. just right-click on it and make it Synchronous (that was the old default behaviour).

Edited September 7, 2012 by Neville D

[Rolf Kalbermatter]

>2 Usually Serial reads are accomplished by polling "Bytes at Serial Port" in a reasonably slow loop and then reading the required number of >bytes with the VISA Read.

Don't do that unless you write some kind of Hyperterminal clone.

Any real world instrument communication using Bytes at Serial Port is in 99.9% a bad choice. If I had a say I would disable the Bytes at Serial Port property and only make it available if the users enters something like neverReallyCorrectVISAUse=True in LabVIEW.ini.

Proper instrument communication should ALWAYS use some kind of termination operation. This can be a termination character (CRLF for RS-232) a handshake signal (EOI on GPIB) or in case of binary communication often fixed size protocol. Using Bytes at Serial Port either results in regularly cutoff messages or in VERY complex handling around the Read operation to analyse any read buffer and store any superfluous data in a shift register or something for use with the next read.

[JoeQ]

I made up in the order of 15 different test cases, trying various things. Sync/async and polling had no effect.

NI has contacted me and I am in the process of running some tests for them. I'll post any findings.

I've never seen or heard of this. In fact, just this morning I just saved some code from 2011 back to 2009 with no problems.

Well, I thought I would retry this. For some reason with my one desktop, I it will not save as anything lower then 2010 no matter what is selected. This was then repeated on three other PCs and it worked fine. At first I though maybe it was because I had installed 2012 on this PC, but one other PC tested also had 2012 installed and it worked fine. Strange.

[ShaunR]

Any real world instrument communication using Bytes at Serial Port is in 99.9% a bad choice.

<snip>

Proper instrument communication should ALWAYS use some kind of termination operation.

You mean any ASCII instrument communication should use termination. I deal with many serial binary protocols where the message length is a number of bytes in the header.

In theory. I agree with never using the bytes at serial port. However, the serial read can no longer be aborted. Not by making the Visa Ref go invalid and not even with the abort button on the LabVIEW bar!

Unless you want your application to hang for, several seconds when the user exits (or you just want to stop the VI at all when debugging). The only practical way is to use your own read VI using the bytes at serial port in a loop with a very short timeout on the Serial Open (since you can only set a timeout on the open unlike other comms vis that are on the read). Then you can implement your own timeout without the VI hanging whilst VISA fiddles with it's gonads. This "feature" of the serial read has annoyed me enormously over the years.

[Rolf Kalbermatter]

You mean any ASCII instrument communication should use termination. I deal with many serial binary protocols where the message length is a number of bytes in the header.

Fixed block size binary messages also falls under the global group of terminated messages, as I have indicated in my post. You may have to read a data packet in more than one read to retrieve for instance block length indications for variable sized data, but each block in itself is always of a specific size that is known before you start the read.

In theory. I agree with never using the bytes at serial port. However, the serial read can no longer be aborted. Not by making the Visa Ref go invalid and not even with the abort button on the LabVIEW bar!

Unless you want your application to hang for, several seconds when the user exits (or you just want to stop the VI at all when debugging). The only practical way is to use your own read VI using the bytes at serial port in a loop with a very short timeout on the Serial Open (since you can only set a timeout on the open unlike other comms vis that are on the read). Then you can implement your own timeout without the VI hanging whilst VISA fiddles with it's gonads. This "feature" of the serial read has annoyed me enormously over the years.

Normal device communication always is based on the principle that you send a request and then receive some kind of response and each response is usually terminated either by a termination character or by well known block sizes.

This in fact only leaves Bytes at Serial Port for situations where the device spews data without having been queried first (or you simulate a device that of course needs to check for new commands regulary). Even here, Bytes at Serial Port should be normally only used to determine that there is any data and the more protocol specifc termination method should be used to read that data instead of using the value from Bytes at Serial Port to read that many bytes.

And VISA Read can be aborted, just not with a native VISA node. But a little Call Library Node to call viTErminate does actually work fine, I just can't find the post where I put this VI up a few days ago.

[ShaunR]

Fixed block size binary messages also falls under the global group of terminated messages, as I have indicated in my post. You may have to read a data packet in more than one read to retrieve for instance block length indications for variable sized data, but each block in itself is always of a specific size that is known before you start the read.

<snip>

And VISA Read can be aborted, just not with a native VISA node. But a little Call Library Node to call viTErminate does actually work fine, I just can't find the post where I put this VI up a few days ago.

I never said anything about fixed sized blocks.

I think we will just have to agree to disagree.

Edited September 8, 2012 by ShaunR

[Rolf Kalbermatter]

I never said anything about fixed sized blocks.

I think we will just have to agree to disagree.

Well for simplicity I consider variable sized messages with prepended size information similar enough to fixed size messages, as in both cases the size is known before you start the read operation.

And the link to the VISA Abort VI can be found here!

[JoeQ]

I was unable to replicate the problem with saving for a previous version after testing on five other installs. The PC that had the problem is the one I used to help NI debug their PCI problems in VISA 5.1.1/2 Labview had several "patch" files installed. Even though I had used the windows uninstaller I wondered if something was not cleared out. I fully uninstalled ALL the Labview code (had to go into safe mode for some of it) then installed only LV 2011, SP1 clean using VISA 5.2. The save for previous now works for this PC.

I have sent NI several reports and traces from various PCs which shows the problems with the serial port. I noticed while running the MAX techincal report, two of the 4 PCs I tested would crash. On one PC, I had the option to ignore the error and it would eventually create the report. The other PC did not have this option and MAX would just exit. This PC was the one that would not save for a previous version. After doing the complete uninstall and reinstall, the first time I ran the report generator without the drivers installed it worked. After installing the Aug release of drivers (VISA 5.2) using the default settings, MAX again crashes as before. The following is from the Windows log file:

Faulting application name: NIMax.exe, version: 5.3.0.49152, time stamp: 0x4fbc1658

Faulting module name: MSVCR90.dll, version: 9.0.30729.6161, time stamp: 0x4dace5b9

Exception code: 0xc0000417

Fault offset: 0x0003523b

Faulting process id: 0xa00

Faulting application start time: 0x01cd9028c95bd9ae

Faulting application path: D:\Program Files (x86)\National Instruments\MAX\NIMax.exe

Faulting module path: C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50934f2ebcb7eb57\MSVCR90.dll

Report Id: 348e6ea6-fc1c-11e1-b449-005056c00008

Of course, Labview 6.1i ran flawless during all of this! The above information was also provided to NI.

[JoeQ]

It's been about a month now and I am sorry to say we have made no progress. I am now on my third support person. With each new person, I am asked the same questions over and over. I have been told that NI only supports the NI USB adapter. I understand they have tested one in-house and it worked correctly so this may be an option. I have been unable to get NI to purchase any of the listed adapters to replicate the problem in-house.

I have been using an RS422/USB adapter with Labview over the last week that uses a FTDI chipset. Even running with BAUD rates of 921.6K, it has worked flawless. They offer RS-232 and RS-485 adapters as well using this chipset.

Not mentioned above, another way to mark the end of data is using a break, or lack of data. Say for example, there is no data for 1.5 bit times, that would mark the end of a packet. This is/was a fairly common technique.

With the PC not having a real time OS, timing something like this can be difficult without using additional hardware. As the PC talks to various peripherals, it can cause false timeouts. In my example, you notice that the timeout is set to 600ms. It is set this long for this reason.

[asbo]

You could ask about loaning an adapter to see how it works for your setup. Conversely, you could send your adapters in for them to test with.

[Rolf Kalbermatter]

It's been about a month now and I am sorry to say we have made no progress. I am now on my third support person. With each new person, I am asked the same questions over and over. I have been told that NI only supports the NI USB adapter. I understand they have tested one in-house and it worked correctly so this may be an option. I have been unable to get NI to purchase any of the listed adapters to replicate the problem in-house.

I have been using an RS422/USB adapter with Labview over the last week that uses a FTDI chipset. Even running with BAUD rates of 921.6K, it has worked flawless. They offer RS-232 and RS-485 adapters as well using this chipset.

Not mentioned above, another way to mark the end of data is using a break, or lack of data. Say for example, there is no data for 1.5 bit times, that would mark the end of a packet. This is/was a fairly common technique.

With the PC not having a real time OS, timing something like this can be difficult without using additional hardware. As the PC talks to various peripherals, it can cause false timeouts. In my example, you notice that the timeout is set to 600ms. It is set this long for this reason.

In addition to what asbo said, testing with no name adapters is anything but conclusive. Some things can work, with a particular hardware device and depending what driver version you get installed and it then can not work after some seemingly unconnected changes like Windows updates. So even if NI can conclude one thing it may only be valid for that exact HW/SW combination on that computer and behave rather differently on other setups.

Sometimes NI HW may seem expensive in comparison to no-name, or semi no-name asian low cost devices, but there is a difference in what you get. One is a hardware device where the people at NI actually sat down and wrote a specific driver for it by people who have some serious device driver development experience, the other is usually a minimalized copy of the reference design from the chip manufacturer with often a completely unaltered device driver from the same chip manufacturer. However reference designs are usually not meant to be end user sell-able items but developer platforms to "develop" a product with. The provided device drivers with those reference designs are at best a starting framework but seldom a fully featured device driver.

FTDI drivers are an exception in that respect, as they already are pretty feature complete, although support for things like line breaks, no-data detection are still not something that I would rely upon from the reference design driver. It's the reason why FTDI based adapters are usually fairly functional for standard serial port applications, no matter what no-name producer sells them. Most no-name manufacturers wouldn't know what button to push to compile their own device driver!

[JoeQ]

I had suggested they make a drive to Staples. They of course are always welcome to send one here as well, but with them not being able to replicate the problem in-house there would seem to be little value in doing so.

Again, all of the listed adapters work flawless with the older versions of Labview. This is something they have changed after 2009.

I have tested the adapters on five different PC/OS combinations. It appears related to the new Labview as all of my other programs continue to work correctly.

I would like to know more about how they couple into Windows. I can't imagine they are do any direct calls to the hardware. I have a hard time understanding why they would even be making changes to their serial interface. I am not aware of any major breakthrus in serial port technology in recent years.

[ShaunR]

One is a hardware device where the people at NI actually sat down and wrote a specific driver for it by people who have some serious device driver development experience, the other is usually a minimalized copy of the reference design from the chip manufacturer with often a completely unaltered device driver from the same chip manufacturer.

Don't forget the support! Support for NI devices is second-to-none. It is this you are truly paying for.

Edited October 1, 2012 by ShaunR

[JoeQ]

I must have higher expectations.

My favorite support call was back when Labview 5 came out. There was a new bug with their Ethernet GPIB controller. After many emails, they decided to setup a test inhouse to replicate the problem. It was the normal case where they could not reproduce it. We ended up talking on the phone and I asked about how the system was configured. As we talked I discovered they had a GPIB controller in the PC. They had connected the GPIB cable to that card, then to the Ethernet GPIB controller. They thought the GPIB Ethernet controller took GPIB and turned it into an Ethernet port. I gave up at that point and had them close the case. The bug remained there for several years but I am happy to say it has been fixed.

We used one of their boards for a project once. Early on, we started having trouble with the board. I ran many tests on it and discovered the board did not meet their own specification. I sent them a detailed report outlining the tests I performed along with the results. After many attempts over several months to talk with someone inside NI, we gave up and designed a new front end for their board. Keep in mind this was not a single board purchase. Later I received an email from them.

"I am the Product Support Engineer ...." "Thank you for the information that you provided." "In addition, I would like to thank you for pointing out that our CMRR specification is incorrect for this board at the +/-10V range. I have re-tested the board's CMRR specifications, and my numbers are in agreement with yours." "Finally, while I understand your desire to speak with a person knowledgable about the design of the board, at National Instruments we prefer that our design engineers work on designing new products with the least amount of interruption possible."

In the end, the correction was to change the specification for the board.

[asbo]

In the end, the correction was to change the specification for the board.

Did you expect them to retroactively fix the board? Re-design it?