Shared Variable Help

Hey,
I need some help with shared variables. Here is what I'm trying to do. I run a vi on the computer that uses a camera to track certain objects. I would like this program to send the position of the object to another vi that is running at the same time on the speedy-33. The speedy-33 takes the position and rotates the robot towards the object. The problem I have is communicating the position from the computer to the speedy-33.
From what I've read, I think I'm supposed to do this with shared variables. On the computer target, I created a library with an integer variable (to hold the x position of the object). I set this variable in the computer vi using the shared variable. All of this is in a while loop. On the speedy-33 VI, I've connected a control to the shared variable. When I run the program everything works as intended so far. When the object's x value changes the control on the speedy-33 front panel changes appropriately. However, when I try to drag the variable onto the speedy-33's block diagram from the project explorer I get a bunch of errors. The first is "My Computer\Variables.lvlib\xpos: Not supported for current target." Since it appears this isn't supported for the speedy-33 how am I supposed to transfer the data?
Hope all that makes sense.
Thanks

Squirell wrote:
Hope all that makes sense.
Well, I for one got lost somewhere in there. Didn't you say that you already had the shared variable in both the computer VI and the Speedy-33?
It may be a good idea to take a look at the Shared Variable Client-Server example, and perhaps test it to see if it, at least, can work on your setup.
I for one gave up on shared variables (flow control was just too much trouble) and am using "functional globals" instead. http://zone.ni.com/devzone/cda/epd/p/id/4364 was particularly helpful.Message Edited by kehander on 02-20-2007 12:46 PM

Similar Messages

More shared variable help

Yep, I'm attempting a large shared variable project, so, I guess it's time to get active on the board again.
Anyway, so I had this problem;
http://forums.ni.com/t5/LabVIEW/Getting-a-list-shared-variable-references/td-p/1817829
but we got that figured out.
Now, when I go to write the data to the variables, I can watch it go from 'No Known Value' in the distributed system manager to ' ', and yes, I mean blank. Granted, the data is coming from a simulated DAQ currently, but I can probe the data line in the .vi and there's numbers there, they're just not getting to the shared variable. Any ideas as to what I'm doing wrong? I've got the variables deployed and the shared variable engine is running on the computer. Is there something I need to do programmatically prior to writing to them?
Here's the snippet so you don't have to switch between tabs to look at it,
Thanks for any help,
-Ian
Solved!
Go to Solution.

Hi Ian,
It is hard to tell exactly how the data will display when pulling from a citadel database. One recommendation I have for you is to use the Read Trace/Write Trace .vi's which will allow you to break up the waveform and handle the data apart from the timestamps they are associated with.
Hope this helps!
Allison M.
Applications Engineer
National Instruments
ni.com/support

Using shared variable not in the project.

hi all
I have a project with the 2 RT targets and the development PC which were i currently deploy all my shared variables, But I need to finally deploy these shared variable in a different stand alone windows based machine. To do this I created separate application which does nothing but deploys the shared variables in this PC. but when i tried to bind to this variables (frount panel binding) from my RT targets it woudnt work, the led does not glow, it is always transperent. but when I tried to connect to these variables from my development PC it works fine. I double checked the firewall problem, that is not the case here. Can anyone tell me what am i doing wrong?
Thanx
Arun

Hi Prashanth
Thanks for the reply. I did realize that the front panle connection would not be supported in RT, now i have the shared variables on my RT machine which has te source as the windows machine. If the windows machine is my development machine the shared variables connect fine, but if its a different PC the shared variables connect for few seconds and with the error info "shared variable value 0" then the connection gets disconnected.
Also i read a note in the shared variables help, it said to subscribe and publish on a network shared variable all the shared variable which connects to this variable should be active. does this mean that if there are 2 RT targets that subscribe data and one of them is not switched on the shared variable does not work.?
Thanks again for your support.
Regards
Arun

Need help getting networked shared variables on compact fieldpoint to work

