Big project

[shared brain]

Hi,

We are starting a DSC project up to 1500 variables. Anyone knows any tools to make faster data binding and manipulate variables properties?

Thanks

[crelf]

Um, LabVIEW DSC?

[Rolf Kalbermatter]

Hi,

We are starting a DSC project up to 1500 variables. Anyone knows any tools to make faster data binding and manipulate variables properties?

Thanks

Have you done some benchmarks first to make sure 1500 variables is going to fly? I have no idea about the latest LabVIEW DSC versions, but from what I know they are based mostly on the shared variable engine technology and I have in fact some doubts that technology scales well. So before going through all that hassle I would make sure I can operate with a reasonable amount of variables first.

As to automating the binding to front panel controls you might be able to get at that information through the scripting API. In that case you could fairly easily create a little tool yourself that does whatever automation you feel is right.

[Grampa_of_Oliva_n_Eden]

Have you done some benchmarks first to make sure 1500 variables is going to fly? I have no idea about the latest LabVIEW DSC versions, but from what I know they are based mostly on the shared variable engine technology and I have in fact some doubts that technology scales well. So before going through all that hassle I would make sure I can operate with a reasonable amount of variables first.

As to automating the binding to front panel controls you might be able to get at that information through the scripting API. In that case you could fairly easily create a little tool yourself that does whatever automation you feel is right.

Ditto that!

I have managed more than 5000 using the old version of DSC (pre-shared variable) and it ran well even on the 400 MHz PC it was deployed to. Modern PC maybe able to handle the I/O via DataSocket read/writes so it would be a good idea (as Rolf wrote) to benchmark the performance to minimize that risk.

Ben

[PaulL]

Some comments:

Regarding scalability:

1) Performance: I created my own bench test a while back, programmatically creating 1000 SVs and writing 1000 messages to each. I don't remember the exact numbers, but the performance was quite good.

2) Ability to configure SVs easily:

What exists:

a) Control binding

i) Manual configuration of each control

ii) Front Panel Binding Mass Configuration tool

iii) Programmatically updating the URLs with the DataSocket API

b) Configuring SVs

i) SV library interface (good but not ideal for a very large number of variables)

ii) Multiple Variable Editor (convenient spreadsheet-like interface for each library)

iii) DSC SV creation and configuration methods

iv) To clone a library (same variables, new library name) one can just use a method to copy it on disk.

This may be a personal thing, but I don't like using the DataSocket API for shared variables in general. (The read/write SV methods only use buffering if you pass the reference, unlike SV nodes, which also make the code much easier to read. Moreover, I don't like the concept of using DataSocket methods for all sorts of unrelated communications methods. I think NI should incorporate all shared variable capabilities into a single consistent API--and there has been some progress here.)

