Shared variable architecture for distributed crio system

I have a distributed system consisting of 20 cRIOs and one central server running Windows XP. Each cRIO is a mix and match of AI, AO, DO, DI and TC modules. There are around 200 AI and TC channels and close to 100 AO, DO and DI channels. I need to acquire data from all the AI & TC channels at 10 Samples/sec and log them in the Server. In some cRIOs I have 2 to 3 PID loops, in addition to the data acquisition or generation code. Since a cRIO chassis can have only eight modules, certain PID loops will have to use data of channels that are available in other cRIOs. cRIOs can be turned ON and will be running even without the control server, but facility and test will be started only through the control server.
We have decide to use LabVIEW DSC for this application and shared variable for data transfer, logging and alarm. We are using the following SV architecture.
1. Each cRIO will have its own RT shared variables for AI, AO, DI, DO and TC parameters
2. Each AI and AO parameter shared variable in RT will have its corresponding host shared variable which will be bound to the RT Shared variable. In host shared variable we are enabling logging and alarm option for variables corresponding AI parameters.
3. In cRIO RT, data is read from the FPGA (using FIFO every 500ms, and we get 5 Samples for each channel) in binary format and scaling is done. After scaling we are updating the corresponding AI RT shared variables using DataSocket write in a loop. In any cRIO there will be only a maximum of 32 AI or TC parameters.
4.  The server has a mimic panel where we need to display the status of DIs and allow the user to turn ON and OFF DOs. For the we decided to use Front panel DataSocket binding. 
I would like to know whether there is any better shared variable architecture that we can follow. Considering the number of variable that we are using, will the current architecture cause any performance issues?
Thanks!
"A VI inside a Class is worth hundreds in the bush"
യവന്‍ പുലിയാണു കേട്ടാ!!!

Hi Mike,
Looks like you are lucky as you can make use of the great feature available in 8.6. Over here I have 8.5.1 so got to do some of the things the 'hard' way But I must say, 8.5.1 is the so far the best version of LabVIEW I have worked after 7.1 as the crashes are less and less frequent. 
BTW I faced some problems directly dragging and dropping an RT SV node  to Windows. If the RT code is running and if you try to run the Windows code, it was asking to stop the code running in RT. That's one reason I had to duplicate some RT Shared variable in host and bind them to corresponding RT Shared variables.
This is the first time I am handling this many number of shared variables. In case I come across some issues, I will post them here.
"A VI inside a Class is worth hundreds in the bush"
യവന്‍ പുലിയാണു കേട്ടാ!!!

