Datasocket Peformance is Slow

[xlAutomation]

Hello,

I am using LabVIEW 8.2 and DSC. I have an application that worked quite well in 7.1, and I have upgraded the application to 8.2. As part of the upgrade, I replaced all of the legacy DSC reads and writes to utilize shared variables, and removed a large chunk of code that handled the FieldPoint I/O (using the FP open/create tag/etc) to now utilize shared variables bound to I/O via the Fieldpoint OPC server. I also obviously am using the LabVIEW project approach now to support all of the changes.

Because of the way the application works (I can attach source code it it helps), I am using a lot of individual datasocket reads and writes to access tags that are bound to the FP OPC Server. I am just using the datasocket read and write VIs and am directly attaching the shared variable tag name to it, without DS open/close VIs. I have a hundred or more of these in the program. Prior to 8.2, I was using DSC reads and writes to perform the same functionality.

The problem is that the fastest I can get the main loop to update now is about .25 seconds, while before I was getting update times in the low tens of milliseconds. Because many PID loops and other controls in the program require fast update times, .25 seonds is not good. Additionally, it might take 30 seconds or more for the initial program pass to perform the first read/write to the tags.

I am wondering if there is a better way of doing this, or has 8.2 become an unwieldy beast.

Since a lot of people have similar problems, I hope that this thread will get a lot of input from NI techs as well as programmers with good experience.

Thanks so much in advance for your help!!!

Michael Hampson

[JLS]

Hello,

There are at least a few other ways to access your io items from the fieldpoint device - I think your current method "goes through" more layers.

Other Method 1:  You could configure and save an iak file in MAX, import this into your project, and then use the fieldpoint io api directly.  This way you'd be going LabVIEW -> Fieldpoint API -> Fieldpoint I/O Server.

Other Method 2:  Bind shared variables to your fieldpoint io items directly - you can bind a variable to a network source, in this case a fieldpoint i/o item.  In the shared variable properties, you browse to the fieldpoint device as a network item and select your desired channel. This way you'd be going LabVIEW -> Shared Variable/PSP -> Fieldpoint.

Other Method 3: You could use datasocket to tag fieldpoint items (this uses psp underneath, the same communication behind shared variables) - sample syntax: fieldpoint://host/FP/module/channel.  This way you'd be going LabVIEW -> Datasocket -> PSP -> Fieldpoint.

Currently, I think you're going LabVIEW -> Datasocket -> Shared Variable/PSP -> OPC -> Fieldpoint.

If you want to use the DSC shared variable features such as logging and alarming, I think method 2 is probably best - it may be the most efficient overall in fact.  If you're set on datasocket and aren't using any special DSC shared variable features, then I think method 3 is probably best.

I am not a fieldpoint expert however, so I can't comment on how method 1 will fare as far as performance is concerned, against methods 2 and 3.  However, at first glance, all three methods above seem to be more direct than the route you're currently taking.  You may consider posting a more fieldpoint-specific question (in the Fieldpoint forum) regarding communication and performance of fieldpoint io when using shared variables vs datasocket vs the fieldpoint API in LabVIEW to get a better figure of merit on which method is most efficient.

An entirely separate consideration would be to look for places in your LabVIEW code where you can gain efficiencies.  Common performance gotchas when you're trying to minimize loop iteration times include anything that causes screen updates (ie. a swap to the UI thread).  Perhaps most notably, beware that all property nodes run in the UI thread, so they implicitly have a performance consideration.  Removing those from loops can cause a significant speed up - sometimes 2 or 3 orders of magnitude.

I hope this helps!

Best Regards,

JLS

Message Edited by JLS on 02-08-2007 05:43 PM

[xlAutomation]

Wow, those are some really great suggestions. I am extensively utilizing the DSC features such as alarming, datalogging, export traces, trending, etc., so I have to use a method that supports this.

I tried method 2, but I had a problem; i was unable to see all of my FieldPoint 1601 (Ethernet) communication blocks. Only 2 out of the 3 show up when I select Network Items in the Network-Published Source drop-down box when binding a shared variable (in the shared variable properties from project explorer).

One of the reasons I have done things the way I have is that I have a set of 80 PID loops: The process variable input and control variable output are configurable from the front panel, i.e. you can select which analog input serves as the process variable and which valve, heater, etc. serves as the control output. This makes the application very customizable for the operator, and the configuration of these parameters are saved in a ".ini" file so that the loop configurations are saved and restored when closing and re-opening the program.

Method 3 is a possibility, but would require some significant programming changes, and isn't really desired, as the definitions in the .ini files would not have understandable settings, i.e. a PID control variable would be pointed directly to FieldPoint rack x, module y and channel z instead of a control variable pointing to "Reactor Flow Control Valve 10" or something.

The only easy way I found to read and write to tags dynamically (i.e not the same tag every time) is to save the save and restore the tag information in the .ini file as a tag data type and poke this directly into the datasocket read and write VIs.

Let me know if you have any other recommendations or if you want to see the vi. I'll try to post it later.

Thanks again,

Michael

[xlAutomation]

Here is a copy of the application FYI.

Thanks,

Michael

[eek]

Method 2 sounds like a promising endeavour. It is curious that you do not see all three of your FP targets when you attempt to directly bind shared variables. Can you see all three in Measurement and Automation Explorer (MAX)?

Do you have any other targets configured in your project? Are you able to see these when you expand the Network-Published Source drop-down box?

[xlAutomation]

It turns out that one of the three FieldPoint communication modules was an older revision firmware than the other two; after updating the firmware, I was able to browse all three communication modules in the "Network Items" source with no problem when trying to bind variables directly to the FieldPoint points.

So I deleted the OPC server and rebound all of my variables directly to the FieldPoint I/O. Upon running the project, I think performance is a little better, but still an order of magnitide slower than an acceptable level. The frame that handles the datasocket reads and writes takes anywhere from 0.1 to 4.0 seconds to complete, although the delay is random: it might work great for a couple of seconds, executing 5 or 6 times really fast, and then delay 4 seconds for the next couple of times.

I'm just not sure what to do. I do have a service ticket open for the problem.

I am going to try to rethink how I can change the way that I utilize the datasocket reads and writes, somehow consolidating them into fewer separate read and write requests, and perhaps combining them into one or two operations.

Any suggestions would be appreciated!

Michael