I'm still a newbie and am trying to get Networked Shared Variables to pass from a VI running on a PC to a VI running on a Compact Fieldpoint. I created a VI that sends a message via a Networked Shared Variable and a VI that receives it. I have them both in the same project. If I run them both on the PC, it works, I can send a message string from the first VI to the Networked Shared Variable and read it in the second VI. I have the second VI turn the LED "A" on and the LED "B" off if I send the string "a", and turn the LED "B" on and the LED "A" off if I send the string "b", and turn them both off if I send anything else. It works as expected if both the VIs are running on the PC. The second VI also continuously blinks the LED "C" so I can verify that it's running.
I "deployed" the second VI to the Compact Fieldpoint as follows:
In Project I dragged the VI from My Computer (under Project: name.lvproj) down and put it under the Compact Fieldpoint name.
I right clicked on Compact Fieldpoint name and verified it was set to "Connect".
I right clicked on the second VI and selected "Deploy".
I started both VIs with the "Run" arrow. At this point I know second VI is running since the LED "C" keeps blinking. But, when I try to send an "a" or "b" nothing happens, so the VI on the Compact Fieldpoint must not be receiving the messages in the Networked Shared Variable.
I also right clicked on Compact Fieldpoint name and selected
"Disconnect". The second VI continued to run since the LED "C" keeps
blinking, but I still can't get messages to pass.
Any help will be greatly appreciated.

I got this to work. I moved the library (.lvlib) containing the Networked Shared Variable to down under the Compact Fieldpoint name. Now it works.

Performance of Modbus using DSC Shared Variables

   I'm fairly new at using Modbus with LabVIEW. Out of the roughly dozen tools and API's that can be used, for one project I'm working on I decided to try using Shared Variables aliased to Modbus registers in the project, which is a DSC tool. It seemed like a clever way to go. I've used Shared Variables in the past, though, and am aware of some of the issues surrounding them, especially when the number of them begins to increase. I'll only have about 120 variables, so I don't think it will be too bad, but I'm beginning to be a bit concerned...
   The way I started doing this was to create a new shared variable for every data point. What I've noticed since then is that there is a mechanism for addressing multiple registers at once using an array of values. (Unfortunately, even if I wanted to use the array method, I probably couldn't. The Modbus points I am interfacing to are for a custom device, and the programmer didn't bother using consecutive registers...) But in any case, I was wondering what the performance issues might be surrounding this API.
    I'm guessing that:
1) All the caveates of shared variables apply. These really are shared variables, it's only that DSC taught the SV Engine how to go read them. Is that right?
   And I'm wondering:
2) Is there any performance improvement for reading an array of consecutive variables rather than reading each variable individually?
3) Are there any performance issues above what shared variables normally have, when using Modbus specifically? (E.g. how often can you read a few hundred Modbus points from the same device?)
Thanks,
    DaveT
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
There are 10 kinds of people: those who understand binary, and those who don't.
Solved!
Go to Solution.

Anna,
    Thanks so much for the reply. That helps a lot.
    I am still wondering about one thing, though. According to the documentation, the "A" prefix in a Modbus DSC address means that it will return an array of data, whereas something like the F prefix is for a single precision float. When I create a channel, I pick the F300001 option, and the address that is returned is a range: F300001 - F365534. The range would imply that a series of values will be returned, e.g. an array. I always just delete the range and enter a single address. Is that the intention? Does it return the range just so you know the range of allowed addresses?
   OK, I'm actually wondering two things. Is there a reason why the DSC addresses start with 1, e.g. F300001, instead of 0, like F300000? For the old Modbus API from LV7, one of the devices we have that uses that API has a register at 0. How would that be handled in DSC?
Thanks,
    Dave
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
There are 10 kinds of people: those who understand binary, and those who don't.

Is there a way to reset the shared variable engine?

I would like to be able to reset the SVE in a manner that is equivalent to what occurs during a hardware reset.
My motivation for doing so is as follows:
I have an cRIO app with lots of IOV's and NSV's that operate via the SV API and also with plenty of static nodes. I am finding
that on first run, from the DE, my CPU%=~55%. On all subsequent
runs my CPU%=~65%. If I do a hardware reset or redeploy one particular
NSV library then
my cpu usage will return to ~ 55%. I have tried isolating the area of code that accounts for this and have found that
the problem centers around my initialization of one library of NSV's
where I set its init value via the SV API. The NSV references
are all closed after writing without error. So I am wondering if it
is possible that the NSV ref's are not actually closing or possibly
the setting of the inital value has some effect on the SVE so that subsequent runs get bogged down.
Anybody have any ideas?

