Dsc shared variable property are saved to library?

Hi,
I would like to be sure to know if the shared variable properties like "alarm level" and "description" are saved to the library directly?
If not, where? database?
Also can we not add table to the dsc ms sql express database? (the one for alarms and events)
Thanks
Patrick
Message Edited by paubine on 09-04-2009 08:23 AM

The properties of the shared variables like alarm and description do get saved to the library. As for your second questions about a table in ms sql, can you tell me more about this? Are you using the LabVIEW DSC VIs to do this, if so provide a screen shot or your code or a good description. Tell me exactly what is going wrong, what behavior you expect and what you are seeing.
Thanks,
Anna K.
National Instruments

Similar Messages

Using Modbus TCP I/O Server with new DSC Shared Variables in LabVIEW 8.6

Hello,
I'm using LabVIEW 8.6 and want to communicate with a Beckhoff BK9000 Ethernet TCP/IP Bus Coupler via Modbus TCP. Instead of using the NI Modbus Library, I've tried the new LabVIEW 8.6 feature "DSC Shared Variables" as described at the bottom of this page: Latest NI LabVIEW DSC Module Features and Demos. Reading of analog input bus terminals works fine. However, I haven't figured out yet how to write on an anolog output bus terminal with these shared variables.
It's about a 16 bit analog output and I need to write to the registers 0x1121 and 0x0801. It works with the NI Modbus Library (just using function code 6 and choosing the registers), but on the other hand I don't know which shared variables I have to choose for these registers. I've tried several data items (e.g. 400001 upwards as well as 402049 for 0x0801) but none of them worked. I would be glad for a short explanation - thanks in advance for your support!
Regards
utechle

The Beckhoff documentation says, that holding registers start with 0x0800. I've checked this by using the NI Modbus Library. I used the "MB Ethernet Master Query.vi" togehter with the function code 6 for "Write Single Registers", changed the settings of the starting address to hexadecimal view and entered 801 (since it starts with a control byte in 0x0800 and the data out word follows in 0x0801). Furthermore, I had to address register 0x1121 in the same way for resetting the watchdog. As I've mentioned in my first post, this method works fine. However, I haven't found out yet which shared variables i have to use for accessing these registers.
On the other hand, it's no problem to read data from analog input bus terminals using shared variables. They start with 0x0000 (status byte) and 0x0001 (data in word) and I can read data with the shared variable and data item 300001, respectively.
Message Edited by utechle on 01-27-2009 11:12 PM

Performance of Modbus using DSC Shared Variables

   I'm fairly new at using Modbus with LabVIEW. Out of the roughly dozen tools and API's that can be used, for one project I'm working on I decided to try using Shared Variables aliased to Modbus registers in the project, which is a DSC tool. It seemed like a clever way to go. I've used Shared Variables in the past, though, and am aware of some of the issues surrounding them, especially when the number of them begins to increase. I'll only have about 120 variables, so I don't think it will be too bad, but I'm beginning to be a bit concerned...
   The way I started doing this was to create a new shared variable for every data point. What I've noticed since then is that there is a mechanism for addressing multiple registers at once using an array of values. (Unfortunately, even if I wanted to use the array method, I probably couldn't. The Modbus points I am interfacing to are for a custom device, and the programmer didn't bother using consecutive registers...) But in any case, I was wondering what the performance issues might be surrounding this API.
    I'm guessing that:
1) All the caveates of shared variables apply. These really are shared variables, it's only that DSC taught the SV Engine how to go read them. Is that right?
   And I'm wondering:
2) Is there any performance improvement for reading an array of consecutive variables rather than reading each variable individually?
3) Are there any performance issues above what shared variables normally have, when using Modbus specifically? (E.g. how often can you read a few hundred Modbus points from the same device?)
Thanks,
    DaveT
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
There are 10 kinds of people: those who understand binary, and those who don't.
Solved!
Go to Solution.

Anna,
    Thanks so much for the reply. That helps a lot.
    I am still wondering about one thing, though. According to the documentation, the "A" prefix in a Modbus DSC address means that it will return an array of data, whereas something like the F prefix is for a single precision float. When I create a channel, I pick the F300001 option, and the address that is returned is a range: F300001 - F365534. The range would imply that a series of values will be returned, e.g. an array. I always just delete the range and enter a single address. Is that the intention? Does it return the range just so you know the range of allowed addresses?
   OK, I'm actually wondering two things. Is there a reason why the DSC addresses start with 1, e.g. F300001, instead of 0, like F300000? For the old Modbus API from LV7, one of the devices we have that uses that API has a register at 0. How would that be handled in DSC?
