Dsc opc shared variables yields Server Failure

I've been struggling with the transition from DSC 7.1 to 8+ ever since the release of version 8. I use the Allen Bradley OPC server supplied with the DSC module (Industrial Automation OPC Servers v 5.1) to communicate with a PLC 5/30 via Ethernet, or at least I did when I was using 7.1.
Prior to today I always failed to get the shared variables that were bound to addresses in the OPC server to deploy, usually getting an error number that started with -19. However today I finally got it to deploy by keeping the I/O server and the shared variables in separate libraries within my project. Now that they deploy I find that I am unable to monitor them. I keep getting a Server Failure. I have browsed the forums here heavily, and the documentation all relates to remote OPC, which is not what I'm doing here (OPC client and server are on the same machine). I tried changing the login account for the Variable Engine service anyway, but that doesn't help, so I put it back.
I have had some luck simply binding my front panel objects to the OPC server addresses using Datasockets, so it appears that my OPC server is working. However, Datasockets is not a viable option for me because there are times when my project needs to write to a large number of addresses in the PLC sequentially, which never works over datasockets (in my experience).
We have continued to work in version 7.1 because of the challenges of moving to 8+, but since we can no longer purchase DSC runtime licenses for version 7.1 in order to deploy, it seems that we MUST move forward to 8+ or abandon LabVIEW altogether (which is certainly an option).
For clarification, I am now working with version 8.2 (but I've been fighting with it since 8.0 without much success). If anybody out there can think of a critical step that I might have missed that might cause this, or if there is a known solution, I could really use (and would greatly appreciate) the help. Thanks!

Nobody out there seems to have any answers for this, so I kept pounding on it (and pulling my hair out). In the end I finally succeeded in getting one of my old 7.1 DSC projects to run on 8.2. Here's what I did:
1. I begin with a fresh installation of Windows. I tested it with both 2000 and XP Pro. Vista RC1 will absolutely NOT work!
2. Install LabVIEW 8.2, DSC 8.2, and just the OPC server that I need from the IA OPC CD (in my case the Allen Bradley server)
3. Open the IA OPC server editor, and create a new file with an object in it for my PLC (PLC 5/30, Ethernet in my case)
4. Save, set it as the startup file
5. Run LabVIEW, create an empty project
6. Add an IO server
7. Launch Multi Variable Editor, load project file created in step 6, and bind one variable to PLC address
8. Save all. Uncheck auto deploy for the library, and deploy all.
9. Launch variable monitor, browse to new variable, double click to monitor.
10. This will ALWAYS fail with "server failure". Don't worry, just exit completely out of LabVIEW.
11. Stop the Variable Engine service.
12. Run OPC server editor again, and load up the lpd file from your old project. Modify if needed, save, and set as startup
13. Start the Variable Engine service again.
14. Launch LabVIEW
15. Create a new empty project (I created mine in the same directory as my old 7.1 project resided)
16. Add an IO server, and uncheck auto deploy for its library
17. Save all
18. Run Tools->DSC->Migrate->import scf
19. Convert your old SCF file
20. Add the new library to your project (it will be named LabVIEW)
21. Uncheck auto deploy for the "LabVIEW" library you just added
22. Right click on the "LabVIEW" library and do deploy all
23. Save, and open the variable monitor
24. Browse to a tag in the LabVIEW library, and double click
25. This time it will actually monitor the variable, with a status of "Good"
26. Now you can add your main front panel VI to your project, open it and run it
27. Version 8.2 will select the proper legacy tag read/write VI's, whereas 8.0 does not. The writes however do not work. Replace them with shared variable writes. The reads work fine.
28. The empty project that you created in step 5 is a throw away. It will never work anyway.
29. So far the only variables that I can get to work at all are the ones that I import from an scf file, which is a pain, but if I must create all my tags in 7.1 and import them into 8.2 I will (for now). I may try exporting to Excel and copying variables that work in order to get functional new variables, since binding them in the editor does not work.
I hope this helps anybody else out there struggling with moving to 8+ DSC. I saw a few posts with similar issues, but without ANY answers at all. It's a convoluted solution that doesn't make a lot of sense, but for me it is repeatable.

Similar Messages

  • OPC Shared variables supported types

    HI,
    What are the supported types for shared variables when using DSTP protocol (OPC server) ?
    Only Double, Boolean, U8 and strings seem to be supported.
    Can I have some specifications about this ?
    Thank you,

    Hi,
    I can create shared variables of any types but only  Double, Boolean, U8 and strings will be seen by OPC clients.
    Kerv

  • LVE / OPC / Shared Variable / LV 8.0 & 8.2

    I try to communicate with an OPC Client having problems...
    There are two ways to do that:
    First way:
    Simply create a shared variable in my project file which I can use per drag & drop after deploying it. The shared variable uses the Labview Variable Engine (LVE) and the NI-PS-Protocol. If I have read it correctly, these shared variables can also be OPC items. And yes, it works but limited.
    Second way:
    Each control / indicator has a data binding tab under properties. There I can select data socket and pass manually the OPC protocoll reference (e.g. opc://localhost/National Instruments.Variable Engine/\\.\test\SGL Array) which is not very comfortable but it works unlimited.
    Is problem is that the second way works fine for Labview 8.0 and 8.2 but the first way works in a curios manner on Labview 8.0.
    That means:  In labview 8.0 I can use the shared variables as OPC items without problems but only for non-array data types. Each array type (SGL,DBL, Waveform,...) does not work. We used the shared variables as simple OPC items a long time and now intented to add an array realizing that it does not work. Than someone told us to install DSC Modul wich adds the OPC functionallity to LabView, seeming to solve the problem.
    The remaining fact is that LabView 8.2 has no need for the addionally OPC functionally of the DSC Modul. Way 1 and 2 works without problems in 8.2.
    Ok, we have an unlimited license of using LabView in all versions and with all toolkits. But we want to use LabView 8.0, because our vis are programmed there and we do not to intend and vesion upgrade.
    If there is no solution here, we can use way to, but I am really interested, why shared variable arrays are not supporting OPC compatibility while non-array data types do.
    THX for an answer, best regards from Berlin

    Please refer to that thread http://forums.ni.com/ni/board/message?board.id=170&message.id=76313&view=by_date_ascending&page=1 for further information.

  • DSC: Importing Shared Variables results in error -1950679010

    This post is more of an "FYI" rather than a question.  I am using LV DSC 8.2.
    ASIDE:  I ran into this problem because I was trying to solve a related problem with Deploy Library.vi (I had dependant libraries that deployed manually, but not programmatically).  Eventually, I found the answer in http://digital.ni.com/public.nsf/allkb/8EF71E1DDDC36C908625716900594B50 (not a very satisfactory answer however, IMHO).
    During my solution search, another hint was provided with http://forums.ni.com/ni/board/message?board.id=170&message.id=177268&requireLogin=False which hints that using a "Network" defined SV, as opposed to a "Project" defined SV, could help.  Then I discovered the difference between NetworkrojectPath and Network:URL in the SV property definition.  Then I realized that NetworkrojectBinding is exposed in the Import fields (using the Multiple Variable Editor to do the importing of course), and this gave me the idea of being able to define a Network SV using the Import function.
    Unfortunately, it does not work.  In the csv file I set NetworkrojectBinding to FALSE, Network:UseBinding to TRUE and provide a valid Network SV path, but this results in error -1950679010: "Shared variable is bound but path or URL is not specified", which occurs when trying to save the LVLIB.  It would be nice to know why this doesn't work, as I think it should.  I think it is a problem with the SV import mechanism.
    David Moerman
    TruView Technology Integration Ltd.

    Yes, you can do this programatically.  I've attached a small chunk of example code (LV 8.5) that creates just 1 variable, as well as an image of it in case you are using an earlier version of LV.  If you want to create multiple variables for the same library just put the "AddSharedVariableToLibrary" in a loop, of course.
    David Moerman
    Attachments:
    Create Library and SV.PNG ‏48 KB
    Create Library of SVs - BASIC.vi ‏24 KB

  • DSC Saving Shared Variables to Library

    I'm guessing this is a bug (LV/DSC 2009 SP1), but I wanted to see if anyone else had experienced this or had a workaround.
    I'd like to make changes to the logging state of some shared variables programmatically and be able to save the changes. When I use the SharedVariablestoLib.vi function on a simple test library it works. However when I use it on my actual library I get the following (testing vi I'm using is Untitled 2):
    Error Code 1
    Invoke Node in PRC_SVsToLib.vi->PRC_DumpSharedVariables.vi->NI_DSC.lvlibharedVariablesToLib.vi->Untitled 2
    Possible reason(s):
    LabVIEW:  An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.
    =========================
    NI-488:  Command requires GPIB Controller to be Controller-In-Charge.
    I think the culprit is that my library has variables organized into virtual folders. Any thoughts?
    Thanks,
    Kyle
    CLD using LV, DSC 8.5-2009, RT 8.5
    Ghoti!

    I can pretty well cause the problem with virtual folders. I have attached the vi I'm using to change the logging state and save the changes as well as the two libraries I used for testing purposes.
    What I did to test:
    -Disabled logging on both variables in both libraries.
    -Saved, undeployed, and redeployed both libraries.
    -Ran my log enabling vi on each library. It ran on Test 2 (no folders) fine. On Test 3 (includes a folder) it threw the same error as above.
    -At this point I tested and both libraries were logging both variables.
    -Looking at the variable properties in the project, both Test 2 variables showed Enable Logging checked. Neither Test 3 variable did.
    -Exited the project. Test 3 had unsaved changes so I saved it.
    -Re-opened the project and examined the variables, both Test 2 variables showed Enable Logging as before. In Test3 the root variable showed Enable Logging but the variable in the folder did not.
    -Undeployed and redeployed both libraries.
    -Confirmed that both Test 2 variables and only the root Test 3 variable were logging.
    CLD using LV, DSC 8.5-2009, RT 8.5
    Ghoti!
    Attachments:
    Programmatic Log Change.vi ‏17 KB
    Test 2 Library.lvlib ‏5 KB
    Test 3 Library.lvlib ‏4 KB

  • LabView DSC + OPC Servers + Windows 2003 server

    I just want to suggest this guide from Matrikon to the ones that are going to deal with DSC labview modules, OPC servers and windows 2003 server (Win 2003 is not officially supported by NI).
    Appling this configurations I solved some problems I was having with my application.
    gianpiero

    Here are the updated links:
    pdf MatrikonOPC: DCOM for Windows 2000 and NT
    pdf MatrikonOPC: DCOM for Windows XP SP1 and 2003 (base)
    pdf MatrikonOPC: DCOM for Windows XP SP2 and 2003 SP1
    Misha

  • 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

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

    Hey,
    I need some help with shared variables. Here is what I'm trying to do. I run a vi on the computer that uses a camera to track certain objects. I would like this program to send the position of the object to another vi that is running at the same time on the speedy-33. The speedy-33 takes the position and rotates the robot towards the object. The problem I have is communicating the position from the computer to the speedy-33.
    From what I've read, I think I'm supposed to do this with shared variables. On the computer target,  I created a library with an integer variable (to hold the x position of the object). I set this variable in the computer vi using the shared variable. All of this is in a while loop. On the speedy-33 VI, I've connected a control to the shared variable. When I run the program everything works as intended so far. When the object's x value changes the control on the speedy-33 front panel changes appropriately. However, when I try to drag the variable onto the speedy-33's block diagram from the project explorer I get a bunch of errors. The first is "My Computer\Variables.lvlib\xpos: Not supported for current target." Since it appears this isn't supported for the speedy-33 how am I supposed to transfer the data?
    Hope all that makes sense.
    Thanks

    Squirell wrote:
    Hope all that makes sense.
    Well, I for one got lost somewhere in there. Didn't you say that you already had the shared variable in both the computer VI and the Speedy-33?
    It may be a good idea to take a look at the Shared Variable Client-Server example, and perhaps test it to see if it, at least, can work on your setup.
    I for one gave up on shared variables (flow control was just too much trouble) and am using "functional globals" instead. http://zone.ni.com/devzone/cda/epd/p/id/4364 was particularly helpful.Message Edited by kehander on 02-20-2007 12:46 PM

  • Custom data type causing trouble in deploying shared variable to RT target

    I seem to be having some difficulty in using a network published shared variable created from a custom data type when deployed as an executable on an RT cRIO target.  I'll start by describing why I believe this is where the problem lies.  I created my RT VI in the LabVIEW development environment (LV 2012) and everything works fine.  This VI is pretty simple because it rapidly devolved in to a debug exercise.  The RT VI starts by simply blinking the User LED a couple of times and then starts a simple acquisition loop to read a few values off the hardware using the scan engine (while still blinking the User LED).  After reading the hardware, the values are bundled in to a cluster and written to a network-published shared variable defined by a type def custom control.  The custom control contains five dbl precision floats.  If it matters, the cRIO RT system hosts the shared variable in this case.
    So, I deploy this under the development environment and everything works fine.  The LED blinks merrily along, telling me that the program is running properly.  Running a host VI that reads the network-published shared variable yields the desired result.  All is good.
    Now I want the cRIO system to run this simple program autonomously at startup.  I build it, set it as the startup VI, deploy it and then restart the cRIO target.  The LED never starts blinking... the VI does not seem to run.  I will spare you most of the debugging work and jump to the end.  I basically "Diagram Disabled" various sections of code until the VI started running correctly as an executable.  I kept reducing the size of the disabled code until only one thing was disabled:  the write to the custom data type shared variable.
    So, I guess my question is this:  Are custom data types defined by type def'd custom controls allowed in executable RT programs?  I've read through the cRIO Developers Guide, my NI Real Time Development course book and the Using Shared Variables white paper and I didn't see anything that forbade it.  I know that there are some things not allowed in executables that are allowed in the development environment (front panel property nodes, dialog VIs, OS-specific calls, etc), but no mention of custom data type shared variables.  Any ideas as to why my VI runs in the development environment but fails when compiled unless I remove the write to the network published shared variable?
    Thanks in advance for your help!!
    Solved!
    Go to Solution.

    Paolo,
    So I thought that you meant to disconnect them in the build specification.  Under the Additional Exclusions in the build specification, there is a check box for Disconnect Type Defs.  I checked that box, recompiled, redeployed and it did not work.  At this point I had to give and move forward, so I was going to convert the data typed from a cluster to an array.  When I went in to change the data type in the shared variable pop-up from the project explorer, there was a big button under the variable definition that "Disconnect from Type Def".  Clicked that button, recompiled, redeployed, restarted and everything worked great.  Thank You!!
    I suspect that I'll have to be careful if I change the definition of that data type (add an element, etc) since it is no longer connected to the data type.  We'll cross that bridge when we need to.
    Thanks again

  • Shared Variable

    Hello all:
    I developer a VI with OPC Shared Variable . It run good in my developer PC.
    Then package it into setup programme， intall it to another new PC.
    Run vi.exe. When deploying shared variable, i got an error.
    my_opc.lvlib\\127.0.0.1\my_opc deployment failed(error: -1967362042, os and network serviceshex ox 8abc7006)
    Attachments:
    11223.JPG ‏33 KB

    Hi,
    This url may help you:
    http://digital.ni.com/public.nsf/allkb/1F45A4298B976F4A86257168006EA0C3
    Then, when you use SV communication, you have to check :
    - the network settings of the PC,
    - the runtime Labview or a development Labview installed  on all PC.
    I hope that it has solved the problem.
    Best regards.
    R. Kaszubiak

  • Problema di polimorfismo con Read/Write delle Shared variable

    Salve,
    Cercando di modificare l'esempio di progetto "Shared Variable Client/Server" in un progetto dove sono i diversi client a mandare dati al Server ( ovvero l'esatto contrario di quello che fa )
    mi sono inbattuto nel problema illustrato nelle due figure che seguono.
    Ovvero, sostituendo "Writable PSP Variable" ad "Readable" nella scheda "Connect"(FIGURA 1) mi da un errore nella scheda "Read/Write" (FIGURA 2), ovviamente anche qui ho sostituito a "Read Variable" un "Write Variable".
    Mentre utilizzando il Data Socket funziona, ma non mi sono chiari i vantaggi e gli svantaggi nell'utilizzare quest'approccio.
    Qual'è la strada migliore tra Shared Variable e Data Socket per creare un sistema Client/Server così costituito, ovvero con un cospicuo numero di client da servire ( destinato a crescere  )che mandano simultaneamente un discreto quantitativo di dati ( circa quelli di una seriale a 115200bps ) ad un server
    FIGURA 1 
    IMMAGINE 2

    Translation 
    Hi,
    Trying
    to modify the sample project "Shared Variable Client / Server" in a
    project where different clients to send data to the server (ie the
    exact opposite of what it does)
    I untapped in the problem illustrated in the two figures that follow.
    That
    is, replacing "Writable PSP Variable" to "readable" in "Connect"
    (Figure 1) gives me an error in "Read / Write" (FIGURE 2), and of
    course here I replaced "Read Variable" a "Write Variable.
    While using the Data Socket works, but I have clear advantages and disadvantages of using this approach.
    What
    is the best route between Shared Variable and Data Socket to create a
    client / server system so constituted, or with a large number of
    customers to serve (to grow) that simultaneously sends a fair amount of
    data (approximately those of a serial to 115200bps) to a server
    The images points to a gmail location. It is not properly attached.

  • Shared Variable: Server Failure

    I'm binding Labview 8.2 Shared Variables to Fieldpoint channels, using OPCFieldPoint Server. The OPC Server works properly, i can connect to it using Server Explorer 2.4.1 and see all the channels (though i had to do a repair installation of Fieldpoint 5.0.1 to obtain this!). But Shared Variables bound to OPC Items don't work, i get "Server Failure" error both in Variable Manager and in project VIs.
    Fieldpoint channels are visible in MAX, and readable using direct Bind to Source. Just OPC and NI Variable Engine don't seem to talk to each other, though everything is on the same machine. I have even set up the SVE as explained in http://digital.ni.com/public.nsf/websearch/8719713F089653C1862570F10074E06B?OpenDocument and set an administrator account (do administrators always have DCOM privileges?).
    Thanks for any help!

    With this kind of "intelligent" FP, you don't need to use OPC!
    You can create your variable and write in it in the field point, and read it from the PC, as you can see in the example picture i attached.
    You do this simply using the variable engine.
    Ciao!
    Attachments:
    example.JPG ‏113 KB

  • Problem Connecting Shared Variable to OPC Server

    Hi All,
    I use LBW 8.2.1 and DSC.
    I try to connect to an OPC server :  Emerson DeltaV
    When using Datasocket, I am able to connect to the DeltaV OPC server and browse (DSTP Server) to the variables I want to Read/Write.
    But, since I'll need to connect to hundreds of variables I want to use DSC and so the Shared Variables.
    When I try to bind the variable, Labview cannot detect the DeltaV OPC Server... Browsing results in a "Populating Node" comment... But never completes...
    Does anyone have a clue?
    Thanx to All
    Dai
    Dai
    LV 7.1 - WIN XP - RT - FP

    Hi,
    I do not trust datasocket for this. I already tried with LBW 7.1and after something like 150 datasocket connections to DeltaV OPC, some variables do not respond anymore.
    It's kinda wierd. It happens to groups off variables. Just add one more connection and a all bunch off the other connections freeze. Remove it and it comes back...
    One application Engineer of NI told me at the NiDays that datasocket was not meant for so many variables and that I had to use DSC.
    He said something like : "Now you know why datasocket ships with Labview and that you have to pay for DSC..."
    I'll take some screenshots to explain, but later... In fact, we are going to upgrade our DeltaV to version 8 or 9 soon (currently 7.4).
    Dai
    Dai
    LV 7.1 - WIN XP - RT - FP

  • Does OPC UA Shared Variable Server support Alarm&Event and historical access?

    OPC UA Shared Variable Server is a sample code and resides at https://decibel.ni.com/content/docs/DOC-25602
    It seems to support DSC <-> OPC-UA tag synchronization.
    But does it support alarm&event and historical access?
    I tried to open it with LabVIEW 2012, but lots of VIs were missing in the code, and I am not familiar with DSC and OPC-UA.

    Hi iCat,
    From your post on the example itself, a colleague of mine responded with: "This uses the OPC UA server included in DSC 2011 SP1 which does not include direct support for Alarms and Events. However you could use this idea to synchronize to shared variables on a Windows host which could have those abilities enabled."
    So it looks like it doesn't directly do this.
    Matt S.
    Industrial Communications Product Support Engineer
    National Instruments

Maybe you are looking for