Why do Single-Process shared variables create a single variable VI in my dir.

I'm creating an application VI following the example which is created by starting a two loop Real-Time project which creates a Single-Process shared variable and a Network-Published shared variable for each variable that needs to be sent to a non-Realtime host VI. Each of the Single-Process variables shows up as a VI file with the following format: <variable library>_<variable name>.vi. The VI has one control which is the shared variable. I have a large number of variables and this creates a lot of clutter in the directory. I expected them to be rolled up into the library file. Is this expected behavior? I'm attaching a screen shot to show the behavior.
Attachments:
Shared Variables in Directory.JPG ‏383 KB

Hi davidreed10,
This is a known issue with single process variables that are saved in a
project that has the .lvproj and .lvlib files initially saved in different
locations, as is the case with Real-Time projects. This has been
previously reported to our R&D department with the ID #56580, and
is being worked on for a fix in a future release of LabVIEW.
This should be only a problem for Single-Process variables, and not
Network-Published variables, so if you want to keep your folder from
getting cluttered up, changing the variable types to Network-Published
should get you around the problem for now.
Regards,
Stephen S.
National Instruments
Applications Engineering

Similar Messages

Using a 2-D array Single Process Shared Variable w/ RT FIFO for comm between a Deterministic and non-deterministic loop on an RT Target

Our problem is that we currently use a 2D array to store CAN data on a Real-time Target. The array is 20 elements of 3 byte elements as so:
                0              1              2
0              [byte]   [byte]   [byte]
19           [byte]   [byte]   [byte]
These values are passed between a Deterministic Timed (DT) loop where they are set and a Non-Deterministic Timed (NDT) loop where they are read and passed into a Network Published Shared Variable (NPSV) for communication across the network to a Host PC. I have insrted an image for illustration, pardon the size.
Currently to pass the data between the DT and NDT loop we are using a Global Variable (GV). To improve the system we have attempted to replace these GVs with Single Process Shared Variables (SPSV) with an RT FIFO enabled.
To create the shared variable I simply right clicked the GV of interest and selected create Shared Variable Node form the drop downs. At this point LabVIEW presented me with a 2D NPSV within a new Library hosted on the RT Target. I then selected this new NPSV from the Project, changed it to a SPSV, and enabled a single element FIFO. This variable was initialized with a default value for the size described above and then used in our code for the DT to NDT communication, and conversion to a corresponding NPSV for sending to the Host.
When I went to run the code I noticed that the variable was in fact 2D, however its size was only 2 elements of three bytes each, in other words only two of the row indices were populated and the other appeared as uninitialized. in addition, this data had no resemblance to the set initilazation value. This was also how the variable was presented on the host side of the network after tranfer into a NPSV.
The peculiar part is that If I change this SPSV to a NPSV and then try to change it back, I receive an error saying the type is not supported for SPSV with an RT FIFO enabled. I have to disable the FIFO (which defeats the entire purpose) in order to successfully compile! I am unclear as to what is the bug in this case. Should I not be allowed to create the original 2D SPSV with a single element RT FIFO enabled without receiving an error? Or if this is okay how do I fix the problems associated with the variable after being allowed to create it?
I have found the following discussion in which a user states “The only limitations for custom controls is the ability to use it with RT FIFO enabled on a network-published shared variable”. Is this also true for SPSV? I have not found any documentation explicitely stating this for SPSV, though it is stated for the NPSVs.

Martin,
RT FIFOs don't support Multi-Dimensional Arrays, which would corroborate the issues you're seeing. You can break up the 2D array into 1D arrays by reshaping the array, then you'll be able to use the RT FIFO enabled variable, just set the array size to the total number of elements (20*3 = 60).
You can also pass the 2D array via pre-allocated queue, or using a Functional Global. We have a reference example for a circular buffer using Functional Globals here.

DSC - Event triggering for Single Process Shared Variables

Hello,
I understand how to set up a Value Change Notification for Network Published Shared Variables so that an event will trigger when that particular Shared Variable changes. However, I can't figure out how to do the same for Single Process Shared Variables. Is this even possible? Can someone shine a light on this, please?
Thanks in advance.
- James Pham
Solved!
Go to Solution.

VRspace4,
Hello! It is not possible to enable alarming for Single Process Shared Variables. A workaround to setup a Value Change Notification would be to create a network shared variable that reads from your Single Process Variable, but at that point in time it might be worth just replacing your variable with a networked shared variable.
Ben Sisney
FlexRIO V&V Engineer
National Instruments

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 does not work between two computers

