Leaderboard

I once wrote a 'converter' that was able to create xml files from LV code and recreate the LV code from the xml file. In my testing I did use kdiff3 to see if the LV->xml->LV->xml produced the same xml files. Based on this experience, this will be the issues you will need to solve to make it usable: There is no 'lines' in LV code as in text. To serialize it, the complier/IDE/converter needs to impose such an 'order' on wires and nodes. To my finding, it's the order in which the objects are created. So if you delete some section of the code and recreate it identically, the serialized code would have changed. Nodes (functions, SubVIs, ...) and wires are different entities. I did store them in different sections of my xml file. So reading this text would mean constantly scrolling from the one section to the other (like a basic code thats full of GOTOs). But how to make a better guess? A SubVI can have a number of output terminals, and each wire from those terminals could branch to feed more than 1 input terminal. Let's ignore the technical details of the points above and abstract the bigger picture from it. When coding in LV, we use a 2D space (with some limitations such as cyclice wires are not allowed). A text file is always linear 1D. To transform the 2D into 1D (and reverse) without loosing information is not really easy. When coding the 'converter', too much effort was absorbed by getting everything positioned correctly when converting back to LV, and the xml file was obfuscating the code by recording every wire-bend. Also you need to use a lot of 'links' (I just assigned id-numbers to the wires, propably using hyperlinks would improve it a bit), making it very hard to read. Felix

Not for technical reasons, to be sure. It's a business decision on the part of National Instruments. You are absolutely right that some sort of textual representation could be implemented. However once diagrams were converted to an equivalent textual representation, it would be fairly easy to create other IDEs to edit those files or at least read and write the common format. It would also be easy enough to create a different execution system to read those text files and run them as a program, without having to reverse-engineer NI's patent-protected technology. I think this would vastly increase the popularity of LabVIEW, but I'm not sure NI would be able to monetize that growth. These patents are the property of NI and it is their right to do as they please and their obligation to try to benefit their shareholders (including me holding a piddly amount of them). I'm quite sure they have had this debate internally. So you can add this to the NI Wish List, and collect all the kudos you want, but don't hold your breath.