Slow update of Shared Variables on FP-2015

My application consists of a VI running on an FP-2015 which collects and transmits data from/to various I/O modules (DI-301, aI-111,Do-401 etc.) and passes this data to a Host PC using Shared Variables. It runs embedded on the FP-2015 so that it can react to certain conditions I/O conditions and implement the appropriate safety measures independently of the host pc. When I try to change some of the values of the shared variables from the host PC, it seems to take a long time for them to update on the Fieldpoint controller. For instance, if I try to change the value of a Digital Output on the DO-401 from the Host machine, it can take anywhere from 1-3 seconds before the I/O point actually toggles. I am using an Array of Booleans as the shared variable type. I am pretty sure the code is running at the correct speed at that this delay is caused by the shared variables because if I remove the shared variable and toggle the digital outs from high to low and low to high, they switch at the appropriate rates. Has anyone had any problems with using shared variable on a FP-2015? (The shared variables are hosted on the PC, not the 2015)
Also, I have seen some postings which say the FP-20xx do not have enough memory to run the shared variable server. Should I be OK if the server is running the Host pc? The link below says the shared variable engine will not work properly on the FP-2015 because it does not have enough memory but the second link below says 32mb are required (although 64 are recommended), which the FP-2015 has. Any confirmations whether the shared variables will work properly on the FP-2015. In all, I presently have 6 shared variable, each on being an array with a length of 20 elements.
http://digital.ni.com/public.nsf/allkb/6e37ac5435e44f9f862570d2005fef25
http://zone.ni.com/devzone/cda/tut/p/id/4679
Thanks
Damien

Thanks Tommy, I appreciate the advice. However, I think I will be abandoning the network-published shared variables for now. Before I left the office yesterday, I found the "communication wizard" for the Real-Time module. It allowed me to select my top-level VI and it automatically set up a communication routine to transmit all the controls and indicators from the RT target to the VI running on my host PC. It allowed me to select from multiple communication protocols (I selected TCP) and everything is working well now. I would have liked to use shared variables because they seem to be so simple to use but I do not want to waste time trying to hunt down a problem I may never fix. For now, out with the shared variables, in with TCP.
PS. I didn't change any of my code, (I was using timed loops in case you were wondering), and by changing over to TCP communication all my delay problems were solved. This reinforces my suspicion that the delays were caused by the shared variables.
Damien

Similar Messages

Slow update of shared variables on RT (cRIO) after building exe

Hi,
I've been struggling with this for the past few days. I am having a problem with slow updating of shared variables on my RT project....but only after building the application into exe's.
The application consists of an RT target (cRIO 9073) sampling inputs at a rate of 1sec. I have a host PC running the front panel that updates with the new acquired values from the cRIO. These values are communicated via shared variables.
Once the cRIO samples the inputs, it writes the values to the shared variables, and then flags the data as 'ready to be read' using a boolean shared variable flag. The hostPC polls this boolean shared variable and updates the indicators on the front panel accordingly.
Now, this worked fine during development, but as soon as I built the RT exe and host exe's, it stopped working properly and the shared variables ended up being updated very slowly, roughly 2-3sec update time.
To give you some more background:
I am running the Labview 2010 v10.0.
I am deploying the shared variable library on the RT device (as the system must work even without the hostPC). I have checked that its deploying using Distributed System Manager, as well as deploying it into the support directory on the cRIO and not the exe itself.
I have also disabled all firewalls and my antivirus, plus made sure that the IP's and subnets are correct and its DNS Server address is set to 0.0.0.0.
There are 25 shared variables all in all, but over half of those are config values only used once or twice at startup. Some are arrays, plus I dont have any buffering and none of them are configured as RT FIFO's either.
The available memory on the cRIO is about 15MB minimum.
What strikes me is that it works fine before building exe's and its not like the cRIO code is processor intensive, its idleing 95% of the time.

Thats exactly what I'm saying, it takes 2-3seconds to update the values.
I have tried taking out the polling on the PC side, and registered an event on the changing of that shared variable and that doesn't do anything to change the slow update time. Even if I stop the PC, and just monitor the shared variables in DSM it updates slowly.
I also tried utilising the "flush shared variables" vi to try to force the update....that does nothing.
I wire all the error nodes religously. Still no luck.
Its very strange, I'm not too sure whats happening here. These things should be able to update in 10ms.

Updating of shared variable

