Mathematical description of the G-language

[laskar01]

Hi, I am a beginner in Labview and often when I read Labview code I wonder how one can determine if the code makes sense.

Is there a mathematical description of the Labview Language? Vi's need to be connected in certain order to do something meaningful (semantics), but there is also a syntax-rules, which for instance  are that you must create a virtual channel before you write to the virtual channel, you must obtain a queue before you enqueue an element.(I don't know if this will result in a broken wire actually)

What is a Labview program? Can I validate if the above program is correct? If it makes sense? What it does by "mechanically" applying rules from a description of the language? Or is it only by testing and gathering experience of previous behavior that I can validate a code?

What can a Labview program consist of? You can also have files that are of .vi, .lvclass, .ctl, .lvlib. I understand that a vi is a virtual instrument, a graphical code entity, and a lvlib must then be a collection of vi's located on a computer. What is a .ctl file and a .lvclass file?

I've also noted that many entities in a labview program have propertynodes. These seams to be very little documented. Just trial and error here I suppose.

Then a question from a colleague: Is Labview fly-safe? That is, can one prove that a certain Labview code behaves a particular way and doesn't crash an aeroplane which have a computer that runs the Labview-software. An instrument that is used to test certain functions on an aeroplane on the ground must also be fly-safe. His question has the same roots as mine I suppose..-How do I understand a Labview-program, can it be done using rules, or is it just by experiencing the behaviour of the software.

I think you're in a dilemma here... If you write down a mathematical description of Labview, there will be non-NI Labview compilers out there the next month, if you do not do some computer science theory on the Labview language, no computer science deparment will pick it up and do reasearch on it, and that means still no university courses in Labview. Maybe you should wait until you reach a critical "mass".

Kindest regards,

Lasse

[TCPlomp]

Could you give an example of such a 'mathematical description' for another language (C# for instance)?

[RavensFan]

This forum is for giving ideas of how to improve LabVIEW or to propose new features.  Your post isn't anything like that.  I'm not even sure what you are really talking about it here.  It belongs in the regular LabVIEW forum.  If you don't understand LabVIEW (which is the only thing I can get out of your long message), then you should take some training courses.  I would recommend to start by looking at the online LabVIEW tutorials

LabVIEW Introduction Course - Three Hours
LabVIEW Introduction Course - Six Hours

[MikeS81]

Hi,

sounds a bit like the "NI LabVIEW Desktop Execution Trace Toolkit" could help, answer your questions.

Mike

[laskar01]

Hi TCPlomp, with a mathematical description I mean the mathematical formulation of the computer language used by the compiler of that language.

Have a look at "Context Free Grammars" on Wikipedia, if you're interested.

[altenbach]

You are touching a few things that would be difficult in any programming language, but I am sure that (giving enough effort), Darren could come up with some VI analyzer tests that could identify certain race condition and such.

In general, you would need something on the order of Watson to truly validate code. We probably need a few more years for this to become reality.

(For example, the statement "The sky is green" is grammatically correct, but how can a program verify the statement if it is a caption of a b&w photograph? It could be correct under some unusual athmosperic condition.)

In the meantime, well written LabVIEW code is probably much easier to validate than text based code because it is more compact and shows 2D relationships and parallel parts directly. Glaring errors, such a two sources for a wire result in a broken wire already. If you try to dequeue an element and nothing has been placed in the queue, it will wait forever, or timeout and create an error depending on how it's programmed. We already have mandatory connectors that break a VI if left unwired, so if you try to write to a channel before creating it first, the VI cannot run.

Pressing the broken run button will give you a detailed explanation of the problems.

If you have a specific VI that you want validated for flow errors, feel free to post it in the LabVIEW forum and we'll have a look. 😄

[Elijah_K]

It's worth noting that the verification and validation of LabVIEW code is very important for a lot of users.  As with any development environment, a regimented software engineering approach is generally used to verify and validate the quality and functional correctness of the application.  This includes everything from code reviews, static code analysis, dynamic analysis, unit testing, regression testing and general configuration management practices.  Over the last several years, we've added tools and capabilities in the product to improve and automate many of these time-consuming tasks - for more information, click here.  

[Brian_Powell]

There's been some research in this area.

See, for example, Verifying LabVIEW Graphical Programs with ACL2.

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.