Shared variables location

   I'm starting a fairly large project and wanted to organize it properly.  When I needed a shared variable, I first created a new library.  I was able to specify the location of this library in a sub-directory within my projects file structure.   Then I made some shared variables (single process).  After saving the project, the shared variable files appeared in the main project directory, at the same level as the .lvproj file, not in the subdirectory where the library was created.
   Any tips for orginizing shared variables?
Thanks,
    Dave
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
There are 10 kinds of people: those who understand binary, and those who don't.

   Thanks for the reply.  Unfortunately, the problem remains:
   I first create the library explicitely, before creating any variables.  I saved the library to a subdirectory.  Then I create variables.  When the variables are instantiated within a VI, at some point LabVIEW automatically creates vi files on the disk corresponding to these variables.  These VI files were placed in the main directory with the project file, not in the subdirectory where I put the library.  This is surprising to me and I would think this is a bug.
    My solution at this point was to create a "Project" subdirectory.  I put the .lvproj and the .lvlib file in that subdirectory and now the shared variable vis appear there as well.  This is a kludge.
   My main question at this point is:  can you specify where these shared variable VI's get created and stored?  I suspect that you could edit the .lvproj file or other xml files to change the share variable paths, but that is inappropriately difficult.  I tried just moving the files to where I wanted them, but then the variables don't load.  I managed to reload them, but at some point, they recreated themselves in the original location.
   At a minimum, the shared variable VIs should create themselves in the same directory as the .lvlib file that they belong to.  At least you can specify where the .lvlib file lives.
Regards,
   Dave
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
There are 10 kinds of people: those who understand binary, and those who don't.

