REM1

QUOTE(superslug @ Mar 27 2007, 08:13 PM)

Being able to plug the datasocket straight into the front panel object was what I wanted. I am updating graphs on the main vi from a sub vi and using the references with property nodes was being processor intensive so my boss suggested that I use datasockets to see if that could reduce the load on the processor.

Also I am under the impression that with a datasocket the data posted will only be read once by a particular subscriber and I didn't know whether or not this was the case with shared variables.

The front panel connection mechanism does not require the use of the datasocket server. You can make a front panel connection to a shared variable in exactly the same way. Furthermore, the correction mechanism is the same in each case. The FPDS connection will subscribe to updates from the respective server and will be modified only when the value changes rather than constantly polling. So, up to this point, there is no difference between the two. Where the difference comes in is the server and the transport mechanism. PSP, the transport mechanism for the shared variable, is faster than DSTP, the transport mechanism for the datasocket server. It is also the case the the server for shared variables is already running on your system whereas the datasocket server would have to be started adding an additional executable for the OS to deal with. Lastly, the shared variable is the newer of the two technologies meaning that future improvements are more likely to be made there rather than the datasocket server.

QUOTE(superslug @ Mar 26 2007, 07:59 PM)

I want to use datasockets to communicate between 2 vi's.

I have them working fine except that i have to manually start the datasocket server.

For development this is fine but to deploy the code I need to be able to do this automatically.

Can it be done programatically or somehow in the exe for an application?

thanks

Any particular reason for using the datasocket server as opposed to shared variables?

Which examples?

QUOTE(Rick @ Mar 14 2007, 12:09 PM)

Could you elaborate on this? Do you have other info?

I *hope* there will be updates to LV8.2, but this info came from an NI rep....

Post from an NI employee about upcoming releases.

And, since I work in LabVIEW R&D and I'm putting the link here I suppose you could consider me another confirmation...despite the fact that I won't come out and plainly state what you are looking for.

QUOTE(JohnRH @ Mar 14 2007, 11:44 AM)

Well, assume that we were trying to get something specific in a given release (additional support for the release of a new OS...purely as a hypothetical example) and we thought that we could have everything ready to go but it would take an extra month. I would think that extra month time well spent rather than either putting out something prematurely to meet an arbitrary time schedule or delaying functionality for the same reason.

QUOTE(crelf @ Mar 8 2007, 02:36 PM)

Just to clarify: this isn't a public beta - your participation in the program must be authorized by NI.

True, your participation must be authorized by NI. When I say public beta I mean one where you can request admittance by going to ni.com/beta as opposed to a private beta where you must get an invitation email from me the beta coordinator just to get to the signup page.

QUOTE(jaegen @ Mar 8 2007, 03:03 PM)

Yes, you should.

National Instruments has opened the beta program for its next release of LabVIEW. If you'd be interested in participating, go to http://ni.com/beta, select LabVIEW from the drop box on the right and fill out the form.

I have it on good authority that the beta coordinator is pretty accepting of applications.

Hello,

I upgraded from LV 7.1 to LV 8.0. When I run the program, there is automatically starting the shared variable engine, which is correct, but also the Tag Engine from LV7.1 . It pops up an error that tag engine doesn't find the scf file. This is logical because in LV8 there are no scf files. They have been converted in DSC Module. Does anybody has a equivalent situation?

kind regards and thx in advance.

Dietmar.

Could you please describe, in detail, what happens when you start up? Does this occur when you start LabVIEW? When you run a VI in the development system? When you run a built application?

LabVIEW 8.0 should not attempt to start the 7.1 tag engine. In fact, it shouldn't know that the tag engine ever existed.

I've gotten shared variables to work between VIs in two projects with a small example. Now when I scale it up to my large project, LV crashes when I have both VIs running and the code gets to the point where it's trying to write to the shared variable. I backed out the shared variable of each project and the VIs function fine independently. When I put the shared variable back in it crashed again. Has anyone else run into this? Seems to me that the size of the project shouldn't matter.

George

The size of the project should not matter. Could you post a snippet of your code for us to look at?

Well, I guess a related question would then be, "Is there any way to register for these shared variable value change events without the entire DSC module installed?" I don't mean to circumvent the need for the DSC which, I'm sure, is well worth it. It just seems that if that is all you want to do, there may be some other way.

-Matt

Not at this time. DSC had to do a good bit of extra work to get this to work.

That's the problem with humor, you never know who you're going to insult.

Anyway, not having used most features of the DSC module (except for mainly the image navigator and the IA OPC server) I'm not one to pass (or not pass) judgement on it.

I wasn't offended...I just forgot to add the smiley to my post.

I don't understand what do you refer to with "the VI server case with shared variables", I considered them two different ways of transmitting data. Or do you mean affecting shared variables through VI server? I hadn't thought about that, but it would sound interesting (if you hadn't already stated that won't work, of course ;-)).

About the crash, I really don't know, the laptop just crashed repeatedly when the "deploy" window appeared. I'll try to test it in another machine, if the license allows me to do so.

Saludos,

Aitor

I had meant affecting shared variables through VI server...and it won't work.

I got hold of an engineer at NI that sent me an example of how to do it with "Bind to Source" (I asked him to make it available as an example). It was really pretty easy. It seems like that way would be a lot easier than having to include a datasocket read. I thought shared variables were supposed to take the place of datasockets.

George

The variable is the preferred method. The datasocket read is useful when you do not know the URL of the variable to connect to at edit time. Datasocket refers to both the diagram API (and, in fact, a front-panel API) and a communication protocol. The shared variable very definately replaces the datasocket communication protocol. The diagram and front-panel APIs were adapted to work with the underlying shared variable technology.

