REM1

QUOTE(superslug @ Mar 27 2007, 08:13 PM) 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) Any particular reason for using the datasocket server as opposed to shared variables?

Which examples?

QUOTE(Rick @ Mar 14 2007, 12:09 PM) 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) I was wondering about that as well. (I guess 'quarterly' doesn't necessarily mean every 3 months!) 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) 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) I applied several months ago, but haven't heard any response. I'm very keen to get at this - should I apply again? Jaegen 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.

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.

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

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

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

I had meant affecting shared variables through VI server...and it won't work. 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.

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

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.

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.

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.

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

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.