LabVIEW
Exporting Vi Files to XML or some other Readable format.
Solved!
@joem333 wrote:
Do you know of an example as to how someone else has maybe done this move from block diagram to readable text and back?
Unsure as to how that would be done to be honest.
Thank you in advance, I really appreciate it.
If someone knew how to do this it would be available...
It's totally possible, just not feasible.
And frankly, even if you could convert a VI to XML and back, I doubt if the XML would be considered "human readable". You might have to double or triple your efforts to oblige.
Of course if you'd limit the scope (e.g. support 60-80% of what's in LV) this gets a lot easier (still not easy though).
Search LabVIEW like a graph! 
@paul_a_cardinale wrote:
There is software out there that will convert any file into a hex file and back again. I suggest using something like that.
Base64 encoding for instance. But that was done to circumvent ASCII 7-bit limitations in early communication channels.
The whole request to convert all VIs to text sounds bogus. Is someone seriously going to analyze those 100ds of MB sized XML files for nefarious threats? If not, why would it have to be a human readable format?
Just making everything XML doesn't solve anything. People were claiming that NXG going XML would solve all problems from frozen cheese to source code control systems and diffing/merging of changes. They quickly found that text alone is no guarantee that a merging algorithm could securely merge different code versions together. This even works barely for simple text based languages, but fails blatantly for complex hierarchical multi level syntax systems like XML, and that doesn't even account for context specific logic encoded in the XML structure (what is often refered to as the XML schema or application specific context specification). A LabVIEW loop when converted to an XML representation spans possibly a dozen or more levels of XML syntax and a little change in the loop configuration could have consequences in the XML stream in two or more places that are possibly 5000 text lines apart.
Without knowing exactly what these "security concerns" are it is basically useless to discuss this further. But it is likely just a hypothetical problem or possibly a security IT specialist gone mad.
@RTSLVU wrote:
@joem333 wrote:
Due to security reasons of my building, Vi files are not acceptable for movement between certain systems as they are a form of binary file.
Hmmmm.... I totally understand the security issues of running an unapproved binary. For instance I can run any VI in the LabVIEW development environment on my computer. But as soon as I compile that into a Windows executable, I can no longer run in on my computer because our corporate security software only allows us to run pre-approved executables.
This is something that could be solved by having a long talk with your IT department. I mean you could have a "code review" done by another person to make sure there's no "time bombs" or other malicious code in your program. Then with proper use of source control software only approved source code would be used to build the executable. This should cover any security concerns your company has.
Isn't this about trust?
If it's a production environment, there shouldn't really be source code in the first place. Make executables that are signed by the programmers you (hopefully 🙄) trust.
LabVIEW or C\C++, it really makes little difference.
C# (.NET actually) is different, as .NET has several security levels allowing levels of capabilities. You can (are allowed to) safely execute an executable (successfully) without any rights as long as there isn't anything potentially harmful in it. The .NET Runtime will know. Quite clever IMHO.
@paul_a_cardinale wrote:
Without knowing exactly what these "security concerns" are it is basically useless to discuss this further. But it is likely just a hypothetical problem or possibly a security IT specialist gone mad.
Sometimes absurd requirements come down from someone high up who is clueless about many things.
If they are that clueless, maybe just changing the extension from "*.vi" to "*.txt" and back might be worth a try 😄
@joem333 wrote:
I understand that you can get around this by taking screenshots and recreating said .vi files on the other system, but I wanted to see if there was an already existent tool from LabView.
That won't get around anything because you'll lose all metadata (connector assignment, subVI settings, mechanical action of booleans, project and disk hierarchy, etc. etc.). It is also very error prone, especially if the diagram is a mess,
In computing, everything (everything!!!) is just bits and trying to inflate it by limiting yourself to printable characters does not solve any security risk.
Just place the entire project inside a passworded zip file or similar and see if it gets blocked. 😮