Similar Messages

  • Shared variables missing in distributed system manager

    I have multiple shared variables in a library (.lvlib).  These are all network-published shared variables.  I can see the library in Distributed System Manager but not the variables in the library.  When I look at the properties page in Share Variables Properties Dialog, aliasing is not enabled because the library is hosted on the same machine as the application. 
    I tried to run the Shared Variable Monitor application but was given a Runtime Error for TagMonitor.exe; "This application requested Runtime termination in an unusual way.  Contact application support team."
    I also tried undeploying and deploying the library as suggesting by KB 56PCQ3RR.
    Why does Distributed System Manager see the shared variable library but not the shared variables in it?

    Hello faustina,
    Has there been any software or hardware changes on the application since the error occurred? Also I would recommend to format and reinstall the software on your Real-Time target, after this you can follow Matt’s recommendation to test this behavior with a new project and single shared variable.
    Regards
    Jose R

  • Shared Variables stop working on cRIO-9074

       I have a Dell E5540 laptop running W7 and LV 2013.  The project talks to a cRIO-9074.  I use a handful of shared variables to communicate some of the data between the two platforms.  I have gotten this all working fine.  Then twice, something has gone wrong.  The shared variables just stop communicating.  They are hosted on the laptop.  The host program sets them just fine.  The Distributed System Manager can monitor them and sees them change.  But the RT program never gets the new values.  The RT connection is fine.  I can probe into the running RT VI, and I see that the shared variables do not get the correct values.
        The firewall is off.  I've undeployed and redeployed everything over and over.  Cycled power, rebooted, etc.
        In both cases, I finally was able to fix the issue by re-installing the entire suite of NI software on the cRIO.  After I did that, the program started up and behaved fine.  I have no idea what triggered the failure in either case.  Also, I have a second laptop that I've used to verify that the problem is with the cRIO and not with the laptop.  When things are broken, it fails with both laptops.   As soon as I reinstall the software on the cRIO, both laptops work with it fine.
        Has anyone seen this before?  Any ideas how the cRIO might be failing?  It seems like some software component on the cRIO must be getting corrupted, since the software reinstall is the only thing that fixes this.  Perhaps the cRIO is bad?  The one other possible clue I have is that during the second fix, I even went so far as to reformat the cRIO disk using MAX.  After the format worked for a while, it popped up an error saying that the format had failed.  But I was able to reconnect and reinstall the software and get things running.  I just wonder if that error code is another symptom of a bad piece of hardware...
    Thanks,
        DaveT
    David Thomson Original Code Consulting
    www.originalcode.com
    National Instruments Alliance Program Member
    Certified LabVIEW Architect
    There are 10 kinds of people: those who understand binary, and those who don't.

    Hello Dave,
    You can try to pinpoint where the problem is with some tests. First, you could try running the real-time VI on your host instead and seeing if the problem with communication still occurs. Then if this seems to work fine, try running a LabVIEW shipping example for network shared variables on the host and target. One such example is Analog Input - Getting Started - Scan Mode.lvproj from the NI RIO driver.  If this succeeds, the problem is most likely with the LabVIEW application you have. However, if it fails there is a much higher chance that there is a problem with the cRIO.
    Have a good day,
    Siana A.
    Application Engineering
    National Instruments

  • I/o server shared variable not working in deployment system ( error no-1950679034 (0x8BBB0006) (Warning))

    Hello ,
             am using shared variable from opc client in labview when am run a exe file at development system its working fine but when am running it in deployment system its not working am using same configuration file in opc server at development and deployment system error -1950679034 (0x8BBB0006) (Warning)

    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.

  • Shared Variable used for Subreport Record Selection

    I have a couple of shared variables created in the main report. But I get an error message "Shared Variable can only be used WhilePrintingRecords" when I try to incorporate them into the subreport's record selection formula. Any suggestions?
    Thanks,
    Art

    the report to capture the values should use
    whilepritingrecords;
    shared nubmervar x:= x + field;
    the one to display (your sub shared variables)
    whileprintingrecords;
    shared numbervar x;
    x

  • Shared Variable Alias vs Programmatic Assignment, which is better?

    Hello,
    I am programming an application for a cRIO platform using the scan engine in LV2009SP1.  I'd like to use the cRIO as a standalone controller, and only connect a computer to it occasionally to download data.  I decided to do this using shared variables.  So far I've been successful at doing this in two ways, both involved creating nearly identical sets of shared variables on the cRIO and on the PC, which I think (correct me if I'm wrong) I understand is the way it should be done.  The differences are the following:
    The first method was to create a parallel loop on the RT VI which would assign the values passed through the shared variables to the individual I/O channels.
    The second method was to Enable Aliasing on each shared variable and bind it to the appropriate I/O channel.
    After deploying the RT code to the cRIO for each case and running the UI on the PC, I noticed that both worked, however, the second method showed a short lag between command and feedback (~200ms or so).  The test I ran was to wire an analog output to an analog input, command the AO, and read back the value on the AI.  I can deal with the delay on the UI since it's only for reference - what I'm really interested in is the data that's logged on the cRIO controller.  My question is:  Is one of the two methods better or more appropriate than the other?  Is there something even better?
    Thanks,
    -NS

    No Substitute wrote:
    I decided to do this using shared variables.  So far I've been successful at doing this in two ways, both involved creating nearly identical sets of shared variables on the cRIO and on the PC, which I think (correct me if I'm wrong) I understand is the way it should be done.
    Hi NS,
    No correction necessary.  These are both valid ways of sharing data between your Real-Time controller and your PC.  Here's a forum that discusses some similar options to accomplish the same task (
    Shared variable architecture for distributed crio system)
    Regarding the latency issue with method 2, take a look at KnowledgeBase: Why Is Accessing IO Variables Through The Shared Variable Interface So Slow?
    I hope this helps!
    - Greg J
    Why Is Accessing IO Variables Through The Shared Variable Interface So Slow?

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

  • Are clusters or individual elements better for shared variables?

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

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

  • Deploying cRIO as Shared Variable Engine

    I am finishing up a project where a crio will be continuously recording data and the computer is running a program that will download the data once daily as well as comunicate with the program running on crio device over shared variables. Since the crio will be using a cellular modem to connect to the internet, connection loss is expected. For this reason we have made the crio serve the shared variables so that if connection is lost to the PC, the crio will continue to record data normally without problems when it writes to or reads from the shared variables.
    The crio will be running headless. I built a real-time application and deployed it as startup successfully on the crio device without warnings or errors. I connected to it via font panel to confirm it started up and is working properly. I will eventually use the application builder to build an installer that will install everything needed to run the program on the PC side. However, when I open the 'Belle Glade System PC' and run it, it attempts to deploy the shared variables on the crio device. It warns me that it will close any applications running on the crio device. This is not what I want. The shared variable engine is already deployed on the crio device and the program is running. All the PC program (Belle Glade System PC) needs to do is run and connect to the shared variable engine already deployed. I am obviously doing something really fundamentally wrong here and I could use some help. 
    [will work for kudos]

    I apologize for not posting the solution to the problem.
    Basically what you end up having to do is create two nearly identical shared variable libraries, one on the pc and one on the crio. The library on the PC has each of its shared variables binded to the corrosponding variable in the cRIO Shared Variable library by PSP URL (ip address and variable location). To do this, open the PC shared variable library and go to the properties of a specific variable. Check "Enable Aliasing" and under the bind to drop down menu select PSP URL. Then hit browse and find the variable on the crio. Do this for each of the variables on the pc.
    This option does not seem to be 100% reliable as it has trouble detecting connection problems between host PC and crio device. This is because shared variables look for a connection to the shared variable engine. However, both the pc and the crio have their own shared variable engine running as a host so there is always a connection as far as it knows, lol. This solution worked ok for me since I could not find a more relable option.
    There is a better explaination on this post: http://forums.ni.com/t5/LabVIEW/cRIO-Shared-Variables-amp-stand-alone-application/m-p/797139?query.i...
    [will work for kudos]

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

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

  • 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
    ~~

  • Serializin​g read/write operations of network-pu​blished shared variables

    Hi all,
    I'm developing a distributed application (PC + CompactRIO), and using shared variables (SVs) for inter-device communication. Here's my journey so far:
    Intended procedure
    PC parses file
    PC writes processed file data (custom cluster, large) into the 1st SV 
    PC writes a "grab data" signal/command (enum) into the 2nd SV
    cRIO polls the 2nd SV
    cRIO sees the command, then reacts by reading the 1st SV
    Steps #2 and #3 were sequenced, using error wires.
    Unexpected results
    Even after the command is transmitted and the cRIO sees it, the cRIO could not read the data (which I wrote BEFORE the command) -- LabVIEW reported that the buffer was empty.
    The operation succeeded when I placed a wait (5 seconds) between steps #2 and #3.
    Questions
    What am I doing wrong, and how do I achieve my desired outcome?
    Is SV I/O asynchronous by design?
    Is it possible to use event-driven programming to handle SV access? (i.e. does LabVIEW signal when the new SV value has propagated across the network?)

    BillMe wrote:
    Why do you have to "notify" the other end that data is available? The subscriber can simply sit in a loop doing a timed read just as if using a queue or notifier IPC. If it doesn't time out, you got new data. If it does time out, do some other processing if needed and then loop back for another timed read.
    My sytem architecture is command-driven -- the cRIO listens for instructions from the PC interface (sent as an enum via one SV), and performs tasks (motor control) in response. One of the commands (the one described in this thread) happens to be "download a new motion profile from the PC, by reading the other SV". Given that the cRIO is already polling the command channel, I felt that there's no need to also poll the data channel (especially since the "download" command is issued very infrequenty). Plus, I thought that polling two channels would increase the chances of race conditions or illegal state transitions, particularly if the app is developed over a long term.
    I am also new to LabVIEW, so my current programming style will heavily reflect my C++/Qt background while I get a feel for LabVIEW's strengths and weaknesses -- Qt is a heavily event-driven framework (even for networking!), where polling often means you're doing something wrong.
    Still, thank you for pointing out that I can use timeouts to determine if new data has arrived -- my subscriber current writes a null command back into the SV when it has consumed the command, but you showed me that I don't have to.

  • Shared Variables, Scan Engine & Multiple Targets

    I am seeking some general advice about the structure of my LabVIEW project.
    The project consists of a laptop with LabVIEW, and a joystick connected, and a CompactRIO connected via ethernet. I had been running the cRIO in FPGA Interface mode, however a change in some things caused the project to have to be shifted to scan mode.
    As of now, the code on the laptop updates shared variables on the cRIO, and reads from shared variables on the cRIO for monitoring. I want the shared variables hosted on the cRIO because it will also need to operate without the laptop connected. Before switching the cRIO to scan mode, I found that I had to first run the laptop code, and then run the cRIO code, or the shared variables would not communicate properly. Now that I have switched to scan mode, I have to run the cRIO code first, and even then the shared vars do not communicate properly for more than a few seconds, and are much laggier.
    My ideal project solution is a system that can run with or
    without the laptop connected, and obviously not having all these shared
    variable issues. I would like to autostart the code on the cRIO, and
    have the user run the laptop code if necessary, but in the past this did
    not seem to work with the shared variables.
    I am really confused about why this is happening. Hopefully I have explained my problem well enough. I don't really want to post the entire project on here, but I can email it to people if they are willing to take a look at it. Thank you for taking the time to read this.
    I am running LabVIEW 2010 SP1 with the Real-time, FPGA, DSC, and Robotics modules. I have the Feb '11 driver set and NI-RIO 3.6.0 installed and all completed updated on my RT cRIO.
    Solved!
    Go to Solution.

    I do this type of stuff all the time...
    Move all your NSV libraries to the cRIO.  From the project you must deploy to the cRIO and from then on they are persistant until you reformat.
    From your windows HMI app, you can place static NSV tags on the block diagram or use the dynamic SV API to R/W.  Also you can bind HMI controls and
    indicators directly to cRIO NSV's (This is what I do)  Also I create a 'mirror' library in the PC HMI that is bound to the cRIO library.  This library has DSC Citadel
    data logging enable and will automatically save historical traces of all my important data - very nice.  PC hosted libraries can be set to autodeploy in the app build. 
    also the project has a autodeploy option for the Development Environment which I normally turn off.  If you have PC to cRIO binding setup then you need to be cautious
    about any sort of autodeployment since it will potentially force the cRIO app to stop when you deploy.  To get around this, you can use PSP binding (IP address rather than project
    process name) and use the DSC deploy library vi's in your HMI app.  Once you are using the scan engine you can use the DSM (Distributed System Manager) app to view, proble and
    chart all of you IOV and NSV's on your network.

  • RT Shared Variable Engine stops publishing

    I have an RT system (PXI-8106) that hosts quite a few network published shared variables (NPSVs) for communicating to a Host PC. My Host and RT executables have been functioning fine on their respective systems for weeks, but just recently, I started running into problems with my NPSVs. My Host application has indicators to display DAQ data being acquired on the RT target and transferred via NPSV, and lately the application will update normally fine for several hours and then the displays will stop updating all of a sudden. If I reboot the RT target, the communication is restored...for a couple hours, anway, until we get another NPSV lockup. I can see no rhyme or reason as to why it stops updating the variables when it does; it seems to just randomly crap out.
    It just happened again, so I brought my development laptop down to run the Distributed System Manager. Sure enough, the NPSVs all stopped updating (latest timestamp was about 30 min previous to my check). I know, however, that the RT system is still running (I can open remote front panels), and none of the NPSV calls use their error input clusters, so an upstream error would not be causing the issue. Also of note, I have a couple NPSVs that are aliased to PSP URLs (NI_SystemState\CPULoad), which do continue to update while the remaining NPSVs do not. So that seems to indicate to me that it is not a networking issue, nor is it a Shared Variable Engine issue.
    I also programmatically deploy the NPSV library from the Host to the RT target on initialization, so I know they are deployed properly. Redeploying does not kickstart the RT SVE into updating. The only thing that seems to solve the problem (albeit temporarily) is a reboot of the RT target.
    Does anyone have any ideas as to what might be causing the RT to stop updating the NPSVs? I have already check the NPSV Troubleshooting KB (http://digital.ni.com/public.nsf/websearch/6E37AC5435E44F9F862570D2005FEF25?OpenDocument), and none of those suggestions appear applicable in this case (most address networking issues that result in never being able to read the NPSVs in the first place, whereas my problem is NPSV communication dropping out arbitrarily). Has anyone else run into such a problem?
    Thanks!

    I think I have an idea as to why my NPSV communication was freezing. One of my NPSVs is a 2D String Array of Alarm History Data, which just published infomation about alarms that have been triggered on the RT system; each new alarm appends a 10 element string array onto the 2D string array. For the most recent testing we were running, there was a recurring alarm condition that was not applicable (i.e. did not need to be handled--it just kept adding new elements onto the history array), and I am guessing that the array may have just gotten too big. When the RT target kept updating the NPSV (at 1 Hz) with more and more 2D String Data, it may have caused a buffer overflow for the shared variable.
    I will attempt to recreate the problem on another system to verify the cause.

Maybe you are looking for