Thanks,
    Dave
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
There are 10 kinds of people: those who understand binary, and those who don't.

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

Using a Meter control in LV Touch Panel, and using shared variables that are custom controls.

I Just started using LV touch Panel module with an NI TPC-2106.
I have two differenct problems:
1) I was planning on using the "Meter" control quite a bit. I can set up the meter exactly how I like on the host PC, but on the touch Panel computer it seems to ignore my adjustments, mainly the start and end of the scale - i.e. I would like control to run from 0 to 360 with 0 straight up, using the entire circle. However, on the Touch panel computer it always puts 0 at about 7 o'clock and 360 at about 5 o'clock. I have also tried adding markers to no avail.
2) I am communicating with a compact fieldpoint controller. I can creat a shared variable that is a simple double with no problems. However, I have some shared variables that use a custom control for the variable type - bascially a cluster with a couble doubles, a time stamp, and an enumeration. It lets me drag the shared variable into my diagram, but it seems to ignore it when I run it.

Ipshita_C,
- I am using LV 8.6.1f1and LV Touch Panel 8.6.1.
- I have attached a simplified VI that shows how I want to use the meter. Notice that the placement of the endpoitns does not work correctly on the touch panel, and that it ignores the arbitrary markers that I placed.
- I also have included an XY graph control that displays on the TPC with margins around the graph area that I removed from the graph control.
- For the shared variable, it appears to be an issue related to the touch panel, not fieldpoint. I found another thread in this forum that mentioned that clusters containing Enumerations do not work in shared variables on the touch panel. I changed the enumeration to an integer and it now works fine.
In general, there seem to be a disappointing number of limitations in the touch panel implementation. My biggest concern is that I have not found any documentation from NI that lists these limitations. I seem to have to try things out and see what works and what does not work. Can you point me to a comprehensive list of touch panel modules limitations?
Attachments:
test 2.vi ‏10 KB

Shared PL/SQL Area of the Library Cache

When Oracle allocates a Shared PL/SQL Area, do the SQL statements in the block get broken out into a separate Shared SQL area?

They should be in v$db_object_cache.
See: http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14237/dynviews_1083.htm#sthref3589
Message was edited by:
Pierre Forstmann

My font book won't install new fonts. These fonts are saved in Library/Fonts so not sure what is happening. Please help.

I am trying to install fonts from the internet, from dafont.com...in particular colleged.
I have downloaded the font, and saved it under User/Library/Fonts - and it appears there, but for some reason when i try adding this to my fontbook it will not install. I need it for Adobe InDesign.
Please help.

See Font Management in OS X for starters.

Shared Variable Properties and DSC

Is there a way to assign engineering units to a shared variable as a
configuration parameter? This should be on the "Scaling" page of
the shared variable properties. It seems this is a logical and
convenient place to track units. Assigning units programmatically
using the Scaling:Units property is awkward (to say the least).
On similar lines, why aren't shared variable properties automatically
saved to the DSC historical database? Every trace should have a
set of information that exposes ALL the shared variable properties that
created it. Take something like engineering units for
example: then you would know what kind of historical trace you
are looking at! This seems so basic I can't imagine why it was
missed.
Unless I missed something -- please enlighten me.
Regards,
David Moerman
TruView Technology Integration Ltd.

Hello David,
You are correct in that the units property is not exposed on the
Scaling page of hte Shared Variable properties dialog, and it sounds
like you are already well aware of the existing method to access this
property through the property node interface. As you have also
discovered, the Citadel database that we use with DSC does not have a
built-in provision for storing metadata about the shared variable from
which a trace originates. You can emulate this with, for example, an
array of strings which is also logged to the database, with each string
containing the metadata for a particular trace.
Since it seems like having these features would benefit you, I
encourage you to let our DSC development group know your needs by
filling out product feedback, accessible on our site at
http://www.ni.com/contact . This will send a feature request
directly to the appropriate R & D group, who reads and evaluates
every suggestion made. This is your most direct way to let us know
what features would best meet your needs.
Cheers,
Matt Pollock
National Instruments

Enable shared variable buffer

Dear all,
I'm writing on a program to create shared variables programmatically. I use the examples available in labview and DSC 8.0 as reference. I'm able to create and set the different properties such as scaling, alarms, inital value etc for the shared variable(s). However, when i wire a boolean "true" to " enable buffering", it doesnt seems to work. I checked the shared variable created in the shared variable engine, the variable is created but the buffering cant be enabled programmatically. Can anyone guide me what's the fault? thanks.