I am using LabVIEW 8 on Windows XP computers.
1. On one computer I have created two projects, writeProject and readProject.
2. In the writeProject I have a shared variable, writeData, which is "network-published" double. In this project I have a writeData.vi which in while loop assigns a random value to the writeData variable.
3. In the readProject I have a shared variable, readData, which is "network-published" double and is bound to the writeData variable. This is on the same computer as the writeProject.
4. I run both the writeData.vi and the readData.vi and all works fine.
5. Now, I create a readProject on a diferent computer. Perform all the steps as described above and also in tools/shared variable/register computer, I have entered the IP address of the target computer on which the writeData shared variable exists.
6. Binding the readData variable fails in the following way. When I browse for the source, in the "Select Source Item" dialog, I see <IP> <Populating Node...>, where <IP> is the IP address of the source computer (on which exists the writeData shared variable). A very long time later it is still "Populating Node...". Neddless to say, this readData.vi does not work!
What am I doing wrong? Or, perhapse what else do I need to do to make it work?

Hi,
I would suggest checking out the two KnowledgeBases I have linked below for common issues with Network Shared Variables. Let me know the results. Thanks!
Troubleshooting Network-Published Shared Variables
Why Are My Network Shared Variables Taking Very Long to Initialize?
Stephanie

Changing shared variable reference modes for all nodes in application. Shortcut?

I have a large application which makes extensive use of both network-published and single-process shared variables. I want to change the reference mode of every such node in the application from absolute to target-relative. Is there any way to do this without having to open every subVI in the application and use the right-click menu on every node?
Sean

I don't know of any shortcut, but if you want to change the reference node of everything in the application you could probably script it. I was thinking something similar to what I have below where you traverse the BD of a specific VI for all SharedVariableNodes and change the relative mode to Target Relative.
Depending on how your project is organized you can add some additional functionality before the open VI reference to go through and open the reference of every VI in your project.
Matt J
Professional Googler and Kudo Addict
National Instruments