Hello There
I am using Shared variables (SV) on an RT host. The use of these variables seems to be functioning correctly. However, after certain events, which are not that frequent, I write the values in this variables to a spreadsheet.
What has happened on a number of occasions is that previous values that were stored in the SV are being written to the spreadsheet. I have been careful to employ VI to write to spreadsheet after the values are stored in the SV. I may or may not have had the file download link between the RT host and the desk top at the time of these errors.
I have independent hardware and software checking the operation of my RT controller, which was all correct, so the problem is simply related to file storage.
Can anyone help.
Thanks MAC_D

Thanks for your reply Wayne.
The shared variable is reading and writing correctly and there is no errors.
I am using these shared variables to control digital outputs, and i have verified using external hardware and software that my application preformed correctly.
The issue is that the correct values of the shared variables were not written to file correctly. Previous values were replicated.
Kindest regards

Shared variable no longer updates

All,
I have an RT Systems 2011 and have been using shared variables between the RT and Host. Working for months. Then I renamed a shared variable and it no longer updates. When I try to look at the variable in the NI Distributed System Manager, it reports that it does not exist.
I changed the name back to what it was, it is seen by the System Manager but the current value is not displayed.
I did a remote debug into the RT code and the variable is being updated.
Any ideas\comments\etc would be appreciated?
Thanks

What hardware are you using as your real-time target? When you mentioned that you are using "RT Systems 2011", are you using LabVIEW 2011 and the Real-Time Module?
After you updated the shared variable, did you re-deploy it? I highly recommend reading through the “Deployment and Hosting” section of the DeveloperZone Tutorial linked below:
http://www.ni.com/white-paper/4679/en/#toc3
Regards,
Cameron F
Applications Engineer
National Instruments

Shared Variables for Real-TIme Robot Control

I'm really stuck in my efforts to use LV real-time in my hardware control application. I have a 6-axis industrial robot arm that I must control programmatically from my PC. To do this I've developed a dynamic link library of functions for various robot control commands that I can call using Code Interface Nodes in LV (using 8.5). This has worked great, that is, until I tried to port parts of the application to a real-time controller. As it turns out, because the robot control dll is linked with and relies so heavily upon several Windows libraries, it is not compatible with use on a RT target, as verified by the the "DLL Checker" application I downloaded from the NI site. When the robot is not actually executing movements, I am constantly reading/writing analog and digital I/O from various sensors, etc.....
This seemed to suggest that I should simply segregate my robot commands from the I/O activities, using my host PC for the former, and my deterministic RT loop on the target machine for the latter. I set up a Robot Controller Server (RCS) vi running on my host PC that is continuously looking for (in a timed loop) a flag (a boolean) to initiate a robot movement command. Because several parameters are used to specify the robot movement, I created a custom control cluster (which includes the boolean variable) that I then used to make a Network Shared Variable that can be updated by either the RT target or the host PC running the RCS. I chose NOT to use buffering, and FIFO is not available with shared variables based on custom controls.
Here's sequence of events I'd like to accomplish:
1) on my host PC I deploy the RCS, which continuously pools a boolean variable in the control cluster that would indicate the robot should move. The shared variable cluster is initialized in the RBS and the timed loop begins.
2) I deploy the RT vi, which should set the boolean flag in the control cluster, then update the shared variable cluster.
3) an instance of the control cluster node in the RCS should update, thereby initiating a sequence of events in a case structure. (this happens on some occassions, but very few)
4) robot movement commands are executed, after which the boolean in the control cluster is set back to its original value.
5) the RT vi (which is polling in a loop) should see this latest change in the boolean as a loop stop condition and continue with the RT vi execution.
With the robot controller running in a timed loop, it occassionally "sees" and responds to a change of value in members of the shared variable cluster, but most times it does not. Furthermore, when the robot controller vi tries to trigger that the movement has completed by changing a boolean in the control cluster, the RT vi never sees it and does not respond.
1) Bad or inappropriate use of network shared variables?
2) a racing issue?
3) slow network?
4) should I buffer the control cluster?
5) a limitation of a custom control?
6) too many readers/writers?
7) should I change some control cluster nodes to relative, rather than absolute?
8) why can't I "compile" my RT vi into an executable?
Any help would be greatly appreciated. Unfortunately, I'm writing this from home and cannot attach vi files or pictures, but would be happy to do so at work tomorrow. I'm counting on the collective genius in the universe of LV users and veterans to save my bacon.....
David