Hi,
The VI worked without any problem though I had to change the shared variable name. One thing to note about changing the properties of shared variables programmatically using the shared variable I/O is that it only affects the deployed shared variables and not the actual library file. In essence, these changes are not saved in the library. So the shared variable properties window will not reflect the current status of the "Network.UseBuffering" option. To verify that the "use buffering" is enabled, place another "Network.UseBuffering" property node on the block diagram and read the current state from it.
Attached is a modified version of the VI with the current status of the "Network.UseBuffering" property for the deployed shared variable.
Tunde
Message Edited by Tunde A on 03-05-2007 12:34 PM
Attachments:
Modified_buffering_error.vi ‏10 KB

Network shared variables lose binding

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

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

Why do Single-Process shared variables create a single variable VI in my dir.

I'm creating an application VI following the example which is created by starting a two loop Real-Time project which creates a Single-Process shared variable and a Network-Published shared variable for each variable that needs to be sent to a non-Realtime host VI. Each of the Single-Process variables shows up as a VI file with the following format: <variable library>_<variable name>.vi. The VI has one control which is the shared variable. I have a large number of variables and this creates a lot of clutter in the directory. I expected them to be rolled up into the library file. Is this expected behavior? I'm attaching a screen shot to show the behavior.
Attachments:
Shared Variables in Directory.JPG ‏383 KB

Hi davidreed10,
This is a known issue with single process variables that are saved in a
project that has the .lvproj and .lvlib files initially saved in different
locations, as is the case with Real-Time projects. This has been
previously reported to our R&D department with the ID #56580, and
is being worked on for a fix in a future release of LabVIEW.
This should be only a problem for Single-Process variables, and not
Network-Published variables, so if you want to keep your folder from
getting cluttered up, changing the variable types to Network-Published
should get you around the problem for now.
Regards,
Stephen S.
National Instruments
Applications Engineering

Shared variables location

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

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

How to use shared variables with native c programs

Hello
What is the way to use shared variables with native c programs?
I have a c/c++ program that uses the NIDAQmx C-API to perform measurements. Now I want to communicate to a LabVIEW program via shared variables.
Is there a C-API for shared variables as there is for the NIDAQmx functionality? Where can I find further documentation? The document "Using the LabVIEW Shared Variable" mentions that one "can read and write to shared variables in ANSI C", but there are no hints about how and where to look.
Thanks in Advance

Hi user42,
with CVI 8.0, you cannot create or configure shared variables. However, you can read or write to an already configured LabVIEW 8.x shared variable from CVI using the DataSocket API.
In order to do this you need to have and DataSocket 4.3 or higher installed.
Here's a forum post about using the DataSocket functions a LabVIEW Shared Variables:
http://forums.ni.com/ni/board/message?board.id=180&message.id=24569&requireLogin=False
With CVI 8.1 and Measurement Studio 8.1 it's possible to use Shared Variables via the Network Varaiable Library (check out the end of the "Network-Published Shared Variable" section within the "Using the LabVIEW Shared Variable" documentation and the following link).
Datasocket with LabWindows/CVI and LabVIEW Real-Time:
http://digital.ni.com/public.nsf/allkb/CC4343488413A2F586256E6200099638?OpenDocument
Daniel
NIG

Debug shared variable array

I am passing data between a PXI RT Target to a PC Host using Shared Variables. Everything passes correctly between the Host and the Target, but Shared Variables that are arrays do not pass between the Target and the Host. Single elements whether boolean, numeric, or string pass from Target to Host with no problem. I use NI Distribution Manager to examine Shared Variables. How can you find the content of a Shared Variable that is an array, without writing my own VI?

This tool doesn't give me any more information than the Dist Sys Mgr. The SVs that are working show quality "good" vs "no know value" for the SVs that are not working.
My network-published SVs are single-writer 1D arrays (U32/SGL) of varying sizes (64-1005).
When I write to the SV I get error -2147024891 with the source being \\My Computer\Lib\mySV\\xxx.xxx.xxx.xxx\Lib\mySV where xxx.xxx.xxx.xxx. is the IP address of My Computer.
When I read the SV I get warning -1950679044with the source being \\My Computer\Lib\mySV\\xxx.xxx.xxx.xxx\Lib\mySV where xxx.xxx.xxx.xxx. is the IP address of My Computer. I get this warning when I'm reading the SV either from the target or the host.
I've checked the properties pages for the SVs and I don't see how LabVIEW is interpreting the network path twice. What could be causing this?
Also, if I delete a SV from my library of SVs it still shows up in the Dist Sys Mgr until I restart LabVIEW. Why?

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

Dsc shared variable property are saved to library?

Similar Messages

Maybe you are looking for