Jump to content

LabVIEW DSC Benchmarking


Recommended Posts

Hi

I am currently working on a project that has about 1000 IO Points. The IO Point are connected to PLCs that are accessible through OPC server.

I would like to get some benchmarking information for data socket and for LabVIEW DSC.

For example, can I expect to be able to read the 1000 tags within 100 ms using data socket? What about LabVIEW DSC?

Does the share variable introduced in LV 8.0 increase performance?

Btw, I was watching this presentation from NI regarding LabVIEW DSC 8.0, and it mention the following: "The LabVIEW 8 DSC Module introduces integration of DSC events, such as monitored value changes and alarm condition changes, into the LabVIEW event structure...Now, the desired event conditions can be easily registered with the LabVIEW event structure and are automatically monitored." This seem pretty cool.

Thanks in advance

PJM

Link to comment
Hi

I am currently working on a project that has about 1000 IO Points. The IO Point are connected to PLCs that are accessible through OPC server.

I would like to get some benchmarking information for data socket and for LabVIEW DSC.

For example, can I expect to be able to read the 1000 tags within 100 ms using data socket? What about LabVIEW DSC?

Hello,

My experiences are with LV-DSC 6.1 (& earlier) from a couple of years ago. We used Modicon and AB PLCs on different projects with 1200 - 2000 PLC IO points.

Imo, 1000 IO points is a LOT for data sockets. If the OPC server is fast enough, the data socket server *might* keep up, but the CPU load would probably be pretty high. The 6.1 DSC engine was fast enough & quite efficient (for "memory tags"), but its the OPC server & the PLC(s) that may not be fast enough.

Test EVERY OPC server available (PLC vendor's, PLC-interface card vendor's, NI's, & 3rd-party like Matrikon) to compare performance & stability. There were very DRAMATIC differences between OPC servers back then.

Before OPC & DSC, we used <http://www.softwarewithrelish.com/> products for PLC communications. Very reliable software with the added bonus of PLC comm errors being directly reported to LV. OPC & DSC comm errors did NOT get reported to LV6.1.

Does the share variable introduced in LV 8.0 increase performance?

Btw, I was watching this presentation from NI regarding LabVIEW DSC 8.0, and it mention the following: "The LabVIEW 8 DSC Module introduces integration of DSC events, such as monitored value changes and alarm condition changes, into the LabVIEW event structure...Now, the desired event conditions can be easily registered with the LabVIEW event structure and are automatically monitored." This seem pretty cool.

Thanks in advance

PJM

LV8 shared variables *might* be faster than the previous DSC+Logos for "network tags", but as I stated earlier, its the OPC side of the house that will probably be your bottleneck with PLC points.

The new features of LV-DSC 8 sound GREAT! I hope to work with it later this year.

Good luck with your project!

Catfish ...

Link to comment

Hi Catfish,

Imo, 1000 IO points is a LOT for data sockets. If the OPC server is fast enough, the data socket server *might* keep up, but the CPU load would probably be pretty high. The 6.1 DSC engine was fast enough & quite efficient (for "memory tags"), but its the OPC server & the PLC(s) that may not be fast enough.

Just wanted to make sure I understood your setup correctly. You used Memory tags in DSC to talk to the OPC Server? I am guessing via DataSocket. Why not create tags directly off the OPC Server? DSC as an OPC Client can browse OPC Servers and allows to create tags directly off of it. Or, is this what you did? Then, why use Memory tags?

Thanks for the clarification.. in advance.

-Khalid

Link to comment

Insofar as LabVIEW 7.x is concerned, I think that attempting to deal with 1000 DS points would be difficult, at best. The addition of the DSC module would allow you to connect to the OPC points and having them as tags would provide both the ability to give more meaningful names to the points and to easily access the same point in multiple locations within your code.

It is my belief that the DSC engine will handle data updates faster than DS but I confess that I have no data to back that up. Having said that, as others have mentioned the OPC side of the equation will be your bottleneck...enough so that the differences between DS and the DSC engine might well be overshadowed.

In any event, the throughput that you are looking for ~10Ksamples/sec are beyond the capability of the DSC engine. ~5Ksamples/sec is more realistic and, with the overhead of OPC, possibly even less.

Insofar as LabVIEW 8.0 is concerned and bearing in mind that this is the first release of the new engine, what we see with the new shared variable is not a higher absolute throughput but, rather, a significant improvement in the performance drop-off caused by adding more variables to the system.

Other reasons to consider the newer version:

  • Shared variable engine supports OPC 3.0 and OPCEnum
  • Shared variable engine allows multiple processes
  • Shared variable engine supports dynamic changes
  • Shared variables are usable on RT
  • LabVIEW 8.0 integrates DSC events and variable changes into the event structure

**I am not in NI marketing but I like the changes to the DSC module in ver. 8 and I think it has great promise**

Link to comment
...

Just wanted to make sure I understood your setup correctly. You used Memory tags in DSC to talk to the OPC Server? I am guessing via DataSocket. Why not create tags directly off the OPC Server? DSC as an OPC Client can browse OPC Servers and allows to create tags directly off of it. Or, is this what you did? Then, why use Memory tags?

Thanks for the clarification.. in advance.

...

Hi Khalid,

DSC Memory tags were the only real way to test the DSC engine performance alone. Once a tag is connected to a PLC point via an OPC server, then the performance being tested is that of the DSC engine+ the OPC server+PLC. The DSC engine will be the fastest of these three components by far.

We used DSC network tags, some pointing to OPC servers tags for real I/O points, & others were memory tags used as "network globals" for communicating status changes between PC nodes running the DSC runtime engines. I've used datasockets to communicate variables between PCs that were not running a DSC engine.

Did that answer your questions?

Catfish ...

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.