DSC Question

At the moment i have a deployment system whereby:
- Virtual machines are created by various means.
- A 'post installation' powershell script is executed by the answer file at the final stages of install.
- This script is used to do things like set-up IP addressing, host name, install software packages, anything we need.
I have been looking into DSC and i was wondering if it were possible to use it for these final stage 'state configurations'.
My only issues are:
- I cannot configure WinRM past the default config on these machines.
- I don't actually want to use the consistency feature of DSC, i just want to use it for one-time config. I want the config to be able to drift over time. I appreciate this is not quite the use which DSC was designed for.
Is it feasible to setup DSC in pull only mode, let it perform a state configuration and then effectively remove\disable any trace of DSC?
Cheers.

You'd be better off using a Push rather than a Pull, in the scenario you've described.  You can set the LCM to ApplyOnly mode, which will apply the configuration you push, but then will not bother to re-check the system on a schedule afterwards.
As to whether using DSC this way adds any value over just using your existing scripts, that's a harder question to answer.
Possible pros:  DSC resources will eventually get more use and scrutiny by the community, possibly more reliable code.  Automatic logging into the event log which you can archive and/or review later to see what happened.  Simpler code for
you to write; the configuration itself doesn't show all the complexity of the resources themselves.
Cons:  Many DSC resources currently available have problems, and may not be ready for prime time yet.  You'd have to re-implement all of your scripts as DSC configurations, possibly even having to write some custom DSC resources if the existing
set doesn't quite meet your needs yet.  Basically, time investment (and possible introduction of bugs that aren't in your scripts today.)

