Version compatibility in shared variable communication

I have a cRIO running a new piece of hardware that arrives today. I have done all the development in LV 2012/13, but we still have some older machines running LV 8.6.1. These machines will be upgraded soon-ish, but the code is byzantine and so it will probably require some downtime to do the switch. In the meantime, I found conflicting information online (e.g., here and here) about whether I can communicate between these systems using shared variables. I do not want to do a lot of this, but it would greatly ease the transition if I could write a few booleans and doubles from the old computers to either the cRIO or to the new computer as a stopgap.
In LV 8.6.1, I can see the cRIO and the names of the shared variable libraries on the Distributed System Manager. However, MAX says the system is unsupported if I try to connect that way. The Distributed System Manager also seems unreliable--just poking around this morning, it has frozen a few times, and right now for some reason it doesn't show any of the variables, just the target's IP address (although it's not grey). In LV itself, I can't figure out any way to make the shared variables appear, but I have never tried to use them in a pre-2012 version of Labview, so maybe I just don't understand how to do that.
Is there any way I can make this work, or do I have to do something stupid like communicate with text files and while loops between these systems until I get them all upgraded to the same version of Labview?

Sorry, I was not clear--the cRIO and the computer I use to write code for it are running LV 2013. I have an old computer running 8.6.1 that needs to be able to talk to the cRIO occasionally through the shared variables.
I think I figured out at least part of my problem--I finally noticed a dropout on the shared variables on the LV 2013 computer as well. So I lowered the clock speed and network publishing rate on the cRIO and the variables stopped dropping out constantly in the DSM in version 8.6.1. I think maybe this was the problem, and the faster computer running LV 2013 was just better able to recover from occasional missed signal or something like that. Anyway, I will try to implement the shared variables in the 8.6.1 code the next time I am able to take down the system. Thanks for the clarification.

Similar Messages

Shared Variable communication (network publiched )

Hi all ,
The whole day I have been banging my head with Shared variable communication between RT Host and host computer :
I essentially attempted to pass an array from the RT host to the Host computer .For this purpose I used a Network published shared variable of type Array U64 . I utilized this link to help me understand usign shared variable communication
http://www.ni.com/white-paper/4679/en ..
I also enabled RT FIFO .Now in the mentioned link this the information given about using single element FIFO or Multi element FIFO
'' By enabling the real-time FIFO, you can select between two slightly different types of FIFO-enabled variables: the single-element and the multielement buffer. One distinction between these two types of buffers is that the single-element FIFO does not report warnings on overflow or underflow conditions. A second distinction is the value that LabVIEW returns when multiple readers read an empty buffer. Multiple readers of the single-element FIFO receive the same value, and the single-element FIFO returns the same value until a writer writes to that variable again. Multiple readers of an empty multielement FIFO each get the last value that they read from the buffer or the default value for the data type of the variable if they have not read from the variable before.''
I had read the above content a 100 times but still I am not able to get a clear picture of the difference and when to use which option .So I decided to throw away the text and attempted to try somethign out for myself .
I had a loop in the RT host that writes different 3 element arrays into the ''network published shared variable '' . Now when I use the multi element option with '' number of arrays as - 2 '' I am able to read the arrays seperates one by one in the host computer ( as we can read a general queue).
Now when I used the single element option for the RT FIFO with un editable 1 array option ,only the last written array into the ''network published shared variable '' gets read in the host computer .
This sounds absolutely silly as if this is the case then what is the purpose of setting the ''buffer''.For testing purposes I had set the buffer as 5 arrays .
In fact I have only one writer ( writing in loop in the RT Host ) and one reader ( again reading in loop in the Host computer ).So I am not even sure if I require The RT FIFO option for the network published shared variable .
I apologise for the long message but I have reached the limits of running in circles waiting to bang somewhere
I know I am doing a silly mistake somewher or I am probably missing a simple obvious trick but dont know what it is ..
I request for some clarity .. In fact I had posted a little while earlier today as well .... link - http://forums.ni.com/t5/LabVIEW/RT-Host-to-Host-computer-communication/td-p/2348130 )
any help would be appreciated
Cheers
me
Solved!
Go to Solution.

Hi,
I think the difference between both types is clearer in the LabVIEW help :
Enabling the Real-Time FIFO
You can enable the real-time FIFO of a shared variable from the Real-Time FIFO page of the Shared Variable Properties dialog box. Place a checkmark in the Enable Real-Time FIFO checkbox to deterministically share data using single element or multi-element FIFOs.
Single Element FIFO
A single-element FIFO shares the most recent data value. The shared variable overwrites the data value when it receives a new data value. Use this option when you need only the most recent value. Configure the size of the array elements or the size of the waveform for the FIFO buffer if you select an array or waveform data type.
Multi-Element FIFO
A multi-element FIFO buffers the values shared by the shared variable. You can configure the size and the elements of the FIFO buffer to match the settings from the Use Buffering section of the Variable page, or you can configure a custom size for the FIFO and the FIFO elements.
Note For both single-element and multi-element FIFOs, if the variable contains array or waveform data, you must configure the size of the FIFO elements equal to the size of the data you want to share. If both the network buffer and the RT FIFO are enabled, the network buffer must be at least as large as one FIFO element. Sharing data smaller or larger than the length you specify causes a memory allocation that affects determinism.
Note Waveforms contain variable-size variant elements that are not compatible with the Real-Time FIFO. Therefore, if you enable the Real-Time FIFO on a shared variable that contains waveform data, the variant element of the waveform data does not transfer.
http://zone.ni.com/reference/en-XX/help/370622K-01/lvrtconcepts/rt_projectvariable/#Single_Element_F...
'Hope it helps
Aurelie

Shared Variables should support LVOOP as a data type

Almost all LabVIEW data types can currently be sent through a shared variable without any hassle. The notable exceptions are native LabVIEW classes, which cannot be selected as the data type for a shared variable. This causes a problem for anyone who wishes to send objects across a network. They are forced to rethink their use of LabVIEW classes, use a communication method other than shared variables, or flatten and unflatten the object on either side of the shared variable communication. The use of classes is growing more common with every version of LabVIEW, so I think it is time for these two prominent LabVIEW features to work together seamlessly.

There has been some debate (both within NI and with customers) about whether or not the flattening/unflattening solution is actually desirable. After all, if NI made the shared variable support classes, to do the writing to the variable, the object would be flattened to a string and then unflattened when the variable is read. In other words, having the shared variable support classes does not actually remove any work that the program has to do, so having the shared variable do this behind the scenes is just syntactic sugar. The negatives crop up with the issues that Phillip raised -- suddenly the shared varible is reporting a number of errors that it did not support previously, whereas by separating the (un)flattening into a separate node, it is easier to tell where an error is arising -- was it a failure to read a shared variable or was it a failure to unflatten the data therein? By keeping the shared variable ignorant of such complex data types, it is easier to swap out the communication mechanism used -- shared variables might get support for LV classes, but TCP/IP prims might not, or whatever other communication protocol comes along in the future (i.e., the network stream primitives that are brand new in LabVIEW 2010 -- effectively queues that are usable over the network).
Users may choose to create a custom string format for objects, one that can be unflattened by any system that uses the shared variable -- including CVI and MeasStudio. Having shared variables support classes directly does not get in the way of this, but consideration of exactly what private fields actually need to be exposed in that very global global variable might be encouraged if users are consciously aware of the serialization taking place.
I'm not pro or con this feature at this point... this post is merely to document debate I've heard about any intermachine communications protocol handling LV classes directly.

Problem while binding variable progmatically shared variable in RT

Hi All,
I have a problem while programaticaly binding the shared variable from RT controller.
The application scenario is as follows
I have three cFP controllers and two
server PCs in my application. Servers are implemented with Redundancy. If server
1 fails, server 2 will take care and vice versa. The cFP controller program is
intelligent enough to detect this switching and identify the active server.
I am using shared variable
communication for transferring the data between cFP and Active Server. This I am
achieving by binding the cFP variable to Server variables. I can bind server
variables to cFP variables also. But I have some advantage with first one rather
than second one.
Now, cFP Variable to Server Variable
binding I can do in two ways.
Right click the variable in Project
Explorer and select the network URL.
Other method is by programmatic
binding.
Now Programatic binding should be
done in cFP controller since cFP controller should bind to second server
whenever it detects switching.
For this, I tried with
SharedVariableIO property node like in the below attached diagram 1.
But I was getting a deployment error
shown in attached diagram 2.
The second method I tried is by
transferring a shared variable library cFP Library.lvlib to cFP through FTP and
opening the Library variable reference and by using the variable property node.
This way of binding was successful when I run from windows PC. But in RT
controller, it was giving me Error 1 while opening a
library.
I am attaching the code with this post
Summary of the problem is I am not able to progmatically bind variables from
RT Controllers
Kindly help me in solving this
problem.
Regards,
Blackperl
Message Edited by blackperl on 08-18-2008 08:29 AM
Message Edited by blackperl on 08-18-2008 08:31 AM
Attachments:
Code and Library.zip ‏27 KB
Diagram 1.jpg ‏15 KB
Diagram 2.jpg ‏25 KB

Hi All,
I have a problem while programaticaly binding the shared variable from RT controller.
The application scenario is as follows
I have three cFP controllers and two
server PCs in my application. Servers are implemented with Redundancy. If server
1 fails, server 2 will take care and vice versa. The cFP controller program is
intelligent enough to detect this switching and identify the active server.
I am using shared variable
communication for transferring the data between cFP and Active Server. This I am
achieving by binding the cFP variable to Server variables. I can bind server
variables to cFP variables also. But I have some advantage with first one rather
than second one.
Now, cFP Variable to Server Variable
binding I can do in two ways.
Right click the variable in Project
Explorer and select the network URL.
Other method is by programmatic
binding.
Now Programatic binding should be
done in cFP controller since cFP controller should bind to second server
whenever it detects switching.
For this, I tried with
SharedVariableIO property node like in the below attached diagram 1.
But I was getting a deployment error
shown in attached diagram 2.
The second method I tried is by
transferring a shared variable library cFP Library.lvlib to cFP through FTP and
opening the Library variable reference and by using the variable property node.
This way of binding was successful when I run from windows PC. But in RT
controller, it was giving me Error 1 while opening a
library.
I am attaching the code with this post
Summary of the problem is I am not able to progmatically bind variables from
RT Controllers
Kindly help me in solving this
problem.
Regards,
Blackperl
Message Edited by blackperl on 08-18-2008 08:29 AM
Message Edited by blackperl on 08-18-2008 08:31 AM
Attachments:
Code and Library.zip ‏27 KB
Diagram 1.jpg ‏15 KB
Diagram 2.jpg ‏25 KB

Multiple versions of Shared Variables on same network

I have 2 seperate reactors working on the same network each deploying ~50 shared variables (different names on each process) communicating with LV 8.5RT running on FP hardware. One of the reactors is requested for new features and to be upgraded. Is it possible to heve 2 different shared variable engines (8.5 and 2010) and versions on the same network and client computer, or am I asking for trouble.
Paul Falkenstein
Coleman Technologies Inc.
CLA, CPI, AIA-Vision
Labview 4.0- 2013, RT, Vision, FPGA
Solved!
Go to Solution.

I believe we address this here: http://forums.ni.com/t5/LabVIEW/multiple-versions-of-Shared-Variables-on-same-network/m-p/1487366#M5...
Sam S
Applications Engineer
National Instruments

Modbus Communication, Adding shared variables, Licenses

Hello, I am having trouble communicating with a third party DAQ. I am receiving data from a thermocouple input module through a modbus library address but I recently purchased a digital I/O module which is giving me trouble. As soon as I add the shared variables which correspond to the modbus addresses of the digital I/O module channels I am using I get a few different errors. If I turn off aliasing for one of the thermocouple channels I get Error 1550 "the license for the I/O server type is invalid"....If I turn it back on I get errors for every modbus location saying "invalid value for enable aliasing option" I am using the student edition and on the opening screen it says the data logging license is expired. Is that the problem? I don't think so because I am successfully communicating with the thermocouple module of the same DAQ device. Is there a simple way to write a new VI that I can try to communicate with just a switch on the digital I/O module and see if it is reading on or off (0 or 1). Thank you very much for your time

Hi brade,
To clarify where we are at. the behavior you are seeing isn't expected. It is a minor bug that we have seen in R&D but haven't been able to reproduce and fix yet.
People have gotten around it by
1) re-making their projects
2) Enabling descriptions, as the engineer in other post. The problem went away for him on this post: "Aliasing is no longer an error. (As long as NI Variables (task description) is enabled)."
We were talking about the aliasing tab you can see on the modbus variables in hte labview project by right-clicking and going to properties;
I assume he checked the box on this tab:
Can you also post your project?
Jesse Dennis
Design Engineer
Erdos Miller

