is there a utility to convert vi files to text and back agin

[GerdW]

Hi Tim,

---

@TimBlaisdell wrote:

The purpose would be to store VIs in a way that could be checked into source control, and meaningfully/easily checked for differences, etc.

---

You can check in all your VIs into your SCC repository! (I do that since years…)

To compare for differences there is a Diff tool coming with LabVIEW (Pro)…

[BertMcMahan]

---

@TimBlaisdell wrote:

I would also like to see a utility like this.  

The purpose would be to store VIs in a way that could be checked into source control, and meaningfully/easily checked for differences, etc.

I imagine something that basically just stores the location of every wire, every VI call, all controls and indicators, etc.  Storing it in an XML format file would be fine.

Then, when you want to work on the project, you check out the text files, run the utility to re-build all the VIs exactly as they were when checked in, and load the project in LabVIEW.

---

I like where your head's at, but doing a block diagram cleanup (with no code changes) would cause the position of everything on the diagram to change. Thus, all of your XML wire and item locations would change. You could perhaps filter location changes out, but what if that location change mattered? Like if it was inside a loop, then wasn't?

All I'm saying is that creating such a tool is theoretically possible, but reading an XML description of a LabVIEW diagram is like dancing to describe architecture. I seriously doubt you could do any meaningful diffs unless you built some really specific tools. Like the built-in LV diff tool 🙂

[Hooovahh]

GerdW is right and the diff and compare tools for LabVIEW do exist.  I'm not really a fan of them and so instead of trying to merge files in SCC I lock them so only one developer can edit them at once.  This obviously has its challenges and you'll be trading one set of problems for another.  But again SCC itself works fine with VIs.  NI experimented with saving a VI file as XML, both in 20xx LabVIEW and officially in now unsupported NXG.  It wasn't the perfect solution that we all hoped it would be and lots more work was needed before it would work well.

[billko]

Oops, some posts just rendered mine obsolete.

[rolfk]

It’s a pipe dream. Merging of normal text source files is already impossible to do fully automatic if two edits happen to close together in the source file. To describe a graph based LabVIEW diagram (the organization of the dataflow as a directed graph, not the graphical nature alone) you require a more complex description language than what a simple sequential text flow can offer. So you end up quickly with something like XML which is already Very hard to merge reliably. To make things worse, understanding the XML structure alone is not enough to merge properly as you also need to understand the XML schema for the application in question. In short there exist pretty much no real world XML merge tools that can be reliably used. And the problem is not just XML, any structured description language has the same problem. The merge tool needs to understand the entire structure perfectly and at that point it is easier to create it on the original binary data than to insert another transformation step that adds additional complexity to the already very difficult problem.

It’s pretty unlikely that NI is going to create such a full automatic capable merge tool, but it is even more unlikely that anyone else would do it, no matter if the VI files were in text format or not!

[Mark_Yedinak]

---

@Hooovahh wrote:

GerdW is right and the diff and compare tools for LabVIEW do exist.  I'm not really a fan of them and so instead of trying to merge files in SCC I lock them so only one developer can edit them at once.  This obviously has its challenges and you'll be trading one set of problems for another.  But again SCC itself works fine with VIs.  NI experimented with saving a VI file as XML, both in 20xx LabVIEW and officially in now unsupported NXG.  It wasn't the perfect solution that we all hoped it would be and lots more work was needed before it would work well.

---

It should be noted that for SCC to be effective you MUST separate the compiled code from the source. Otherwise you gets lots of churn in your SCC repository for VIs that didn't really change and were simply recompiled. A change to a single typedef could result in the SCC thinking lots of VIs were changed.

[TimBlaisdell]

I appreciate all the responses on here, telling my why my idea won't work.  I would like to respond to some of them:

@BertMcMahan wrote:

I like where your head's at, but doing a block diagram cleanup (with no code changes) would cause the position of everything on the diagram to change. Thus, all of your XML wire and item locations would change. You could perhaps filter location changes out, but what if that location change mattered? Like if it was inside a loop, then wasn't?

First, the fact that doing a diagram cleanup would only change the positions of things is kind of the point.  A comparison of two text files would show plainly that the only things that changed were the positions.