Similar Messages

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

  • Why should you explicitly open and close shared variable connections?

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

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

  • Modbus Communication, Adding shared variables, Licenses

    Hello,  I am having trouble communicating with a third party DAQ.  I am receiving data from a thermocouple input module through a modbus library address but I recently purchased a digital I/O module which is giving me trouble.  As soon as I add the shared variables which correspond to the modbus addresses of the digital I/O module channels I am using I get a few different errors.  If I turn off aliasing for one of the thermocouple channels I get Error 1550 "the license for the I/O server type is invalid"....If I turn it back on I get errors for every modbus location saying "invalid value for enable aliasing option"  I am using the student edition and on the opening screen it says the data logging license is expired.  Is that the problem?  I don't think so because I am successfully communicating with the thermocouple module of the same DAQ device.  Is there a simple way to write a new VI that I can try to communicate with just a switch on the digital I/O module and see if it is reading on or off (0 or 1).  Thank you very much for your time

    Hi brade, 
    To clarify where we are at. the behavior you are seeing isn't expected. It is a minor bug that we have seen in R&D but haven't been able to reproduce and fix yet. 
    People have gotten around it by
    1) re-making their projects 
    2) Enabling descriptions, as the engineer in other post.  The problem went away for him on this post: "Aliasing is no longer an error.  (As long as NI Variables (task description) is enabled)."
    We were talking about the aliasing tab you can see on the modbus variables in hte labview project by right-clicking and going to properties; 
    I assume he checked the box on this tab: 
    Can you also post your project? 
    Jesse Dennis
    Design Engineer
    Erdos Miller

  • Distributed application: Networked Shared Variables, Named Services (Raw TCP/IP) or Other?

    Happy New Year NI forums! 
    I am working on a project involving mobile interacting robots. In the future it is likely the application's components may need to run on different PCs (Targets). Note: at this point in time all the components are seperate but all running on the localhost machine. Thinking towards the future I want to pick the 'best' architecture to allow all these components (VIs performing various functions) in multiple locations. For example, several VIs on the Robots, VIs on serveral PCs. 
    I am  currently aware of using Server/Client TCP/IP using named services. My mock up works well, but is it time efficient (my time coding) I wonder.. ?  
    Whereas I am aware of networked shared variables which handle connections and all the parsing for the underlying tcp/ip communication. But will this be difficult the manage? I am unsure if I can associate shared variables with a VI similar to named services. I suppose I could pro grammatically create the variable upon initialization of the server component - and the client could just search the list of avaiaible variables to connect too. Downside this would require DSC module. 
    As you can see, I am rather unsure. Any advice would be great!
    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!

    Hi Jason,
    Thanks for your reply. I hope your enjoying NI UK as much as I did.. fun times!
    I have seen the link you posted a few times before. But today, I took a better look at it.
    My issue is I need several multi-client severs, i.e. many servers which allow multiple clients to connect to them.
    Now the STM does have an example of this - STM mutli-client Example - Server.vi (used with the STM mutli-client.vi)
    However, when a make copies of these code (to have my second server) - it refuses to run. As in , it just stops itself.
    I DID change the port number, on the lister aspect of the server code. But I Am unsure what else I would need to change to get this setup to work?
    One thought I had was, the FIFOs all having the same name - this probably isn't a good idea between servers.
    Any suggestions would be grateful!
    *please could you provide me email support
    Kind Regards,
    James Hillman  
    Kind Regards
    James Hillman
    Applications Engineer 2008 to 2009 National Instruments UK & Ireland
    Loughborough University UK - 2006 to 2011
    Remember Kudos those who help!

  • Migrating large project from DSC 7.1 to LabView 2009 Shared Variables ... What's the next step after recreating my variables?

    I am in the process of migrating a large distributed (multi-workstation) automation system from the LabVIEW 7.11 DSCEngine on Windows XP to the LabVIEW 2009 Shared Variable Engine on Windows 7.
    I have about 600 tags which represent data or IO states in a series of Opto22 instruments, accessible via their OptoOPCServer. There are another 150 memory tags which are used so the multiple workstations can trade requests and status information to coordinate motion and process sequencing.  Only one workstation may be allowed to run the Opto22 server, because otherwise the Opto22 instruments are overwhelmed by the multiple communications requests; for simplicity, I'll refer to that workstation as the Opto22 gateway.
    The LabVIEW 2009 migration tool was unable to properly migrate the Opto22 tags, but with some help from NI support (thank you, Jared!) and many days of pointing and clicking, I have successfully created a bound shared-variable library connecting to all the necessary data and IO.  I've also created shared variables corresponding to the memory tags. All the variables have been deployed.
    So far, so good. After much fighting with Windows 7 network location settings,  I can open the Distributed System Manager on a second W7/LV2009 machine (I'll refer to it as the "remote" machine henceforth) and see the processes and all those variables on the Opto22 gateway workstation. I've also created a few variables on the remote workstation and confirmed that I can see them from the gateway workstation.
    Now I need to be able to use (both read and write) the variables in VIs running on the remote workstation machine. (And by extension, on more remote workstations as I do the upgrade/migration).
    I have succeeded in reading and writing them by creating a tag reader pointed at the URL for the process on the Opto22 gateway. I can see a way I could replace the old DSC tag reads and writes in my applications using this technique, but is this the right way to do this? Is this actually using the Shared Variable Engine, or is it actually using the DataSocket? I know for a fact that attempting to manipulate ~800 items via Datasocket will bog down the systems.
    I had the impression that I should be able to create shared variables in my project on the remote workstation that link to those on the Opto22 gateway workstation. When, however, I try to browse to find the processes on that workstation, I get an error saying that isn't possible.
    Am I on the right track with the tag reader? If not, is there some basic step I'm missing in trying to access the shared variables I created on the gateway workstation?
    Any advice will be greatly appreciated.
    Kevin
    Kevin Roche
    Advisory Engineer/Scientist
    Spintronics and Magnetoelectronics group
    IBM Research Almaden

    I have found the answer to part of my question -- an relatively easy way to create a "remote" library of shared variables that connect to the master library on my gateway workstation.
    Export the variables from the master library as a csv file and copy that to the remote machine.
    Open the file on the remote machine (in excel or the spreadsheet app of your choice) and (for safety's sake) immediately save it with a name marking it as the remote version.
    Find the network path column (it was "U" in my file).
    replace the path for each variable (which will be either a long file path or a blank, depending on the kind of variable) with \\machine\'process name'\variable name
    where machine is the name or ip address of the master (gateway) workstation (I used the ip address to make sure it uses my dedicated automation ethernet network rather than our building-wide network)
    and process name is the name of the process with the deployed variables visible in the Distributed System Manager on the gateway machine.
    NOTE the single quotes around the process name; they are required.
    The variable name is in the first ("A") column, so in Excel, I could do this for line 2 with the formula =CONCATENATE("\\machine\'process name'\",A2)
    Once the formula worked on line 2, I could copy it into all the other lines.
    Save the CSV file.
    Import the CSV into the remote library to create the variables.
    Note: at this point, if you attempt to deploy the variables, it will fail. The aliases are not quite set properly yet.
    Open the properties for the first imported variable.
    There is probably an error message at the bottom saying the alias is invalid.
    In the alias section, you'll see it is set to "Project Variable" with the network path from step 4.
    Change the setting to "PSP URL" with the same path and the error message should disappear.
    Close the properties box, save the library, and then export the variables to a new CSV file.
    Open the new CSV file in Excel, and scroll sideways to the NetworkrojectBound field.
    You'll notice it is False for the first variable, and true for the rest. Set the field FALSE for all lines in the spreadsheet.
    Scroll sideways... you'll notice there are two new columns between NetworkrojectPath and Network:UseBinding
    The first one is NetworkingleWriter; it should already be FALSE for all lines.
    The second one is Network:URL. That needs to be set equal to the value for each line of NetworkrojectPath.
    You can accomplish this with a formula like in step 4. In Excel it was =U2 for line 2, and then cut and paste into all lines below it.
    There is a third new field, Path, which should already be set to the location of the variable library. You don't need to do anything with it.
    Save the edited CSV file.
    Go back to the remote library, and import variables from the just-edited remote library CSV file.
    Once you have imported them and the Multiple Variable Editor opens, click on done.
    You should now be able to deploy the remote variable library without error. (Make sure to open the Distributed System Manager and start the local variable engine. It took me a few failures before I realized I had to do that before attempting a deployment).
    Voila! You now have a "remote" library of shared variables that references all the shared variables on the master machine, and which should be deployable on other machines with very little difficulty.
    It actually took longer to write out the process here than to perform these steps once I figured it out.
    Kevin Roche
    Advisory Engineer/Scientist
    Spintronics and Magnetoelectronics group
    IBM Research Almaden

  • Exporting Shared Variables to csv

    When I try and export SV information to csv, LV (2009, DSC) doesn't seem to recognize any variables that are located within virtual folders in the library. Does anyone know a work-around to get that data tabulated short of cycling through the whole library writing values from SharedVariableIO property nodes to file?
    Thanks,
    Kyle
    CLD using LV, DSC 8.5-2009, RT 8.5
    Ghoti!

    muks wrote:
    Have you seen this?
    Yep. That's the problem. The shared variable library I'm working with contains well over 1000 variables that are organized into a few dozen virtual folders within the library. When I use the Export Variables function you linked to, it doesn't "see" any variables in folders, only those in the library root.
    CLD using LV, DSC 8.5-2009, RT 8.5
    Ghoti!

  • Network shared variables lose binding

    Hello,
    I am developing an application in LabVIEW that uses network shared variables to transmit data between two PC's on the same subnet. The shared variables work fine when running the VI's in development mode, however, when i build the vi's into an executable I find that they no longer work. Here is what I have found so far:
    I deploy the shared variable library on the publisher machine (also happens to be the development machine) through an invoke node in the executable. NI distributed system manager confirms that this does deploy and indeed updates as it should.
    For the executable on the subscriber PC I created a second shared variable library (same project) with the same shared variables and bound them to the respective shared variables from the first library by selecting enable aliasing, then bind to PSP URL and browsing to the shared variable I wish to bind it to (e.g. \\hallnet-ellm2\shared variable library\serial Number). The machines listed under browse were listed by name so when I tried this initially and it did not work I manually changed the name of my machine in the URL box to the IP address of the publisher hoping that would fix it in case the subscriber could not resolve the publishers machine alias. So now my bind URL read \\192.168.0.1\shared variable library\serial Number.
    As part of the executable on the subscriber I deploy this second shared variable library. NI distributed system manager confirms that this deploys but under quality for an individual variable it has a list of issues (see attached) and the bound variable is not updating. At this point the publisher shared variables are still functioning fine. By clicking on 'edit variable' I can see that the variable on the subscriber is still bound but the PSP URL is now \\localhost\shared variable library\serial number. Changing the PSP URL on the subscriber to \\192.168.0.1\shared variable library\serial number enables the variable to update as expected.However by this time my executable has already picked up the error and does not function.
    I think that the issue lies with the bind URL used on the subscriber as for some reason it does not keep the binding configured in the project and instead changes to 'localhost'. Why is this? Should it not stay bound to the address specified in the project?
    I have tried changing the IP addresses in the aliases file so that
    [My Computer]
    My Computer=localhost 
    becomes
    [My Computer]
    My Computer=ip of local machine
    This did not help.
    The shared variable libraries are included in the build spec to go into the support files directory and they are successfully deployed from there on both publisher and subscriber.
    I am using LabVIEW 8.6 on Windows XP
    Thanks for any help you may be able to offer,
    Lee
    Attachments:
    distributed system manager.JPG ‏74 KB

    Hi Lee,
    I hope you are well.  Thank you for your post.  Your application sounds very interesting.
    Looking at your issue I was wondering, have you tried lowering your firewalls, as this may be causing the problem.
    Also, another option would be to setup a private network.  Do you have access to any routers that you could use to link the two machines independent of your IT's infrastructure?
    The other thing to try is two other computers entirely.  Again, it would be ideal to take them off the network you are on, but it's something to try if my prior suggestion doesn't work.  It should work on the original two machines though, and it's likely that different computers won't solve your problems because I suspect the network.
    Remember that the client variables must know the location of the variables on the server, so you can't move the server exe around without changing this value.
    Make sure to set the network location in the "Bind to Source" option for the client variables.
    It is also possible to write a separate piece of code to install on every machine that is responsible for deploying the library and by doing so eliminate the need for programmatically deploying the variables in the original application.  However, this won't really help you, because the variables you use in the application have to be the same as the ones deployed in the library, so if you change the library, they'll no longer be linked and they won't receive data.  You'd have to create a separate exe for every binding source you wanted to link to, and then have a second, known library for the sake of communication locally on the computer between the ‘deployer’ and the actual application.  The main application could then be assigned the responsibility of launching the correct ‘deployer’' if it sees it needs to switch to a different variable binding source.  This method is not the most streamlined or effective, but it might work.
    Just to let you know, you will need to use the DSC toolkit.
    Please find below some knowledge base links that I think you will find helpful in your application.
    Using Shared Variables in Executables
    How do I Programmatically Change the Data Binding Source for Shared Variables?
    I hope this information helps and if you can give these suggestions a go and let me know how you get on, that would be great.
    Kind regards,
    Prashant M
    Applications Engineer
    NI UK & Ireland

  • 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

  • How do you synchroniz​e accesses to a LabVIEW Shared Variable?

    I would like to create an ad-hoc weather station program (I'll explain more in a bit).  I am using LabVIEW 8.0 Full Edition, and I would like to share data over a network between stations with the LabVIEW Shared Variable.  Here's what I want to be able to do:
    A node would start up, and begin publishing data to a network via a shared variable.
    The shared variable is an array of clusters
    The cluster information would hold things like:
    Station Name
    Station Location
    Weather information cluster (temperature, rainfall, windspeed, wind direction, etc...)
    Timestamp of last update
    When a new node would like to enter, it would bind to the shared variable, grow the array, and add its information.
    If a node's Station Name and Station Location is already in the shared variable, it would merely update the information in the cluster.
    Viewing nodes could pop in, bind to the shared variable, and read/display the information at any time. 
    I am trying to enumerate problems with this before implementing, and I have run into a stinker of a problem that I am not sure how to solve.  How do I synchronize accesses to the LabVIEW Shared Variable?  If I read the variable, modify it, and write it back, I will undoubtedly run into a race condition where 2 nodes attempt to update its data and I will lose the data written by the first node - Node A reads, Node A modifies, Node B reads, Node A writes, Node B Modifies, Node B Writes, and thus the modifications made by Node A are lost.  In my specific application losing some data isn't critical, but if not remedied this type of problem could cause massive amounts of data to be lost when there are numerous nodes, and that is definitely not acceptable. 
    Does anyone have any recommendations on how to synchronize the read-modify-write operations on the data in the Shared Variable?
    -Danny

    Wendy,
    I am afraid Semaphores are not network-shared objects (to my knowledge), they are system-level objects that use operating-system synchronization mechanisms.  If I were synchronizing on a single machine, a semaphore might be a valid mechanism; as an aside, most user-mode semaphores are designed to synchronize within a single process - to synchronize between processes you need to store the semaphore in the Kernel, and to synchronize over a network you would need a network node to handle serialization of requests.  My Shared Variable is published over a network, and to my knowledge there are no network-published synchronization mechanisms available - mostly because there is no way to currently perform an atomic test-and-set on the Shared Variable (am I correct?) and there isn't a mechanism for blocking access to a Shared Variable from another network device/machine (or is there?).  I've been looking for some way to implement an atomic test-and-set but I am running into a wall; I know that if I select the "single writer" attribute of the Shared Variable I can get LabVIEW to force a single writer allowing me to have an atomic "set", but I need more than that.
    If only there was a network-shared Semaphore or some way to block other network accesses to the Shared Variable I would be in business - something like what I want doesn't exist, does it?
    Thanks!
    -Danny
    Message Edited by texasdiaz on 02-23-2006 02:52 AM

  • Using network shared variables in two computers connected via a network switch

    let me start by saying im a rookie to the programming environment but i have used Labview a couple of times to understand the basics,  i have a computer and a laptop (both using vista), both of them with Labview Full development System (Student ed. with Mathscript) installed, so what im tryin to do is to use the built in microphone located in the laptop to aquire sound and then use a Shared Variable to transfere the sound signal from the laptop to the computer, the laptop and the computer are connected to a network via a network switch and ethernet cables,  so far i nothing worked, i can manage to create the shared variable in the laptop and use it there but it doesnt appear in the computer, im not sure whats the problem i have even disabled firewalls in both systems, help from anyone wil be appreciated.....

    Hi Lukie,
    This KB should be of some assistance to you.
    Trouble shooting network published shared variables
    Also the following link gives some instructions on the use of shared variables.
    http://zone.ni.com/reference/en-XX/help/371361B-01/lvhowto/bind_to_source/
    I hope this is of some assistance, let me know if you have any more problems.
    All the best,
    Message Edited by mickeyw on 08-05-2008 12:29 PM
    Mike W
    Applications Engineer
    National Instruments UK&Ireland

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

  • Touch Panel Shared variable binding does not work.

    Hi,
    Is there any reason why shared variable binding is not working under Touch Panel Target?
    Is there any plan for implementing or there is some trick I should know?
    Andras

    RebeccaFo wrote:
    Hello Andras,
    which version of LabVIEW are you using? As yu can see in:
    http://digital.ni.com/public.nsf/websearch/04AAA6903A9456F08625715A0026BC57?OpenDocument
    it should work. So what for problems do you have?
    Thanks,
    Just FYI, the KnowledgeBase article linked above has been revised and moved to a new location.  See the new KnowledgeBase 58JFBGD2: Are Shared Variables Available For LabVIEW Mobile Module (Formerly PDA Modul...

  • 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

  • RT cRIO: Shared Variable Engine Errors

    This is an app written in LV2011 running on a cRIO-9076 (Scan mode), with the August release of software installed on it.
    I have gown to great lengths to try an optomize my code, I have reached an impasse.  The VERY FIRST TIME I run the code on the target (be it via a self-starting EXE or targeting from my Windows development machine I am able to read and write to several shared variables, but then when I access them again (possibly when I am starting a couple timed loops and the processor is very high) I get this:
    Error -1950679023 occurred at Shared Variable in targetIdleLoop.vi->ZDAQ_cRIO_Target_Main.vi
    Possible reason(s):
    LabVIEW:  (Hex 0x8BBB0011) The connection to the server was disconnected.
    This error or warning occurred while writing the following Shared Variable:\\ZeeAero-RIO1\variables - network - RT (separate)\RTStatus\\10.10.10.10\variables - network - RT (separate)\RTStatus
    If I go back to the Dev machine and restart the code, I don't get this error; it only happens after a reboot.
    BUT on this second run (or subsequent VI starts), when we get to that same point, a client priogram running on Windows and reading a network variable successfully suddenly gets:
    LabVIEW:  -1950679035 (Hex 0x8BBB0005) Unable to locate variable in the Shared Variable Engine.  Deployment of this variable may have failed.
    Which lasts a minute or so, then goes away.  The code is made to loop, and when it loops back through this point there are no errors at all.
    So, to recap:
    1st Run after reeboot, 1st loop :Error on Target (0x8BBB0011), connection to server disconnected
    Subsequent Runs, 1st loop: Error on Windows Client (0x8BBB0005) Unable to locate variable in the Shared Variable Engine.  Deployment of this variable may have failed.
    Subsequent Runs, 2nd+ loop: No error
    Here is a link to a screenshot of the installed SW on the Target:
    EDIT:  I should mention that there are three loops running in parallel on this app; 1 is a Timed-loop (at the moment) set to a period of 10ms with 100 priority, #2 is also a timed loop and is set to 3ms with priority = 50 and the third is a WHILE loop with a 50ms wait.  The error occurs during the WHILE init phase, which happens once per run, not repeatedly.
    Solved!
    Go to Solution.

    This is killing me.  It's obviously something to do with when the Timed loops start AND when I access the network variables.
    See the screenshot below.
    Note that I read and write to several network variables in Subroutines to the left of this screenshot at startup.  The starting of the timed loops causes the issue with the shared variables.  (also note that the periods are set to 100ms and 99ms in my testing after the initial 1st loop.
    Now look at the Wait at the bottom set to 10 seconds.  In this case, it will work.  There is no error at breakpoint 37 if I wait around 10s.  If I DON'T wait the 10 seconds, there is an error after the check on the BOOL "stop - Network" variable that NEVER GOES AWAY.  If I look at the CPU monitor, there is an initial bump in the cpu when starting the loops, and then it drops to about 15%.  But if I don't have that 10s wait, there is ERR 0x8BBB0011 and the CPU spikes to 75% every 5 seconds and it never goes away.
    And that's only the 1st loop after reboot.  The 10s makes this work, but I still have an issue with it once I start doing individual runs (loops).

Maybe you are looking for

  • Officejet Pro 8600 Plus wireless printing dilemma

    Hello, I recently purchased the Officejet Pro 8600 Plus for my dorm room in college. However, the school requires all devices that want to use its wi-fi to register their IP addresses through detection software in addition to the default log-in infor

  • Different versions of Siebel

    Please let me know whether we can use JCA or any other api to connect to different versions of Siebel namely 7.5 and 7.8 without invoking any jars provided with Siebel. If incase anybody has faced this problem. thanks in advance.

  • HTML Tags in XML Update

    I have a unique situation (may be not that unique). I want to update or add HTML tags in an XML element I am writing a PL/SQL Stored Procedure to insert, update or delete elements/attributes from an XML Type column based on the input XML (coming from

  • Cfc component with readonly properties and web services

    I want to transfer a cfc component across coldfusion web services as a data transfer object. This cfc component is received when calling a load web service, and then supplied to an update web service. Some properties within the cfc need to be readonl

  • Client Copy for Solution Manager

    Hello! I need to know for the client copy phase , which clients do I need to copy from , for Solution manager 40 SR3. Regards