If monitoring PLC registers, are there performance differences between using DataSockets directly from LV and using tags in LV-DSC?

[Ben]

I want to monitor approx. 800 registers in 15 PLC that are connected using a dedicated e-net LAN. I will be developing the app in LV 6. I expect 1-2 polls per register per second should be sufficient.
Is DSC superior for this app?
Anyone seen any knowledge base articles that will help me decide (before I write the app)?

Ben

[Matt_K]

You will definitely see performance improvements when switching from DataSocket to DSC. As a rule of thumb, you won't want to monitor more than 30 points with Datasocket. There is a good knowledge base that discusses this issue as well. Here is the link:

http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/ea15f53db6fecca5862567240064df09?OpenDocument

Matt Kisler
Applications Engineer
National Instruments
http://www.ni.com/ask

[nealpederson]

If the PLC server supports array reads and writes you can do much better
than 30 points with DataSocket. In my experience, it is the number of
DataSocket connections you have that will slow you down rather than the
number of data points. You probably don't want more than 30 DataSocket
connections but if each connection reads or writes an array of points you
can probably get access 100s or even 1000s of points in a reasonable amount
of time. I used this method to communicate 410 registers from a total of 5
PLCs with an update rate of 5 Hz. I did have to create my own tag manager
in LabVIEW to handle the conversion between arrays and individual points.
DSC has this feature built in.

"Matt K." wrote in message
news:506500000005000000CD540
000-1007855737000@exchange.ni.com...
> You will definitely see performance improvements when switching from
> DataSocket to DSC. As a rule of thumb, you won't want to monitor more
> than 30 points with Datasocket. There is a good knowledge base that
> discusses this issue as well. Here is the link:
>
>
http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/ea15f53db6
fecca5862567240064df09?OpenDocument
>
> Matt Kisler
> Applications Engineer
> National Instruments
> http://www.ni.com/ask