Shared variable version on host and RT target

Hi,
Is it possible to use different shared variable engine on host computer and RT target? We use shared variable to communicate between RT target and host computer. Once the products shipped to customers we will keep the software on RT target unchanged but we would like to keep updating the program on the host computer with newest LabVIEW version. Is it possible to just update the host computer without updating the RT target?Thanks for help!
Tao

Hi Tom,
Are you getting an error code or some thing else?
Attached are two zip files. The 8_5.zip is a LabVIEW project that was written in 8.5 and deployed to a cFP. The 9_0.zip is a LabVIEW project written in LabVIEW 2009 (9.0), that reads the shared variable off of the cFP running the 8.5 code.
This works for me, so if you could give a little more detail, hopefully I can help you out.
Justin Parker
National Instruments
Product Support Engineer
Attachments:
8_5.zip ‏36 KB
9_0.zip ‏30 KB

CRIO and ni 9234 modules not working or communicating through fpga with accelerometers, fpga connected to real time application which is also connected to shared variables linked to modbus slave

Hi,
I have a compact rio which has a 4 way chassis attached to that chassis is three ni9234 modules they are linked using fpga to a real time application then using shared variables in the low speed loop that are linked to a modbus slave to communicate with dcs, the ni 9234's have accelerometers connected to them with iepe ac coupled option on the c modules, my problem is the real time application seems to be running okay even when power loss occurs it restarts with no problem and the fpga writes to the portable hard drive bin files fine but without a accelerometer connected I get low noise readings as soon as I connect a accelerometer to any one of the 10 outputs it just goes to a fixed number (0.03125) as soon as disconnect it again it reverts back to reading noise, I have run a scan on the modules and only get a spike when I connect or disconnect the accelerometer, I have tested the voltage at the pins of the module and I get 22 volts dc which makes it more likely that the hardware is not the problem but a software is maybe causing this to hang-up, I attach project and files for your perusal. I also carried out a new project which in scan mode directly linked the module input to shared variable and the same scenerio again. Help would be much appretiated.
Many thanks
Jason
Solved!
Go to Solution.
Attachments:
logger 2plusmodbus2.zip ‏679 KB

