Variant in Variant of a shared variable

Hello,
I am trying to read some Tags in a Siemens S7-1200 PLC over NI OPC server. I can read them in NI-DSM (Distributed System Manager). However, I can not read or write them in Labview. I generated a shared variable event loop which will run when a variable changes. I get always Variant in Variant as Value which is not correct as I want to convert it to a data type. (See attached image)
How can I correct it?

It is quite common for a function/property/method to return a value as a variant if the data type is unknown at runtime (e.g. getting a control value for a generic control).
Is your shared variable a variant? If so - the event data converts that to a variant (even though it is already a variant) because you might have registered for events for different shared variables that might be of different data types so it returns as a variant so you can convert it to the correct type (based on the 'data type' event data item).

Similar Messages

Unspecified error when writing variant shared variable

Hi everybody,
I'm getting an unspecified error (-2147467259) when trying to write a variant to a shared variable hosted on my cRIO device.
I'm using a cRIO chassis as a headless controller that dynamically finds remote ScanIO chassis at startup. Similar to the LabVIEW example, the cRIO finds the chassis and generates clusters containing the IO container refnums as well as other information about the modules. I generate two arrays (local and remote) of these clusters, turn them into a variant, and publish it as a network published shared variable so they can be used in a remote PC to add or remove remote channels as needed.
Has anyone had this sort of issue before? I'm new to real-time so I'm not sure if I have violated some canon here or not Thank you for your help
-Jordan

Jnelson,
There appear to be a few Corrective Action Requests (CARs) associated with using shared variables of the variant data type. The closest one I could find related to your issue was CAR #291679 where Wiring FieldPoint IO Point into shared variable throws error -2147467259. All CARs that I could find about using shared variables of the variant type threw the same error you are seeing and are feeding into it less standard datatypes (FieldPoint IO, LVClasses, IMAQ references).
To get a more general overview of your problem, does this error come up the first time you try to write to this shared variable or does it come up somewhat randomly? It would help if you could tell us exactly what hardware you are doing and if you can recreate this issue by simply deploying a program that writes a constant cluster with the same data types into that shared variable.
A possible workaround for you to try would be using the Flatten to String and Unflatten from String functions and pass that through a string shared variable. This has seemed to work for others in the past.
Matt J
Professional Googler and Kudo Addict
National Instruments

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?

Error Reading a Shared Variable Array

Hi,
I am having a problem reading an array of 20 unsigned integers from an Allen Bradley ControlLogix PLC with Labview.
I have set up a shared variable for this purpose. I have set the Data Type of the shared variable to ArrayOf Unit16. The Variable Type is Network-Published, and I have check the Bind To Source checkbox. I think my problem is in the shared variable path. I have tried the following with no success:
MyComputer\ControlLogixTags.lvlib\RsLinx\ProjectX\Online\Faults\Faults
MyComputer\ControlLogixTags.lvlib\RsLinx\ProjectX\Online\Faults\Faults[0]
MyComputer\ControlLogixTags.lvlib\RsLinx\ProjectX\Online\Faults\Faults[]
MyComputer\ControlLogixTags.lvlib\RsLinx\ProjectX\Online\Faults\
MyComputer\ControlLogixTags.lvlib\RsLinx\ProjectX\Online\Faults
I have created a simple vi for testing. I have wired the shared variable to an indicator which is an array of UInt16 items. When I run the vi, I get an error which says "Error 91 occurred at Variant to Data in Text.vi. Possbile Reason: The data type of the variant is not compatible with the data type of the input."
Does anyone have a suggestion as to what I am doing wrong?
Thanks in advance for your help,
Phil

Phil,
In order to determine that you can correctly communicate with your OPC server, I would suggest creating a shared variable bound to a single tag. It sounds as if you already have an RSLinx I/O Server in your project library. Now you can create a new shared variable and use the browse option to browse the items of your I/O server. Be sure to select a tag that has a known value such that you can verify successful communication.
Also, does your VI utilize a dynamic data conversion? The error code mentioned (error 91) is normally associated with this data type. Our next step will be to look at this VI once we can establish successful communication. I hope this was useful for you. Please let me know if I can be of further assistance.
Mike
National Instruments
Applications Engineer

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

