Data Socket rate slow

[teritask]

For digital and analog I/O I have been using an AutomationDirect DL205 rack with an EBC module (ethernet) to communicate with Labview via datasockets to connect to the KepDirect OPC server. This technique has worked well in the past but on my 2 recent projects I noticed that I'm only receiving data at approximately 100 ms. I have my data collection in a 10 ms loop but I get 10 of the same data sets, making for a choppy graph.

I know the data is being updated much faster in the OPC server but apparently the datasocket is slowing it down. I contacted NI but never got a clear answer of how fast the datasocket actually updates. Adding the DSC module and associated  items is not an option, very cost prohibitive when adding an executable to a machine.

I've used this hardware combo for awhile, back to LabView 2010 but it seems to have become an issue in version 2013 and now 2014. We like using this method because there are no plug in boards or USB, just an ethernet cable running to the control PC or laptop.

Anybody have experience with datasockets? Is there something I can change to increase the read speed?

I'm using LV 2014 Professional, KepDirect OPC 5.5, private LAN within the machine (not connected to company network).

Thanks.

[natasftw]

You've seen the settings for DataSocket.  Are you hoping for a secret menu?

I'm curious.  You say the problem only exists in 2013 and 2014.  Have you run the program you're complaining about in an older version?  You'd still have the license. 

Here's the problem.  You're asking a question that doesn't have an answer.  That's why you're not getting an answer.  You want us to tell you what your computer is running so that we can determine how Windows will control your loop rate.  You do understand THIS has a greater impact than anything else, right?

In the future, please just say "private LAN."  It's not within your machine.  Explaining that private means it's not connected to a larger network is redundant.  We understand the idea of a private LAN.  It's not a complex concept.

[Michel_Gauvin]

From "I have my data collection in a 10 ms loop but I get 10 of the same data sets, making for a choppy graph." I'm guessing this loops execute the "Datasocket Read" function?  Instead of "hardcoding" the loop to 10ms do the following to find out the rate at which you read the data.  Set "Datasocket Read" input parameters "wait for updated value (T)" to TRUE, and the "ms timeout" to 200.  Graph the "Datasocket Read" timestamp output and determine the reading rate.

You said "I know the data is being updated much faster in the OPC server but apparently the datasocket is slowing it down." Did you perform any tests to validate this statement?

[teritask]

Sorry my wording wasn't exactly as you would have liked. No need to be nasty.

[teritask]

Yes I did do testing to verify that the data is coming in faster in the actual OPC server. I have also written a small LV program (to eliminate anything else in my program that could be slowing it down) to see the actual update rate, similar to what you suggested and I see the actual data update around 105-110 ms.

When time permits, I will try running the program in an earlier version of LV AND I will try one of my older programs in the newer version of LV as was suggested in another reply.

I didn't mean to spark nasty comments from others, I'm not looking for someone to solve my problem, I was just wondering if anyone else has experienced this issue between versions. 

[Dave_Brandt]

OPC Servers performance is very dependent on the PC and  OS it is running on. Is this all the same when you had 10 ms update rates? Are you also getting plc data the same way as before?  Data as an array is much faster than as multiple points? 

[teritask]

I'm using the same laptop as I have for about 4 years so the op system is the same. I do Data Binding, Data Socket Selection, DTSP Server to select the path. As pointed out earlier there are no properties that can be altered and unfortunately arrays are not an available choice in the OPC server.

I appreciate your response and suggestions.

[Dave_Brandt]

Instead of a front  panel data binding try using the Datasocket Open and Read Data. Labview would interact directly with the OPC Server.  In the past I have had problems with front panle bindings. Especially with boolean values not updating. But when I used the Datasocket VI open and read it worked or I know when there is an error.  This will also allow you to figure out it it is labview or the OPC Server that is slow. See Example

[teritask · Accepted solution]

Thanks, I did that before but for the heck of it I tried it again. I used the same concept that you had but left it in a loop to find the minimum time difference while running my other program. The smallest value I saw was 0.0700 sec.

Since I don't really want to send out a machine with an older version of Labview, I'm not going to bother trying it with earlier versions. I just purchased a different analog I/O module with an ethernet connection that has sub VI's instead of using datasocket. I'll see how that works for data collection.

Thanks for your help, I guess I'm done investigating it for now.

[natasftw]

---

@teritask wrote:

1) I'm using the same laptop as I have for about 4 years so the op system is the same.

2) The smallest value I saw was 0.0700 sec.

3) Since I don't really want to send out a machine with an older version of Labview, I'm not going to bother trying it with earlier versions.

4) I just purchased a different analog I/O module with an ethernet connection that has sub VI's instead of using datasocket. I'll see how that works for data collection.

---

I wanted to key on these four things you've said.

Claim 1 simply isn't true.  Even with the same hardware and "same" OS, the computer isn't the same.  You've made changes.  In the past 4 years, think of all the changes you've made.  Let's assume you didn't change any of the hardware and didn't do something like update to a new service pack.  You've still installed new software.  Have you installed patches, updates, or other new software?  You've already mentioned three versions of LabVIEW.  That makes it abundantly clear you've made some changes.  Keep in mind the same hardware generally struggles to run newer versions of software.  Even if you made NO changes other than updating LabVIEW, it wouldn't be surprising that a 4 year old system handled 4 year old software well and struggles to handle current software.

Observation 2 is somewhat concerning.  You're only seeing ~14Hz.  Typically, you cap out around 100-150Hz for a "software timed" loop.  You're not getting anywhere near this.  You mentioned knowing it's updating faster.  One thing you might consider is the network and the traffic passing across it.  This could slow down updates being received.  This alone is difficult to troubleshoot.

Claim 3 missed the point of the question.  You stated it runs well on 2010.  You've since updated twice.  This suggests you've been developing in 2013 or 2014 rather than 2010.  If it's been a while since using 2010, the updates and other software changes may also have the same effect on 2010.  If the problem didn't exist in 2010 before and does now, you've eliminated the LabVIEW iteration.  If you see the problem growing between each new version, it's likely a hardware issue with you pushing the limits of the hardware.  It's unlikely there would be multiple changes to the way DataSocket is handled.  You'd also want to look at a newer computer to see if it handles differently.  You're making a LOT of assumptions that you shouldn't.

Statement 4 may work.  For your sake, I hope it does.  But, you decided on this solution without really knowing the problem.  That's a bad way to problem solve.  Take the time to troubleshoot.  It's generally cheaper.  Although it takes time, it generally saves time overall.