Whren using waveform acquisition with the 9234s we recommend the following FPGA and RT template.
http://sine.ni.com/nips/cds/view/p/lang/en/nid/209114
it can be extended as a data logger with:
http://zone.ni.com/devzone/cda/epd/p/id/6388
or using shared variables combined with scan engine
http://zone.ni.com/devzone/cda/tut/p/id/9851
The FPGA in all of these, as well as the RT framework have been used successfully by 1000s of users. I would recommend giving these a try.
Preston Johnson
Principal Sales Engineer
Condition Monitoring Systems
Vibration Analyst III - www.vibinst.org, www.mobiusinstitute.com
National Instruments
[email protected]
www.ni.com/mcm
www.ni.com/soundandvibration
www.ni.com/biganalogdata
512-683-5444

Problems with communication across a network using shared variables

I have two programs(projects) running on two different computers connected with a LAN. I am using LabVIEW 8.0, and the DSC-module. The program on one of the computers have measurements that I want to collect and show on the program running on the other computer on the network. I choose the indicator where I want to show the data, select ''Properties'', ''Data binding'', ''Shared Variable Engine (NI-PSP)'', ''Network Items'' and then browse for a Network...but the problem is that in my ''Network Neighborhood'' There is only one computer...and that is the one I am one...not the computer on my Network that I want to communicate with....
Have anyone any suggestions on how to solve this?
Kind regards Mari