Similar Messages

  • Dedicated Forum for LabVIEW DSC?

    I would like to see a dedicated forum for LabVIEW DSC.  Right now
    I'm not sure where to post DSC questions:  LabVIEW general,
    Lookout, or some other?  Even if the Lookout and LabVIEW DSC forum
    was consolidated into one, at least it should be labelled in the forum
    list.
    David Moerman
    TruView Technology Integration Ltd.

    Sep 6, 2005
    Dear David,
    Please post your LabVIEW-DSC questions in the LabVIEW-RT or the Lookout forum for now. I will pass on your suggestions to the right people at NI.
    Have a great day!
    Regards,
    Prashanth.

  • DSC Run-Time Licence Questions

    Hello,
    I have recently discovered that LabView Developers Suite that I thougt was a complete development & deployment platform is not:
    Since I had chosen to use DSC Modbus funcitonality, I need the DSC Runtime as well, apprantly both on my development system, and on the PC where the system will be deployed.
    As bad as this is, I find it more frustrating to find out how these licences must be handled.
    Our customer is a Precast Concrete Production plant that is not accustomed to handling software installation and licence issues.
    Further, the PC is of course not online to the internet: This is a rough production environment.
    I will build a complete installation package so that that customer can install the complete software onto the PC in a few easy steps.
    I thougt LabView was up to this task, but I am now wondering if this is the case.
    My questions are:
    Must the DSC Runtime Licence be activated on the client's PC?
    If yes, how is the licence activated when the PC has no internet connection?
    PCs quite frequently die in these rough environments, and the client must be able to quickly install my software package onto a new PC to keep the production running!
    Can the client reinstall my software package on a new PC with no DSC Runtime licence hassle?
    What are the exact steps to do this?
    Suggestions:
    I strongly feel that NI should put up information about the fact that a DSC runtime is needed and links that explain these Licence issues on the following page:
    http://sine.ni.com/nips/cds/view/p/lang/en/nid/1012
    The page above should also contain a link to this page: http://www.ni.com/labview/labviewdsc/faq.htm
    Like it is now, developers are waiting valuable time to find answers to thse questions (at least we did).
    Message Edited by geirove on 12-07-2009 03:44 AM
    Message Edited by geirove on 12-07-2009 03:46 AM
    Message Edited by geirove on 12-07-2009 03:48 AM
    Geir Ove
    Solved!
    Go to Solution.

    Christian_M wrote:
    Hi,
    If you simply need to use ModBus, here is a free library for LabVIEW: http://sine.ni.com/nips/cds/view/p/lang/en/nid/201711
    To your questions:
    Must the DSC Runtime Licence be activated on the client's PC? Yes
    If yes, how is the licence activated when the PC has no internet connection? You can call your local NI Office, give them the Serial Number and the Computer ID (could be found in the license manager) and activate it per hand.
    PCs quite frequently die in these rough environments, and the client must be able to quickly install my software package onto a new PC to keep the production running! They can again call NI with the new computer ID
    It is not an option to start rewriting code to use the Modbus library directly at this time. We use DSC to bind Shared Variables to Modbus addresses.
    So NI is open 24  * 7 to support this and other 24 * 7 industries with new Runtime Licenses when a Control System PC / RT Module breaks down?
    This does not look good for using DSC functionality in this industry. The potential client base here, is quite large: > 130 factories throuhtout Europe.
    Why doesn't NI simply let users run 30 days on a temporary DSC Runtime License the way you do it for all other NI products?
    a) This way we could test the software.
    b) Clients could reinstall and have 30 days to get help to activate the DSC Runtime License.
    Does not look like NI is interested in supporting 24 * 7 industries at all !
    Better suggestions from NI?
    Geir Ove

  • Some DSC developing relating questions

    Hi,
    I am new with DSC and have some questions relating to building the custom periodic I/O DSC server:
    1. After building the custom VI and implementing it as an I/O DSC server, I found there are some mistakes inside the custom VI. I would like to modify it and rebuild it. But all of the shared variables are bound to this server. What I did is I deleted and removed these variables and rebuild them again. It takes a lot of time when I want to  modify this custom VI. Is there anyway to avoid it?
    2. To communicate with the custom VI, I use some controls and indicators. But to program a VI sometime I need to initialize or change the value of controls. But the guidelines for creatin a data access VI, I cannot use the local variables, property nodes, or control references for those controls need to be public. I would like to know if there is any solution to program effectively in my situations?
    Thank you,
    Thang

    Hi - I'd like to clarify the issue you are having in question #1.
    Here's what I think you are doing:
    1.  You write a VI with some controls and indicators wired to the VI's connector pane.
    2.  You use the DSC "create periodic I/O wizard" to create the server VIs.
    3.  You open an empty project and right-click "My Computer" and select "New->I/O Server".  You then select "Custom VI - Periodic" from the list and click "Continue".
    4.  You see the name of the VI you created in step 2 under "configuration name" pulldown and click "OK".  A new library appears in the Project Explorer called "Untitled Library 1". 
    5.  You click the "plus" and see a globe on a hand icon with the name "Custom VI - Periodic1" or something similar related to your VI name.
    6.  You right-click on "Untitled Library 1" and select "create bound variables".  You then navigate down through the tree structure to your server inputs and outputs and select them and add them and then click OK.
    7.  The Multiple Variable Editor pops up showing the new variables.  You click "done" and see the new variables listed in your project explorer window.
    8.  You use these variables on your Client front panel by dragging them from project explorer onto your VI front panel where they work ok.
    9.  You want to make changes to the VI server, and rebuild it, and update your Client VI.  Rebuilding the VI server is no problem.   I don't think you will have any problems as long as you haven't added or changed any variable names.   If this is what your question #1 is about, then there are several different ways to deal with this using the multiple variable editor, or the front panel mass binding editor.

  • Questions re: Licensing & Feature Availability of the DSC module

    Hello,
    I transferred a project to another development PC. When I opened it, some of my network shared variables (NSV's) were flagged with Feature Errors: "Initial Value: Not licensed or cannot be edited outside of LabVIEW." I found out that it's because I didn't install the DSC Module on the newer machine; removing the "initial value" feature made the error message disappear.
    That error itself wasn't a big deal, but it got me thinking and investigating. http://www.ni.com/white-paper/4679/en says:
    If you want to use the features of the LabVIEW DSC Module, you must host the shared variables on Windows. The LabVIEW DSC Module adds the following functionality to network-published shared variables:
    · Historical logging to NI Citadel database.
    · Networked alarms and alarm logging.
    · Scaling.
    · User-based security.
    · Initial value.
    · The ability to create custom I/O servers.
    · Integration of the LabVIEW event structure with the shared variable.
    · LabVIEW VIs to programmatically control all aspects of shared variables and the shared variable engine.
    Question 1
    I did not realize that the Initial Value feature was part of the DSC Module. If I use it in a project, does that mean that my customer would need to buy a DSC runtime license? (I'm not using any other DSC feature)
    Question 2
    In my project, the NSV's in question were hosted on a cRIO target, yet my prototype (which had Initial Value enabled) ran happily without issues. This contradicts the documentation above which says "you must host the shared variables on Windows". Is this expected?
    Question 3
    I created a new NSV on my new machine (which doesn't have DSC installed). I saw the "Scaling" option. Is Scaling part of the DSC module or not?
    Question 4
    Initial Value and Scaling are generic features, unrelated to data logging/supervisory control. Why are they in the DSC Module? Should they not be in the base SV Engine?
    Solved!
    Go to Solution.

    Hi,
    1. Yes, any build that uses DSC features require a runtime license.
    2. That's a recommendation for more reliable operations.
    3. No, it is a native LabVIEW capability. The DSC modules simply adds more features regarding communication to protocols, alarming, etc
    4. Initial value, Yes. Scaling, no. I believe is for easy access. Old school method is the one shown in here at the section "Initialize Your Shared Variables".
    For more information about DSC visit this page.
    Alejandro | Academic Program Engineer | National Instruments

  • Data Logging and Supervisory Control (DSC) Alarm Acknowledge / General Alarm Questions

    Hi All -
    I would like to know if anyone can help me with DSC and alarms.  I have several shared variables that I have setup with alarms and logging with DSC.  I can view them with the Shared Variable Manager, the value, status, alarm state, etc.  So, I want to be able to view this info on my Front Panel and acknowledge alarms there - - Is that possible?  I put "alarm and event display.vi" on my front panel and it shows when a variable goes to alarm state, but I don't see how to acknowledge the alarm once it enters the alarm state.
    Other question, once a variable is in an alarm state, obviously it stays there until it is no longer in alarm, but if you acknowledge it - - what happens? does it stay 'red' color and remain in the alarm list - and what about logging, does the log indicate when the alarm was acknowledged any by whom?
    So that is my next question, how do I setup and force a user to 'log-on' to be able to acknowledge alarms?
    If anyone could point me at a document / tutorial / example I would really appreciate it!
    Thanks!
    Get Mystified

    Mystic wrote:
    Hi All -
    I would like to know if anyone can help me with DSC and alarms.  I have several shared variables that I have setup with alarms and logging with DSC.  I can view them with the Shared Variable Manager, the value, status, alarm state, etc.  So, I want to be able to view this info on my Front Panel and acknowledge alarms there - - Is that possible?  I put "alarm and event display.vi" on my front panel and it shows when a variable goes to alarm state, but I don't see how to acknowledge the alarm once it enters the alarm state.
    Other question, once a variable is in an alarm state, obviously it stays there until it is no longer in alarm, but if you acknowledge it - - what happens? does it stay 'red' color and remain in the alarm list - and what about logging, does the log indicate when the alarm was acknowledged any by whom?
    So that is my next question, how do I setup and force a user to 'log-on' to be able to acknowledge alarms?
    If anyone could point me at a document / tutorial / example I would really appreciate it!
    Thanks!
    Get Mystified
    When your VI is running, you can right-click on the alarm & event display control and it will give you the option of acknowledging the alarm.  Another option would be to use the Acknowledge Alarm.vi and create your own interface.
    Once the alarm is acknowledged, the alarm color will change to magenta and the acknowledgement information will be displayed.
    The acknowledgement information - user, time, comment - will be logged if logging alarms is enabled.
    Regards,
    Robert

  • DSC-RX100 III - 50i (French model) - observations and questions

    SONY DSC-RX100 III running firwmare Ver. 1.00 out of the box.Unit made in China serial 288XXXX.French specs - PAL 50i model Pros:This is an excellent camera! I love the weight (heft) and feel to the touch. The wider end of the lens is now 24 mm and it is fast F1.8.Neutral Density filter built-in! The functions and manual controls do not disappoint either.The PlayMemories Mobile app v. 4.2.2 (which is required to use the Remote Control app on the camera) also works as advertised on my Android Nexus 5 running 4.4.4 to remote trigger the shutter and then transfer the shot over to the phone via WiFi.Can't comment on the image quality as I just got it yesterday and I am still learning to use it properly.  Cons:The LCD pannel on my unit leaks light from the bottom left corner and the whole vertical right side. Very annoying.Also, I can see it getting scratched with use by the body sharp edge when the panel is flipped-up (why not rubberize that part?). I *really hate* how pushing the viewfinder down will turn the camera off. It should stay on. They did this because opening the viewfinder will turn ON the cam if it's OFF and they figured it should go OFF too when the viewfinder is put away. The solution is to add a menu item to let the user choose. FIRMWARE this update please!!! Switching the camera to record video to NTSC 60i will cause the camera to show that info *every time* the camera is turned ON. ***This is also very very annoying***. FIRMWARE UPDATE THIS AS WELL PLEASE. I can't find anywhere in the User Manual or online a complete legend of all the symbols displayed on the screen. Some of those I have no idea what they mean, e.g. a green running little man which shows up and disappears.Someone please send this info.   

    Thank you for your note. Yes, I have been using it in Auto Mode. The little green man. I think it sense motion as it only seems to show when I am making ample moves with the camera in hand. Light leak means that the lights is visible through an opening/ gap in the frame surrounding the LCD screen. Obviously it is not normal and I have seen have had my RX100M3 exchanged  by another one. The new one is from a more recent produciton batch serial 289XXXX, doesn't have that problem but the LCD screen has a slightly yellowish tinit to it. So annoying. Video: I thought there is only one way/ mode to shoot video.There is a discussion about this on dpreview as well. I also would like to see an edge/ border protective rubber edge or something similar to protect the screen when it's deployed vertically and touching. The current implementation has me worried it will gret scratched somehow.  Let's Sony know we expect a fix for everything listed.Please pile on!   Love it otherwise!    

  • Questions about LabVIEW

    Dear support team,
    Could someone please respond to Eric's questions? Eric works at Bonneville Power Administration and they are gearing up for another major LabVIEW and DSC project. He may have LabVIEW 7 beta. I am on my way out of town for two weeks and won't have access to phone or email. Thanks!!
    Tricia Lee
    DSM Inland Northwest
    [email protected]
    "Pierce, Eric - TNCB-TPP-2"
    05/01/2003 08:05 AM
    To: [email protected]
    cc:
    Subject: The list of question i never sent
    Sorry for the long delay, things have been very busy here with this new project. I have questions / concerns about the DSC, OPC and LOGOS; first here is our architecture.
    We will have two servers running windows 2000 server. Both servers will be live and need to have all DSC components installed. One server is to act as the primary server and the second is to act as a failover server. We have custom components that manage all of our custom services, if one of the custom services stops responding the failover service will shut down all custom services on the primary server and start all of the custom services on the secondary server, thus, the secondary server becomes our primary live server.
    My understanding is that we will have to load a *.spf file on each HMI that tells the HMI where the server is, at the same time we need to initialize the DSC and OPC with *spf and *.lpd files. Now I might have the file extensions wrong but the idea is the same. We have all of our data in a SQL 2000 database, how do we make sure that all of the configuration files match the SQL 2000 db? We have several GUI's that can edit the SQL 2000 data, how do we update the DSC / OPC configuration files?
    So in short here are my current questions:
    How can we manage failover with two live servers
    How can we ensure that DSC / OPC / Logos configuration files match the data in SQL 2000?
    Does any of this make sense? This labview stuff is very new to me.
    Eric Pierce
    ACS Group, Inc.
    Sr. Software Engineer
    w. (360) 619-6284

    Hi Eric,
    You got it right that once the primary machine goes down, the standby machine detects this, and then loads the appropriate SCF file, etc. Caveat: This would mean however that the hardware in question is accessible by both the machines (it's on an Ethernet, for instance). Any hardware physically connected to the primary machine will obviously be not accessible by the secondary (unless there's a way to have a "Y" connection).
    The logging part you mention is not very clear to me. Several questions come to mind: Isn't DSC the logger, logging to its Citadel database? Or, is SQL 2000 the main database? And DSC is logging to SQL 2000? If yes, how? Or is the SQL 2000 querying Citadel and hence getting the data into itself?
    Regards,
    Khalid

  • How to Setup Historical DSC Database on a standalone Server

    Hey @all,
    I am looking for documentation how to setup a standalone server for the DSC Module(Ver. 8) Historical Database.
    My aim is to log all data to this server. The Server will be running Win2K.
    Do I have to install the complete Labview 8 software and the DSC Module?
    Does a walkthrough exist how to setup a DSC server?
    Thx!
    Carsten  

    After installing the runtime you should only have to reboot the computer in order to get the citadel service running.  At the point, for citadel purposes, this machine will behave as though you had the DSC development system installed.  The 8.0 runtime has no setup requirements...it should only need to be installed.  Unlike previous versions, 8.0 requires you to build your application into an executable and the runtime should be invisible to you once you install it.  If this is not the case, please post about it so it can be looked at.
    If you have specific questions, please post them and I will either try and help you find the answers, get them posted, or answer them myself.
    Regards,
    Robert

  • 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

  • LV7.1 DSC tag engine VS LV8.6 DSC shared variables

    I'm currently running LV7.1 with DSC and RT. To handle communications and logging RT variables I'm using the init / read / write publish.vi's on the RT side and datasockets on the HMI side (Windows XP). This has worked out great - new tags can be programmatically created in real time with the publsih vi's and then I go to the the .scf file and use the tag configuration wizard to add them to my scf file and handle data logging. This worked very well - the wizard would organize all of the memory tags into folders by block name used by the init publish vi. I could also select entire groups of tags and add hundreds at a time to the .scf file. Hardware Tag also worked in a similar fashion, organizing tags by controller and module folders. Now - looking at LV8.6.I found I can still use the init / read / publish vi's on the RT side - great. However there is not tag configuration editor as in LV7.1 to let me add large numbers of tags through a wizard. The closest thing I've found is to create a library to represent each block name from the RT init publish.vi then use "create bound variables" option under the library to bind the new shared variables to the RT memory tags. I can browse to the tags on the controller by network items, but when I add them it doesn't bring the block name of the tag as it did in 7.1, only the item name. I use a lot of PID loops that share the same tag names (i.e.: P,I,D, mode, output), so not including the block name represents an organizational problem. The problem with this is, it's very labor intensive compared to the wizard in LV7.1 DSC, especially talking about creating systems with thousands of RT memory tags. Also, there is a similar problem with hardware channels (I'm using compact FieldPoint). To log channels via DSC do I have to create a shared variable for each channel to access the DSC logging capabilities? Again how do I add all of the hardware channels in some organized fashion? I hope I'm missing some tool that is an analog to the tag configuration wizard to bring in these channels and organize them. Any help or suggestions would be appreciated. Thanks,Brad

    Hi lb,
    We're glad to hear you're upgrading, but because there was a fundamental change in architecture since version 7.1, there will likely be some portions that require a rewrite. 
    The RTE needs to match the version of DSC your using.  Also, the tag architecture used in 7.1 is not compatible with the shared variable approach used in 2012.  Please see the KnowledgeBase article Do I Need to Upgrade My DSC Runtime Version After Upgrading the LabVIEW DSC Module?
    You will also need to convert from tags to shared variables.  The change from tags to shared variables took place in the transition to LabVIEW 8.  The KnowledgeBase Migrating from LabVIEW DSC 7.1 to 8.0 gives the process for changing from tags to shared variables. 
    Hope this gets you headed in the right direction.  Let us know if you have more questions.
    Thanks,
    Dave C.
    Applications Engineer
    National Instruments

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

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

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

  • Dsc 8.20 bug

    HI,
    there is an issue with DSC 8.20 and opc client (updated or not) that is bugging me.
    Make a new library with an opc client inside and deploying works.
    Change the name of the computer (restart the computer) and 
    when  I try  to deploy  a library  with opc client
    inside it , I get "Visual C++ runtime error, Labview needs to close in
    an unusual way.....".
    Verified with win2000 and winXP with DSC 8.20.
    Another issue is that from a computer with winXP the opc client does
    not connect to a any opc server from a win2000 computer besides
    OPCLabview ver.6.
    I followed every configurations (DCOM and else) specified by NI. From win2000 to win2000 works ok.
    cosmin

    Cosmin:
    Thank you very much for your response, here are some suggestions/answers for your questions:
    1. I created a library with an OPC server using LabVIEW DSC 8.2 and I then deployed it. After renaming and restarting my computer, I re-deployed my library and everything still worked fine. I am curious as to what you did differently to obtain that error.
    2. I would suggest you to see if you can use "Server Explorer" to communicate with your OPC server on the client pc that is running Windows XP and let me know what you find.
    3. Regarding not being able to install LabVIEW on a computer with Win 2000 and sp2, Page 3 of the LabVIEW Release Notes mentions that to use LabVIEW with Windows 2000, you must have service pack 3 or later installed.
    I hope this helps and please let me know what I need to do to reproduce your issue.
    Best Regards,
    Rudi N.

  • LabVIEW DSC: Migration from 6.1 to 8.6 problems

    Colleagues,
    I need help from someone who experienced with LabVIEW DSC. I would like to recompile pretty old application written in LabVIEW 6.1/DSC 6.1 to LabVIEW 8.6, and got lot of troubles with this.
    At the first I have tried to migrate my old scf file as described here: "Migrating from LabVIEW DSC 7.1 to 8.0".
    Well, it seems to be OK, and LabVIEW.lvlib library with variables was created, but when I tried to double click on the some items, then exception occurred in LabVIEW (see dsc_exception.png in attachment).
    Can you please open test project (attached to this post) and double-click on the Slave005_A0 Item? Is crash happened only by me or by someone else?
    The second problem with understanding.
    In LabVIEW DSC 6.1 I have used "Read Tag.vi" / "Write Tag.vi" vis for accessing the items. When my VI opened in LabVIEW/DSC 8.6, then these calls replaced with "legacy_Write_Tag_(analog)7x.vi" (see screenshot). I'm unable to found according VIs in DSC 8.6. How can I write/read my tags in the latest version? As far as I can understand, I can use Shared Variables directly. Is this correct? But then how can I read multiple tags? Through DataSocket VIs?
    The same with "legacy_Get_Tag_List7x.vi". How can I get items list in DSC 8.6 programmatically?
    Or should I leave all legacy* vis in my application?
    thanks in advance and best regards,
    Andrey.
    Attachments:
    dsc_exception.png ‏26 KB
    dsc_legacy_Write_Tag.png ‏3 KB
    TestProject.zip ‏4 KB

    Hi Andrey,
    Yes, my LabVIEW crashes as well. As you may have noticed, a lot has changed in LabVIEW 8.0 with regards to DSC, the most important being that tags are replaced with Shared Variables. I would recommend that you go through each variable and create them by yourself to ensure the most reliable performance. 
    If you are interested in reading 'tags', then you just need to drag the Shared Variable and place it on the block diagram (that's the direct way). If you are interested in doing this programatically, then have a look at the DSC Module -> Engine Control -> Variables & I/O Servers -> Get Shared Variable List palette on the block diagram. You can then use DataSocket to access the Shared Variables.
    Don't leave the legacy VIs on your block diagram. Upgrade your whole project; shared variables are here to stay. Have a look at the following article to get a thorough understanding of them:
    Using the LabVIEW Shared Variable
    Let us know if you have more questions.
    Adnan Zafar
    Certified LabVIEW Architect
    Coleman Technologies

  • Do I need to buy OPS server for target PC to deploy my DSC application?

    I'm planning to use LabView as SCADA system and distribute my application on several PCs. So, the plan is to have Engineering PC with LabView + DSC Module + OPC Server + Application Builder to design my applications.
    As I understand, these are the steps to be taken, in order to deploy my application on standalone PC: 
    On Engineering PC
    1) Configure OPC server with proper channel and tags.
    2) Include my OPC server as I/O Server into my LabView project.
    3) Create my Shared Variables (linked to my PLCs via mentioned I/O Server).
    4) Design my panels.
    5) Build my Application (with Shared Variable Deployment function).
    6) Build my Installer (if required).
    On Target PC:
    7) Install DSC Run-Time System.
    8) Deploy my Application.
    Now, the question is - Will my Application (or Installer) include OPC Server or I have to buy it and install on each target PC?
    In other words, will my application still be able to communicate to PLC without additional installation of OPC Server on that particular standalone target PC?

    I dont use the DSC too much but this link might help
    http://digital.ni.com/public.nsf/allkb/E56DB8726DB68F288625770E00594351
    Some labview addons such asa vision require a paid license for deployment. 
    Paul Falkenstein
    Coleman Technologies Inc.
    CLA, CPI, AIA-Vision
    Labview 4.0- 2013, RT, Vision, FPGA

Maybe you are looking for