Hello,
If you redeploy your library, does that bring your CPU usage back down? perhaps you can use that as a suitable workaround? How exactly are you setting the initial value of your shared variables?
Tejinder Gill
National Instruments
Applications Engineer
Visit ni.com/gettingstarted for step-by-step help in setting up your system.

Are clusters or individual elements better for shared variables?

So... I have some RT code that is being updated, and pulled out of the Stone Ages of LabVIEW. It was originally written for an old FieldPoint controller operating in "headless" mode, and used the "publish" and datasocket methods for communications and external control. I had to get clever way back then, and put together a parsing/unparsing system for strings to send sets of data back and forth between the controller and any HMI or other computer attached.
Now, I'm completely rewriting the code for a cRIO system, and doing my best to leverage all of the strengths of the latest LabVIEW versions. I have already done an intermediate stage, where I converted from the publish/datasocket method to using network shared variables for my strings, so I could keep some of the original control and calculation logic. Now, however, I'm going back to the drawing board for most of the program, with only some of the proven logic being held over into the new version. And, as I'm putting together the data structures I need for both internal control and external communication, I'm in a bit of a quandary...
I have come upon a data structure dilemma: should I use individual shared variables for my data, or assemble associated data into clusters? My original program had a string (essentially a flattened cluster) for each sensor in use (up to 4), one for the system parameters and states, and one for the control parameters and states. There was a certain advantage to keeping the data compartmentalized like that, it kept things organized and forced me to avoid too many random references of each data point. And it kept the number of communications channels limited to just a handful. Mimicking this structure with cluster shared variables would be easy. But, I'm not sure it's the best or most network-efficient method.
I know the bundling/unbundling will add some processor time in my code, that is not new to me (it will still be much faster than my old parsing routines). But, if I have individual data points being thrown around, I can access them easily from things like Data Dashboard (which is great, but far too limited to be able to grab items in clusters and such). Having all of my data points individually available would make my project messier, but open up easier access. It would also dramatically increase the number of data points being thrown around on the network at any one moment. For reference, I would probably have a maximum of 100 data points at one time, made up of a combination of integers, floats, booleans, integer arrays, boolean arrays. Or I would have a maximum of 8 clusters that would contain those data points.
Any suggestions on which way I should lean? Are there any advantages/disadvantages between shared clusters like the ones I need vs. the number of individual shared variables I would need using the alternative methods? Network traffic and efficiency are always a concern, particularly since this is a "headless" cRIO in a control situation that must maintain a fast scan rate...
Thanks for any help. I'm so stuck on this fence, and I can't figure out which side to fall off!
Solved!
Go to Solution.

Thanks Tim, that is a great source that I somehow missed in my hunt for information regarding my dilemna...
I have to wonder though, does that 25 number also include the I/O points on your cRIO? Anyone know that particular? Most of the I/O points are network shared by default during initial configuration, and you could very quickly exceed 25 variables on an 8 slot rack (such as the one I use, a 9074). Now I'm a bit worried that I'm overusing the variable engine, even before the communications clusters get figured in...

Print-time charting with shared variables on a report without groups...

hello all,
I have an interesting conundrum; I am working on a report (Crystal XI) with no groups to it, just several subreports. Presently the report is run weekly and sent to the manager of one of our departments.
The report itself showcases all areas of the department with total tasks, longest outstanding task, average days outstanding, MTD tasks completed, and YTD tasks completed. Due to the variety of tables the data pulls from, I have it set up as subreports that simply display the data.
All total, there are 20 different shared variables that have been obtained from 10 different subreports. I have the shared variables set as the running totals from the subreports (hence, all are print time). Since the running totals and all the subreports are time based and are not actually linked to ANYTHING on the main report, I am struggling with how to set up the formulas described in the white paper, "Charting on Print Time Formulas".
The setting up of the two formulas ({@onchngof} and {@showval}) will be different for my situation, as all of the subreports run off of date information relative to when the report is ran. I've got all of the subreports that the shared variables originate in early in the report; but where to from here?
Would I set up maybe a date grouping or some other non-essential consistent grouping to make it work? The way this report is, it really doesn't need grouping, because the main report is just a display agent for the subreports...
As always, any help is greatly appreciated!