Mari,
Check this link regarding trouble shooting network-published shared variables:
http://digital.ni.com/public.nsf/websearch/6E37AC5435E44F9F862570D2005FEF25?OpenDocument
This might be a firewall issue, so I would check that first.
Frode

Communicating Between Multiple LabVIEW Executables on different computer using Shared Variables

hi,
I need to develop some executables which will be launched on different computer of a LAN. Some DATA are common. I need to share the data using shared variables.
I usually used LabVIEW so I 'm familiar with shared variables but in this case, the RT target is a part of my
project.
I do I need to procceed in my case?
thanks

Ok but it's not my configuration and I haven't found my answer in the tutorial.
You speak of a case where there is a computer and a RT target under the same LabView project. As I said earlier, I often use labview RT and shared variable between computer and RT target. But I assume here it's different.
My question is : how do you acces to the SVE from 3 computers (without any RT target)?
1. If I create 3 labview projects using the same Shared Variable, do I need to use the same .lvlib on each project?
2. Is it possible?
3. How can I configure where the SVE should be? When I use a RT target, It only depends where I put my Lvlib. But here there is 3 projects.
James
Attachments:
Sans titre.JPG ‏9 KB

Are clusters or individual elements better for shared variables?

So... I have some RT code that is being updated, and pulled out of the Stone Ages of LabVIEW. It was originally written for an old FieldPoint controller operating in "headless" mode, and used the "publish" and datasocket methods for communications and external control. I had to get clever way back then, and put together a parsing/unparsing system for strings to send sets of data back and forth between the controller and any HMI or other computer attached.
Now, I'm completely rewriting the code for a cRIO system, and doing my best to leverage all of the strengths of the latest LabVIEW versions. I have already done an intermediate stage, where I converted from the publish/datasocket method to using network shared variables for my strings, so I could keep some of the original control and calculation logic. Now, however, I'm going back to the drawing board for most of the program, with only some of the proven logic being held over into the new version. And, as I'm putting together the data structures I need for both internal control and external communication, I'm in a bit of a quandary...
I have come upon a data structure dilemma: should I use individual shared variables for my data, or assemble associated data into clusters? My original program had a string (essentially a flattened cluster) for each sensor in use (up to 4), one for the system parameters and states, and one for the control parameters and states. There was a certain advantage to keeping the data compartmentalized like that, it kept things organized and forced me to avoid too many random references of each data point. And it kept the number of communications channels limited to just a handful. Mimicking this structure with cluster shared variables would be easy. But, I'm not sure it's the best or most network-efficient method.
I know the bundling/unbundling will add some processor time in my code, that is not new to me (it will still be much faster than my old parsing routines). But, if I have individual data points being thrown around, I can access them easily from things like Data Dashboard (which is great, but far too limited to be able to grab items in clusters and such). Having all of my data points individually available would make my project messier, but open up easier access. It would also dramatically increase the number of data points being thrown around on the network at any one moment. For reference, I would probably have a maximum of 100 data points at one time, made up of a combination of integers, floats, booleans, integer arrays, boolean arrays. Or I would have a maximum of 8 clusters that would contain those data points.
Any suggestions on which way I should lean? Are there any advantages/disadvantages between shared clusters like the ones I need vs. the number of individual shared variables I would need using the alternative methods? Network traffic and efficiency are always a concern, particularly since this is a "headless" cRIO in a control situation that must maintain a fast scan rate...
Thanks for any help. I'm so stuck on this fence, and I can't figure out which side to fall off!
Solved!
Go to Solution.

