FieldPoint Family

Showing results for 
Search instead for 
Did you mean: 

Why is ConnectTo DataSocket faster with Server Explorer running in background

Im using:
Measurement Studio 7.1
FieldPoint 5.0.1
Max 4.2.1
I have a simple button array to change output states:
Private Sub Slot3Bttn_ValueChanged(Index As Integer, ByVal Value As Boolean)
  dim ch as string
  ch = cstr(index)

  frmIOTester.CWDataSocket2.ConnectTo  "opc://localhost/National  Instruments.OPCFieldPoint/FP\cFP-RLY-425 @3\Channel "+ch, cwdsWriteAutoUpdate
  frmIOTester.CWDataSocket2.Data.Value = Value
end sub
When I have NI Server Explorer 2.4.1 OPCFieldPoint connected in background,  I can switch between each button channel immediately.  When I disconnect NI Server Explorer OPCFieldPoint in background, I can still switch (ConnectTo) between button channels, but there is about a 300msec delay in connecting.    What is the Server Explorer doing right in connecting that I'm doing wrong in my VB code that it takes longer to connect?  I send the message from DataSocket2.update.status to a label and I see a message of "connecting..." before getting a "connected" message.   With the Server Explorer running in background I never see the "connecting.." message, which further proves my program runs faster with Server Explorer running in background.  I messed around with '?updaterate=", but it didn't make a difference.
0 Kudos
Message 1 of 8
Could it be that buffers are better maintained in the server explorer?  
0 Kudos
Message 2 of 8

Hello delphi Dan,

I'm not a DataSocket expert, but I think this is what is happening.  When Server Explorer is running in the background, Server Explorer will open a connection with the FieldPoint OPC Server and keep it open.  In your code when you connect to the FieldPoint channel, the FieldPoint OPC Server must be opened and connected to.  If Server Explorer already has a connection open, your code only needs to connect to the server.  This saves the time required to open the FieldPoint OPC Server.

Here is the KnowledgeBase article I used to understand how DataSocket connects to different servers.  According to this article, if you would like to achieve the faster connection times, you will need to keep Server Explorer open since DataSocket will automatically connect to the desired server when you perform a DataSocket read or write.

Please let me know if you have any additional questions.

Ching P.
DAQ and Academic Hardware R&D
National Instruments
0 Kudos
Message 3 of 8

ok,  it's not as repeatable as I originally thought.  When the Server Explorer is running in the background, my VB application for switching channels is always fast.   When I shut down the Server Explorer in the background, my VB application for switching channels is sometimes as fast as when the Server Explorer is running in the background.  There are other times though that my VB application for switching channels is noticeable slower.  I'm currently trying to narrow down the reason it's slow at times.  I am new to the DataSocket command set, so I'm not entirely sure I have my connection commands and read/write commands optimally set up.  I'm a little confused why you have to open/connect to each item/channel.  Maybe it's just semantics, but it's seems if you connect to an item, you should be able to read and write to any channel within that item without re-connecting to each channel.  Also, when you state Open/Connect, Is there an Open Server or Url command?   I thought the "DataSocket.ConnectTo" did it all - open url server then connect item.

thanks for your response

0 Kudos
Message 4 of 8
Hello delphi Dan,

You are correct, the "DataSocket.ConnectTo" does open and connect to the URL address, but I believe it has to open the connection each time it would like to connect to that address.

Again, I am not too familiar with DataSocket either, this is just my best guess.  If you are able to narrow down what causes the slowed switching, please let me know and I'll be more than happy to help.
Ching P.
DAQ and Academic Hardware R&D
National Instruments
0 Kudos
Message 5 of 8

I have more information on why sometimes connecting to DataSocket is real slow.   When the Server Explorer is running in background the task manager Process ID for FieldPoint is stable when I use 'Connect To" datasocket.  When Server Explorer is Not running in background, every time I use 'Connect To' I notice a new Process ID is assigned for FieldPoint and my CPU time is about 11% versus 2%.  Getting a new Process ID everytime seems to be slowing the connect to a crawl.    There have been times though that Server Explorer wasn't running in background and my connection times were fast and my Process ID for Fieldpoint was always stayed the same.  So, I can't exclusively say that Server Explorer is the reason my connection times are fast.  Why would a new Process ID  be assigned on every 'Connect To' datasocket and how can I get around this?


0 Kudos
Message 6 of 8
Maybe a better approach to my program is to only do 1 "Connect To" datasocket per item.   I notice that there is an 'all' bit which can be updated using 'And' or 'Or'  to turn on and off the outputs I need, without connecting to a different channel everytime.   Would this be the preferred way to handle I/O?  I still don't understand why a different PID is assigned in task manager whenever I "Connect To" a datasocket item channel.    I appears there are very few experts on FieldPointOPC using VB6.     Also, I noticed that FieldPointOPC2.exe is being used as a server.  Is this correct?  I would think it would be just FieldPointOPC.exe.    
0 Kudos
Message 7 of 8

Hi delphi Dan,

After some more investigation, it seems that you should connect to the FieldPoint OPC Server once in the program.  You will then use the Update function to update the value as needed without reconnecting to the FieldPoint OPC Server.  Please take a look at this document for more information regarding this.

I believe that FieldPoint OPC2.exe is the correct server.  Does your program ever use FieldPoint OPC.exe as the server?  I have not found any mention of FieldPointOPC.exe, but have found the use of FieldPoint OPC2.exe.

Ching P.
DAQ and Academic Hardware R&D
National Instruments
Message 8 of 8