Hi David,
I'm curious why you decided to build a CIN instead of developing the code in
LabVIEW. Is there some functionality that that LabVIEW couldn't
provide? Can you provide some more information about the LabVIEW
Real-Time target you're using? What type of IO are you using?
It is impossible to get LabVIEW Real-Time performance on a desktop PC running
an OS other than LabVIEW Real-Time. Even running a timed loop in LabVIEW
for Windows won't guarantee a jitter free application. Also, no TCP based
network communication can be deterministic. This means Network Shared
Variables are also not deterministic (they use a TCP for data transport) and I
advise against using them as a means to send time critical control data between
a Windows host and a LabVIEW Real-Time application.
In general, I would architect most LabVIEW-based control applications as
follows:
- Write all control logic and IO operations in LabVIEW Real-Time. The
LabVIEW Real-Time application would accept set points and/or commands from the
'host' (desktop PC). The Real-Time controller should be capable of
running independently or automatically shutting down safely if communication to
the PC is lost.
- Write a front-end user interface in LabVIEW that runs on the desktop
PC. Use Shared Variables with the RT-FIFO option enabled to send new set
points and/or commands to the LabVIEW Real-Time target.
Shared variable buffering and RT-FIFOs can be a little confusing. Granted
not all control applications are the same, but I generally recommend against
using buffering in control applications and in LabVIEW Real-Time applications
recommend using the RT-FIFO option. Here's why: Imagine you have a
Real-Time application with two timed loops. Time-loop 'A' calculates the
time critical control parameters that get written to hardware output in
timed-loop 'B'. Loop 'A' writes the outputs to a RT-FIFO enabled variable
with a RT-FIFO length of 50. Loop 'B' reads the outputs from the shared
variable, but for some reason, if loop 'B' gets behind then the shared variable
RT-FIFO will now contain several extra elements. Unless loop 'b' runs
extra fast to empty the RT-FIFO, loop 'B' will now start outputting values that
it should have output on previous cycles. The actual desired behavior is
that loop 'B' should output the most recent control settings, which means you
should turn off buffering and set the RT-FIFO length to 1.
There is also a clear distinction between buffering and the RT-FIFO
option. The RT-FIFO option is used to add a non-blocking layer between
network communication and time-critical code in LabVIEW Real-Time
applications. It also provides a safe mechanism to share data between two
loops running in a Real-Time application without introducing unnecessary
jitter. Network buffering is a feature that allows a client to receive
data change updates from the server even if the client is reading the variable
slower than the server is writing to it. In the example I presented above
you don't need to enable networking because the shared variable is used
entirely within the Real-Time application. However, it would be
appropriate to send control set points from a Windows PC to the Real-Time
application using network published shared variables with the RT-FIFO option
enabled. If it is critical that the Real-Time application executed all
commands in the sequence they were sent then you could enable an appropriate
buffer. If the control application only needs the latest set point
setting from the Windows host then you can safely disable network buffering
(but you should still enable the RT-FIFO option with a length of 1 element.)
Network buffering is especially good if the writer is 'bursty' and the reading
rate is relatively constant. In the robot application I can imagine buffering
would be useful if you wanted to send a sequence of timed movements to the
Real-Time controller using a cluster of timestamp and set point. In this
case, you may write the sequence values to the variable very quickly, but the
Real-Time controller would read the set points out as it proceeded through the movements.
The following document presents a good overview of shared variable
options: http://zone.ni.com/devzone/cda/tut/p/id/4679
-Nick
LabVIEW R&D
~~

How Can i retain the Shared Variable Values after PC rebooting

Hi all,
I am facing a paculiar problem with Shared Variables. I have an application in which shared variables are used for data communication.
One of the application requirement is to retain the variable values eventhough PC is rebooted or started after crashing.
As per the my understanding, the variable values will retain eventhough the PC is rebooted. But here i can observe a paculiar problem like some library variables are retaing the values while some others not. I enabled logging for all the variables.
I tried many ways. like logging enabled, logging disabled, changing variable names, changing process names etc... But i am not getting a consistent behaviour.
I hope some you can help me in solving this issue.. "How Can i retain the Shared Variable Values after PC rebooting"
Thanks and Regards,
Mir