Thanks Tim, that is a great source that I somehow missed in my hunt for information regarding my dilemna...
I have to wonder though, does that 25 number also include the I/O points on your cRIO? Anyone know that particular? Most of the I/O points are network shared by default during initial configuration, and you could very quickly exceed 25 variables on an 8 slot rack (such as the one I use, a 9074). Now I'm a bit worried that I'm overusing the variable engine, even before the communications clusters get figured in...

Peculiar behavior of Shared Variable RT FIFO

I'm trying to "leverage" the enhanced TCP/IP and Shared Variable properties of LabView 8.5. My application involves (among other things) doing continuous sampling (16 channels, 1KHz/channel) using 6-year-old PXIs (Pentium III) and streaming data to the host. I developed a small test routine that was more than capable of handling this data rate, even when I had the host put a 20msec wait between attending to the PXI (to simulate other processing on the host). To do this, I enabled the "RT FIFO" property of the Shared Variable (which was an array of 16 I16 integers) and specified a buffer size of 50 (that's 50 arrays). Key to making this work was figuring out the "error codes" associated with the SV RT FIFO, particularly the one that says the FIFO is empty (so don't save the "non-data" that is present).
Flush with success, I started developing a more realistic routine that involves rather more traffic between Host and Remote, including the passing back and forth of "event" data. These include, among other things, "state variables" to enable both host and remote to run state machines that stay "in sync"; in addition, the PXI also acquires digital data (button pushes, etc.) which are other "events" to be sent to the Host and streamed to disk. I developed the dual state-machine model without including the "analog data" machine, just to get the design of the Host/Remote system down and deal with exchanging digital data through other Shared Variables. Along the way, I decided to make these also use an RT FIFO, as I didn't want to "miss" any data. One problem I had noticed when using Shared Variables is the difficulty of telling "is this new?", i.e. is the variable present one that has been already read (and processed) or something that needs processing. I ended up adopting something of a kludge for the events by including an incrementing "event ID" that could be tested to see if it was "new".
Today, I put the two routines together by adding the "generate 16-channels of integer data at 1 KHz and send it to the Host via the Shared Variable" code to my existing Host/Remote state machine. I used exactly the same logic I'd previously employed to monitor the RT FIFO associated with this Shared Variable (basically, the Host reads the SV, then looks at the error code -- a value of -2220 means "Shared Variable FIFO Read Buffer Empty", so the value you just read is an "old" value, so throw it away). Very sad -- my code threw EVERYTHING away! No matter how slowly the Host ran, the indicator always said that the Shared Variable FIFO Read Buffer was empty! This wasn't true -- if I ignored the flag, and saved anyway, I saw reasonable-looking data (I was generating a sinusoid, and I saw numbers going up and down). The trouble was that I read many more points than were actually generated, since I read the same values multiple times!
Looking at the code, the error line coming into the Shared Variable (before it was read) was -2220, and it remained so after it was read. How could this be? One possibility is that my other Shared Variables were mucking up the error line, but I would have thought that the SV Engine handling reading my "analog data" SV would have set the error line appropriately for my variable. On a hunch, I turned of the RT FIFO on the two Event shared variables, and wouldn't you know, this more-or-less fixed it!
But why? What is the point of having a shared variable "attached" to an error line and having it return "Shared Variable FIFO Read Buffer Empty" if it doesn't apply to its own Read Buffer? This seems to me to be a very serious bug that renders this extremely useful feature almost worthless (certainly mega-frustrating). The beauty of the new Shared Variable structure and the new code in Version 8.5 is that it does seem to allow better and faster communication in real-time using TCP/IP, so we can devote the PXI to "real-time" chores (data acquisition, perhaps stimulus generation) and let the PC handle data streaming, displays, controls, etc.
Has anyone been successful in developing a data-streaming application using shared variables between a PXI and and PC, particularly one with multiple real-time streams (such as mine, where I have an analog stream from the PXI at 16 * 1KHz, a digital stream from the PXI at irregular intervalus, but possibly up to 300 Hz, and "control" information going between PC and PXI to keep them in step)? Note that I'm attempting to "modernize" some Version 7 code that (in the absence of a good communication mechanism) is something of a nightmare, with data being kept in PXI memory, written on occasion to the PXI hard drive (!), and then eventually being written up to the PC; in addition, because the data "stayed" on the PXI, we split the signal and ran a second A/D board in the PC just so we could "see" the signal and create a display. How much better to get the PXI to send the data to the PC, which can sock it away and take samples from the data stream to display as they fly by on their way to the hard drive!
But I need to get Shared Variables (or something similar) working more "understandably" first ...
Bob Schor

Bob,
The error lines passed into and out of functions are just just clusters with a status boolean, an error code, and an error string, and are not "attached" to a particular function as you describe in your post. Most functions have an error in input and an error out output, and most functions will simply do nothing except pass through the error cluster if the error in status is True (to verify this for yourself, double click on a function such as a DAQmx Read or Write and look at the block diagram. If there is an error passed in, no read/write occurs). This helps prevent unwanted code from executing when an error does arise in your program. By wiring the error cluster from your other shared variables to your analog data variable, you're essentially telling LabVIEW that these functions are related and that your analog data variable depends requires that the other shared variables are functioning properly. The error wire is a great way to enforce the flow of your program, but you must always consider how it will affect other functions if an error does arise.
Anyways, it's great that you have things more or less working at the moment. Keep us all updated!

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

Shared variable synchronization

Hi,
I am trying to send data between computers. I have used shared variable to do this and to avoid race condition I have append "?sync=true" in URL to synchronize access to shared data. But when I run Send and Read VI, race condition sometimes still appears? Even when I run both VIs on same PC.
I have attached VIs, if someone would like to try it.
Thanks,
andrej
Attachments:
SV.zip ‏53 KB

You maybe running into a race condition even though you are appending
the '?sync=true' tag is because the synchronous operation only ensures
that the dataflow proceeds after the the datasocket has communicated the
update to the shared variable engine. The race condition maybe caused
due to the time that the shared variable engine takes to update the
variable. The second iteration of the while loop may still read the
value of the SVRead variable from the previous iteration which might
cause a race condition. To avoid this possibility, I implemented a
tri-state SVRead variable. Instead of using a boolean, I used an
integer to check the status so that the Sender/Receiver do not wait for
the same value of SVRead which could potentially cause a race condition.
Assuming that the SVRead variable will be initialized to a '0' Value,
refer to the following image for more information on how the SVread
values are being cycled.
Also, I am attaching the editted version of your VIs so that you can test it out.
Please let me know if this helps in resolving the race condition.
Mehak D.
Attachments:
SV.zip ‏84 KB

Version compatibility in shared variable communication

Similar Messages

Maybe you are looking for