Why is G graphical only

[joshxdr]

Electrical circuit design can use either schematic or HDL. They are equivalent representations of the same thing. The designer can choose the best solution. Why does G have to be graphical only?

[jdunham]

Why does G have to be graphical only?

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.

[Ton Plomp]

Electrical circuit design can use either schematic or HDL. They are equivalent representations of the same thing. The designer can choose the best solution. Why does G have to be graphical only?

What you are implying is a graphical IDE for C, .NET or ........? I don't think there's a market that is economically valid for NI, the LabVIEW language is pretty good covered by patents, while other languages are more open.

And in fact LabVIEW code is converted to text, Machine Code to be more precise.

Ton

[Val Brown]

Electrical circuit design can use either schematic or HDL. They are equivalent representations of the same thing. The designer can choose the best solution. Why does G have to be graphical only?

I guess I'm wondering why you want to use a text-based representation instead of the graphical IDE of LabVIEW?

[joshxdr]

I guess I'm wondering why you want to use a text-based representation instead of the graphical IDE of LabVIEW?

My interest in text representation would be version control. At my company, the general procedure for software qualification is that old versions are compared to new versions with text compare by a non-technical QA guy, and I explain all of the changes. This actually works out very well, since it forces me to have formal check of all changes. This is not possible with my version of LabVIEW. Other than that the graphical representation is fine for the kind of software I develop.

As a general comment, I know a lot of designers that started out designing circuits with schematics, but switched to a HDL like Verilog. From what I can tell, for very large complicated digital designs, the graphical representation gets too unwieldy. For circuits like memories and analog circuits, schematics are still used, so there is a place for both kinds of representation. If a text version of G were available, I imagine very large, complicated, multi-developer projects would be possible.

I think there is an opportunity for a G competitor to arise with a dataflow-based language with both graphical and text-based representation. Dataflow programming has some advantages for creating code for multiprocessor systems, so maybe this is a possibility...?

[Val Brown]

Actually multi-developer projects work quite well with LabVIEW -- graphical IDE only -- as does version control. It just seems like your company is rather text-based in its orientation. And FWIW I seriously doubt that there will ever be a competitor to LabVIEW that has all of its functionality AND adds in a text-based version. It's taken over 20 years to get LV to the state it's in and, as you've seen, there's really no incentive or good reason for a text-based version to be developed by NI. I simply don't see it happening that any other company would invest the requisite person-hours to develop what NI has done.

Again FWIW my suggestion would be to ask others how they manage multi-developer, multi-site projects and specifically how requirements and validation processes are handled. There is a real wealth of experience and knowledge here.

[Black Pearl]

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

[joshxdr]

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.

I see what you mean in terms of converting back and forth between graphical and text formats. It is almost impossible.

Also, the sequence of elements in the text file would be somewhat arbitrary, and you would be jumping around a lot in the file(s) to figure out how something actually worked, while in graphical form it would all be in one page.

The analogy between LV and circuity schematics is maybe not as strong as I had assumed. A LV vi will wait forever until the input ports have valid data and then execute. A circuit block will execute its function when it gets a clock edge, it doesn't wait for valid data. A digital circuit goes from register to register with some logic in between each register. This is really more of a line-by-line execution than a dataflow execution, so it is not really the same thing.

[dannyt]

My interest in text representation would be version control. At my company, the general procedure for software qualification is that old versions are compared to new versions with text compare by a non-technical QA guy, and I explain all of the changes. This actually works out very well, since it forces me to have formal check of all changes. This is not possible with my version of LabVIEW.

I disagree totally, this IS possible with LabVIEW.

It has been possible (though not necessarily easy) with LabVIEW for several version now, but has become increasingly easy with LabVIEW 2010 and useing the seperate source & compile code feature.

Using separate source and compile code feature in LabVIEW 2010 you can now ensure that only VI's that you have actually change i.e. edited by a developer are saved into the source control tool. So this mean is is now easy to see which file you need to compare, rather than as used to be the case all those recompiled file and the file you actually changed.

Using the LVCompare tool will allow you to do a side by side compare of the differences and you can sit down with somebody and talk them through the changes just as you could with a text file (it help to have two monitors one version on each)

Dannyt

[Aristos Queue]

This is not possible with my version of LabVIEW.

Which version are you running? LabVIEW has had the ability to diff (compare) two VIs since LV 5.0. LV gained the ability to do the graphical merge of two VIs in LV 2009. These features are under the Tools menu, and if you've enabled source code control integration, it's pretty easy to diff and merge your local version with the version in your SCC repository. You can also use LVCompare, which someone else mentioned, which is a small stub program that you plug into your SCC application and tell it to use as the diff/merge tool for files with .vi, .vit, .ctl and .ctt file extensions. That small stub launches LV and does the graphical diff/merge when requested by your SCC app.

I've glossed over a lot of the details... lots more info exists in LV's online help and in various web sites both within LAVA and on ni.com.

[joshxdr]

Which version are you running? LabVIEW has had the ability to diff (compare) two VIs since LV 5.0. LV gained the ability to do the graphical merge of two VIs in LV 2009. These features are under the Tools menu, and if you've enabled source code control integration, it's pretty easy to diff and merge your local version with the version in your SCC repository. You can also use LVCompare, which someone else mentioned, which is a small stub program that you plug into your SCC application and tell it to use as the diff/merge tool for files with .vi, .vit, .ctl and .ctt file extensions. That small stub launches LV and does the graphical diff/merge when requested by your SCC app.

I've glossed over a lot of the details... lots more info exists in LV's online help and in various web sites both within LAVA and on ni.com.

I am using version 7.0 for SPARC. There is no graphical compare available for this version I am aware of...

[jdunham]

I am using version 7.0 for SPARC. There is no graphical compare available for this version I am aware of...

Oho, very interesting! You started this thread with a rather intriguing philosophical question, but now we've drawn you into admitting that you're stuck in a specific situation because some business externality is forcing you to use 8-year-old tools? I mean, even if NI came up with a textual representation, you'd still have to upgrade to use it.