Vestigial fields when exporting shared variables

Hello,
Is this a bug? I have a network-published shared variable that used to have aliasing enabled. After I cleared the "Bind to:" field and disabled aliasing, I exported its library into CSV mode. However, it still contained the columns (among others):
NetworkrojectBinding = TRUE
NetworkrojectPath = <old variable that it was bound to>
The extra columns messed up my CSV parser. The only way I could find to prevent their appearance was to delete all the variables that used to have project binding, and re-create them

JKSH,
I was able to reproduce the same issue here. I'll look into this a little more and see if this may in fact be a bug.
James K.
National Instruments
Applications Engineer

Similar Messages

Formatting of text fields when exporting from InDesign to Acrobat Pro

How does one preserve the formatting of a text field when exporting from InDesign CS6 to Acrobat Pro? It loses both the font and the alignment formatting in the PDF.

Use a font that allows embedding/ check the font embedding settings in the PDF output settings.
Mylenium

Coercion problem when using Shared Variable

I have a curious coercion problem when using Shared Variables. I want to share the state of a State Machine, which is an enum saved as a control (typedef) called TYPE State (see attached). I create a shared variable called State and define it as a Custom Control, using the just-mentioned typedef. So far, so good. I've attached three simple VIs -- the first one, Init State, simply wires a constant to the input of the Shared Variable to initialize it -- the wired constant is, of course, defined by the typedef. However, the Get State and Set State, meant to wire an indicator (for reading the state) or control (for setting it), develop coercion dots when wired into the Shared Variable. Why? How do I get rid of the dot? [I suppose I could abandon my typedef and custom control, but the beauty of typedefs and custom controls is that it "enforces" rules, lets you use enums for clarity, keeps the code "honest", etc. -- I'd hate to give that up just to get rid of a dot!].
On a related note, the code seems to work. This is much too simplistic to do anything, but if you open Set State and Get State, set the state to anything, run it (it immediately stops, of course), then run Get State, you'll see the chosen state appear in the indicator. So it does appear to work. The "error" (coercion dot) may, I suppose, be a "bug" in Labview because it can't figure out the mapping of the (very simple!) Custom Control, but if so, I hope it gets fixed quickly!
Bob Schor
Attachments:
Coercion Problem1.zip ‏38 KB

Hello Bob,
I am also seeing this behavior, I will escalate this question to our LabVIEW developers and post again here no later than next Tuesday, November 27th as National Instruments will be closed for the remainder of this week.
If this issue does turn into a product suggestion, I would suspect the workaround would to live with the coersion dot for the time being.
Enjoy the holiday
Regards,
Erik J.
Applications Engineer
National Instruments

CR XI R3: Issue exporting shared variable to Excel - with workaround

Hi,
I have a report that uses a subreport to calculate a field based on the existance (or not) of data in a database other than the main report database. When I use a shared variable to pass this field back to the main report and display it on a detail line (in the main report), it works fine - until I try to export the report to Excel. When exported, the value that gets exported on all detail lines of the report is the final non-blank value of the shared variable, not the value that it contained when the detail line was initially generated. I am using a shared variable because there are multiple values that I want to pass back to the main report.
Luckily, only one of the shared variables are being printed, so the workaround that I am using is to use the subreport to print the field instead of passing the value back in a shared variable and displaying that (and hiding the subreport on a separate format).
Is this a known issue with R3 exporting to Excel? (It was happening in R2 as well...)
HTH,
Carl

Simplified somewhat, what this report is doing is looking up open orders in one database and checking to see if something specific happened to it in another database. If so, it generates the XML that needs to be applied to the first database to update it. The XML references the order number and line number. What I mean is that instead of the data coming out as
Order Line XML Snippet
12345 1234 ...<order>12345</order><line>1234</line><status>received</status>...
22345 2234 ...<order>22345</order><line>2234</line><status>received</status>...
32345 3234 ...<order>32345</order><line>3234</line><status>received</status>...
42345 4234 ...<order>42345</order><line>4234</line><status>received</status>...
I get
Order Line XML Snippet
12345 1234 ...<order>42345</order><line>4234</line><status>received</status>...
22345 2234 ...<order>42345</order><line>4234</line><status>received</status>...
32345 3234 ...<order>42345</order><line>4234</line><status>received</status>...
42345 4234 ...<order>42345</order><line>4234</line><status>received</status>...
I have Base Column Widths on Details, so there should be no merging attempted, but I'll check and make sure.
It seems to me, though, that the DLL is being told the wrong value to export...
Carl