Let me ask couple of questions before trying to resolve this.
1. The chart you are trying to built is placed in which section and is it on Main report or sub-report of its own. This is needed because if you are trying to access shared variables values in Main report, the section should be below the sub-report placed sections.
2. Try pacing few test formulas in Main report and make sure the correct values are being pulled in on Main report.
If you are successfully pulling the variable values on the report, try creating a simple chart in report footer with the values you have pulled and see if its taking you somewhere...
Would need more information on how those variables are being accessed form sub to main or sub to other sub for example are you making an array of those variables and splitting or bringing it in as separate...

How to use shared variables to address multiple Watlow controllers on the same COM port

Hello,
I am trying to use LabVIEW 2010 to control 4 Watlow temperature controllers on one COM port. 3 are Model 96 and 1 is an EZ zone controller. Each controller has a unique modbus address, and I am trying to read from and write to individual registers (such as closed loop setpoint) using shared variables. I am getting return data when reading (although the data appears to be invalid), but am unable to change the value in the register by writing. How can I be sure that the Modbus server is sending commands to the correct controller?
Chuck
Solved!
Go to Solution.

Peter,
Thanks for the reply. I have actually solved that problem. I realized that the Modbus server address has to be the same as the controller's Modbus address.
I have, however, run into another problem. Perhaps you could help me with that. I have a system with 4 Watlow controllers, 3 are series 96 controllers, one is PID only and 2 are ramping. The 4th controller is an EZ zone. I am using RS485 for communications and the controllers are all wired in parallel for communications and power.
I have set up 2 Modbus servers for 2 of the controllers.
This is the first I have ever worked with Modbus based communications. I have successfully programmed using the Modbus read/write VIs, and am wanting to move to shared variables. My questions right now revolve around addressing, Modbus I/O servers and COM ports. Specifically, at this point, I know the addresses need to match up between the server and the slave device (Watlow controller in my case), how many servers can I create and use on one COM port? If the number is limited, is there a way I can specify an address that I want the server to talk to? Will the broadcast mode work to request data values from the controllers?
I'd appreciate any information you can help me with, or if you could point me to some sort of concise 'How-To' for Modbus communication.
Thanks.
Chuck

How to add a new Shared Variable programmatically to an existing and deployed library?

Hi there!
I am trying to accomplish this on both LabVIEW 8.6 and LabVIEW 2010 and seems like it's not any different in this situation.
My case: A project has a library with 4 Shared Variables (SVs). The library and the variables are deployed (visible in Distributed System Manager 8.6/2010). I want to add 2 more variables into this library. It is possible to do this manually from Project Explorer window's options menu. But while running an application it has to be done programmatically. Can I provide the library reference to the one currently existing without creating a new one?
"Create Or Add Library To Project" function in the Datalogging and Supervisory Control (DSC) toolkit does not help in this case. That function, as the name suggests, just tries to create a new library in the project.
Two possible methods:
The function "Add Shared Variable To Library" (DSC>EngineControl>Libraries & Processes) needs a library reference, which could be provided via "CreateOrAddLibraryToProject" function, but this function tries to create a new library, and if I provide the path of the existing library it throws an exception that the library already exists in the project (yes, as I wrote above, I need to add new variables to an existing and deployed library).
OR
The function "Create Shared Variable" (DSC>EngineControl>Variables & I/O Servers) will add Shared Variable in a process, and not physically in a library file, and the problem (limitation) with this approach is that it doesn't allow to add complex data type Shared Variables (for example in LabVIEW 8.6 it has only 4 datatype options in input parameter, and even in LV2010 it does not have "Image" datatype that I need).
The scond method is my preferred method as it allows to work on Online Shared Variables and doesn't create them physically in libraries (and this is good as the variables' scope remains only till the Variable Engine is running). But it doesn't support advanced data types, and the first method is powerful in terms that it supports to virtually any datatype, it just seems tricky to get that reference to the library.
Any tips?
Thanks ahead!
Vaibhav

