Modbus I/O server & Shared Variable Engine

小弟做專題用到Labview,想請教一個問題,目前是用labview對智慧電表讀取資料
主要用modbus I/O server(TCP/IP模式)和shared variable engine
但是網路上大多數資料是教學如何建立I/O server和設定shared variable
小弟想知道背後理論是什麼?
例如:labview如何對modbus TCP/IP的封包進行處理,並取出所要資料。
謝謝各位指教

建議使用 google
關鍵字 = labview shared variable concept

Similar Messages

  • Modbus I/O Server Shared Variable Not Updating Immediately After Flush

    Hi everyone,
    Weird issue here... If I create a Modbus I/O server in a LabVIEW project, bind a shared variable to a holding register, write to the shared variable, flush, and read back, the value returned in an immediate readback is NOT the value I previously wrote. I've attached an example snippet.
    In this example, PLC Command Complete is TRUE coming in. I write a FALSE to it. I flush the shared variable buffer. I read back PLC Command Complete. When I do this, PLC Command Complete will return TRUE (???), and after 100ms or so, return FALSE. How is this possible??
    Some notes:
    The shared variable is NOT network buffered.
    The slave is NOT altering the value of this variable; only this snippet of code is.
    Altering the refresh rate of the Modbus server does not affect the outcome.
    If anyone has any idea as to what's going on, I would greatly appreciate it!

    Couple of points.
    First, your screenshot shows network shared variables, not single process!
    Next, network shared variables take time to update (much longer than NI tell you!) If you knock up a little timing noddy to set a variable and then loop reading that variable until the transition comes through you get results like this (runnng from the programming environment, I've not tried with a compiled exe):
    Network shared variable, no flush - approx 20ms (NI say is should be 10)
    Network shared variable, flush buffer - very fast (faster than the ms clock resolution) but still took between 14 and 20 iterations of my loop before the change percolated through (certainly not what you would expect)
    Single Process variable - instant (even without the flush)
    This has caused me so many problems in the past (my own race conditions are bad enough without NI throwing in extra ones with this unexpected behaviour) that I try to avoid network shared variables now.
    Change yours to single process and you should be fine (or do they need to be NS?)

  • Is Shared Variable Engine with LV8 an OPC server ?

    Hello
    Is the shared variable engine with LV8 an OPC server ?
    Does any OPC client can acces to Variable Engine OPC server an read shared variable ?
    Can I build an installer and deploy my application with Variable Engine OPC server on other PC without LV8.
    Thank you 

    Hi
    You can communicate between an OPC serveur and LV8 and use shared variable. To deploy an LV8 exe application, you must have the run time engine installed on the PC without installing LV8. You can create a setup with LV 8 in which you can integrate the run time engine.
    Kamal
    NIF

  • Shared Variable Engine OPC Server & Matrikon OPC Explorer

    Hello All
    I have a shared variable Engine OPC server running on my IPC. I am querying NI OPC Server through Matrikon OPC Client. My situation is if shared variable engine process is switched forcefully off (NI DSM) or communication between server and client is lost then client is crashing which is quite obvious. But the problem is if Server is Up again then the client is not connecting to server automatically.
    First of all is it  possible, that if server is up again then it will try to send some signals to the priviously connected clients ? If yes then do i have to make changes in shared variable engine properties ? How i can do this ?
    I hope you all will understand my problem, if not please post you doubts. I will try to clear my points.
    Thanks & Regrad´s
    Varun Garg

    Hi, just now I face a similar problem. When clients restart connection, the variable engine crash, for now the only way founded is restart the program programmatically, but I'm interested in how fix that.

  • Shared variable engine OPC delay

    Hello All,
    I've got a bit of a problem with the delay time of updates between a non NI OPC server and a shared variable engine OPC client. I am using the redion OPC software OPCWorx with a database of around 120 tags to monitor and log data from a small pilot plant. The OPCWorx server has been configured with a 500ms update rate and the NI OPC client as the same. So here is my problem; logged updates occur no faster that 2.5s which is fine as we are exporting in 3 sec intervals (would still like to increase the performance of this to around 1 sec) but the main nuisance is the delay in changing control registers in the PLCs. The controls and indicators are directly bound to the shared variable items where by a change in a boolean control on the front panel to the indicated response can range from 5 to sometimes 15 seconds delay. If I bind the same control and indicator directly to the OPC item through the data socket the delay in response is almost unnoticeable at around 1 sec. I have increased the update/logging dead bands of the shared variables which seemed to help but only by a second or so.
    Im wondering what the limitations of using an OPC shared variable engine is and if this is expected or have I gone wrong somewhere. All the variables are configured as non buffered and to have single writers.
    A few changes have been suggested;
    - Upgrading the PC. The current hardware is AMD Phenom 2 3.21GHz processor, 4GB of ram running windows XP.
    - Using Modbus over ethernet instead of OPC.
    This is the first major use of the DSC module and using the shared variable engine as an OPC client so any information or insight to help with this would be much appreciated. 

    Hi Kallen,
    The Shared Variable Engine can become bogged down when there are more than 100 shared variables.  This may be what you are experiencing.  We can check buffering for the variables and disable it, and that should improve performance slightly.  As it is, using datasockets may be the best method for over 100 shared variables.  I apologize for the inconvenience.
    Here are some KnowledgeBase articles that can be of use with regards to this issue:
    How Does Buffering Work for Shared Variables?
    http://digital.ni.com/public.nsf/allkb/5A2EB0E0BC56219C8625730C00232C09?OpenDocument
    Why Is Accessing IO Variables Through The Shared Variable Interface So Slow?
    http://digital.ni.com/public.nsf/allkb/F18AEE4BE7C9496B86257614000C43DF?OpenDocument
    Matt S.
    Industrial Communications Product Support Engineer
    National Instruments

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

  • NI Visa - Shared Variable Engine

    Hi,
    I am using labview Shared Variable Engine to create variables on my workstation and bind them to variables on my server.
    I have labview 8.2 installed on my workstation and labview 8.5 installed on my server.
    The communication between them worked perfectly and I was able to use the variables created in the workstation.
    In my application I need yo use NI visa to take serial input. So I installed the NI Visa on my workstation and the NI visa worked.
    However, the Server was not able to see the variables I have created in my workstation.
    Does this mean that NI visa do not work in parallel with the Shared Variable Engine, or does the NI visa change some of the settings parameters that would stop the Shared Variable Engine from working properly.
    Thanks in Advance

    This information helps me get a better idea of what you are doing, but I need much more information in order to help pinpoint what is happening in your application. You should absolutely be able to use VISA as well as the Shared Variables concurrently. What is the device that you are using for data acquisition? I'll need the model of the device. What kind of data are you acquiring? How are you using VISA to communicate with your instrument?
    One other item is to look in the distributed system manager to see if your shared variables are actually getting updated
    Any code you could post here would help as well.
    National Instruments
    Applications Engineer

  • 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 clock is consistently inconsistent

    From the annals of the weird:
    I noticed a while back that the DSM displays a different time than my system clock when I manually change a NSV value. I didn't think much of this, but then I noticed that it is not just wrong but inconsistently wrong. Here's the time difference, in seconds, between the system clock and the SVE timestamp for a dozen NSV value changes [the SVE clock always lags behind]:
    35, 14, 1, 18, 29, 2, 21, 24, 14, 17, 29, 20
    I checked these numbers in two different ways: (1) with the "Time stamp" event property node with NSV events using the DSC module and (2) manually changing values with the DSM and comparing to the displayed Windows time.
    What's the deal? The timestamp is completely useless to me with a seemingly random offset from the system time; it's by far the best way to deal with this little bit of unfortunate SV event handling behavior. Filtering event timestamps against system time is fairly standard procedure and I can't see it being useful with this going on.
    This should be trivial to reproduce--does anybody else see this? If so, is there an explaination--or better, a fix?
    [I should note that I have seen this but I'm running Intel core 2 duo, not an AMD multicore. I'm using LV and DSC 2010 SP1]

    You may have to set up the Time Synchronization Services on the computer with the DSM running. 
    In LabVIEW Help, look for Shared Variable Engine Page (Options Dialog Box)
    In DSM Help, look for Shared Variable Engine Time Server Configuration Box
    I don't know if both are necessary but I made all the computers on my system point at the same time server. The time server is configured as an Authoritative Time Server under Windows. It is in turn slaved to our DSN server which follows a Public NTP server. 
    JohnCS 

  • 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 on Windows PC w/o full install of LabVIEW

    I have the NI Developer Suite (8.20) and need some conformation before I get too deep in a project. 
    First of all, it is my desire to become very efficient on develop compiled executables with LabVIEW 8.20 as my NI Developer Suite license allows me to deploy these programs to any number of machines without facing copyright infringement.  I have been successful with this to a certain degree, but am still having problems in the testing stages of my application especially in cases where the hardware I am trying to target does not exist on my developing station.  If anyone can point me to white papers that would help me get the mindset to develop in this way, I would appreciate it.
    Onto the topic of this post:
    I am just scratching the surface of the shared variable interface that is available in LabVIEW 8.2.  My project involves two computers where both of them need to share variables back and forth from each other.  I've been reading everything I can get my hands on and I am having a hard time answering my unlying question: Is it possible for both of these machines to be running compiled LabVIEW programs and still manage the shared variables between them?  That is to say, can one of the machines have the Shared Variable Engine running on it as a Windows service, or compiled into my application executable.
    I've read that I can access shared variables from my compiled LabVIEW application through NI-PSP.  I am wondering what my limitations would be sans-LabVIEW installation other then the troubleshooting head ache you get from developing applications without direct access to the hardware.
    Thank you for your time and submissions.
    -Nickerbocker

    I am trying to get the "Shared Variable Client - Server" project example compiled so that both the server and client vi's can be run as executables on a standalone machine.
    I have created 3 build specifications:
    1. "My Server" which is the compiled EXE of the server.lvib.  Added that entire library to the source.
    2. "My Client" which is the compiled EXE of the client.lvib.  Added that entire library to the source.
    3. "My Installer" which is the installation package of the vi's and NI supporting software.  In the additional installers I have added:
     * NI DataSocket
     * NI LabVIEW Run-Time Engine 8.2
     * NI Measurement & Automation Explorer 4.1
     * NI Variable Engine
     * NI Variable Manager
     * NI-DAQmx 8.3
    Some of those are added for future needs.  Installed the package on my target machine and run the server executable it appears to run fine but I get various error messages from my client.exe package (which I won't go into detail here, yet).  Upon stopping the server I get the message "LabVIEW: (Hex 0x8BBB0005) Unable to locate variable in he Shared Variable Engine.  Deployment of this variable may have failed."
    I check the services running and see that the "National Instruments PSP Server Locator" and the "National Instruments Variable Engine" are both in the list and "Started."  I open up the Variable Manager that has been installed on my target machine and manually add the "waveform" and the "command" variables under a process I call "server" and start the process.  After that I start my server.exe that I have compiled from the server.lvib library.  The process gives no error messages until the stop button is pressed, and then I receive the message "LabVIEW: (Hex 0x8BBB0011) The connection to the server was disconnected."
    The compiled programs run fine on my development machine as well as the uncompiled VIs within the LabVIEW development enviornment.  Something tells me that I simply do not have the Variable engine properly configured on my target machine.  Also, the process and variables should automatically be populated under "Local System" in the Variable Manager, right?  I do not need to add them manually, or do I?
    Thanks for your input!
    -Nickerbocker

  • Shared variable engine network published source issue

    Hello,
    I am attempting to use the shared variable engine to share some simple stings over a network between a Windows 7 computer and a Windows XP computer. 
    I got through the shared variable example just fine and can share variables between VIs on a single computer. When I open the shared variable engine, it shows the client and server variables that are shared on the local computer. I then create a new process, and attempt to define a new variable, and the Shared Variable Property screen comes up. I attempt to "Bind to Source" and click browse, and see the computer name I am attempting to connect to. However, when I click it, it stalls and I cannot expand the computer to find the variable I am trying to bind to. What am I missing?
    Thanks, Arron

    Arron,
    This document may be useful in helping to setup your network shared variables. Take a look at this and see if you have followed all the outlined steps in setting up a network shared variable.
    http://zone.ni.com/devzone/cda/tut/p/id/4679
    Let me know how this works for you.
    -Nick-
    Nick C | Staff LabVIEW Platform Product Support Engineer | National Instruments

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

Maybe you are looking for