Visa communication error

[Dragonrider]

Greetings everyone. The first thing I want to say is thanks to everyone who attempted to help me and who gave me some great advice and things to try. The issue has now been resolved but not in a way that I expected.

I asked the lead firmware engineer who worked on the software for this board to sit down with me so that I can demonstrate what was happening to see if he had any ideas. We connected a serial sniffer in line with the communication cable and ran the source code with some probes to see exactly what was happening.

The sequence of events for a normal test, executed through an action engine, is as follows :

Initialize communications. 

Execute DOS commands to initialize the operating system.

Verify communications (this was the point of failure).

It then would execute the remaining actions of which there were several.

What we found was that after the DOS commands were executed to initialize the operating system on the board the serial port buffer had some garbage in it. The software engineer believed it was an artifact of the operating system initializing. I explained that we have not had any issue in over 2 years and that I had been running this test for the past 5 months with no issues. He could not explain why it was happening now.

My first attempt to correct this was to add code to clear the buffer right after the DOS commands were executed. For some reason this did not work and I had the same failure. We then decided to change the sequence of the action engine to the following:

Execute the DOS commands first .

Initialize communications .

Verify communications .

Continue with the remaining tasks.

Low and behold this all worked! I have now verified it on all three computers I was having trouble on and it works on every one including the development system. I created new executables and placed them on the two laptops that I have been working on and ran flawlessly. We still don't quite understand what could possibly have changed but regardless it has no effect on the test and everything is now working. As time allows I am hoping to try to figure out why this was happening but at least now I can complete the laptop set up that has to be shipped to a contract manufacturer and get them online.

Thanks again for everyone's assistance. This has really been a nightmare and it has occupied my thoughts day and night for a month. Thanks again everyone!

[crossrulz]

---

@Dragonrider wrote:

What we found was that after the DOS commands were executed to initialize the operating system on the board the serial port buffer had some garbage in it. The software engineer believed it was an artifact of the operating system initializing. I explained that we have not had any issue in over 2 years and that I had been running this test for the past 5 months with no issues. He could not explain why it was happening now.

---

I have seen some weird stuff happen while watching a serial port during a device's initialization (power cycle, OS boot, initializing the port especially if the baud rate is changed from the hardware default, etc.).  Typically, just detecting the error and ignoring it is enough.  Sometimes a port reset on your side is required to clear the errors in the hardware.

I generally avoid the Clear Buffers as it has never fixed any issues I've had and often causes more issues.

[Kavanakt7]

---

What did you discover in terms of serial port settings? The issues you described and the procedure you listed sounds like your serial port settings default back to how they are configured in device manager or NI MAX. Since you have resolved the issue for now, I just wanted to share something I did not see previously in the thread. Using NI MAX or the device manager, you can configure the serial port settings as desired. This allows you to not need to configure the port in LabVIEW whenever you want to use the port. In your application, it sounds as if the port is configured once properly but likely during the DOS command stage, your connection is reset and those settings fall back to your settings found in MAX or device manager. Then every call after that fails due to the unexpected reconfiguration. An interesting point is that VISA will reopen a connection if it is closed(not necessarily how you configured it though). So I am not too sure what caused the change of port settings in the first place. There are many very likely scenarios that prompted this issue considering the device settings are not default settings. Windows updates, COM port enumerations, MAX updates or failures, hardware changes etc... So just wanted to share that it is possible the ports settings were configured outside of LabVIEW (which would persist under normal conditions) and this behavior was occurring all along, you just happened to have the correct settings configured in MAX/device manager to where you never saw it. Hopefully this helps in the future.