Unfortunately, I don't have any experience with the DSC module. If I don't use the "Bind to Source" then how do I tell the second executable how to access the variable?

George

Write your first application and have it include a library with your variable in it. Choose to have the library automatically deployed.

Now you have three options:

1. Assuming that you prefer to have the ability to choose the variable to which your 2nd application connects at runtime, place a shared variable control (located on the I/O palette) on the front panel of your application. Clicking the drop-box control you will be presented with the option of browsing the variable space. This will allow you to choose the variable to which you are connected. The output of this control must be wired into a datasocket read/write (depending on whihch you want to accomplish.)

2. You can determine the URL of the variable from the 1st application and wire that as a constant to the datasocket read/write rather than having the control on a front panel.

3. Assuming that you prefer to set the variable at edit time and do not want to change it, add the library containing your control variable to the 2nd application's project (in addition to being in the project for the 1st application.) You can now drag/drop the variable from the project list to the diagram and it will be automatically bound to that variable. This use case will redeploy the library when the 2nd application is launched.

Note: in either case listed above you will have to put the read in a loop and check it occasionally (or use a timeout on the datasocket read.) Optionally you can make use of the event structure but that requires the DSC module be installed as we discuss in another thread.

Yep, and it's a pretty good system that allows a lot of customization like connecting simultaneously with several instances of the same executable, etc. Another option is to compile the exes as ActiveX servers, then you can communicate between them in a very similar way (in fact you just need one of them to be registered as a server, the other one reads and writes on it). An example is attached. The advantage of this system is you can communicate with the program through another languages, not just LV.

That been said, I was wondering about the shared variables in two local exes too, 'cause it seems a simpler solution in some cases. My guess is they should be the network type, because for each one the other application is external, even if they are running in the same machine (the same holds true for VI server, when you must use remote access and a valid port number though you never go through the net), but unfortunately I still haven't be able to check it, because the shared variables crash my PC :-(.

Saludos,

Aitor

The vi server use case will not work with shared variables since they are technically external to the LabVIEW executable. And why do the shared variables crash your PC...if I may be so bold.

There's nothing special about it. NI would be happy to give it to anyone who would give them money for it.

While I would argue that there IS something special about it...it is a purchasable add-on and is required to make use of the feature you are asking about.

I have two separate projects that will be built into stand alone executables (Win XP). I want the apps to be able to function as separate entities. In some instances though I want one app to be able to trigger an event in the other app. After reading about shared variables I'm still not sure how to do this. Do I have to use network published variables even when both apps are on the same PC? If I do use a network published variable I assume I have to use the "Bind to Source" property (I don't really know that for sure). What do I enter for the Path? This gets confusing when working with executables.

George

You should use "network published" even though both executables are on the same machine. This will put the variable into the data engine so both applications can use it.

Do not use "Bind to Source"...this allows you to have the variable connected to hardware. If you are familier with previous versions of the DSC module, by not binding you have the equivilent of a memory tag...your appplications can both read and write to the variables which seems to be what you are looking for.

FYI...'Path' refers to the network addess to which you want to bind the varaiable. N/A in your case.

The FAQ on shared variables (#30) says that the "DSC Module adds the ability to register for shared variable alarm and event notifications and data value change notifications as separate event cases in the LabVIEW event structure". I tried to do that, but can't figure out how to register the event. Can anyone clue me in please?

George

DSC includes an example for using this feature. Go to the examples directory/lvdsc/Event Structure Support. This should do a pretty good job getting you started.

How can I get the "shared variables list" from the remote server/DSC Engine programmatically ?!

Regards,

Helios

See this post on NI's forum.

Hope this helps,

Robert

Check for a file with your executable named foo.aliases, where foo is the name of your executable. Make a copy of this file (just in case ) This is just a text file. Modify both 'localhost' and 'My Computer' to point to the new target machine rather than the original dev machine. This should fix your problem.

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**

I'm very excited about this "new" method of using Shared variables to pass data around. It'll change how we use RT-FIFO's and how we configure DSC "items" while making the data easier to get to (or at least it looks that way). I think i heard that it will also be usable as a triggerable event as well.

I asked these question at the 3pm CT web event on "shared variables" today:

1) How does it compare to datasockets? Will it replace Datasockets?

A) datasockets is built on this new "shared variable engine". There are people out there relying on datasockets so no, DS technology will not be replaced. DS Vi's will still be included and supported....

I guess my follow up question would be: Is this just another name for "LOGOS"?

2) What are the performance boundaries?

A) 3 mb/sec Max transfer rate was a number that was mentioned.

3) Is there a max # of points?

A) there was no problems when tested with 10,000 items.

For those who've used the Lv8 or beta, any thoughts on this? This almost sounds too good to be true.....

Regis

To begin with I would recommend watching the LabVIEW 8 DSC tutorial - it is NI marketing and discusses the DSC Module but it provides some additional information about the shared variable that you might find useful.

To answer some of your questions more specifically:

1-ish: The shared variable engine acts as a host, or publisher, of networked shared variable data - and hosts additional services which can be applied to that data. The shared variable engine uses the PSP networking protocol, basically an updated Logos, as its native communication mechanism. The datasocket API, primatives, etc., now uses PSP as its default communication mechanism - although it will still communicate with older datasocket devices. This API can be used to read/write to shared variables when the identity of the variable is unknown at edit time.

There is also a new node for the block diagram called the shared variable, think local/global, which makes a connection to the engine and but also provide automatic wire-type updates, and linkages, if the shared variable configuration changes.

2-ish: Final numbers on performance are not available at this time.

3-ish: I'll try and get back to you.