Exporting Shared Variables to csv

When I try and export SV information to csv, LV (2009, DSC) doesn't seem to recognize any variables that are located within virtual folders in the library. Does anyone know a work-around to get that data tabulated short of cycling through the whole library writing values from SharedVariableIO property nodes to file?
Thanks,
Kyle
CLD using LV, DSC 8.5-2009, RT 8.5
Ghoti!

muks wrote:
Have you seen this?
Yep. That's the problem. The shared variable library I'm working with contains well over 1000 variables that are organized into a few dozen virtual folders within the library. When I use the Export Variables function you linked to, it doesn't "see" any variables in folders, only those in the library root.
CLD using LV, DSC 8.5-2009, RT 8.5
Ghoti!

Bug? Cannot export shared variable, if it's in a virtual folder within an .lvlib

Hello,
I was trying to keep my libary of shared variables organized by categorizing the variables into different virtual folders. However, it turns out that variables in virtual folders are excluded from exports, even though they (and their folders) are visible in the Multiple Variable Editor.
Is this by design (in LabVIEW 2012)? If so, what's the rationale?
Thanks!

Hi,
When there are variables inside nested virtual folders within a Library, the multiple variable editor does not work. If you select several variables in a virtual folder and right-click and select Multiple variable editor, the editor opens but you cannot change anything.
Workaround: Convert folders to libraries or move variables under a single folder.
Regards,

Error -196736204 occurs when deploying shared variables?????

When I try to deploy shared variables contained in a library named 'DAQ_sv.lvlib' I get the following message for each shared variable in the library.
Deploying DAQ_sv.lvlib:exit \\192.168.1.100\DAQ_sv\exit deployment failed (error: -1967362041, IAK_SHARED: (Hex 0x8ABC7007) Out of range.).
this paticular message was generated by the shared variable 'exit'.
Does anyone know what caused this?

Hello Steve,
You probably have a shared variable in this library that has the "Bind to Source" option checked in its properties but the path for that binding is either incorrect or empty. Make sure all the variables in this library have valid bindings. Also try deploying a new library to new variables make sure that there is nothing else wrong.
Regards,
Chetan K
Application Engineering
National Instruments

ALV truncates last digit of field when exported to Excel.

Hello SAPients!
I have an ALV grid that truncates the last digit of one of the fields (VBELN) when it is exported to Excel. The field is defined with reference to the standard field VBRK-VBELN.
I'm working on SAP 4.6C.
Any idea?
Thank you for your help

That's funny. Make sure the the outputlen is big enough.
REgards,
RIch Heilman

Acrobat Pro XI - "Failed to Export" when exporting Shared Mailbox Folders to PDF in Outlook 2007 - any solution?

When trying to export a Shared Mailbox folder in Outlook 2007 to PDF, messages are failing consistently.
We are using the latest and greatest Adobe Acrobat XI.
It will export a little bit of the folder and then fail the rest of the items.
There are approximately 929 items in the folder, and about 237 exported before the failures started happening.
Any advice would be great!

Bill - there is a typo above. Customer is using Acrobat X, not XI.
When we tested, we upgraded the office suite to 2010 and it worked with XI. We will just have to get him both upgraded. This hopefully should resolve the issue.
I will check back in with the results.

How to change the order of fields when exported to csv

I am using LiveCycle Designer 8 and have created a great form with the correct tab order.
However, when the form is filled in and returned to me, the fields in the CSV file are all over the place. How can I make sure the fields in the CSV file are displayed in the same order as the tab order?

The actual requirment is to re-arrange the elements of the queryoutput node, to look more organised
say for ex.
Seq 1:
c code company name g/l ac g/l ac description
Seq2 :
g/l ac description c code g/l ac company name
Seq 1 way of representation is more organised that Seq2. How can we achieve this re-arranging of ordering in the queryoutputnode.

Jumpy video when exporting (sharing) to Quicktime

