LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DataSocket Data Error

I have a large LabView application (Win 2000) with which I need to communicate from another machine (Win XP Pro) using the DataSocket Server (dstp).
I do not have LabView on the Win XP machine, so I compiled a small LabView application to run on it.  I have installed the Labview Runtime Engine 7.1 on the Win XP box corresponding to my version of LabView on the Win 2000 box.  The data being transferred is cluster data (booleans, doubles, and ints) that has been flattened into a string. 

The problem is that some of the data is being corrupted some of the time.  For example, one of the numeric fields has the value of 1000, but it is being displayed on the Win XP box as 831.  If I change the data to say, 1100, it is displayed correctly.  The corruption is predictible, and depends on the data values. I am not getting any errors on the connection.

If I run this same application on the Win 2000 box, it runs fine.  Is there some compatibility issue between Win2000 and Win XP for compiled applications?  What else might I be doing wrong?
0 Kudos
Message 1 of 12
(4,044 Views)

This is indeed an odd one.  Since DSTP tunnels through TCP/IP, it should have all the error correction afforded by the protocol.  However, just to narrow things down, try this.  Can you install two instances of your runtime application PLUS your datasocket server on your XP machine.  (Rename one of your applications, you will then be able to open up two instances)  If your applications can "talk" to each other properly on the same machine, you probably have some TCP/IP issues between your boxes.  If you still see weird errors, you will have to dig further.

Eric

 

0 Kudos
Message 2 of 12
(4,038 Views)
Eric,

The runtime applications are designed to display data from the main application running on the Win2000 box.  I can't run the main application on the Win XP box, because there is hardware involved.  What I did do, however, is run the DataSocket Server on the Win XP box, and I ran my runtime applications on both the Win XP box and the Win 2000 box.  The Win 2000 box again displayed the data correctly, while the Win XP box displayed as described above.  I would think this would rule out a TCP/IP error.

This is getting more and more bizarre as I look at it.  And unfortunately, this is my first exposure to LabView, so I am muddling my way through as best I can.  For what its worth, both machines do have multiple versions of the Runtime Engine (7.0 and 7.1).  The Win 2000 even has version 5.1, although for the life of me, I don't know why.  Is it possible I'm dealing with version compatibility issues here?  And I'm still wondering if an application built on the Win2000 machine is 100% compatible with the Win XP machine.

Any thoughts you may have would be greatly appreciated.
Bill
0 Kudos
Message 3 of 12
(4,023 Views)
Hey Bill,
    You said the corruption is predictable, could you expand on that a little more?  It depends on the data values, but is it just certain values that change, or does it have to do with when you change them?  Any other information about the predictability?
Brian B
Account Manager
National Instruments
0 Kudos
Message 4 of 12
(4,007 Views)
Brian

Sorry I was slow to get back.  Out of town. Anyway, to answer your question...

One of the fields is a simple i32 value coming from my main application running under LabView (Win 2000) to my remote executable (Win XP).  The expected value is 1000, but it is being displayed as 831.  If I run the same remote application on the Win 2000 box, it is displayed correctly.  Most values actually produce the correct results, but many don't.  For example:

0 - 137 ->  displayed correctly
138, 140, 142 -> displayed as 63
254, 156, 158, 159, 164 -> displayed as 63
170 -> displayed as 215
186 -> displayed as 247
192-255 -> displayed as 63

As you can see, there does not seem to be any "pattern to the erroneous data.  I also have floating point values that don't seem to get updated at all and then all of a sudden they get updated consistently.  That, too, seems to be based on their values.

I am monitoring the error conditions out of my VI's, and all appears good.  What is particularly odd is that it runs correctly on the Win 2000 box.

Any other thoughts?
0 Kudos
Message 5 of 12
(3,992 Views)
Any additional thoughts on this?  Its beginning to get critical!
0 Kudos
Message 6 of 12
(3,965 Views)
Hey schlew,
    Can you reproduce this behavior with a fresh VI?  Also, have you tried other communication methods, such as shared variables?  If you can reproduce this behavior with a simple VI, please let me know and I can setup a test here in house.


Brian B
Account Manager
National Instruments
0 Kudos
Message 7 of 12
(3,953 Views)
Brian,

The attached send and receive VI's show the problem.  Again, when I run both on the same machine, everything is fine.  When I run them on different machines, then I get data corruption.  The most common error is setting Number of Samples on the TestSend.vi to 1000 results in 831 being displayed on the other end.  As stated earlier, I am compiling these into executables, and 1 machine is XP while the other is Win2000.  LabView is 7.1 with the same runtime engine.  I have noticed that both machines have other versions of the runtime engine installed as well.  I assume the executable knows which version of the runtime engine to launch?

Message Edited by schlew on 01-20-2007 10:12 AM

Download All
0 Kudos
Message 8 of 12
(3,905 Views)

Dear Schlew:

  Please do confirm the run time engines in both the OSes be that for 7.1 and try uninstalling the run time engines for the other versions.

http://digital.ni.com/softlib.nsf/websearch/71B1D78C8DFBA33786256E7D00724692?opendocument&node=132070_US

I was unable to run the test today due to a missing subVI from what you send, but will continue to try running them on different OSes tomorrow. Are you able to reproduce the issue with two systems running XP?

Does this happen only across multiple OSes. What version of the Data socket you are running in the different systems. Also I would reduce the VIs even further to just the one in the example program and then post the findings. Doing a simple read and simple write with no local variables and the additional. Also do you have a copy of the newer versions of LabVIEW that you might be able to try?

Thanks and please let us know
Regards
Avi

0 Kudos
Message 9 of 12
(3,883 Views)

Dear Schlew:

     I debugged your VI , and it appeared that you are using the older datasocket VI. What I would recommend is replace them with the VIs in 7.1 and also for now remove the option of having to run the VI through the operate - change to run mode option.  Attached please find a simple VI that I would like for you to create executables of and try running and then move ahead adding code from there.
Thanks and hope this helps
Regards
Avi



0 Kudos
Message 10 of 12
(3,863 Views)