STM vs shared variable

From what I have seen on the forum so far, it seems to me that compared to shared variable, STM is better with different data type and bigger data size. The only thing that makes shared variable slightly better than STM is being a bit more simple. If that's the case, why use shared variable at all? Are there aplication where shared variable is a lot better than STM?
Kudos and Accepted as Solution are welcome!
Solved!
Go to Solution.

soupy wrote:
Yup, you can set up multiple connections with STM, but it does not come with the stock examples. You'll have to do quite a bit of development to make it happen. This is the implementation i plan to go with, and the work involved is what is preventing me from going this direction.
Getting off-topic a bit from the original question here, but I wrote a server in LabVIEW that used the TCP primitives and handled multiple connections. The same approach should work for the STM, using STM connection info clusters in place of connection references. In case it's of use to you, here's what I did (unfortunately I no longer have access to that code, it was several jobs ago):
- have one loop dedicated to listening for new connections. When one arrives, put it in a queue and go back to listening.
- in another loop, maintain an array of connection ids. For each connection ID, also store a timestamp. When a new connection arrives, dequeue it, bundle it with the current time, and add it to the connection ID array.
- inside the same loop, add another loop to iterate through each connection, checking for data. If there's data, do whatever you need to with it (usually enqueue it for some other loop to handle), and update the timestamp associated with that connection ID. Ignore error 56 (timeout) since any connection that doesn't have data will report this error. For any error that indicates the connection is closed or no longer available, remove that connection from the array. If the difference between the timestamp for a connection and the current time is greater than some amount, close the connection and remove it from the array (this is optional, but prevents you from leaving connections open that haven't been cleanly closed).
If you're using a command-response scheme, and you pass the data off to another loop to handle, you'll need to track the connection with which it is associated so that the response can be sent to the right place. I was using "Variant to Flattened String" and "Flattened String to Variant" for data passing over TCP, so I just tacked on the connection information as a variant attribute, but there are many other ways to handle this.

Labview 8.2 can't write shared variable

Hi!
I developed LV 8.2 program using shared variable (network published) variant type. After extension of variable the vi charased after writing value in shared variable. If i changed shared variable from network published to single proces type the vi working OK.
Attachments:
problem.jpg ‏23 KB

Hello,
I have created a network published shared variable of type variant, and successfully written to and read from it. Can you also post a snipet of your code which reproduces the problem?
General things to try in case include:
1. undeploy and redeploy the shared variable.
2. repair your LabVIEW installation - this will repair the variable engine, and I know of at least one case where this helped after it was corrupted.
I hope this helps!
Best Regards,
JLS
Best,
JLS
Sixclear

I am trying to connect Dashboard shared variables to a server on a different subnet. Any ideas?

My goal is to control a device that is connected to our wired network using an Android tablet via Dashboard. I have created a vi with shared variables that controls the device as expected when it runs on a computer that is connected to the same wired network. The problem is that my Android tablet running the Dashboard app cannot connect to the shared variables on the PC running the vi on the wired network.
Our wireless network is on a separate subnet from our wired network. I am able to ping my Android tablet from the PC on the wired network but when I try to connect a variable in Dashboard, the PC running the SVE cannot be found. I tried listing it in the alternative server settings window and it still did not work. The only way I have been able to get around this is to run the vi which launches the server on a laptop that is connected to the wireless network and the wired network at the same time. My tablet can then find the server and my VI can connect to the instrument that is connected to the wired network. The laptop is somehow acting as a bridge between the subnets. I need to find a way for the Dashboard app to connect directly to the PC on the wired network. My PC IP address is 192.168.0.105. My Android IP address is 192.168.10.93.

Data Dashboard doesn't care about subnets, but it has to be able to access the server using the right ports. There is probably a firewall blocking the shared variable ports. This document explains how to configure a firewall to allow shared variables to be accessed. Your challenge will probably be to figure out where the firewall is and how to configure it.
It is also possible that the router that your Android device is connected to doesn't know how to route to the other network. Again, that is an issue with your router that you need to resolve.

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.

Issue with use of shared variables in Crystal Reports 2008 Offline Viewer

Hi,
I have a report that contains a number of sub-reports which include drill-down functionality. The report returns data relating to an individual team with the user being able to view top level summary information in each area from the parent report and then drill into the sub-reports to view see more detail. The data returned by the sub-reports is filtered, using sub-report links, based on the team code parameter value given by the user. This parameter field resides in the main report.
One of the values returned by the main report is the team name. This is passed to each sub-report using a shared variable and each sub-report displays this team name as part of a heading.
This all works fine in Crystal Reports 2008, but when a report, containing data, is opened using Crystal 2008 Offline Viewer there is a problem with the shared variable. The value is displayed correctly when the user initially drills into the sub-report. However, when the user begins to drill into grouped data within the sub-report the value passed to the sub-report using the shared variable disappears.
How can I ensure that, when a report is viewed using Crystal Offline Viewer 2008, the value within the shared variable is not lost when users drill into grouped data within sub-reports
Thanks
Stuart

Please re-post if this is still an issue or purchase a case and have a dedicated support engineer work with you directly:
http://store.businessobjects.com/store/bobjamer/DisplayProductByTypePage&parentCategoryID=&categoryID=11522300?resid=-Z5tUwoHAiwAAA8@NLgAAAAS&rests=1254701640551

Why should you explicitly open and close shared variable connections?

I'm looking into switching over from the old Datasocket API to the new Shared Variable API for programmatic access to shared variables, and I noticed that LV doesn't seem to have any problems executing Shared Variable Reads & Writes without first opening the connection explicitly. That is, I can just drop in a shared varaible Read VI, wire a constant to the refnum input, and it will work. I'm wondering, then, what benefits are offered by explicitly opening the conenction ahead of time...?
I guess I could see some cases where you want to open all necessary connections in an initialization state of a top-level state machine, particularly if you want to use the "Open & Verify Connection"---so you could jump straight to an error case if any connections fail. But other than that, why else might one want to explicitly open the connections.
And, along those lines, are there any problems with implicitly opening the connections? One reason why I am hesitant to open them explicitly is because for one of our applications, we need to be able to dynamically switch from one variable to another at runtime. It would be nice to just switch the variable refnum (wired to the input of the Read function), without having to manually close out the old connection and open a new one. A quick prototype of this seems to work. But am I shooting myself in the foot by doing so?
Thanks in advance.

I'd expect there's a very small number of people at NI that would know the answer to the detail you're asking for. But, let's try to extrapolate from this rather old post to see if we can understand what they're forming their impression on.
The shared variable has to have some sort of reference going on in the background. It looks like they're calling this a connection. It's how LabVIEW knows where to find this variable on the network. We can also see this reference certainly exists if we're opening/closing the reference in the explicit method. You see the connection as just a string referencing the variable by URL. This "reference" has to be stored somewhere. No matter how we're looking at this, we're aware there's a reference of some sort stored.
Now, we'd want to look at what would cause this reference to go away. If you open/close explicitly, it's easy to see it goes away at the close. If it's implicit, when would it make sense to close it out? The VI can't be expected to guess where it's done being referenced and close it out. This puts us into a situation where the soonest it could close is when the VI ends. From my experience, references tend to be wiped when you close out LabVIEW. It's this kind of idea that makes the FGV possible. I wouldn't be surprised by Morgan's claim here.
If we look at scalability, you're talking about two different topics. You're talking about adding an extra open, close, read, etc rather than just a few wires. That certainly would look a mess. In terms of the dynamic swap that was being discussed, we wouldn't be adding all of those. The concern would be if enough connections were opened it'd start to behave similar to a memory leak. This could be something that works with a smaller number of variables. If you continue to scale, it becomes problematic. This is why they suggest it's not scalable.
To your questions:
Does LV allocate some kind of session in memory using that string as a lookup?
It would HAVE to allocate some memory to hold that string. Otherwise, it'd be pointless to even have the reference.
Does it reuse that session if other parts of the application reference the same variable, or does it create a unique session for each referencing call to "Read Variable.vi"?
I would expect this to be "it depends." With the implicit method, I would expect it to open a new reference in each point it isn't wired. This is similar to int x,y = 5; x and y share the same value but are their own unique memory location. If you wire the reference to the other points, it should use the same reference. This would make more sense to me than the program seeking out any other potential usage of the variable in the application to see if there's already a reference open. I could be wrong, though.
And what resources does this "connection" actually represent?
At best, this is just the string. At worst, it's the string and the TCP socket. I'd lean towards the first. Opening and closing sockets should be relatively easy in most applications. But, it also wouldn't surprise me if it holds the socket.
I'm sure others have a better understanding than I do. But, that's what I'd expect for anything you've asked.

Is there a way to reset the shared variable engine?

I would like to be able to reset the SVE in a manner that is equivalent to what occurs during a hardware reset.
My motivation for doing so is as follows:
I have an cRIO app with lots of IOV's and NSV's that operate via the SV API and also with plenty of static nodes. I am finding
that on first run, from the DE, my CPU%=~55%. On all subsequent
runs my CPU%=~65%. If I do a hardware reset or redeploy one particular
NSV library then
my cpu usage will return to ~ 55%. I have tried isolating the area of code that accounts for this and have found that
the problem centers around my initialization of one library of NSV's
where I set its init value via the SV API. The NSV references
are all closed after writing without error. So I am wondering if it
is possible that the NSV ref's are not actually closing or possibly
the setting of the inital value has some effect on the SVE so that subsequent runs get bogged down.
Anybody have any ideas?

Hello,
If you redeploy your library, does that bring your CPU usage back down? perhaps you can use that as a suitable workaround? How exactly are you setting the initial value of your shared variables?
Tejinder Gill
National Instruments
Applications Engineer
Visit ni.com/gettingstarted for step-by-step help in setting up your system.

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

Print-time charting with shared variables on a report without groups...

hello all,
I have an interesting conundrum; I am working on a report (Crystal XI) with no groups to it, just several subreports. Presently the report is run weekly and sent to the manager of one of our departments.
The report itself showcases all areas of the department with total tasks, longest outstanding task, average days outstanding, MTD tasks completed, and YTD tasks completed. Due to the variety of tables the data pulls from, I have it set up as subreports that simply display the data.
All total, there are 20 different shared variables that have been obtained from 10 different subreports. I have the shared variables set as the running totals from the subreports (hence, all are print time). Since the running totals and all the subreports are time based and are not actually linked to ANYTHING on the main report, I am struggling with how to set up the formulas described in the white paper, "Charting on Print Time Formulas".
The setting up of the two formulas ({@onchngof} and {@showval}) will be different for my situation, as all of the subreports run off of date information relative to when the report is ran. I've got all of the subreports that the shared variables originate in early in the report; but where to from here?
Would I set up maybe a date grouping or some other non-essential consistent grouping to make it work? The way this report is, it really doesn't need grouping, because the main report is just a display agent for the subreports...
As always, any help is greatly appreciated!

Let me ask couple of questions before trying to resolve this.
1. The chart you are trying to built is placed in which section and is it on Main report or sub-report of its own. This is needed because if you are trying to access shared variables values in Main report, the section should be below the sub-report placed sections.
2. Try pacing few test formulas in Main report and make sure the correct values are being pulled in on Main report.
If you are successfully pulling the variable values on the report, try creating a simple chart in report footer with the values you have pulled and see if its taking you somewhere...
Would need more information on how those variables are being accessed form sub to main or sub to other sub for example are you making an array of those variables and splitting or bringing it in as separate...

How do I setup shared variables between executables created in sepparate projects

Hello,
I have several sepparate projects with their own respective executable files and I would like to be able for these executable files to all share the same variable (one program controls the value of the variable, while the others read from it).
I got this setup to work on my personal computer (by being able to access variable manager, etc), but I need to deploy these executables on different computers that don't have the labview development program. What steps do I need to do in order for me to be able to put these executables on any computer (I'm assuming I need to setup a path for the shared variable that is always in the same folder, etc)
Thanks
Vlad
Solved!
Go to Solution.

Hi Vlad,
I think this article may answer some of your questions regarding shared variables in deployed applications.
http://zone.ni.com/devzone/cda/tut/p/id/9900
It sounds like you already have your executables built, but this article may answer some questions about deploying them to other machines.
http://zone.ni.com/devzone/cda/tut/p/id/3303
Jeff S.
National Instruments

Variant in Variant of a shared variable

Similar Messages

Maybe you are looking for