Shared Variables vs Globals

   I started a large project recently and decided to make use of Shared Variables. :I need some network communication between LV apps, so that is the main reason, but I decided to put them to the test by also using single-process Shared Variables instead of globals. (Yeah, yeah, globals are evil. blah blah blah. I'm not really interested in dogma here. Suffice it to say that, IMHO, there are still a few times and places where globals are appropriate and useful.)
   My project is fairly modular, and the main control program launches numerous other top-level programs. The problem is that whenever one of these top--level programs (or the main program) is launched, the Shared Variable deployment window pops up and does its several second initialization.; If this happened just once, when the top level program launched, it would probably be acceptable. But having each dynamic VI go through this gets annoying.
   I'm using 8.2.1. I haven't tried 8.5 much yet, but at least in 8.0 and 8.2, you can't search for Shared Variables. That is also annoying and can lead to maintenance issues.
   So now I am considering replacing all the single-process Shared Variables with good-ole Globals. A couple of the VIs in the system will still use networked Shared Variables, so they will still cause the deployment window to pop up, but it will be much less frequent. And I'll be able to search for the globals and make sure I'm using them responsibly.
   Does anyone have any other ideas on how to minimize the deployment window? Or ideas on development patterns using Shared Variables? Preferences for Shared Variables vs Globals?
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.

Ben,
   Wow, you are quick. And thanks. Good catch. Turning off the auto-deploy removes the dialog. Nice, but now I have to figure out how the SV's are going to get deployed on each installation... I haven't fully digested how SV's really work, especially how to best handle the deployment issues. This project will be installed on a number of computersand used by scientists, not LV programmers. So I need a reliable way of setting up the deployment. Perhaps it is just one more step in the installation process.. That assumes that all the SV's are defined when the program is first installed The program is very modular, so the end-user will be able to copy new modules into a certain directory and be able to use them right off the bat, no extra programming. But if a new module contained a new SV, it wouldn't be deployed...
   Any suggestions for searching? I haven't tried it yet, but it seems that deleting a SV from the project is the only way. That causes an error to occur at each instance of the SV. Assuming all the project VIs are in memory, you can then use the error finding to locate every instance of where the SV was. Of course, it isn't there anymore. Minor issue...
Graziano,
   Thanks for the ideas. I do use functional globals a lot as well. Very nice tools.
   I was really trying to transition to SV's so that I could use the Networked version. I was using Single Process SV's instead of globals just as an experiment and to potentially leverage other SV features for them in the future.
Regards,
   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.

Shared Variable Deployment not accessible in Build Specification

Hi everyone,
I have a large project developed in LV 8.6.1 from which I executed numerous applications. I converted the project in LV 11 sp1f1, everything works well in code, everything is saved.
I wanted to build executable without cod change for LV 11 here is what I found:
Build the executable with Build Specifications inherited from LV 8.6 for which I checked on Use Labview 8.x file layout in Advanced. My application programmatically deploys all internal shared variables and when I wanted to access the Shared Variable Deployment in project in Build Specification then labview locked and I have to kill LV. Other time I did not access the Shared Variable Deployment and I start building executable when it looks the build progressing similar as in LV8.6 and last step before popping the attached error all the saved files in the build location were deleted.
I set up a build specification just for this LV 11. Again I wanted to access the Shared Variable Deployment and again labview is looping something from which I had to kill labview. I opened it again, I skipped the shared variable deployment line and I build the application. Because my application programmatically deploys shared variables I included in builder the lvlib where shared variables belong. The build files does not includes this time as output the file *.lvlib for which my inherited LV8.6 code programmatic deploys shared variables.
My question is should I change the code (very large code) taking out the programmatic variables deployment and to relay on the build executable to do deploy them then what should I do with Shared Variable Deployment line in Build Specification which for my large application is not accessible or is any way to still use the shared variable as in LV8.6 but for which I need *.lvlib in build location.
Another important issue: when I launched my application built as I showed in previous second case, first thing that I see is that my application is not able to save errors (I have a log file where I save different drivers or communication errors). Any idea why application even without shared variable deployed is not able to write a text file? I am administrator of my computer with all rights.
Thank you,
Virginia

No, I am not able to close Labview because of the windows error with only one button to close application. The application is correct executed. Next time when I start this project it is asking me if I want o recover even if I accept to recover it looks what I had last time it does not save.
For my application also I am building a VI without diagram built as source distribution for which I set in my builder this top vi and I excluded everything from the project because my application copies instances at the run time of this vi as many times as hardware modules I have in the system and also I have this vi included in my application (for the content of this vi). My vi contains interfaces for hardware configuration as well as drivers functions call for each hardware module I have to control in my application. Everything is good building this vi, but in less then one minute after the build is executed and build interface closes again I have the windows error which force me to close project. Next time when I open project I did not see the option to recover the project.
In the mean time I received second message and I wonder if you refer to files names or to folder names or all together. I checked and the maximum size is 122 characters in the vi paths.
Thank you,
Virginia

Why string arrays not allow in shared variables?

I'm changing a program to replace some global variables with shared variables. The need for an executable is the reason the globals are being replaced with SV's. At least one of the variables is a 2 diminsion array of strings. Under the 'data type' drop down list on the shared variable properties there is no option for an array of strings among the 28 posibilities. Any way this can be accomplished? I'm using version 8.0
thanks, Mike

Nick, I am attempting your solution. I upgraded to 8.5, created a custom control as a 2 diminsional array and made it a shared variable. it works fine in uncompiled mode but when the programs are made executables the array info is not passed. Now I have to say I find the whole compile process with Labview pretty confusing so I'm guessing I'm doing something wrong in that procedure or I am simply misunderstanding this whole data passing concept on some fundemental level. . I have attempted several different compile property setting under the "Source Files" page. Both the write and read programs are in one project along with the custom control and the shared variable. I compile two applications using the write and read vi's as startup files and have included the custom control and the shared variable in the "always included" area. I've tried including the last two files or not including them in the compile and it makes no difference. Setting the variable as 'single process or 'network published' makes no difference either.
Attachments:
controlrw.lvproj ‏9 KB

Why should you explicitly open and close shared variable connections?

I'm looking into switching over from the old Datasocket API to the new Shared Variable API for programmatic access to shared variables, and I noticed that LV doesn't seem to have any problems executing Shared Variable Reads & Writes without first opening the connection explicitly. That is, I can just drop in a shared varaible Read VI, wire a constant to the refnum input, and it will work. I'm wondering, then, what benefits are offered by explicitly opening the conenction ahead of time...?
I guess I could see some cases where you want to open all necessary connections in an initialization state of a top-level state machine, particularly if you want to use the "Open & Verify Connection"---so you could jump straight to an error case if any connections fail. But other than that, why else might one want to explicitly open the connections.
And, along those lines, are there any problems with implicitly opening the connections? One reason why I am hesitant to open them explicitly is because for one of our applications, we need to be able to dynamically switch from one variable to another at runtime. It would be nice to just switch the variable refnum (wired to the input of the Read function), without having to manually close out the old connection and open a new one. A quick prototype of this seems to work. But am I shooting myself in the foot by doing so?
Thanks in advance.

I'd expect there's a very small number of people at NI that would know the answer to the detail you're asking for. But, let's try to extrapolate from this rather old post to see if we can understand what they're forming their impression on.
The shared variable has to have some sort of reference going on in the background. It looks like they're calling this a connection. It's how LabVIEW knows where to find this variable on the network. We can also see this reference certainly exists if we're opening/closing the reference in the explicit method. You see the connection as just a string referencing the variable by URL. This "reference" has to be stored somewhere. No matter how we're looking at this, we're aware there's a reference of some sort stored.
Now, we'd want to look at what would cause this reference to go away. If you open/close explicitly, it's easy to see it goes away at the close. If it's implicit, when would it make sense to close it out? The VI can't be expected to guess where it's done being referenced and close it out. This puts us into a situation where the soonest it could close is when the VI ends. From my experience, references tend to be wiped when you close out LabVIEW. It's this kind of idea that makes the FGV possible. I wouldn't be surprised by Morgan's claim here.
If we look at scalability, you're talking about two different topics. You're talking about adding an extra open, close, read, etc rather than just a few wires. That certainly would look a mess. In terms of the dynamic swap that was being discussed, we wouldn't be adding all of those. The concern would be if enough connections were opened it'd start to behave similar to a memory leak. This could be something that works with a smaller number of variables. If you continue to scale, it becomes problematic. This is why they suggest it's not scalable.
To your questions:
Does LV allocate some kind of session in memory using that string as a lookup?
It would HAVE to allocate some memory to hold that string. Otherwise, it'd be pointless to even have the reference.
Does it reuse that session if other parts of the application reference the same variable, or does it create a unique session for each referencing call to "Read Variable.vi"?
I would expect this to be "it depends." With the implicit method, I would expect it to open a new reference in each point it isn't wired. This is similar to int x,y = 5; x and y share the same value but are their own unique memory location. If you wire the reference to the other points, it should use the same reference. This would make more sense to me than the program seeking out any other potential usage of the variable in the application to see if there's already a reference open. I could be wrong, though.
And what resources does this "connection" actually represent?
At best, this is just the string. At worst, it's the string and the TCP socket. I'd lean towards the first. Opening and closing sockets should be relatively easy in most applications. But, it also wouldn't surprise me if it holds the socket.
I'm sure others have a better understanding than I do. But, that's what I'd expect for anything you've asked.

What is the best way to create shared variable for multiple PXI(Real-Time) to GUI PC?

What is the best way to create shared variable for multiple Real time (PXI) to GUI PC? I have 16 Nos of PXI system in network and 1 nos of GUI PC. I want to send command to all the PXI system with using single variable from GUI PC(Like Start Data acquisition, Stop data Acquisition) and I also want data from each PXI system to GUI PC display purpose. Can anybody suggest me best performance system configuration. Where to create variable?(Host PC or at individual PXI system).

Dear Ravens,
I want to control real-time application from host(Command from GUI PC to PXI).Host PC should have access to all 16 sets PXI's variable. During communication failure with PXI, Host will stop data display for particular station.
Ravens Fan wrote:
Either. For the best performance, you need to determine what that means. Is it more important for each PXI machine to have access to the shared variable, or for the host PC to have access to all 16 sets of variables? If you have slowdown or issue with the network communication, what kinds of problems would it cause for each machine?
You want to located the shared variable library on whatever machine is more critical. That is probably each PXI machine, but only you know your application.
Ravens Fan wrote:
Either. For the best performance, you need to determine what that means. Is it more important for each PXI machine to have access to the shared variable, or for the host PC to have access to all 16 sets of variables? If you have slowdown or issue with the network communication, what kinds of problems would it cause for each machine?
You want to located the shared variable library on whatever machine is more critical. That is probably each PXI machine, but only you know your application.

How to create an array containing shared variable values

Hi
I am trying to programmatically create an array containing shared variable values and their names. I can get the variable names by supplying the process name to the get shared variable list function. How do I then read the value of all the shared variable items returned?
I have used a data socket open to open a connection to all variables when my program starts. I then use datasocket read on the opened connections to write to an array. This works fine until I try to write to one of the variables using a shared variable node. The variables writes can take from 4secs to 2 mins. When I remove the shared variable node again all is fine. Also when I stop using the data sockets, all is fine.
Is there a conflict between shared variable nodes and data socket writes to the shared variables?
Can anyone help? I cannot easily post example code because I am reading the variables from a Wago PFC (PLC) using OPC.

Hi
Sorry I forgot to mention the LabVIEW version, its 8.20. I have tried saving the shared variable node as a sub VI and it makes no difference.
Attached is a stripped down version of the software. You will not be able to connect to the IO server because it requires some Wago hardware and software. You may spot something I have done wrong with the I/O servers, variables or sub VI's.
The main program that runs is called 'HMI Engine' in the 'Framework' folder. There may be some other things in the project that aren't used in this example. I have removed all but the variable connection part of the code.
I hope someone can help!?
Thanks
Mark.
Attachments:
HMI Test.zip ‏144 KB

Re: shared variable: create programmatically then read/write

I programatically create and destroy Shared Variables using these subVIs (see enclose llb file for Add Variable Connection.vi and Delete Variable Connection.vi). But it seems to take a long time to run each subVI. This might be tolerable for a single Shared Variable, but it gets rather lengthy if several need to be created or destroyed. The user specifies how many depending on how they are using the application. Is there a more efficient way of doing this?
Also, after a Share Variable is "created," it can take a while before it is usable for reading and writing in another part of the application. Is there a way to determine a Share Variable is ready prior to using Search Variable Container and Open Variable Connection functions to find and use it?

Ummm, nothing attached. Also mention, when you do post, what version so that people won't waste time downloading when they don't have the appropriate version installed.
Putnam
Certified LabVIEW Developer
Senior Test Engineer
Currently using LV 6.1-LabVIEW 2012, RT8.5
LabVIEW Champion

Creating shared variables bound to I/O Aliases

Hello,
I'm running LabVIEW 2012. When I right-click on an .lvlib in the project explorer, there's a "Create Bound Variables" option. It's really convenient, as it automatically binds many variables to generic network-published shared variables simultaneously.
However, it doesn't seem to support network-published I/O Aliases -- those libraries just don't show up in the dialog. I know that the I/O Aliases themselves work fine, because I was able to bind them manually, and then read them from my PC.
Is there a way to automate the binding process for I/O Aliases?
Thanks

Hi Joey,
It's mainly for maintainability.
I/O Variables are grouped physically by chassis and module, not by purpose. My current project is a plant controller, using 3 CompactRIO chassis (linked by EtherCAT) and 20 C-series modules. The I/O ports for a logical part of the plant can be split across different modules (and even different chassis sometimes) -- thus physical grouping is suboptimal.
Here is our simplified system architecture:
We need variables hosted on the PC server for DSC logging, but also need variables hosted on the cRIO for robustness (e.g. in case connection with the PC server is lost).
We have 2 primary reasons to create I/O Alias libraries, instead of binding directly to I/O Variables:
It lets us group the variables more logically, which in turn lets us simplify our code for programmatic variable access. It's an abstraction layer between the hardware and the code. The logical groupings also help our developers better visualize the system.
The client has not finalized their specifications, and the I/O port mappings might change. If we use I/O Aliases, we can just change the I/O Variable that the I/O Alias points to, and that's it. However, if we bind directly to I/O Variables, changing the hardware mapping will require us to change (i) the controller code, (ii) the I/O Variable that the PC variable points to, and (iii) (technically optional, but needed for readability) the I/O Variable name
Anyway, since it is possible to (manually) create bindings to I/O Aliases, I'm surprised to hear it's expected behavior that we would not see the Aliases in Project items when we use the Create Bound Variables function

Why string type shared variable takes more time to update in the client

I am using shared variables to share the data across a master and the client PCs connected in a network. (Network published & no buffering)
I have created an integer type shared variable(I32) and a string type shared variable (data size is 60 bytes) in the Master and subscribing to the same in the client PCs. In the master PC, I am modifying the data in this order - update the data in the string type variable and then update the data in the integer vaiable.
But in the client PCs, due to the size difference in the variables, I am receiving the data of the integer first and after that about 3-4 sec later only I am receiving the string data. Can any optimization be done to reduce this latency period? Instead of the string data type any better data type will reduce this delay?
Please suggst. Advnced thanks.

Latency has a lot to do with your network. 3-4 seconds is a long time though. This could also be due to the larget data size of your string. The integer data size is definitaly not 60 bytes. If you're looking for better performance, I would highly recommend looking into Datasocket communication or TCP/IP communication. (There are shipping example for both.)
When it comes to performance of throughput and efficiency, network-published variables are lower on the totem pole.
I hope this helps,
Kevin S.
Applications Engineer
National Instruments

Why do Single-Process shared variables create a single variable VI in my dir.

Similar Messages

Maybe you are looking for