Hi all,
I'm doing a simple internet commercial for a conference in Chicago. I am having a new problem with imovie. When I try to make the video into a quicktime movie the transitions and frames are jumpy. Here's a clip
http://timandalison.com/Transvision2007/Commercial2.html
It worked ok with my first commercial here:
http://forthefields.com/Transvision2007.html
I don't know why it's acting funny. I've used the same settings and everything. I used expert settings in sharing instead of the auto because I wanted to deiterlace it. This setting has made it worse. The jumpy one is compressed automatically for cd-rom and is better than most of the attempts i've made today.
Is it possibly my computer is having a hard time rendering it? It's been acting slow lately on everything else.
Any help is much abliged

i guess i figured it out.

Executable won't re-connect to shared variable engine when it breifly goes offline

Hi,
I have shared variables that are hosted on a field-point controller. I read these variables from executables that run on a PC. When the shared variable engine on the field point controller goes offline and then comes back online (for instance, if I cycle the power to the controller), the executables on the PC don't automatically reconnect. I need to restart the executables in order for them to re-connect and read the shared variables.
Any ideas on how to have the executables automatically re-connect? I don't want to have to restart the execuables when the power cycles on the controller,
Thanks, Derek.

Hi Derek,
It is my understanding that the variables should reconnect, even after your FieldPoint has been power cycled. I found a few articles that could be helpful; read through these and let me know if you are still having issues.
http://digital.ni.com/public.nsf/allkb/7BA64956A475405F862570ED007B2A88?OpenDocument
http://digital.ni.com/public.nsf/allkb/04D9A85B6967EE87862571140065EEC6?OpenDocument
http://digital.ni.com/public.nsf/allkb/AA97FF29D0B3C748862572F600055B22?OpenDocument
Cheers,
Marti C
Applications Engineer
National Instruments
NI Medical

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!

Change Alarm / Quality of Shared Variables for I/O Server

How does one set the Bad Status of a Shared Variable in 2009?
IE). I have a custom device that communicates via TCP/IP. I wrote my own I/O server that handles this communication and publishes a set of Shared Variables that my Main Application displays on a screen. These variables are all doubles and hold pressures and temperatures. If my I/O server in labview loses communication I would like to be able to set the status of the variables to bad so they will set off an alarm. In our main application we have colour indicators that are able to display this status. For example the background goes yellow for all indicators that are in "HI" alarm status, red in "HI HI" and orange when "Bad Status" (disconnected).
We were able to accomplish this using LabVIEW 7.1 DSC, by creating a VI to register all our "Tags" and a VI to run the server. The server vi's that came with 7.1 allowed us to set the quality when writing to the server item. Therefore when the device was disconnected or failed we could set the bad status and use the DSC system to log an alarm and use the alarm features to colour code our indicators.

None of the Shared Variable IO Properties can be configured to allow you to set the alarm. You can only configure the properties such as turning the possibility of the alarm status on/off and the priority, name etc. You do not have the ability to indicate that this shared variable is in alarm because your custom server has encountered a problem. I've talked to tech support about it and I've been informed that this was something that was removed when the shared variable engine was introduced. I've been told informed that the recommended alternative is to create an additional boolean shared variable that will contain the status of the items, or to write some sort of unique garbage value to the actual tag value to indicate there is a problem with it.
I now have to come up with a new way of providing this information. I just find it will likely be a poor programming choice because now my entire system will have to handle "tags" differently based on what hardware is being used. (IE) if its coming from a custom I/O device or from an OPC / Modbus etc capable device.

Shared variable does not work in executable

In editor mode, the shared variables update fine. When I build the executable, the shared variables no longer work.
See attachment.
Attachments:
TestCitadel.vi ‏30 KB

I found this note in the LV2010 help, I wonder if this could be related to your problem...
Note You can use scaling only for network-published
shared variables, I/O variables, or I/O aliases. When the shared
variable you want to scale is a network-published shared variable, it
must have a data source. Configure a network-published shared variable
to have a data source by placing a checkmark in the Enable Aliasing checkbox on the Variable page of the Shared Variable Properties dialog box.

Vestigial fields when exporting shared variables

Similar Messages

Maybe you are looking for