Hi Blackperl,
Thanks for the post and I hope your well.
What do you mean by not getting consistent behaviour.. this will all depend on excatly when the crash happens i.e. before the write or after.
Surely a better method would be to log the data to a file during the reboot...
I beleived the value read back
will be the default value for the shared variable's data type.
The LabVIEW DSC 8.0 module adds more functionality to the shared variable, including initial values and alarms.
If you enable an initial value on a shared variable, when the variable
engine comes back on-line it will default to this value. Setting a bad
status alarm for the shared variable is also a good way of handling
this type of event. Additionally, if you are using a LabVIEW Real-Time
target such as Compact RIO or Compact FieldPoint, it is appropriate to
consider hosting the shared variable engine on the real-time target.
These devices have watch-dog capabilities and are typically the
hardware controlling the critical pieces of an application. Most
Windows or PC-based targets do not have these fail-safes.
I guess, if you could explain to me again that would be great. From my point of view, if I have a cRIO and a Windows PC. If the windows PC crashes, the cRIO will still update its shared variables. Then once the PC has started up its own shared variable engine, and the bindings are loaded, it will once again continue to update its copies of the variables.
Please let me know what you think,
Kind Regards,
James.
Kind Regards
James Hillman
Applications Engineer 2008 to 2009 National Instruments UK & Ireland
Loughborough University UK - 2006 to 2011
Remember Kudos those who help!

Deploy Shared Variable Engine in localhost

