.NET Assembly use in LabVIEW

[EWTech]

Gentlemen,

I've been using ADO.NET assemblies created using C# in Visual Studio 2005 for the last three years for SQL Server 2005 database access. The assemblies read and write using generic SQL queries in DLL functions to pass data back and forth between LabVIEW programs and the database across the network. I've had issues with the network, LabVIEW performance and even the Real Time Clocks built into the PC's themselves. I'd love to have this issue resolved by NI but for a number or reasons that isn't going to happen.

The issues arose when I attempted to transition my applications to LabVIEW 2009 and the question now becomes: Do newer versions of LabVIEW play nicer with more recent versions of Visual Studio than VS 2005? Where I work the current "standard" WIndows development platform is VS 2005. I have access to VS 2008 and I might have the ability to convince my boss that we have need for VS 2010 if I was convinced that there was a serious need to upgrade for our networked data systems.

I don't really think that NI broke mixed development intentionally. Flexibility of a development platform is a selling point rather than a detriment to sales. For large outfits like mine the cost of a few seats of Visual Studio Enterprise is cheap in comparison to some of the other software we use in the labs like Matlab and control software used for the elecrodynamic shaker units in the dynamics lab. I just wonder if the effects I am seeing is a side effect of the systems interaction with either the version of the CLR being used, an interaction with older libraries in .NET or the way ADO.NET accesses data over the network as a client. Has anyone else seen any of these issues on newer versions of LabVIEW?

I'm experimenting with a test system using LabVIEW 2010. I'm trying to transition to something newer as we will eventually end up using Windows 7. We are a Windows XP shop now but attrition will eventually take care of that...

Bob Taylor

[charris]

---

@EWTech wrote:

The issues arose when I attempted to transition my applications to LabVIEW 2009 and the question now becomes: Do newer versions of LabVIEW play nicer with more recent versions of Visual Studio than VS 2005? Where I work the current "standard" WIndows development platform is VS 2005. I have access to VS 2008 and I might have the ability to convince my boss that we have need for VS 2010 if I was convinced that there was a serious need to upgrade for our networked data systems.

---

Bob:

There are a lot of factors involved with the system you're describing, so it's a bit difficult to determine if LV 2009 or 2010 will play nicely with later VS versions in your setup. Would you be willing to elaborate on what particular symptoms you've been having with interfacing LabVIEW 2009 with VS 2005?

[EWTech]

Caleb,

A second machine running Windows XP was built up the day before last. I've built a smll VI that reads the network variables and displys them. The issue does not seem specific to either LabVIEW alone or LabVIEW watching network variables. The issue seems to have something to do with the database access methong being used. I've been using ADO.NET for the last few years in part because I've known it for a while, it's well understood and it plays well with older  versions of LabVIEW (up to 8.6.1). It's definately having issues with 2009 and 2009 SP1.

2010 has yet to show the same problems as the other versions but then I have not tried to use an ADO.NET DLL module imbedded into the VI yet. I'm at a point where I'm ready to try a different compiler if there is a chance they willl play nice together. I don't know LINQ to SQL Server but I learned ADO.NET in about two month of study and experimentation. It wasn't very hard.

Symptoms are that on about the same interval as the system updates from both the database and from network variables the system clock appears to be overwitten and seems to display some other time than accurate system time.

The DLL code is attached.

[EWTech]

A simple test of network variables from the application server to code running LabVIEW 2010 seems to run just fine. The variable values are displayed as expected just the same as the other (official) display applications used in earlier version of LabVIEW. I'm going to experiment as follows:

1. Add SQL Server database read functions as DLL imports into a different executable.

2. The same as above to include write-to-database functions.

3. Both of the above.

Bob

[charris]

Bob:

I look forward to the results of those tests.

Just to clarify the symptoms, does it appear that the time stamps are affected for both the network variables and database entries? (i.e. do they display incorrect times when read) Or does the system clock appear to get mis-set under certain circumstances?

Sorry if that was totally clueless, I'm still not 100% sure I have a handle on your description of the symptoms.

[EWTech]