What we found is that the most common reason we have to want to do things programmatically is when we want to clone a software component (to make multiple instances of an application). Most often we can accomplish this by renaming a SV library before building an executable. I think the builder should support this in the build script (but it doesn't currently).

Another common reason I can think of to want to configure SVs on the fly is to change the logging configuration (resulting in more or less frequent logging rates). One can do this by programmatically creating and configuring SVs using the DSC methods, or one can use the Multiple Variable Editor interface. (An outstanding task for us is to see if we can build the libraries with an executable such that we can edit them while an executable is running, as we can in the development environment.)

[Grampa_of_Oliva_n_Eden]

...

What we found is that the most common reason we have to want to do things programmatically is when we want to clone a software component (to make multiple instances of an application). Most often we can accomplish this by renaming a SV library before building an executable. I think the builder should support this in the build script (but it doesn't currently).

...

My issue with the SV nodes is I can't programatically redirect the I/O to a new widget. DataSockets accept a URL (similar to the old DSC tags). TO do the same with SV nodes I would have to change code everytime a new option was added.

Ben

[PaulL]

My issue with the SV nodes is I can't programatically redirect the I/O to a new widget. DataSockets accept a URL (similar to the old DSC tags). TO do the same with SV nodes I would have to change code everytime a new option was added.

Ben

Ben,

Yes, this is definitely a limitation with the shared variable nodes. DataSocket and the new-to-2009 shared variable API methods accept a URL (though of different formats, so I guess the latter isn't truly a URL!), which allows remapping at run-time.

In practice, however, I still use the nodes, because I don't have to pass references to maintain buffering and performance when I use the nodes, and I think the nodes are a lot easier to read. Also, I find that when I want to "redirect" the shared variables I do this because I want to "clone" a behavior, and I find it simpler to rename the library or copy it (and in the latter case I have started writing override methods to point to the shared variable I want).

I'll explain that last part. I may have a high-level state shared variable that I reuse in all components. I write the overall behavior in a Component class, but I have an updateStatusSV method that each child overrides to point to the variable for that particular component. (In all fairness, one could argue there is a slight cost to readability, but I think the cost is quite minor.)

If I really needed to change the logging levels programmatically or something like that (which may yet happen) I would definitely have to do more programmatically.

My other uneasiness about DataSocket with shared variables is ambiguity:

1) I can specify a shared variable URL with dstp or psp. I know to use psp, but the choice is strange, and I'm not sure I understand the differences precisely. Besides, why do I need a "DataSocket" API to communiciate with PSP? That has never made sense to me.

2) The Data Socket URL does not provide exactly the same functionality as the shared variable API. (The differences are minuscule perhaps--for instance, an indicator bound with DataSocket is not capable of blinking while in an alarm state--but then I guess my concern is that I don't know exactly what the differences are.) Oh, and and when I bind a control I can use DataSocket or NI-PSP, but when I use a DataSocket Read VI on a block diagram I can specify a dstp or a psp URL. NI does not use the terms consistently.

By the way, I am definitely not arguing against using the DataSocket API. I think it is an entirely valid and effective API, and it clearly provides some capabilities that shared variables nodes do not. What I would like to see is a single unified shared-variable-only API that cleanly implements all the allowed functionality unambiguously, such that the decision to use this API would be the obvious choice.

Paul

[Grampa_of_Oliva_n_Eden]

Ben,

Yes, this is definitely a limitation with the shared variable nodes. DataSocket and the new-to-2009 shared variable API methods accept a URL (though of different formats, so I guess the latter isn't truly a URL!), which allows remapping at run-time.

...

Paul

Ben

[Alejandro_i]

Hi,

We are starting a DSC project up to 1500 variables. Anyone knows any tools to make faster data binding and manipulate variables properties?

Thanks

Hi, 'shared brain'. I think this is a very big project !!. Based on my experience, shared variable engine (tagger) is enough powerful to develop a application with this number of variables (break your library process between other lesser libraries).

You have a limited set of tools shipped with LabVIEW DSC to configure links between front panel controls and indicators, and shared variables.

1) Front panel binding, available on ‘Tab’ control properties: Data Binding (use PSP option). This option involves long time to implement connections. Imagine 1000 controls on front panel … !.

2) Mass front panel databinding. You should make some .csv file to configure controls and indicators

The two methods exposed have limitations to keep sustainability and scalability. You should think about others application aspects:

- Control maximum, minimum and increment values. User interface should act as input values filter. When you operate a machine or process is very important to prevent you can’t input dangerous values

- Normally, the communication between PC and PLC’s is made by OPC Servers software layer, so you should verify input values are correctly transmitted. It is necessary to control this communication, waiting until input values are written to PLC

- Messages to user to confirm Boolean operations (Run/Stop,…)

- Application scalability. If you have a monitoring system where two or more machines have a similar process variable mapping, you should re-use the code with minimum changes (I think process name is the unique difference between machines)

- …

As you have seen, the tools shipped with LabVIEW DSC are limited, and you should think about a toolkit/scripting tool to resolve these problems.

I have heard exists a component/toolkit named XDSC, developed for a engineering that can you help, because resolve enough problems, and the most important, you can to save a lot of development time.

I will post information soon…

[shared brain]

Thank for all, because I didn't know how works thir forum... sorry about this comment.

Our problem is not Labview DSC power, we want to make easier and faster all the variable definition , it's like Alejandro_i explains... He says something about a new tool, XDSC, what's that? how it works...

Does anyone know anything about XDSC?

Alejandro_i, where can we see the features of this toolkit? we haven't found in any web page...

[Alejandro_i]

Thank for all, because I didn't know how works thir forum... sorry about this comment.

Our problem is not Labview DSC power, we want to make easier and faster all the variable definition , it's like Alejandro_i explains... He says something about a new tool, XDSC, what's that? how it works...

Does anyone know anything about XDSC?

Alejandro_i, where can we see the features of this toolkit? we haven't found in any web page...

Hi 'shared brain'.

¡I found a video demo named XDSC_Demo.avi!. This video explains how do you use this component. It seems Xnode-Based Technology...

Does anyone have additional information about this component (XDSC)?

Thanks

[Alejandro_i]

Hi 'shared brain'.

¡I found a video demo named XDSC_Demo.avi!. This video explains how do you use this component. It seems Xnode-Based Technology...

Does anyone have additional information about this component (XDSC)?

Thanks

Sorry!. You can't download the file from NI ftp server.

I attach compressed file XDSC_Demo

Enjoy and help me to explain this demoXDSC_Demo.zip!!

[shared brain]

Ok,

do you know if there is more information about it (pdfs, technical articles...)?

[Alejandro_i]

Hi, a friend has send to me a document (spanish language) that explain XDSC toolkit. It seems a beta version of XDSC and I have not found Web information about i-less engineering. I'm translating this document to english.

Best regards,

Alejandro

XDSC.pdf

[shared brain]

Alejandro_i, what a big solution!!!! we have been looking information you posted and we think that XDSC could help us because it's the correct tool!!!.

Please did you know where can we find a demo? is it in NI soft?

I recommend all the DSC users to investigate the XDSC advantages, it will traslate in significant savings!!!!

Regards