I need to talk to multiple RTs using single computer. It seems
obvious to deploy shared variable engine (libraries) in localhost instead of
RT. However, the problem is the shared variables (read) used in localhost VIs
are not being updated from RTs. But when I am using another local VI to update
the shared variable, it is working just fine. The variable path of the RT looks
like "\\My Computer\Local NPSVlvlib\Test
Data". I think this is the problem why the values are not being updated
because RT cannot resolve the network path ("\\My
Computer\Local NPSVlvlib\Test Data"). Also, I tried to change the shared
variable path in RT but I could not do it. Help Needed!!!!
Solved!
Go to Solution.

Thanks for your reply. I found in this link http://zone.ni.com/devzone/cda/tut/p/id/9900#toc2 that host computer can host the shared variable library and RT does not need the shared variable engine. See below
If your application includes a single host computer and a single or multiple RT targets it is recommended to host the library on the host computer. This will save memory and processor time on the RT targets. Also, by hosting the library on the host computer instead of the RT target, you can reduce the software install footprint on the RT target. The RT target will not need the Network Variable Engine, but will still require Variable Client Support. The Network Variable Engine allows hosting, the Client allows communicating with libraries on other machines. You can see a RIO target with these installed in Figure 4.
That exactly what I am trying to do. Any comments?

Shared variable engine memory problem

Hello,
I have a lot of problems with DSC 8. The server that worked very well in DSC 7, in DSC 8 is creating a lot of problems starting with memory leaks in tagsrv process. I have over 5000 shared variables and when I publish them the tagsrv is around 90Mb of memory. After approx. 30 min is around 130Mb and so on until the computer becomes useless. If I restart the computer the process is the same, even if I don't start the VI that updates the shared variables. I tried to uncheck different things in the variables definition like: no alarming, no buffering, no scaling, with no improvement.
Is there a way to undeploy the shared variables or processes manually, not from the labview project, or Variable Manager. To undeploy the mentioned library with the Variable Manager takes more that an hour (just to enumerate all the shared variables).
Any suggestion is welcomed,
cosmin

cosmin,
I have several thoughts for you. First, I recommend
splitting up
your 5000 variable library into a set of smaller libraries. In
contrast
with the LabVIEW DSC 7 engine, the LabVIEW 8 Shared Variable Engine is
optimized for multiple smaller libraries. I would recommend
having at
most about 1000 variables per library. You'll see some different
recommendations from different people at NI, but in my personal
experience I
think 1000 is about as many Shared Variables that can be easily managed
at
once. For your case this would mean having 1000 variables in 5
different
libraries. --Splitting up your library gives you the added
benefit of being able to
undeploy/disable individual libraries without affecting the other
libraries. Unfortunately, the SCF migration tool will not do this
for you manually so it may take a little time to get everything
organized.
Your comment about ever-increasing memory usage is
concerning. Do
you see this while deploying your library, or while writing
values? If
you write to values very fast (like in an untimed loop) for an extended
period
of time memory usage will increase as the variable buffers
increase.
Please elaborate more on this topic and let me know what happens if you
separate your variables into multiple libraries. I was not able
to reproduce this on a similarly spec'd computer using 10 libraries of
500 variables each.
You can programmatically undeploy libraries using the delete process VI
on the DSC Engine Control palette in LabVIEW. Use this VI in combination
with the get process list VI to quickly remove all currently deployed
libraries.
Also, regarding your question about why variables sometimes show up the
Published Variable Monitor window; the different utilities you described may
use different methods to get that variable list. These methods behave
differently depending on how stressed the Shared Variable Engine is. If
you're in the middle of loading a library with 5000 variables I'm not surprised
that the list won't get populated immediately in the Published Variable Monitor
window. After the library successfully loads though, you should be able
to refresh the view and see all the variables.
Regards,
Nick F
LabVIEW R&D
~~

Can a shared variable be forced like an IO variable?

Forcing an IO variable is supported. However, what if I want to force the value of a shared variable?

You cannot just force the value of the shared variable if it's being constantly updated from somewhere else. What you can do is to create an application that updates the shared variable with a value constantly. That way, you can get close to the behavior of forcing the value on the variable. Doesn't help answer the question, but could be used as a way around it.
Adnan Zafar
Certified LabVIEW Architect
Coleman Technologies

RT target slows down after updating with a shared variable

I am using a shared variable that is defined in the RT target (cFP-2110) to transfer data from the host PC. The shared variable is a cluster of scaling parameters that needs to be stored in the RT target. The host PC is only connected temporarily for system setup and calibration.
There is only one instance of the shared variable in both the host PC vi and the target vi. The shared variable in the host is located in an event case that is activated when there is a value change. Everything works great until I make a value change in the shared variable. The target vi promptly slows from 30mSec to about 500 mSec and stays that way. The only way I can get the RT target to run full speed again is to recycle power or reset it.
What am I doing wrong?
Temporarily slowing down the RT target when the shared variable is updated is not a problem for this application. The problem is that I have to restart the target to get it running at full speed again.
I’m using Win-XP, LV 8.5.1 and FieldPoint 6.0.1
Thanks,
Dave J.

Hi Mark,
The host is sending the shared variable via an event case. When the event is activated, the data is sent to the target and it functions as expected, except that it slows down to a crawl. I have to restart the target to get it working up to speed again. The are no error codes.
The shared variable is a cluster of several items and it is attached.
In the mean time to promote the project, I split up the cluster into smaller clusters to use several shared variables and now I do not have a slow down problem. In other words, it works great. As an experiment I have sent the several small clusters at one time and I get the slow-down problem again.
I've come to the conclusion that large single cluster (which is attached) is too much to send at one time.
Please advise if there is something else to learn or understand.
Thanks,
Dave J.
Attachments:
Host Data In.ctl ‏33 KB

Front Panel binding of shared variables very slow initialization / start

Hello @ all,
I am using a server running Windows2000 and LV 8 DSC RTS for datalogging. All shared variables are deployed on that server.
I am now facing the problem, that all front panels running on the clients using the network shared variables on the server take very long to sync on startup. First the flags on the controls bind to the shared variables turn red, after up to ten minutes they start to turn green. The panels use up to 40 controls bind to the shared variables.
All firewalls are turned off. I tried to connect the client to the same switch the server is connected to. Same problem. Does anybody have a clue?
Thx for your quick answers.
Carsten

While I can't offer any solution to your problem, I am having a similar issue running LV8.0 and shared variables on my block diagram (no DSC installed).
When using network published shared variables, it takes anywhere from 30 sec to 4 min from the vi start for any updates to be seen. Given enough time, they will all update normally, however this 4 minute time lag is somewhat troublesome.
I have confirmed the issue to be present when running the shared variable engine on windows and RT platforms, with exactly the same results.
In my case, the worst offenders are a couple of double precision arrays (4 elements each). They will normally exhibit similar "spurty" behavior on startup, and eventually work their way up to continuous and normal update rates. Interestingly enough there are no errors generated by the shared variables on the block diagram.

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 update in QuickClient but not in Variable Manager

Greetings,
I am using LV 8.6 Developer with the DSC module installed. Also, I'm using WinXP Service Pack 3.
I am trying to create a VI that will interact with an OPC server connected to some equipment.
I've created shared variables to read the value of tags in my OPC server exactly according to the instructions on this page:
http://zone.ni.com/devzone/cda/tut/p/id/6346
For some reason though, the value of the shared value never updates to reflect the value on the server.
When I follow the tag on the OPC QuickClient, it updates just fine, but somehow the value of the shared variable isn't updating.
I also tried retreiving this data using the DataSocket method in the "Multiple OPC Items Monitor.vi" example, but running that VI crashes LabView every time.
Also, I can create a shared variable and write to tags using a VI, but I can't read them.
It seems like I'm *this* close to getting the shared variables to work. Any suggestions?

Hi Rob,
To answer your questions...
DataSocket: NI doesn't give me the option to investigate the error when I restart the program. I did a search for .cpp files, but none turned up. I did collect the error report that Windows generates, and I attached it. I'm not sure if that would be something useful or not.
SharedVariables: I went to use the Distributed System Manager to take a look at the variables. For both my shared variable as well as the tags on the I/O data source, the data type is listed as "advanced" and the quality is "unknown bad." I collected the logs from the I/O server and attached them. Oddly, when I look through there, I see some Quality=BAD and some VT_ILLEGAL flags. The deadband is set to zero, and the update rate is 1,000ms.
Also, I've configured the DCOM and Local Security Policy settings as described in numerous support articles, and my Windows Firewall is turned off. The OPC server and LabView reside on the same computer.
I suppose the confusing thing is why the QuickClient works fine, but the SVE doesn't.
I've tried this on three different computers with the same results in all cases. Currently, LV and the OPC server is the only software installed on any machine. The only other OPC server I have access to is the LV server, and it seems to work okay.
Thanks,
Wes
Attachments:
a793_appcompat.txt ‏133 KB
screen.JPG ‏105 KB
OPC I-O Server Diagnostic Information.txt ‏69 KB

SLOW PERFORMANCE OF SHARED VARIABLES

Hello,
We have developed application in LabVIEW 8.6.1 for testing mechanical equipments using cRIO 9074 (Real Time controller).
In this application we have used shared variables (Network published) for communications between Real Time controller and Host PC. All shared variables are deployed on Host PC.
Now we want to access the same application(Host PC application) from Tablet PC through wi-fi connectivity.
We have created two seperate .exe to run the application on Host PC and Tablet PC.Shrared variable response for Host PC .exe with RT controller is good,but when we run Tablet PC .exe then response is sluggish(slow).
In this case we create shared variables on Host PC (Network published) and tying to access it from Host PC and Tablet PC.
In our application,
1)Both Host and Tablet PC operate on Windows XP.
2)Programs on Host and Tablet PC are identical.
3)Both PC's are on same subnet.
Please provide appropriate help on this issue.
Thanks in advance....
Sachin

