Variable engine write hangs

I am using the shared variable engine to bind shared variables to an OPC server (DSC/Labview 8.5)
When using read only variables, all works OK
When using a read/write variable (specified either R/W or W only in the shared variable definition), the shared variable engine hangs, and needs to be stopped and restarted for the program to work again. If the engine is not stopped and restarted, I basically get a shared variable is not located error (same as if I stopped the service manually)
I have tried synchronous or asynch writing as per the OPC Client I/O Server Advanced tab definitions (as well as In or Out of process).
Any idea why writes would be failing, but reads are working OK

a timed loop fires say every 1 sec, so I may have up to 1 sec latency between the clicking of a switch, an the action required.
If I set the loop interval to less than 500 ms, then I get long delays between the writing to the variable, and when it actually occurs. Even shorter times, I may never see the change in the variable.
I don't need fast updates, I just need them to start occurring without a delay when the event happens. In addition, if possible to have some way to allow the next setting of the variable to happen when the first one is finished.
In effect the sequence required is
1) Write to the variable
2) dissallow any further writes to the variable
3) check if the variable state has changed to that expected, and reallow variable write access
4) have a safety check, so if the write does not happen after a given time, time out, and reallow variable writes

Similar Messages

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

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

  • Shared variable engine memory problem

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

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

  • Shared Variable Engine Buffering Enable/Disable

    Hello -
    I am running into a problem where I am seeing a read of data that seems to be lagging the writing of the data. The reading and writing functions are utilizing the same shared variable - a control to write to it and an indictor to display it somewhere else. The indicator is lagging by one value, ie. scrolling up the value from 1,2,3,4.. will yeild in a display of 0,1,2,3, lagging by one. I am writing/reading to/from a value in a PLC using an OPC server, binding the variables to the control/indicator.
    I am assuming it is the buffering which is causing this, but I can not seem to find where the buffering is enabled/disabled.
    Has anyone seen this behaviour before? Also, where do you configure the Shared Variable Engine to disable buffering?
    Thank you in advance for your help -
    John
    PS> One other note, Datasocket binding of the control/indicator does not yield any problems.

    John,
    Buffering is configured in the main window of the shared variable (double click on the shared variable in the project).  Also, you will see this behavior if you have the RT FIFO enabled and you're using the variable on a Real Time target. 
    I would also recommend taking a look at this white paper which covers the workings of the shared variable:
    http://zone.ni.com/devzone/conceptd.nsf/webmain/5b4c3cc1b2ad10ba862570f2007569ef
    --Paul Mandeltort
    Automotive and Industrial Communications Product Marketing

  • Shared Variable Engine Error Handling

    I have a HMI system that connects through shared variables to an OPC Server. I have encountered problems with Variable Engine, and a problem with tagger which I don't know anything about. I checked OPC Server to see  ifit's installed properly and the items status is good, and the server's connected. I tried to restart the shared variable engine service but it doesn't reply. When I monitor variables there's no connection. I used Alarm&Event query.vi in my application and then encountering tagger error, server connection failed. How could I handle these errors? 
    I appreciate any help.

    I've created Bindings to OPC items I want to read/write through an OPC Client instance, bound front panel objects to these shared variables, deployed the entire library and run the VI.
    All the connections were true (green PSP-LED. through the Monitor Variables all the variables and OPC items of client instance had good quality and right value.
    All the variables were configured to log data and alarms.
    Configuring the library for a data base through it's DSCsettings:database, I used Historical VIs (Read trace,… ) to retrieve data from citadel and they worked properly. I used Alarm & Event Query.vi to retrieve alarms from citadel, the VI encountered this Error:
            "Some part of tagger encountered a problem and should be closed"
    After that the entire connections failed (PSP-LEDs goes red) and the I/O Engine couldn't be restarted and shows this Error:
                 "Could not stop the National Instruments Variable Engine Service on local computer.
                  Error 1053: the service did not respond to the start or control request in a timely fashion."
    And the variable monitor dosen't show any library and variables.

  • Network Variable Engine in application started in autorun

    Using CVI 2009 SP1 I developed an application that uses Network Variable Engine:
    At the beginning of main I wait in a do-loop until the Variable Engine is running
    t_start = Timer();
    do {
    CNVVariableEngineIsRunning(&running);
    if (!running) {
    t_rem = 20.0 - (Timer() - t_start);
    if (t_rem > 0.) Sleep(100); //100 ms
    } while (!running && (t_rem > 0.));
     Then I create a buffered subscriber, previously checking that the process exists and is running
    CNVProcessExists (processName, &exists);
    if (!exists) {
    CNVNewProcess (processName);
    CNVProcessIsRunning (processName, &isRunning);
    if (!isRunning) {
    CNVStartProcess (processName);
    CNVCreateBufferedWriter (NetVarPathname, ConnTransferredCallback,
    ConnStatusCallback, NULL, 10, 10000, 0, bufferedWriter);
    This application works perfectly when I launch it as standalone application.
    But If I launch it at the Windows boot time through Start >> Programs >> Startup, CNVCreateBufferedWriter( ) returns -6337 (The network variable process was not found or is not responding).
    Does CNVStartProcess( ) need a delay time?
    How can I avoid this annoying error?
    Vix
    In claris non fit interpretatio
    Using LV 2013 SP1 on Win 7 64bit
    Using LV 8.2.1 on WinXP SP3
    Using CVI 2012 SP1 on Win 7 64bit, WinXP and WinXP Embedded
    Using CVI 6.0 on Win2k, WinXP and WinXP Embedded

    CNVProcessIsRunning only checks if the process is configured to run when the Variable Engine is started...
    I think this advice should be added to the function help.
    But in cases where this function is called during system startup, it is unreliable because the Variable Engine could still have not loaded...
    As I write in the first message, the first function I call in my application is CNVVariableEngineIsRunning( ), then I wait until it returns "is running". Why does the NVE could still have not loaded after "is running" has been returned?
    A workaround for this problem and correct indicator of the availability of the process is to programmatically browse to the process:
    CNVBrowser browser;
    CNVCreateBrowser(&browser);
    CNVBrowse("\\\\localhost\\your-process-name");
    CNVDisposeBrowser(browser);
    If CNVBrowse succeeds, then the process is running. Please let us know if you run into issues with this workaround.
    Done. After this, I've never seen the error anymore... but I'll check again.
    Vix
    In claris non fit interpretatio
    Using LV 2013 SP1 on Win 7 64bit
    Using LV 8.2.1 on WinXP SP3
    Using CVI 2012 SP1 on Win 7 64bit, WinXP and WinXP Embedded
    Using CVI 6.0 on Win2k, WinXP and WinXP Embedded

  • Attempting to install a compiled 8.6.1 package fails with "NI Variable Engine (higher version already installed)

    This is long as there are a collection of details I thought would be useful.  Please bear with me.
    I have a VI compiled with LV 8.6.1 PDS.  The installer ran on the development machine and it works fine there (WinXP SP3).
    Was handed a laptop (another WinXP SP3) that already had LV 7.0 (academic) on it.  Someone was fiddling with an old version of LV.  OK.
    Wanted to uninstall 7.0 so there would be a clean field for the program compiled under LV 8.6.1.
    So: Start --> Control Panel --> Add/Remove Programs and uninstalled "National Instruments Software".  That went smoothly.  It wanted a reboot.  Fine.
    Ran the setup program in my package, the one I'd wanted to install.  No errors.  The following installers were included with the Build:
      * NI LabVIEW Run-Time Engine 8.6.1
      * NI Measurement & Automation Explorer 4.5
      * NI DAQmx 8.8
    By the way, this generated an installation package of "almost" 900 megabytes.
    Connected the hardware (one ethernet-based, another RS-232 based).  Started the program, "EDGAR2".
    First error:
      Unable to locate the LabVIEW Run-Time Engine.
      EDGAR2 requires a version 8.6.1 (or compatible) LabVIEW Run-Time Engine.  Please contact the vendor of EDGAR2 to correct this problem.
    (This is Error1.JPG, attached).
    A check of C:\National Instruments\Shared\LabView Run-Time\8.6 shows that there is only one item in that directory: a sub-directory named "errors".  That's it.  If the executable is looking for something in the 8.6 directory, well, there's nothing there.
    Uninstalled EDGAR2 using the Control Panel.  Reinstalled.  Same problem.
    Downloaded the standalone LabVIEW Run-Time 8.6.1 installer, Standard Edition, from NI's site, unpacked, and ran the setup.exe from that package.
    There is one box with a green checkmark in it:  NI Variable Engine .
    Click Next.  Up pops a pane and Error2.JPG is attached.  It won't continue because the "detected" version of Variable Engine is of a higher revision.
    The "Next>>" button is grayed out.
    Uninstalled EDGAR2 again.  But there was no entry in the Windows uninstall panel for uninstalling any National Instruments software.  This raised a flag in my mind and NI Support was telephoned.
    With the Support Guy running Google searches for relevent topics (I'd done some of that, too), a number of things were tried.. ending up with deleting everything in C:\Program Files\National Instruments while in Safe Mode, everything in C:\Documents and Settings\All Users\Application Data\National Instruments, going through the Windows Registry with REGEDIT, uninstalls and attempted reinstalls.  Nope, nothing worked.  That defective Variable Engine seems glued into the system
    The application can't find the 8.6.1 run-time because it doesn't exist.  It doesn't exist because both the standalone and built-in installers see a Variable Engine of a higher version installed and apparently won't install over it.  There is no uninstall for any NI software in the Windows Control Panel --> Add/Remove pane and so I can't seem to get rid of this Variable Engine.
    At this point, the Support guy says, "Time to reimage your computer.  Call us for anything else.. you know we're here for you."
    This is the first trouble I've had installing a compiled VI.  All other packages built with 8.6.1 PDS just slid right in.
    There's been a LOT of software installed on the target over the years and going on the proverbial "scavenger hunt" to locate all of the installation disks will be a time-consuming task (a week is a conservative estimate).  Is there a solution to this problem?  Where are the installers "looking" for the Variable Engine revision level?  Is there a specific Registry key that can be adjusted?
    Went looking through the WinXP Event log.  No errors are popping up there.
    Your time is appreciated.
    Mark
    Attachments:
    Error1.JPG ‏17 KB
    Error2.JPG ‏28 KB

    Hi Mark,
    I'm sorry to hear your having trouble installing the LabVIEW 8.6.1 Run-Time Engine.  It sounds like there could be a few problems going on here.  First, you should have more options when installing the Run-Time Engine than just the Variable Engine.  If you uncheck the Variable Engine, does it try to install anything?  Second, not being able to install the Variable Engine suggests that there may be something wrong with your registry.  If you removed all National Instruments keys when cleaning the registry, then this shouldn't be a problem.
    At this point, there are a couple things I would suggest.  Unfortunately, the best solution would probably be to reformat.  It sounds like some low level parts have been corrupted and this would be the quickest way to fix everything for sure.  Other than that, you can try installing the full 8.6.1 Development System on the computer.  This will install the Run-Time Engine on the computer.  You can simply not activate the software, which means you won't be able to edit anything.  You will be able to run the program, though.
    Jared S.
    Applications Engineering
    National Instruments

  • Error with the Shared Variable Engine

    Hi,
    I have a problem with the Shared Variable Engine,
    A .doc File is attached to this message, decribing the problem with pictures.
    I will be glad if anyone can help me. 
    Sincerely yours
    Amitai Abramson
    Attachments:
    Question.doc ‏819 KB

    Hi Amitai,
    Good afternoon and I hope your well.
    A member of the team from NI Israel contacted me regarding this post.
    I want to provide you with extra details on how to resolve your issue - i.e. Repair (Or Re-install) the Shared Variable Engine.
    If you use the MsiBlast Tool it will populate a list of all MSI NI Installers. One of these will be NI Variable Engine. On the right-hand side you can the click 'Repair'. I would also Repair the engine support for the versions of LabVIEW you have installed. Please see attachments for MsiBlast and a screenshoot of the MSIBlast screen.
    If this doesn't work I would recommend re-installing LabVIEW using the following guide, which I posted on this forum. (second post by me).
    Please let me know how you get on,
    Kind Regards,
    James.
    Message Edited by Hillman on 12-03-2008 12:19 PM
    Message Edited by Hillman on 12-03-2008 12:19 PM
    Kind Regards
    James Hillman
    Applications Engineer 2008 to 2009 National Instruments UK & Ireland
    Loughborough University UK - 2006 to 2011
    Remember Kudos those who help!
    Attachments:
    Repair Shared Variable Engine.JPG ‏97 KB
    msiBlast.zip ‏110 KB

  • Hibernation problem due to NI variable engine

    Hello,
     I posted a problem some month ago that discribed a problem with hibernation since I'd installed LabView8.
    The proble is still there. I hibernate my laptop and the longer I wait for waking up the machine again the longer it takes to wake up.
    I found out that after I stopped the service "NI variable engine" everything is fine again.
    I don't have DSC installed. So it's not the keyboard driver of DSC.
    Regards.
    Ronny

    Hi Ronny,
    We haven't heard from you in a little while, so I was wondering if
    you're still encountering the same issue.  One suggestion that
    came up here was that if the shared variable engine service appears to
    be causing the delay, we might just be seeing a large number of
    libraries deployed.  To clean out the variable engine, you can
    open the Variable Manager from within LabVIEW by selecting
    Tools>>Shared Variable>>Variable Manager.  Once this
    loads, right-click on Local System and select Remove All
    Processes.  This will undeploy and remove all shared variable
    libraries and will require you to close and restart any running LabVIEW
    projects.  It may be the case that many unused libraries are still
    being deployed, which can potentially drag down your system
    performance. Give this a try and let us know if it helps.
    Cheers,
    Matt Pollock
    National Instruments

  • Installer Builder - Install applicatio​n installer error, NI Variable Engine 2.6.0

    Dear All,
    Good Day!
    Im Shahril.
    My PC have 2 version of LV, 2012 and 2013.
    The application required NI Variable Engine to be installed.
    When i build the installer, nothing got wrong. AKA completed.
    But when tested it by install the application installer, the error occurred as attached.
    I do many times reinstalling the labview 2013. Still got the same problem.
    And i did run the NI Update Service. Update everthing in urgent needs to update.
    Please help me.
    TQ.
    Attachments:
    Error NI Variable.png ‏36 KB

    David,
    I can’t say for certain what’s going on here but I do have a few suggestions before you “recreate the installer for legacy code reasons.” First, I would delete everything from the Build Directory. This may be where the recursive issues are coming from. Lastly, in the My Installer Properties window, I would look at the Source Files and make sure everything is there and check for any broke links.
    Charlie M. CLD

  • Shared variable engine with pro-face touchscreen windows 2000 professional

    hello,
    who has some experience with the shared variable engine from LabView 8.5 and a touchpanel from Pro-Face?
    We try to deploy shared variables from the touchpanel but it doesn't work. Additionally the windows service ni shared variable engine dosn't start and we can't start it manually .
    The touchpanel is a PS3701A from Pro-Face with Windows professional 2000 for embedded, Pro-Face told us that we have the full service of Windows 2000 professional on a regular PC.
    Many thanks in advance
    derN

    Hi Andrew,
    Thanks for the feedback!  Your feedback will help us to improve LabVIEW for our customers.  This bug has been reported to R&D (#45493) and they are currently investigating this issue.  For now, the best workaround appears to be using a different OS, as this seems to only occur in Windows 2000.  Thanks for the feedback!

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

  • Executable won't re-connect to shared variable engine when it breifly goes offline

    Hi,
    I have shared variables that are hosted on a field-point controller. I read these variables from executables that run on a PC. When the shared variable engine on the field point controller goes offline and then comes back online (for instance, if I cycle the power to the controller), the executables on the PC don't automatically reconnect. I need to restart the executables in order for them to re-connect and read the shared variables.
    Any ideas on how to have the executables automatically re-connect? I don't want to have to restart the execuables when the power cycles on the controller,
    Thanks, Derek. 

    Hi Derek,
    It is my understanding that the variables should reconnect, even after your FieldPoint has been power cycled.  I found a few articles that could be helpful; read through these and let me know if you are still having issues. 
    http://digital.ni.com/public.nsf/allkb/7BA64956A475405F862570ED007B2A88?OpenDocument
    http://digital.ni.com/public.nsf/allkb/04D9A85B6967EE87862571140065EEC6?OpenDocument
    http://digital.ni.com/public.nsf/allkb/AA97FF29D0B3C748862572F600055B22?OpenDocument
    Cheers, 
    Marti C
    Applications Engineer
    National Instruments
    NI Medical

Maybe you are looking for

  • Can 2012 iMac be used as monitor for PC with thunderbolt?

    Hi, Im planning on buying a new 2012 iMac and was wondering about TDM - Target Display Mode. My PC rig is up for a new motherboard and the thought was to buy a thunderbolt equipped one and then use my shiny new iMac as display for it. That way I can

  • Question about bittorrent.

    I used my PC for Bittorrent normally and since I just bought a new macbook I've downloaded the software to install in the macbook. Unfortunately, the software said unable to download any document. Do I need to change any Port setting or firewall in o

  • Need a new pair of eyes

    Would someonoe take a look at the navbar on this site I'm redesigning please. In IE7 drop down under ministries and stewardship fall behind the sidebar top box. IE6 and FF look fine. There are still a few errors that I'm working through, but don't be

  • HT1918 how do you verify billing information? suppose to wait for an email?

    after entering the credit card info and saving it, are you suppose to get an email to verify the credit card info, cause I have updated the info, then went on apple tv and it keeps asking me to verify the info. how long does it take to get a verifica

  • Foreign language downloads

    My library recognized Hebrew CDS with hebrew characters. The problem is that when I sync my ipod, the Hebrew does not appear on my IPOD. It is blank. Can anyone help me? Thanks very much