<<<<>>>>
As the above two images show, while a library does not exist, it is easy to use the "CreateOrAddLibraryToProject.vi" which will add a new library to the project (if it doesn't exist on file system, a new library will be created) and that way, using the reference (the green wire going out from the function and the Case Structure, can be used to add Shared Variables to the library. The problem was what to do when a library already exists in the project, how to add more variables to it. I was looking for a way to get a library reference, and somehow I could not see it inside a Project's property (VI Server functions). Hence I posted the question. And upon continuing my search, I found it on the Application's property list.
I hope it was useful for someone else as well. And thanks for the replies. Please share a better idea if you have.
Vaibhav

Peculiar behavior of Shared Variable RT FIFO

I'm trying to "leverage" the enhanced TCP/IP and Shared Variable properties of LabView 8.5. My application involves (among other things) doing continuous sampling (16 channels, 1KHz/channel) using 6-year-old PXIs (Pentium III) and streaming data to the host. I developed a small test routine that was more than capable of handling this data rate, even when I had the host put a 20msec wait between attending to the PXI (to simulate other processing on the host). To do this, I enabled the "RT FIFO" property of the Shared Variable (which was an array of 16 I16 integers) and specified a buffer size of 50 (that's 50 arrays). Key to making this work was figuring out the "error codes" associated with the SV RT FIFO, particularly the one that says the FIFO is empty (so don't save the "non-data" that is present).
Flush with success, I started developing a more realistic routine that involves rather more traffic between Host and Remote, including the passing back and forth of "event" data. These include, among other things, "state variables" to enable both host and remote to run state machines that stay "in sync"; in addition, the PXI also acquires digital data (button pushes, etc.) which are other "events" to be sent to the Host and streamed to disk. I developed the dual state-machine model without including the "analog data" machine, just to get the design of the Host/Remote system down and deal with exchanging digital data through other Shared Variables. Along the way, I decided to make these also use an RT FIFO, as I didn't want to "miss" any data. One problem I had noticed when using Shared Variables is the difficulty of telling "is this new?", i.e. is the variable present one that has been already read (and processed) or something that needs processing. I ended up adopting something of a kludge for the events by including an incrementing "event ID" that could be tested to see if it was "new".
Today, I put the two routines together by adding the "generate 16-channels of integer data at 1 KHz and send it to the Host via the Shared Variable" code to my existing Host/Remote state machine. I used exactly the same logic I'd previously employed to monitor the RT FIFO associated with this Shared Variable (basically, the Host reads the SV, then looks at the error code -- a value of -2220 means "Shared Variable FIFO Read Buffer Empty", so the value you just read is an "old" value, so throw it away). Very sad -- my code threw EVERYTHING away! No matter how slowly the Host ran, the indicator always said that the Shared Variable FIFO Read Buffer was empty! This wasn't true -- if I ignored the flag, and saved anyway, I saw reasonable-looking data (I was generating a sinusoid, and I saw numbers going up and down). The trouble was that I read many more points than were actually generated, since I read the same values multiple times!
Looking at the code, the error line coming into the Shared Variable (before it was read) was -2220, and it remained so after it was read. How could this be? One possibility is that my other Shared Variables were mucking up the error line, but I would have thought that the SV Engine handling reading my "analog data" SV would have set the error line appropriately for my variable. On a hunch, I turned of the RT FIFO on the two Event shared variables, and wouldn't you know, this more-or-less fixed it!
But why? What is the point of having a shared variable "attached" to an error line and having it return "Shared Variable FIFO Read Buffer Empty" if it doesn't apply to its own Read Buffer? This seems to me to be a very serious bug that renders this extremely useful feature almost worthless (certainly mega-frustrating). The beauty of the new Shared Variable structure and the new code in Version 8.5 is that it does seem to allow better and faster communication in real-time using TCP/IP, so we can devote the PXI to "real-time" chores (data acquisition, perhaps stimulus generation) and let the PC handle data streaming, displays, controls, etc.
Has anyone been successful in developing a data-streaming application using shared variables between a PXI and and PC, particularly one with multiple real-time streams (such as mine, where I have an analog stream from the PXI at 16 * 1KHz, a digital stream from the PXI at irregular intervalus, but possibly up to 300 Hz, and "control" information going between PC and PXI to keep them in step)? Note that I'm attempting to "modernize" some Version 7 code that (in the absence of a good communication mechanism) is something of a nightmare, with data being kept in PXI memory, written on occasion to the PXI hard drive (!), and then eventually being written up to the PC; in addition, because the data "stayed" on the PXI, we split the signal and ran a second A/D board in the PC just so we could "see" the signal and create a display. How much better to get the PXI to send the data to the PC, which can sock it away and take samples from the data stream to display as they fly by on their way to the hard drive!
But I need to get Shared Variables (or something similar) working more "understandably" first ...
Bob Schor

Bob,
The error lines passed into and out of functions are just just clusters with a status boolean, an error code, and an error string, and are not "attached" to a particular function as you describe in your post. Most functions have an error in input and an error out output, and most functions will simply do nothing except pass through the error cluster if the error in status is True (to verify this for yourself, double click on a function such as a DAQmx Read or Write and look at the block diagram. If there is an error passed in, no read/write occurs). This helps prevent unwanted code from executing when an error does arise in your program. By wiring the error cluster from your other shared variables to your analog data variable, you're essentially telling LabVIEW that these functions are related and that your analog data variable depends requires that the other shared variables are functioning properly. The error wire is a great way to enforce the flow of your program, but you must always consider how it will affect other functions if an error does arise.
Anyways, it's great that you have things more or less working at the moment. Keep us all updated!

CRIO and ni 9234 modules not working or communicating through fpga with accelerometers, fpga connected to real time application which is also connected to shared variables linked to modbus slave

Hi,
I have a compact rio which has a 4 way chassis attached to that chassis is three ni9234 modules they are linked using fpga to a real time application then using shared variables in the low speed loop that are linked to a modbus slave to communicate with dcs, the ni 9234's have accelerometers connected to them with iepe ac coupled option on the c modules, my problem is the real time application seems to be running okay even when power loss occurs it restarts with no problem and the fpga writes to the portable hard drive bin files fine but without a accelerometer connected I get low noise readings as soon as I connect a accelerometer to any one of the 10 outputs it just goes to a fixed number (0.03125) as soon as disconnect it again it reverts back to reading noise, I have run a scan on the modules and only get a spike when I connect or disconnect the accelerometer, I have tested the voltage at the pins of the module and I get 22 volts dc which makes it more likely that the hardware is not the problem but a software is maybe causing this to hang-up, I attach project and files for your perusal. I also carried out a new project which in scan mode directly linked the module input to shared variable and the same scenerio again. Help would be much appretiated.
Many thanks
Jason
Solved!
Go to Solution.
Attachments:
logger 2plusmodbus2.zip ‏679 KB

Whren using waveform acquisition with the 9234s we recommend the following FPGA and RT template.
http://sine.ni.com/nips/cds/view/p/lang/en/nid/209114
it can be extended as a data logger with:
http://zone.ni.com/devzone/cda/epd/p/id/6388
or using shared variables combined with scan engine
http://zone.ni.com/devzone/cda/tut/p/id/9851
The FPGA in all of these, as well as the RT framework have been used successfully by 1000s of users. I would recommend giving these a try.
Preston Johnson
Principal Sales Engineer
Condition Monitoring Systems
Vibration Analyst III - www.vibinst.org, www.mobiusinstitute.com
National Instruments
[email protected]
www.ni.com/mcm
www.ni.com/soundandvibration
www.ni.com/biganalogdata
512-683-5444

My project writes accelerometer data to usb drive but shared variables do not communicate with modbus

Hi there,
I have got a program that reads input from 3 off 9234 modules on a cRIO, the idea of the program is to read this data and save it in a bin file to a connected usb hard drive, the program also uses shared variables to connect the max signals from the 9234 then send thm to a modbus slave, my problem is that althought I am now getting the correct data on the usb drive I am not getting anything down the modbus link, I attach the program for you to see, all the shared variables are on the rt low speed loop, any help would be most grateful.
Many thanks
Jason
Solved!
Go to Solution.
Attachments:
logger 2plusmodbus2.zip ‏679 KB

Hi Jasonh,
Thanks for posting your code! Due to the lack of comments on the code, would it be possible to direct me to where it sends the code to the modbus slave please?
This tutorial on How to turn a RT Target into a Modbus Slave using IO Servers may also be of some help.
Kind regards,
Tori
Student

Slow performance to read/write shared variables programatically

We are using datasocket read and write functions to read and write shared variables programatically (in the same machine) but we only achieve a performance of aprox. 200 reads/writes per second. We are using Labview 8.6 with DSC.
Is possible to get better results? That performance is normal?
Any help would be appreciated. Thank you in advance.

Hi MMCDAT,
I think this value can
be normal as you can see in this link:
http://zone.ni.com/devzone/cda/tut/p/id/5037
As you can see, the
limit for datasocket depends on your Ethernet limitations, even if you as using
it just in one PC:
http://digital.ni.com/public.nsf/websearch/6AC9E65734E53F9A8625672400637ECC?OpenDocument
You can improve the
performance changing the update mode or Vis configurations:
http://digital.ni.com/public.nsf/allkb/F8F7DE98856B50588625672400648045?OpenDocument
http://digital.ni.com/public.nsf/allkb/2D9C6D73A160537986256B290076456E?OpenDocument

Shared Variables - Properties

Hello,
I have a couple of questions about properties of Shared Variables (SV). They can be configured either by using the dialog box (right-click on SV -> Properties), or programmatically via the "SharedVariableIO" property node. Have a look at the NI-Examples to see how SV can be created programmatically by using the DSC module.
1) The dialog box offers a property "Variable Type" which can be "Network-published", "Single-Process" or "Time-Triggered". The "SharedVariableIO" property node gives no access to this property. Does anybody know why? The same question can be rephrased: How can I create a "Single-Process" SV programmatically?
2) The "SharedVariableIO" property node has two items, "Network.OnScan" and "Network.ConnectionType", which have no direct correspondance to any of the properties available in the dialog box. What is the exact meaning of those properties? The on-line help isn't of much use here...
3) Mutliple SV can be edited by using the Multiple Variable Editor (Tools->Shared Varaible->Multiple Variable Editor). A cool feature is the import/export of CSV-files. I am interested in programmatically creating SVs from the information stored in such a CSV-file. Reading the file is no problem, but connecting the file entries to the properties of the "SharedVariableIO" property node would be quite some job. In principle NI has already solved that within the Multiple Variable Editor. I guess there is a bunch of VIs somewhere below "....Program Files/NI/.../vi.lib that do exactly this thing. Does anybody know, if these (which ones?) are available for public use?
Regards,
Dietrich