Second, obviously I'd be storing more than just the positions of things -- I'd be storing their relationships, e.g. for structures like loops, I'd be storing the fact that one contains the other.  I also envision storing many other details, such as properties, colors, etc., etc.

Lots of people are pushing LabVIEW's compare tools, but they just aren't good enough.  They are cumbersome.  They do not allow you to do things like look at your source control history and say "what's the difference between these two check-ins?"  At least, not easily.  It would require manually retrieving the two versions you're interested in, loading them up in LabVIEW and running its tool, and even then.... it's just too much trouble.

Others are saying that they see no problem using source control with VIs.  Here are some problems:
- Since VIs are binary files, every version you check in is stored in its entirety on the server.  

- Since LabVIEW is notorious for updating timestamps on files when nothing changed (and PLEASE don't tell me separating compiled code from the source fixes this -- it does NOT), you end up checking in many, many copies of the files and it just becomes unmanageable to expect people to use LabVIEW's comparison tools to figure out what changed.

[rwunderl]

---

@apchar_ wrote:

I work somewhere you cant transfer binary files from one machine to another, only text files. Is there a utility somewhere that will convert the native binary vi file to text (like xml) or something and back again? Preferrably in perl or python or even c source code.

Thanks

---

To get back to the original question, I too have experienced the frustration of not being able to transfer files at-will between some machines for security reasons. I think the difficulty lies not in getting the binary content of the VI file out (which should be made impossible for security reasons, so just deal with it), but instead taking with you the "spirit" of the VI's content.

What I mean is if I come up with a new algorithm on such a machine, my only option may be to print the pretty pictures out and then recreate the code manually on another machine using the pictures.

Alternatively, if you could just print a text file with instructions on how to place the primitives and wire them together, that could also be human-readable but automate the process of recreating the code later. Think of it as a netlist for an electrical circuit; it doesn't tell you how to format the schematic in a pretty way, it only describes the essential electrical connections that define the circuit's behavior. It would be something akin to snippets, but perhaps without much in the way of front panel or cosmetic considerations (unlike snippets that just cram the VI's binary content into a custom section hidden in the PNG data).

To me this sounds very valuable indeed. It may also help to "functionally diff" LabVIEW code without much concern for cosmetics. Seems like someone would have tried something like this with scripting by now.

And what do you think the binary of a VI is? I don't really know, but I can intuit that it must be a list of objects and instructions on where to put them, how to configure them, and how to interconnect them. How hard would it be to print this binary information in pain text to a file instead of compressing it into a binary? NXG did it, right?

Finally, I do think that being able to convert a VI to python or c is ridiculous, as that would be insanely complicated for anything more than the simplest collection of primitives.

[RTSLVU]

---

@rwunderl wrote:

---

@apchar_ wrote:

I work somewhere you cant transfer binary files from one machine to another, only text files. Is there a utility somewhere that will convert the native binary vi file to text (like xml) or something and back again? Preferrably in perl or python or even c source code.

Thanks

---

To get back to the original question, I too have experienced the frustration of not being able to transfer files at-will between some machines for security reasons. I think the difficulty lies not in getting the binary content of the VI file out (which should be made impossible for security reasons, so just deal with it), but instead taking with you the "spirit" of the VI's content.

What I mean is if I come up with a new algorithm on such a machine, my only option may be to print the pretty pictures out and then recreate the code manually on another machine using the pictures.

See my response that discusses UUencoding. 

[rwunderl]

---

@RTSLVU wrote:

---

See my response that discusses UUencoding. 

---

I believe you have missed the mark here. I am in no way discussing converting binary bytes to ASCII text. Sure there are many encoding schemes to transmit binary data over plain text media; e.g., uuencoding, Base64 encoding, hex (Base16) encoding, etc.

I am discussing scripting LabVIEW code by writing a text script that describes the creation of a block diagram using an open set of instructions versus proprietary binary LabVIEW code. Thought that might be useful to some folks.

I think the OP's question was detracted from by this entire discussion of binary-to-text encoding. I believe the spirit of the original question was, "how can I represent the logic of my LabVIEW code using text instead of the binary VI file?"