"Just to clarify the symptoms, does it appear that the time stamps are affected for both the network variables and database entries (i.e. do they display incorrect times when read)? Or does the system clock appear to get mis-set under certain circumstances?"

Caleb,

The RTC of the system - usually part of the mainboard - is corrupted and all time values are effected. The clock in the lower right corner of the display becomes a random time value on ten second intervals which seems to correlate to the update rate of the VI while loop. That is why I suspected network variables first as that was the interval for each display panel from the network. It now appears not to be the case, at least not alone since I have a simple VI that is doing a read and display cycle using LabVIEW 2010 and it is not showing the symptom at all yet. The next step is to have the VI read and then write to the database as well - separately and then in combination.

Was I any clearer this time? It isn't the run of the mill "Bob's doing something stupid" type of problem that I usually see.

Bob

[charris]

Bob:

I think I have a better idea now, thanks for the clarification. The system clock is being overwritten by a component of the application(s) and it's affecting our timestamps (to offer a gross oversimplification).

---

It isn't the run of the mill "Bob's doing something stupid" type of problem that I usually see.

---

I hope it didn't sound like I was implying anything

I'm often a master of overlooking things, so my questions can get a bit basic at times. I just like to cover all of my bases.

It sounds like you're on the right track for troubleshooting. Find out what component causes the behavior by adding one factor at a time, and we'll eventually find our culprit.

[EWTech]

The test machine is now running a test VI using shared variable reads of the Vital Signs data used by the application without doing anything else and I've added a second application created using Measurement Studio that normally resides on the data machines. This application is an alarm notifier that resides on the system tray as a green Icon. If there is an alarm condition the program pops a text window up that explains the issue and then changes the Icon on the system tray to from green to red.

The action code is included below. It's ugly but it gets the job done...

[EWTech]

When I installed the source code for the applications the LabVIEW is intended for as a port/recompilation from LabVIEW 8.6.1 I noticed that there was an option to install Visual Studio 2008 MSMs in cases where LabVIEW run-time for 2010 had not yet been installed. What is the dependency here? Is there any conflict between LINQ and the ADO.NET components that I have been using? 

I had thought that VS2008 had the option to create both DOT.NET 2.0 as well as 3.0 and 3.5 which is decided when the project is first created. What I do not know is do I have to transition to Visual Studio 2008 or after to avoid issues like I have seen? Which compiler plays nicer with LabVIEW if I am given a choice? I have access to either if I can make a reasonable business case to my boss. I have not installed Visual Studio or Measurment Studio onto the test system. That may have to be the next steps to see if I can get the system to fail as it did before.

Bob

[charris]

---

@EWTech wrote:

I noticed that there was an option to install Visual Studio 2008 MSMs in cases where LabVIEW run-time for 2010 had not yet been installed. What is the dependency here? Is there any conflict between LINQ and the ADO.NET components that I have been using?

---

Bob:

If you'll bear with me, I'm not as familiar as I'd like to be with the VS and .NET environments, but I believe the merge modules provide functionality for your non-LabVIEW applications (possibly Measurement Studio) that the Run-Time engine otherwise might provide.

I'm really not sure about the differences between using LINQ and ADO.NET.

---

@EWTech wrote:

I had thought that VS2008 had the option to create both DOT.NET 2.0 as well as 3.0 and 3.5 which is decided when the project is first created. What I do not know is do I have to transition to Visual Studio 2008 or after to avoid issues like I have seen? Which compiler plays nicer with LabVIEW if I am given a choice? I have access to either if I can make a reasonable business case to my boss. I have not installed Visual Studio or Measurment Studio onto the test system. That may have to be the next steps to see if I can get the system to fail as it did before.

Bob

---

As far as your overall question, I can't say that one compiler will play nicer than another in every situation. Every system is different, but it is possible that you may get better behavior with VS2008.

My honest recommendation is to keep adding one component at a time back to the system and see if/where it breaks. Once we find the component, we can narrow down the cause and ascertain if it's due to a difference in how LabVIEW is interacting with your ADO, or if there is something else at play.