dietrich wrote:
1) The dialog box offers a property "Variable Type" which can be "Network-published", "Single-Process" or "Time-Triggered". The "SharedVariableIO" property node gives no access to this property. Does anybody know why? The same question can be rephrased: How can I create a "Single-Process" SV programmatically?
You can't. The single-process shared variable is an old style LabVIEW global placed under the shared variable abstraction. There is currently no way to create those on the fly. Time-triggered also cannot be created programmatically. I confess I don't know enough about them to know the reason why.
dietrich wrote:
2) The "SharedVariableIO" property node has two items, "Network.OnScan" and "Network.ConnectionType", which have no direct correspondance to any of the properties available in the dialog box. What is the exact meaning of those properties? The on-line help isn't of much use here...
Network.On Scan = read/write hardware? - this allows you to programmatically control when you are reading from or writing to configured hardware.
Network.ConnectionType = connect to hardware even when no one is viewing me? - this has 2 choices, UpFront & OnDemand, UpFront means that the variable will be connected to hardware even when no one is connected to the variable. This is useful when you want to reserve hardware or when logging is enabled. OnDemand means that you disconnect from hardware whenever no one is reading the variable.
dietrich wrote:
3) Mutliple SV can be edited by using the Multiple Variable Editor (Tools->Shared Varaible->Multiple Variable Editor). A cool feature is the import/export of CSV-files. I am interested in programmatically creating SVs from the information stored in such a CSV-file. Reading the file is no problem, but connecting the file entries to the properties of the "SharedVariableIO" property node would be quite some job. In principle NI has already solved that within the Multiple Variable Editor. I guess there is a bunch of VIs somewhere below "....Program Files/NI/.../vi.lib that do exactly this thing. Does anybody know, if these (which ones?) are available for public use?
I would advise against using any of these. National Instruments can change, or remove, those underlying files at any time as a result of modifications to the MVE. That could cause issues for any code using those sub-VIs.
Regards,
Robert

Shared Variable Help

Similar Messages

Maybe you are looking for