Shared variable among PXI consoles

I am having trouble using shared varibles via binding with two PXI-RT consoles. When I host a network variable on one PXI console and bind an object to that variable on the other PXI console, I am getting no connection. However, when I use a regular PC and bind to the shared variable, I get a valid connection...
Does anybody know why I am unable to get a connection between PXI to PXI, but it works when I do PC to PXI?
Thanks
altran

Hi Altran,
Have you ensured that the Shared Variable Engine is installed on both PXI systems? Also make sure that you don't have the shared variable binded to anything from the PXI that is hosting the variables.
Do you receive an error code when trying to connect?
Sappster

Similar Messages

Sharing variables among frames

I have a single package that has 4 separate class files:
* a base class (happens to be an applet)
* 3 frame classes
Can I create and instantiate a class variable in the base class and access it from any of the frame classes? How?
Currently I'm redundantly using separate objects in each frame class, which is obviously wasteful and slower performing.
Thanks.

I agree with jmccon: the simpliest (and most efficient) way to do this should be to create an interface, and use this interface to communicate. Create a custom constructor for your frames, and pass a reference to the interface of the main class as a parameter to the frame.
I.e:        public class MainClass implements CustomInterface {
          frame1 = new CustomFrame(this, ...);
          frame2 = new CustomFrame(this, ...);
          //... and so on...
          public void sharedMethod() {
             //Here is your shared code: of course, you can implement
             //getters/setters methods to access the MainClass members
             //or put members in the interface for a direct access.
       public class CustomFrame extends JFrame {
          private CustomInterface parent;
          public CustomFrame(CustomInterface parent) {
             this.parent = parent;
          //When you want to use the parent's interface
          parent.sharedMember = new Object(); // for example...
          parent.sharedMethod();               // for example...
       public interface CustomInterface {
          //You can put shared members...
          public Object sharedMember;
          //...and shared methods here!
          public void sharedMethod();
       }Hope this helped,
regards.

Sharing variable among different file

How to set value to a variable from different file.I can not use interface because interface make everything as final.Is there any other way to set number of variables from more than one file?

I guess you want to declare the variable in one class and change the value of the variable in another class. If I am correct, try the following
public class First {
        public int a = 10;
//TODO
public class Second {
     private First firstObject = null;
     public void changeValue() {
           if(firstObject == null) {
               firstObject = new First();
               firstObject.a = 30;
}

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.

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!

Replace local shared variables

Hi,
I have a bunch of VIs in PXI RT target. There are about 300+ local shared variables distributed among these VIs. What I'd like to do is to change all these VIs target to PC instead of RT and debug and test these VIs logic in my PC. The reason that sometimes I could not use RT target for debugging purpose is because it is used to test the other program. The problem I have is that my local shared variables library is set up under RT target, how could I transfer the shared variable library to my PC. Even there is a way to transfer the library to my PC, It is hard to monitor and change the value of these local shared variables. I am thinking setting up a global variable VI in my PC and replace all these local shared variables with global variables. In that case, it is easy for me to control and read the variable value from global variable VI. My question is whether there is an easy way or tool to replace these local shared variables with global varaibles, and after I finish debugging VIs in my PC I could replace them back.
Jason

Hi,
All of the files you deploy to your RT system are stored on your host PC. If you want to run some of the VIs on the host PC instead of the RT target, all you should have to do is move them to your PC in your project or create a new project and add the files and libraries you want to use. If you want an easy way to monitor the values of shared variables you can use the shared variable manager available under the tools menu in LabVIEW. Unfortunately there is not a utility to convert local shared variables to global shared variables.
Eric A.
National Instruments
Distributed I/O Product Support Engineer

CFP-1808 shared variables timestamp

Hi,
I need to control and acquire data from a cFP Ethernet module (cFP-1808) to a PXI RT system. I have tested two ways of doing it:
1. Bind shared variables to the Fieldpoint channels. Works great except for the fact that I have to record the timestamp of every single channel in all Fieldpoint modules. I have to avoid this. The reason I have to record all timestamps is that sometimes two consecutive reads are the same in value and in timestamp; so even if I make sure I get a value every 100ms in my real time application I cannot trust that the shared variable engine will give a real new value every 100ms, because sometimes one read is the same as the previous one. My
understanding of the technology is that the cFP network interface checks for an
updated value of the channels of each module at the Advise Rate. If there’s a
new value the cFP transmits it to the Shared Variable Engine running in the PXI
controller, but if the value has not changed it doesn’t transmit anything, so
more efficiency is achieved in the network communication. This would explain the
timestamp behavior of the shared variables bound directly to Fieldpoint
channels; since there is no new value the shared variable is not updated so the
timestamp of two consecutive reads is the same.
2. Create a Modbus server and then create shared variables bound to the Modbus server channels. With this method any time my RT application asks for a new value the shared variable engine provides a real new value with an updated timestamp, and all timestamps in the same module are equivalent (in 1usec range). Therefore, it looks like using the Modbus solution I only have to record one timestamp per module.
So option 2 probably fixes my problem, but I'd like to understand why. Both methods use the shared variable engine, shouldn't they behave the same way? There's one downside in option 2, which is having to deal with Modbus addresses and not having the ease of use of option 1 that just browses to find the Fieldpoint channel.
Any comments?
A final note, it'd be great to be able to use the Fieldpoint VIs in LV Real-Time! Can this be achieved?
Raimon

Hi Raimon,
How are you binding to your shared variables? This KB reviews three methods:
http://digital.ni.com/public.nsf/allkb/FA610367EC62574186257118005089F2?OpenDocument
I don't believe using FieldPoint VIs on a PXI RT target is possible because FieldPoint is not a driver that you are able to install on the PXI RT target. We do have the cFP-2xxx line of RT controllers for FieldPoint, which can communicate directly to the FieldPoint modules, ensuring determinism.
Trey B
Applications Engineering
National Instruments

Deploy Shared Variables

I'm having an issue with using SVE. I'm using LV 8.6 (cannot upgrade to 2010 at this time, have to "make it work").
I've used shared variables before with an HMI and PXI but my setup is different now:
PXI (called my target) that "talks" to different controllers via Modbus TCP/IP. Separate PC to interface to the PXI to provide a user-interface (called my host).
I've run across posts talking about calling the Deploy Library method in the top-level VI of the application. I want the PXI to deploy the shared variables since it will be running constantly and the PC is optional. Do I "manually" transfer the shared variable library, in this case called the NetworkVars, to the PXI so the PXI application can find it? The PXI will be running independently once the program is completely developed.
I've used Labview a long time but have never had to do much with networking/sharing.
Thanks for any help.
Solved!
Go to Solution.

I still cannot figure this out, have read NUMEROUS white papers, help entries, etc. but I cannot get it to work properly.
PXI system with analog I/O, TCP/IP connections to Watlow controllers. This is where I set up NI-PSP variables, autodeploy enabled, run as startup when I transfer the program to the PXI.
Separate computer running an interface program to the PXI, the front panel controls and indicators are "bound" to the PSP variables.
I download to the PXI, reboot it, start my PC program and there is no communication. The PSP LEDs on the bound items are all green but there is nothing going back and forth, UNLESS I run the PXI program on the other development computer.
I know I'm missing something simple, just getting a little aggravated! LabVIEW 8.6, no DSC module, just the RT module.

Target VI stops before being commanded using shared variable

All,
I decided to post this in general since it deals mostly with shared variables however I am working with a RT target so feel free to move it to another forum.
I originally posted a problem I was having with the RT Module Getting Started example, regarding the 1950679023 error, and trouble shooting led me to create the simplest test project I could think of. (I know you all want a link to the VIs but my company does not allow me to access internet file sharing sites to upload data so bare with me.)
NOTE: This is NOT an RT project. Just deployed on an RT target.
In Project Explorer I have Host.vi under " My Computer " and Target.VI and 3 networked-published shared variables (call them A,B,C here for simplicity) with RT-FIFO checked, under my RT target.
Host.vi is a single while loop with a 0.5sec time delay express VI. The loop contains (along w/ the time delay) 1 numeric control wired to SV A, 1 numeric indicator wired to SV B, and finally a Stop button wired to SV C plus the conditional term (stop if True). SV A is configured as write, SV B as read, and SV C as write.
Target.vi is a single while loop with a 0.5sec time delay express VI. The loop contains (along w/ the time delay) a numeric add function wired to a constant double and SV A configured as read. Also, SV C is wired to the conditional term configured as read (stop if True). The VI adds the two numbers, one of which is controlled by the Host.vi using SV A, and sends the results to Host.vi using SV B until the Stop button is pressed on Host.vi and sent back to Target.vi using SV C.
I successfully ran this project (which included my always present 1950679023 error). Then changing no code but merely redeploying/running it again right after or through out the course of many other project deployments I get incorrect data on Host.vi. Basically sometimes it would work, sometimes it wouldn't; having changed NO code. First discovery was that Target.vi would automatically stop after running ~ 1sec since deploying/running on the target and before I could disconnect and open/run Host.vi. I then deployed/ran Target.vi with a probe on the wire between SV C and the conditional term and highlight execution running. After an average of 3 runs through the loop the SV C would automatically send out a True signal even though I never open/run Host.vi. How can shared variable C, which is write controlled by Host.vi, automatically change it's state like that when I never even open/run Host.vi?
Another interesting observation is, If I first open/run Host.vi and then deploy/run Target.vi, the program ALWAYS works. But those steps go against my limit understanding of running VIs with shared variables on a target, which I got from NI's RT Module Getting Started Guide? I am going to have a hard time developing anything useful with these shared variables if I can not get the LV RT Guide example and this simple VI working. Any help would be great.
Thanks
JD
P.S. I've noticed this error message a few times during deploying/running either the Host.vi or Target.vi. The error is not consistent; sometimes I see sometimes I don;t.:
error-2147220727 (Hex 0x80040309)
The client process cannot communicate with the configuration server process. If this problem persists please note the steps you performed that led to this error and contact technical support.
PXI-1045,PXI-8196 RT,PXI-4220 (slot 2),(2) PXI-6259 (slot 3 and 4),PXI-5152 (slot 5),PXI-2585 (slot 6),PXI-5404 (slot 7)
LV 8.2.1, RT 8.2, DAQmx 8.5, MAX 4.2, VISA 4.1,
Pharlap OS ver.12.0, PH_EXEC ver. 8.2

Thanks for the responses, (sorry this is going to be long)
- First question is how do you initialize a shared variable (SV)? I don't have the DSC module, which I know has an initial value parameter. The SV is configured as a read and doesn't have any inputs, so am I missing something on the way to initialize it? I know the boolean defaults to False, which is good for my application. Also, right clicking on the SV doesn't bring up any obvious solution? Help if I am lost. Also, all my code is inside the loop (both the RT.vi and Host.vi), nothing is outside the loop.
- I think I learned something through some trial and error. I made this test VI project even simpler by just having an incremental counter using shift registers inside the RT.vi while loop. The results of that counter are sent out, by way of a network-published SV, to the Host.vi. This network-published SV is located under the target within the Project Explorer. I temporarily got rid of the boolean SV, which was used to stop both the RT.vi and Host.vi. It was that boolean SV that gave me all the problems.
This new test VI works consistently (also as a stand alone application, which was a first for me). My thoughts are that the issues had something to do with not "completely" removing all previous run instances of the VI and associated SVs/library from the RTs memory. I think I was getting old buffer data or SV corruption when, on my first test VI, would re-run the RT.vi and have the boolean SV inexplicitly switch states from False to True, even though the write controlled instance on Host.vi wasn't even running. I now undeploy everything (and check the Variable Manager) to make sure I have a clean sheet when re-running the VI. Now that brings up a question, is undeploying the only, or proper, way to clear the RT's memory?
Anywho, I reintroduced the boolean SV into this new edition of the test project (read instance on RT.vi and write instance on Host.vi, while "hosted?" under the target in the Project Explorer) and everything works (although I still get that 1950679023 error once in a while when running for the first time). Meaning, I deploy the RT.vi then disconnect, then run the Host.vi and get valid data, then I press stop and both VI's stop. I then clear out the RT memory (I think all of it?) using undeploy and then repeat. Doing this I get consistent, valid results. If this seems like a learning experience for me please let me know, I don't want something to "work" just by accident.
- To answer the second reply: 1) all the SVs where created under the target in the Project Explorer. Also, I have not unchecked auto-deploy or tried deploying manually, but will give it a try. That brings up a great point, most of NI's data on SVs is "technical specification" like and not very in depth for something so complex. I have not been able to find any "tips/tricks" or "best practices", like trying to deploy manually. Is it because SVs are still new?? Also, a frustrating thing is that NI's step by step tutorials treat SVs like they are simple and fool proof, but following their instructions to the T I get errors. They leave out all the little nuances of correctly working with SVs and so it creates a steeper learning curve. Enough of my rant.
Thanks again for the responses and any more help to come.
JD
PXI-1045,PXI-8196 RT,PXI-4220 (slot 2),(2) PXI-6259 (slot 3 and 4),PXI-5152 (slot 5),PXI-2585 (slot 6),PXI-5404 (slot 7)
LV 8.2.1, RT 8.2, DAQmx 8.5, MAX 4.2, VISA 4.1,
Pharlap OS ver.12.0, PH_EXEC ver. 8.2

Not able to access Network Shared Variable when deployed in PC

Initially, when we deploy a Network Published Shared Variable in PC and try to access the same (Read/Write) from RT, we get an error/warning "-1950679023". But when we access the same variable from the PC, it works fine. In the distributed system manager, we can see the variable getting deployed. Also the value changes in Distributed System Manager if we write a value from PC. The attached image "Shared variable Issue.png" will give more understanding of this issue.
The other way round it works fine i.e deploying in RT side and accessing from both RT and PC is working fine.
We also see that the network adapter settings is not loading properly in MAX, if at all we install any software in RT. With no software installed, it loads properly.
The following were the steps that we tried to solve the issue.
1.Flushing the entire NI software and Re- installing again
2.Formatting the RT(PXI).
3.Removing the EtherCAT Card and testing.
4.Checked the network properties of the RT network.
5.Checked the IP/Subnet/Gateway settings.
6.Checked Firewall Settings, If Shared Variable Engine is accessible.
Attachments:
Shared variable Issue.png ‏491 KB

First Root cause needs to be identified before any actions.
I would suggest first check if you can access the shared variable hosted in PC from RT using other ways like using SVE API (Logos and PS protocols, Datasocket etc..)
Check if antivirus or firewall is playing...
Check the same experiment with some other PC if you can.
You can also try creating another Shared Variable in RT and binding the same to the PC and try to access it...
Since you have did all the reinstallations already
Best Regards,
Vijay.

Debug shared variable array

I am passing data between a PXI RT Target to a PC Host using Shared Variables. Everything passes correctly between the Host and the Target, but Shared Variables that are arrays do not pass between the Target and the Host. Single elements whether boolean, numeric, or string pass from Target to Host with no problem. I use NI Distribution Manager to examine Shared Variables. How can you find the content of a Shared Variable that is an array, without writing my own VI?

This tool doesn't give me any more information than the Dist Sys Mgr. The SVs that are working show quality "good" vs "no know value" for the SVs that are not working.
My network-published SVs are single-writer 1D arrays (U32/SGL) of varying sizes (64-1005).
When I write to the SV I get error -2147024891 with the source being \\My Computer\Lib\mySV\\xxx.xxx.xxx.xxx\Lib\mySV where xxx.xxx.xxx.xxx. is the IP address of My Computer.
When I read the SV I get warning -1950679044with the source being \\My Computer\Lib\mySV\\xxx.xxx.xxx.xxx\Lib\mySV where xxx.xxx.xxx.xxx. is the IP address of My Computer. I get this warning when I'm reading the SV either from the target or the host.
I've checked the properties pages for the SVs and I don't see how LabVIEW is interpreting the network path twice. What could be causing this?
Also, if I delete a SV from my library of SVs it still shows up in the Dist Sys Mgr until I restart LabVIEW. Why?

Network streams vs shared variables

I send data from a PXI RT System to users on different Windows computers via Shared Variable and Network Stream. The user that receives the data via Network Stream writes the data to a disk file (aka DAQ computer). The users that receive the data via Shared Variable displays it on front panels (aka Observers).
The data consists of a 1D SGL array where elements 0-3 are the timestamp, element 4 is the counter, and elements 5-1000+ are data. The timestamp is GPS time and is displayed on all computers. When I look at the timestamp on the DAQ it is slowly falling behind the current GPS time. After 4 hours it can be up to a minute behind. When I look at the timestamp on the Observers it is always displaying current GPS time. When I look at the code on the PXI System, it is always sending the current GPS time. The counter on the DAQ computer is also behind.
I am using the Read/Write Single Element Stream functions with the default read/write buffer size of 4096. The 'timed out?' output is always FALSE for both functions. No errors are generated. LabVIEW memory usage is constant during the whole time.
On the PXI RT System the Network Stream and Shared Variable are being written to inside a Timed While Loop. The users read the data within a standard While Loop. Everyone is using LabVIEW 2011.
It sounds like a buffer is slowly being filled up somewhere, but where?
Solved!
Go to Solution.

On the PXI RT System:
How often is data sent?
Are you using a “Flush Stream” function after your “Write Single Element to Stream”?
On the “DAQ Computer”:
Are you buffering the reading of the data (i.e. feeding it to a queue)?
You might try using a property node to read “Available Elements for Reading” to see if they are stacking up here.
The buffer size is another option to consider.
steve
Help the forum when you get help. Click the "Solution?" icon on the reply that answers your
question. Give "Kudos" to replies that help.

What causes the Shared Variable Engine to Crash?

All,
Some background info:
I am using the SVE and DSC so that I can log my data to Citadel using Data Sets. I converted a previous DSC 7.1 project that used the tag engine over. That app ran for over 18 months. Need to upgrade app and add features at my customer requests so we migrated to LV 8.0.1.
I have an app that crashes the Shared Variable Engine (SVE). I created a test app with a single SV and then created a control and bound it to the SV and it works every time until I launch the larger app. The main app only has 33 SV that are set when I receive TCP data from PXI RT system (not using SV on RT since the logged data is only a fraction of the total data streamed and I don't want to take apart the RT data and send the SV separately). I have bound front panels controls to the SV's. When I run, I get server connection has been closed. I verified that the SVE was running with the test app before launching the main app.
I deploy the shared variables in the application and have verified they are deployed by the Monitor Variables utility ... but it always shows "No Value" for the data fields. I have set logging to enabled for data only, set Value Deaband (%) to 0 and Value resolution to 0, Update Deadband is Disabled as is Alarming, Scaling, Initial Value and Description. Security is set to default. All of the variables are set to Double, Network-Published, Single Writer with Buffering and Bind to Source disabled.
I have verified that the SV deploy without error by clicking Deploy from the project. Autodeploy All is off but I get the same results with it On (checked).
I undeploy and kill the process when I close the application.
I have tried only using 1 or 2 of the SV in the main app but get the same results. Every once in a blue moon it will work after rebooting the PC (but not everytime). Once it dies I have tried running NI examples as well as the test app and they fail until I reboot.
The error code indicates that the SVE engine has crashed. I have changed the service settings on Windows to relaunch on 1st, 2nd and all times after but nothing restarts the SVE. After it crashes it is impossible to exit LabVIEW without it hanging or reboot the PC without pressing the hard On/Off switch.
Once it dies there is nothing that I can do to get it back alive without rebooting the PC (a real problem for a control and monitoring system).
Any ideas would be greatly appreciated
Thanks.
Randy

Randy
Sorry for the delay, I've been researching your issue and juggling a few other issues. :-) One thing we can check is the Windows Event Log which will give us some more details as to WHY the Shared Variable engine seems to be blowing up on us (Conttrol Panel -> Administrative Tools -> Event Viewer). Any details in there along the lines of Variable Engine or Tagger crashing will help us narrow down what's going on.
There's always a possibility of files not getting upgraded correctly; however there aren't many shared components between LV 7.1 and LV 8.0. The Shared Variable engine is entirely new and the installations of LabVIEW themselves don't share many files outside of the example finder and a few other small common components (things located in the appropriately named Shared folder) I keep both on my machine (in addition to 5.1, 6.1, 7.0, and 8.2) without any hiccups.
The SVE crashing I have seen in the past (and from internal bug reports) has been from buggered installs, so uninstalling and reinstalling DSC may be a good course of action. One good test to do in the middle is to see if the engine still crashes with DSC uninstalled.
Hope this helps.
--Paul Mandeltort
Automotive and Industrial Communications Product Marketing

Appear to lose connection with the Shared Variable Engine

Have been through the boards, but with no success regarding the specifics of my problem.
I am running a real-time application on a PXI-8108. The host software is taking care of user interface, etc. Information exchange is handled using Unbound Network Shared Variables (located on the host, though problems occur no matter where the variables are located). Everything deploys fine. Software runs swimmingly. I have backed off the DAQ/communication processes until the RT cores are at <10% busy. However, occassionally while running, I get a popup "Waiting for Real-Time Target xxx to respond..." If this message stays up for long enough, then the target's attempts to read the Shared Variables start erroring out with an error -1950679035. As the variables have already been deployed and used prior to this instant, I find this curious. If I filter out the error, eventually the real-time software comes back up and everything progresses as though nothing happened. However, this is a potential deal-breaker for the users who can be impatient with having to wait a few seconds for the software to respond.
Any idea what is happening? I'm not pumping huge amounts of data over the network, no threads should be starving. Kinda confused.
Dan M.

The shared variables are being used much like how a queue would, directing each loop to perform an action should the host require it. If no action is required, then the loops default to check their respective bus or DAQ.
Currently, I am running 13 timed loops (whose periods I have extended signficantly during debug to no detrimental effect of my software, but to no improvement in the issue in question):
RS-232/J1708 converter loop (50ms period)
CAN loop (50ms)
DMM loop (250ms)
Oscilloscope loop (250ms)
DAQ loop (50ms, includes 1 AI task, 4 DI tasks, and 6 CTR in tasks)
Switch loop (50ms)
RS-232 loops (50ms for the main, 1 additional loop at 1Hz)
RS-485 loops (50ms for the main, 4 additional loops at 1Hz)
Both cores appear to share the load, usually the aggregate load is under 15%. When the popup appears telling me that the host is waiting for a reply from the target, the PXI controller monitor output still updates the CPU loads, which do not show anything unusual, such as a spike or a freeze in loading. The target loading does spike up to about 30% total after the communication is reestablished, but that appears to be the software attempting to "catch up" with the events that occurred during the "black out".
The error reads like this:
Shared Variable in Main Target Application.vi
This error or warning occurred while reading the following Shared Variable:
\\My Computer\Host-Target Interface\RS-485 Messages to Target [<--insert other variables here]
\\192.168.1.122\Host-Target Interface\RS-485 Messages to Target
Unable to locate variable in the Shared Variable Engine. Deployment of this variable may have failed.
Are there any other drivers that would be starving the Shared Variable Engine? For example, if a VISA or NI-DAQmx driver goes to sleep, could it hold up the SVE? What execution system are they running under?
Thanks for your help!
Dan M.

RT Network Shared Variable and Visa Serial Instr class

Hi,
I'm using Labview 2009 SP1 with the RT module. I've had no problems creating a RT Target application and a Host PC application which are interconnected using Network Shared Variables, until I came to the COM ports fitted to the RT Target (PXI Embedded Controller and 2 x 4 port COM cards).
I can configure and use the COM ports in the RT Target application providing I use constants to define which COM port to use, i.e. VISA OPEN function accepts hardcoded "COM2" , (VISA Serial Instr class).
But I want to pass the COM Port resource name from my host application.
Is there a suitable Network Shared Variable I can create ? or how do I change the string value (COM Port name) of the VISA Serial Instr class variable in the RT Target application ?
thanks,
Gary.

Hi there Gary,
Thanks fot the post. I think I have found something that may be if use to yourself.
http://labviewwiki.org/Functional_global_variable
This is the functional global variable.
Take a look at it and let me know what you think!
Many thanks,
Liam A.
National Instruments
Applications Engineer

Shared variable among PXI consoles

Similar Messages

Maybe you are looking for