Have you seen this?

Shared variables not updating in exe

Hi,
I've created a project with 2 vi's, they share data via Networked Shared Variables, one vi writes while the other reads.
The data is passed between the 2 vi's whilst running in the Labview 2009 SP1 development environment, but when I create an exe, the screen values in the reader vi do not update at all.
In the build specification I've tried both including the vi's which reference the shared variables and the
option to list the shared variable libaries for deployment at run time, as methods to overcome the problem.
Please, any clues why the exe should fail to allow shared variables to pass data ?
thanks,
Gary.

Hey Gary,
I've just created a project to replicate the issue you are having and indeed when I built the application, the Shared Variables were no longer working. This is because I hadn't deployed the Shared Variables in code; which I think may be the problem that you're having at the moment. When create a Network Published Shared Variable library in LabVIEW, it auto-deploys itself for the development environment; but this is definitely not the case for when you build an executable. Instead, you must deploy the library yourself in code.
In the attached zip folder, please follow the following instructions and hopefully you'll be able to fix your VI:
Unzip the folder and extract the files.
Open up the project.
Look at the project layout. Notice the SharedVariableLibrary.lvlib and inspect the Shared_Double variable.
Look at how the Reader.vi and the Writer.vi interact with the variable.
Go into the Main.vi. See that I make an Open Application Reference VI and Invoke Node to manually deploy the library in code. You'll have to change the path to this library to match the directory structure of your own computer, so just make sure it navigates to the library in the extracted folder.
Check out the Build Specifications. I've done nothing here except ensure I only include the Main VI. Finally build the VI and run the executable.
You should see that this will give you a working Shared Variable setup. The Machine Name input for the Open Application Reference is blank because you only want to communicate with the localhost i.e. Your computer. Therefore by explicitly deploying all libraries you require, your VIs should be able to communicate effectively.
Does this solve your problem?
Alex Thomas, University of Manchester School of EEE LabVIEW Ambassador (CLAD)
Attachments:
GlobalVariableProject Folder LabVIEW 9_0SP1.zip ‏26 KB

Slow update of Shared Variables on FP-2015

Similar Messages

Maybe you are looking for