LabVIEW - XML

Hello,
I looking for a solution for XML with LabVIEW.
I will open an exist XML-File and replace a value from a
Note.
I wrote a Visual Basic programm that
describe the value from a certain note.
I tried to write a accordingly programm with LabVIEW. I used a special ActiveX
Class and used the same methode and property just like in the Visual Basic
programm.
But my LabVIEW programm doesn't work!
I don`t no what the reason is.
Is there anybody who have the problem, too, or have a solution or a answer?
Thank you!
Greetings from Germany.
Sasch

Abdullah wrote:
>I don't know what ActiveX class you are using but i have used>Microsoft
XML Parser ActiveX class and it runs OK when called from>LabVIEW.>You can
read and write attribute to/from XML file. Try XML parser if>you are not
using it already. you can download that from microsoft>website.>>Abdullah
Thank you, Abdullah!
I don`t know what ActiveX class I using,I will try it tomorrow.
I write the result.
Greeting Sasch

Similar Messages

  • LabVIEW XML, GXML, or EasyXML?

    I'm developing some routines to collect behavioral data.  I want to generate a "Header file" that contains two kinds of data -- Experiment-wide (constant) data, such as the name of the subject, the settings of the equipment, date, etc., and "trial-by-trial" data, such as what stimulus was used and what response was recorded.  I will also be collecting analog and digital data in separate files, and will record "pointers" into those files as part of the "Trials" data.
    It occurred to me to use XML to write the Header File.  My thoughts are that being "human-readable" was a plus, and the file format would "naturally" be driven by the data that is generated.
    I notice that there are three sets of XML routines, the "native" LabVIEW XML VIs, an NI "package" called GXML, and a set of routines from JKI called EasyXML.  Other than assuming that EasyXML is "easy-to-use", are there any recommendations or suggestions as to which to use?  Do they have different functional properties?  What are the reasons to prefer one over the other?
    Solved!
    Go to Solution.

    Google "JSON".
    The name stands for JavaScript Object Notation and it is a standard. LV2013 has built-in functions for converting native LV data structure into JSON and converting JSON back into native LV data structures.
    Mike...
    Certified Professional Instructor
    Certified LabVIEW Architect
    LabVIEW Champion
    "... after all, He's not a tame lion..."
    Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

  • Parsing a non-standard (LabVIEW) xml file

    I inherited an xml file which does not use the normal LabVIEW schema, where the types would be defined for each value and the number of elements would be defined for an array.  Although a schema file xsl is listed in the xml header, no such file exists.
    Below is a example of the file's contents.  It is a much much shorter version of the actual file.  As I look at the file and start to implement code to support it, I am wondering if I am creating an oversized monster better known as Rube Goldberg code for this task.  Below is the snippet for the latest attempt that I started (obviously unfinished).   It is obvious that I am not an expert at dealing with xml files, which is why I posted this thread.  In other words, I am seeking advice on the appropriate approach to extract values from an exl file that contains code similar to that below.
    The LabVIEW code will need to do 2 things:  
    1. parse the file and populate clusters with the data (I am trying to avoid a giant cluster)
    2. allow to edit the values and write them back to the xml file, while retaining the original format (this is where it becomes tricky).
    I have tried a couple of other approaches that I was not happy with.  Below is the snippet for the latest code that I just started.  I'm trying to avoid falling into the rabbit hole.
    <?xml version="1.0" encoding="utf-8"?>
    <?xml-stylesheet type="text/xsl" href="myschema.xsl"?>
    <calibration>
      <header>
        <hash>bogus123</hash>
        <version>15</version>
        <date>Dec-2-2014</date>
        <author>Me</author>
        <description>Calibration data.</description>
        <comments>new auto-generation</comments>
    <unit-serial-number>007</unit-serial-number>
    <unit-assembly-number>A01.00</unit-assembly-number>
    <base-serial-number>533</base-serial-number>
    <module-serial-number>788</module-serial-number>
    <di-serial-number>001</di-serial-number>
    <di-assy-number>123-01</di-assy-number>
      </header>
      <content>
        <data>
          <name>Power</name>
          <description>Output power vs Frequency</description>
          <params>
            <param name="RFFlag">TRUE</param>
             <param name="Temperature">38</param>
            <param name="BaudRate">115200</param>
          </params>
          <table>
            <params>
              <param name="Frequency">5551212</param>
            </params>
            <header>Pout (dBm), RF_GAIN</header>
            <rows>
    <row>0,0x05</row>
    <row>0.5,0x08</row>
    <row>1,0x0A</row>
    <row>1.5,0x0C</row>
    <row>2,0x1F</row>
    <row>2.5,0x12</row>
    <row>3,0x16</row>
    <row>3.5,0x1A</row>
    <row>4,0x1E</row>
    <row>4.5,0x23</row>
    <row>5,0x28</row>
    <row>5.5,0x2D</row>
            </rows>
          </table>
          <table>
            <params>
              <param name="Frequency">9993333</param>
            </params>
            <header>Pout (dBm), RF_GAIN</header>
            <rows>
    <row>0,0x05</row>
    <row>0.5,0x08</row>
    <row>1,0x0A</row>
    <row>1.5,0x0C</row>
    <row>2,0x1F</row>
    <row>2.5,0x12</row>
    <row>3,0x16</row>
    <row>3.5,0x1A</row>
    <row>4,0x1E</row>
    <row>4.5,0x23</row>
    <row>5,0x28</row>
    <row>5.5,0x2D</row>
            </rows>
          </table>
        </data>
        <data>
          <name>Loss</name>
          <description>loss vs frequency</description>
          <params>
            <param name="Temperature">34</param>
          </params>
          <table>
            <header>Frequency, Loss</header>
            <rows>
              <row>5551212,0.8</row>
              <row>6661313,0.8</row>
              <row>7771414,0.8</row>
            </rows>
          </table>
        </data>
          <name>Attenuation</name>
          <description>RF vs attenuation</description>
          <table>
            <header>index, DAC</header>
            <rows>
              <row>1,  0xCCC</row>
              <row>2,  0xCCC</row>
              <row>3,  0xCCC</row>
              <row>4,  0xCCC</row>
              <row>5,  0xCCC</row>
              <row>6,  0xCCC</row>
              <row>7,  0xCCC</row>
            </rows>
          </table>
        </data>
        <data>
          <name>Current</name>
          <description>current vs Pout</description>
          <table>
            <header>ADC, current</header>
            <rows>
              <row>0x2,  0x66</row>
              <row>0x2,  0x66</row>
              <row>0x2,  0x66</row>
              <row>0x2,  0x66</row>
              <row>0x2,  0x66</row>
              <row>0x2,  0x66</row>
              <row>0x2,  0x66</row>
              <row>0x2,  0x66</row>
              <row>0x2,  0x66</row>
              <row>0x2,  0x66</row>
              <row>0x2,  0x66</row>
              <row>0x2,  0x66</row>
              <row>0x2,  0x66</row>
              <row>0x2,  0x66</row>
              <row>0x2,  0x66</row>
              <row>0x2,  0x66</row>
              <row>0x2,  0x66</row>
              <row>0x2,  0x66</row>
              <row>0x2,  0x66</row>
              <row>0x2,  0x66</row>
              <row>0x2,  0x66</row>
              <row>0x3,  0x66</row>
              <row>0x3,  0x66</row>
              <row>0x3,  0x66</row>
              <row>0x3,  0x66</row>
              <row>0x3,  0x66</row>
              <row>0x3,  0x66</row>
              <row>0x3,  0x66</row>
              <row>0x3,  0x66</row>
              <row>0x3,  0x66</row>
              <row>0x3,  0x66</row>
            </rows>
          </table>
        </data>
       </content>
    </calibration>
    Attachments:
    xmlTry.png ‏64 KB

    Ray.R wrote:
    Hi Darin.
    How have you been?  Wishing you a belated Happy New Year!
    I like your expression:  "step away from the mouse".  Very much to the point.  
    Thanks for the advice.  I'll check out XPath.
    Cheers,
    RayR
    Doing well, Thanks.  Wishing you an early Chinese New Year.  (that's going to get bleeped). [Edit:  Yay, no more bleeping Chinese]
    Be a little careful with XPath.  Some people have been known to wrap C++ libraries to have access to XPath 2.0 and an XSLT engine for awesome search and replace capabilities.  Others have been known to find ways to program XPath graphically:

  • LabVIEW XML VIs omit Line feeds

    Hopefully I'm missing something really simple here... I am creating an XML file, adding a few nested child nodes, and saving the XML. This all works ok except for the fact that LabVIEW does not insert line feeds (or any whitespace for that matter) between my nodes. This makes the resulting document nearly unreadable by humans, which was the entire point of storing this data in XML to begin with. Any suggestions? Essentially, the output of LabVIEW's XML VIs is this:
    <InstrumentList><PS_VIN Version="1.0"><Data></Data></PS_VIN></INSTRUMENTList>
    And what I really want is this:
    <InstrumentList>
        <PS_VIN Version="1.0">
            <Data>
            </Data>
        </PS_VIN>
    </INSTRUMENTList>
    Charles Chickering
    Architecture is art with rules.
    ...and the rules are more like guidelines
    Solved!
    Go to Solution.

    Charles_CLA wrote:
     Thanks Darin, that works great! Any guesses as to why that isn't the default save method?
    <plug type="shameless">
    If we add this:
    http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-LV-version-info-to-Help/idi-p/2324150
    Then we could look in the help file and see that the Pretty Print functionality for Get XML and Save XML was added in LV9 and was not there in the original VIs in LV8.6.
    </plug>
    My guess is that they never got around to updating the VIs in the palettes.

  • Where can I find an example of a vi which reads a xml file using the Labview schema (LVXMLSchema.xsd)?

    Where can I find an example of a vi which reads a xml file using the Labview schema (LVXMLSchema.xsd)?
    �Unflatten From XML� is of little use in parsing because it requires the data type. So it seems that the user has to parse each data value, and then �Unflatten From XML� can help a little.
    I would like to see NI provide a VI for parsing it�s own schema.

    LabVIEW's XML functions are another way of saving data from controls and indicators that is in a more standardized format. If you look at the Unflatten From XML shipping example, it shows taking the data that you would normally send to a Digital Wveform Graph and converting it to XML instead. This data is then unflattend from XML and wired to the graph. Since you know what you wrote to the file, this is an easy thing to do. If what you are looking for is a way to look at any data in any LabVIEW XML file, then you are right, there is not a VI for that. However, I do not believe that that was the intention of the XML functions in the first place.
    By wiriting data in XML, this allows other applications outside of LabVIEW to parse and recognize the dat
    a. In LabVIEW, you would already know the types and can place a generic item of that type. The issue of knowing the type is that you need to know the type of the wire that comes out of the Unflatten function so that the VI will compile correctly. You could always choose a variant value to unflatten and then do some parsing to take the variant a part. Maybe this will help you out.
    See this example for using the Microsoft parser for XML. (http://venus.ni.com/stage/we/niepd_web_display.DISPLAY_EPD4?p_guid=B123AE0CB9FE111EE034080020E74861&p_node=DZ52050&p_submitted=N&p_rank=&p_answer=)
    Randy Hoskin
    Applications Engineer
    National Instruments
    http://www.ni.com/ask

  • Error in Get Next Non-Text Sibling for XML without CR at end of tag

    Hallo all,
    I'm having a strange error parsing XML files with labview. I have an XML file in one single line, without CR at end of each tag. A normal browser or XML parsing tool is capable to read it, but not with Labview.
    The error I have is with "Get Next Non-Text Sibling.vi", which internally fails to read Type property (Error -2630, Property Node (arg 1) in NI_XML.lvlib:Get Next Non-Text Sibling.vi->XML Get Siblings Childs Nodes.vi->Encode data to label (Path).vi).
    Labview XML parser works if I add a CR at each tag/node.
    I'm quite sure this is a labview bug. A workaround I have found is to open the file, then save the file with Save File (Pretty Print) method and reopen it again, but it is time-consuming and I would like to avoid it.
    Regards,
    Daniele
    Solved!
    Go to Solution.
    Attachments:
    xmlwithnoCR.xml.txt ‏1 KB

    Which node do you pass to XML Get Siblings Child Nodes.vi ? That is also important.
    I can imagine the following scenario causing your problem: Your input node has a child node C,, but this child node has no siblings. Get Next Non-Text Sibling.vi will fail in this case. If you put a <CR> at the right position in your XML you create a text node with content <CR>. If this text node is a sibling of child C then Get Next Non-Text Sibling.vi still won't return anything but no error should occur. IMHO this is expected behavior. You can however implement your own version of Get Next Non-Text Sibling.vi. Use the Next Sibling property and check if it returns a valid refnum.

  • Using XML-Files on RT-Tragets

    Hi
    i have an application which stores it's configuration in a XML-File. The Vi runs perfect on Windows as execution target.
    But running the Vi on the RT-engine fails with error 1108 while loading the XML-formated config file.
    error 1108
    Possible reasons:
    LabVIEW: XML value text is illegal or out of range for type and/or format.
    The XML-file can't be illegal, because the same Vi works on an other excecution target.
    Any ideas what's wrong?
    Is the RT-engine unable to handle XML-files?
    Regards Till

    Till,
    that's true. Not all VIs are supported in LV RT as it states in the LV RT User Manual (7.0, page 1-7, 1-8). In your case the XML VIs require the MS XML DOM parser that is getting installed with LabVIEW on Windows and is unfortunatelly not available on the RT platform (Pharlap).
    I don't know if there is a XML workaround or if NI will integrate other OS independent XML parsers which would run on RT.
    You might consider to use the .ini file approach for the RT platform - I assume this should work.
    Roland

  • I want to export acquired data via XML to a remote URL/web service. Is there some online reference for EXACTLY what XML features are available in 6.1?

    Is there any online reference to the XML methods available in 6.1?
    I would like to set up a LabView system that acquires data from local hardware, and then sends acquired data as XML "packets" to a remote web service. I can't seem to find any online reference to this when I search the site. I don't want the "gee golly 6.1 is cool" marketing stuff. Just a simple technical reference to abilities.

    If you're looking for more technical information about all the new features of 6.1, try the LabVIEW 6.1 Upgrade Notes. Here's what they say about the XML functions:
    "Use the Flatten to XML function located on the Functions»Advanced»Data Manipulation palette to convert any LabVIEW data type to the XML format according to the LabVIEW XML schema. Use the Unflatten from XML function located on the same palette to convert a data type in the XML format into LabVIEW data.
    For these conversions, LabVIEW uses a predefined XML schema that is described in labview\help\LVXMLSchema.xsd."
    Kelly Holmes
    LabVIEW Documentation
    Kelly H
    LabVIEW Documentation
    National Instruments

  • XML tutorial or Help

    Does anyone have a good tutorial for Labview XML schema.  I have created an INI file in LV XML format through flattne to XML string and save to XML file, but every time you write to an XML file it overwrites evertyhing in the file.  I wanted to extract the string and search for data to replace, replace it and store it again, but this seems to be introducing new formatting parameters, that throw everything off.
    Any help appreciated.
    p.s. I do know how to use basic LV XML vi's, so if something has some indepth knowlege of overwriting specific nodes in the XML, while keeping the format and syntax of everything else the same is what I am looking for.  Also ways of sorting the data within XML file, without letting LV choose where in the file it wants to store the data?
    Thanks

    rather than editting the XML directly (which can be done but is twitchy as you've found out) you're probably better off unflattening back to you original INI file text, editing that, and then re-flatten to the XML file.  

  • Which data file format is better for storing setup information? XML, ASCII or Binary?

    Hello,
    Our application is using cluster, string, Integer and other data types and storing them in ASCII files.  We are using flatten to string function and storing it to the text file.  However, going ahead we want to migrate to XML file format.  Is it a good idea?  What would be the pros and cons?
    Thanks.

    If you are using LabVIEW's Flatten to String function, you are storing your data as binary, even if you are sending a string to the file writer.
    The issues you will run into using this method or any of the canned LabVIEW XML VIs:  If your data type changes, your files can't be read in any more.  You mentioned you have clusters.  If you add an element or take one away, the old files won't be read in anymore.  You would have to store old versions of the data type and file reader and then convert the old data type to the new data type.
    The nice thing about OpenG's INI functions is they take variant's, so you can pass complex data structures and it will write the file.  If the data type changes, as long as it can be coerced into the format, it will still be read in.  If you pass a cluster and a value is missing from the INI, the default is used.  If there is an extra value in the INI, it's just skipped.  So, your reader and writers can be updated without as much concern about supporting old data files.
    One method you can do if you want to use binary is the "TLD" method.  TLD stands for Type, Length, Data.  I use an enum for the Type.  The Length is just the length of the Data which follows, and then the data is the binary data.  If I change a data type, then I create a new enum value (always has to be added to the end of the list to maintain value consistency with the old files).  This way, the reader can still handle the old data type and convert it into the new data type in whatever method is necessary.  It can also completely ignore it if desired.  I usually process clusters as individual items so I don't have to save old versions of the cluster.  It works quite well and only adds a few bytes per data item.  The big caveat is you have to remember to update your file writer and reader whenever you change a datatype or add a new value.

  • Precision of Flatten to XML

    In LabVIEW 6.1 the Flatten to XML function seems to truncate double precision data to 5 decimal places. Is there a way to extend the precision to 10 or 15 decimal places?

    I know that this thread is quite out of date, but afaik there is still no solution for this problem.
    I wrote a .NET dll to parse and reformat the LabView-Xml to a more human-readable form, and also not type specific (only specific on the control names). I thought the double-precision problem was already solved, but it is definitely not. Is there any reason that the precision is always truncated? As Xml nowadays is a common way to share data, for me it was no question that LabView supports it completely, but now I know it doesnt. Is there any workaround? I dont want to use OpenG as its to slow, and also not localization-independent; it shouldnt be a problem just to extend the precision to the maximum possible, printf() always supported this.

  • NI XML DAQ Schema ?

    I would like to know if NI, an alliance member, or someone else has come up with, or is working on a DAQ schema for at least the common NI DAQ boards? We seem to use (*.txt) configuration files more and more, which tend to be long and rather ugly text files that in most cases, are handed off to the customer for their use. What usually happens is that they hand it off to someone else and file inputting errors occur, then one of us gets a phone call, which leads to loss of program time & dollars.
    So, I looked at the OpenG LabXML DOM parser as a common architecture for parsing and have started writing an XML schema that would at least allow (the user to edit the XML configuration using validation against the *.xsd schema file, via a LabVIEW XML config
    file editing s/w program. The validation check against the schema code is also in the main data acquisition program. In summary, this greatly limits editing mistakes by the user.
    I would like to incorporate the most common boards we have first, like the 6031E, and the 6508E and the 6509E. Soon, I'm sure we'll like to incorporate the M-Series common boards too. Before I go and "finish" this venture involving most of the DAQmx properties and methods, I was wondering if I am re-inventing the wheel?

    Hello Karl,
    Although your idea of applying XML to your measurement system sounds like a good idea, I believe that you will be the first that I have heard of doing such. NI does not have such a application as you are intending to build, nor do I know of any plans to include one. Good luck on your development.
    Jared A

  • Read XML file problem

    Hi all,
    I am trying to read an xml file and display the output. i get a blank display. Can anybody please help me out.
    Thanks in advance
    I cant attach the xml file. Since its not a valid extension. Please find the xml code below.
    <Company>
    <Name>Samsung</Name>
    <Location>
    <City>Busan</City>
    <Country>South Korea</Country>
    </Location>
    </Company>
    Regards,
    KM
    Solved!
    Go to Solution.
    Attachments:
    Read Data from XML File.vi ‏9 KB

    If you can change saved .xml file, you can modify it to be compatible with Labview XML shema and use Unflatten from XML like in your VI. If you cannot, you should use XML Parser library. In attachement you can find 2 exmaples for these situations.
    Attachments:
    Modified XML file.vi ‏12 KB
    XML Parsing 1.vi ‏20 KB

  • Unflattern in C#: How to parse LV-generated XML in CSharp?

    Hello,
    it is very easy to flattern an object (e.g. my cluster,...) to XML string in LabView!
    And it is also very easy to unflattern this XML string back to the object (to my cluster).
    What I want:
    1. Flattern Cluster in LabView to XML string
    2. Store in SQL Database
    3. Read (Unflattern) in C# Application
    e.g. my cluster consists of:
    1. integer: num1
    2. boolean: on
    3. array of clusters (bool, int): data1
    Question: How to unflattern the XML string in C#?
    Thank you verymuch in advance!
    BR
    EWiebe
    Eugen Wiebe
    Bernstein AG
    CLAD - Certified LabView Associate Developer
    Attachments:
    Flattern_Unflattern_in_LV.vi ‏10 KB

    I don't know anything about how C# treats XML.  However, if you have the XML file that LabVIEW produces, it is "human-readable", so you can print it out and look at it.  What does C# expect for its XML?  If you don't know, try generating a C# XML file with the same type of data that you used in LabVIEW (using analogous C# constructs).  Print that file out, as well.
    If everything were the Best in this Best of All Possible Worlds, the two files would be identical.  I'm going to guess that they'll be different, but (with luck) the differences will be (a) obvious and (b) "editable", that is, you should be able to make a "LabVIEW-to-C# XML Translator" that will transform the LabVIEW XML file to a form that C# can interpret.  Indeed, there may be XML features (analogous to Style Sheets) that will do this for you.
    Good Luck.
    BS

  • Certain data missing from Web service output in LV8.5.1

    I just installed Labview 8.5.1 and thereby got rid of a problem where the Import Web Service Wizard hung.
    However, a new problem appeared. The XML output of my web service call does not contain the actual result values. When I call the web service using SOAPUI from http://www.soapui.org/, I can see the actual result values in a section of the XML output called diffgr:diffgram. When I inspect the Labview XML output, the whole diffgram section is missing! Se attachments.
    Any help appreciated!
    Attachments:
    SOAPUI Web Service output2.txt ‏3 KB
    Labview Web Service output1.txt ‏1 KB

    It is on our company's intranet. The description in wsdl-format is attached.
    (You might have to save it as a .txt file on your hard drive in order to view it with Notepad.)
    Message Edited by andreas nilsson on 04-23-2008 05:47 AM
    Attachments:
    Axaptaws_wsdl.txt ‏146 KB

Maybe you are looking for