LabVIEW :: Part 1

Greetings, colleagues. I hope that the article I propose will be to your taste, and the cycle it opens will find its audience. Whether there will be other publications on the topic, it is up to you to decide in part, so please actively comment in the comments on the relevance and quality of the material.

Dataflow + G = LabVIEW

Some time ago I changed the specialization. It was not just a transition to another programming language or a focus on a different area of ​​tasks, but also a very tangible change in the paradigm I adhered to. A year ago, I plunged into the world of dataflow and visual programming. The most striking and powerful representative of this branch of development tools is LabVIEW (National Instruments). Unfortunately, there is practically no information on Habré on this topic, so I will try to fill the gap.

I do not pretend to complete the presentation of the material, I am not going to write a textbook - there are enough of them. The main task that I set for myself is to highlight the concept of LabVIEW and some software development technologies in this environment. Perhaps this will help someone to make the best choice of development tools, someone will push them to solve problems in their field with a new method. Finally, it is useful to simply expand the horizons.
')


Now, I would like to make a short pause and invite you to get acquainted with the only post about LabVIEW, which still showed up on Habré. My colleague, alas, never again showed himself on this topic, so I accept the baton. I hope that after reading its publication, you will return to mine, and we will continue ...

* * *

In this publication I would like to briefly describe how to implement the simplest automaton on LabVIEW. I will not go into an explanation of what machine programming is, the images will say more. Properly thought-out state diagram of the automaton will make the code convenient for the developer, and the program - stable. But at the beginning, a small digression. I will clarify some points about LabVIEW.

Tunnels and Shift registers.

So, to the left of the loop we see a scalar variable with a value that is wound to zero. The five attached to N tells the loop about five iterations, i.e. i = 0..4.

We get a variable into a cycle in two different ways - either through a tunnel or through a shift register. A little later, we will see the difference between these options. The top three “wires” simply go through a cycle, but the output is different. The first top output has auto-indexing, therefore the output will not be zero, but an array of five zeros. The second exit will give us the same zero as at the entrance. The third exit, the svdigovy register, will also give us a zero. It seems to be no difference from a simple tunnel, however - read on.

Let us now look at the "wiring", which in a cycle are added to the addition node. We will add with variable i, i.e. with iteration number.

What will be the output? As we add to zero (the variable that is entered outside the cycle), we will see on the fourth exit (with auto-indexing) the array [0,1,2,3,4]. Is logical. What will happen in the fifth? The last value is i. The tunnel does not have auto-indexing and is overwritten.

And what about the last exit? But there will be 10. (0 + 1 + 2 +3 +4) Why? Because the shift register at the input will pass to the next iteration of the loop the previous value of the output, and only at the first iteration - the external zero, which we applied to the input.

Check it out.

Task

Now let's try to go straight to the task. Suppose we need to write a program that waits for an incoming TCP / IP connection, sends data to the client, disconnects it, and returns to its original mode.

The diagram of the application implementing this service will be as follows:



Now, take a look at the source code.

The main program loop looks like this:



Cases of the main structure and determine the state of the machine: init, listen, say, quit.

But small nested cases (handling connection errors and handling pressing the exit button) are more detailed:





The remaining cases of the main structure:







We start the program, connect to telnet localhost 10000 and see in the console “hello, world!”. Then the connection breaks.

Dry residue

One of the main features of visual programming - the code can really be visual and beautiful! On the other hand, it can easily turn into noodles, after all, we are dealing with data flow “postings”. However, LabVIEW has a number of tools (queues, local, global, network variables, properties of controls, etc.) that can improve the readability of the code. True, to the detriment of the ideology of dataflow. To tell the truth, there are even special structures for controlling user interface events. There is an OOP! And in LabVIEW 2009 there is even a recursion, which by no means fits into the dataflow. However, no matter what, LabVIEW is more than worthy of having in mind when choosing a development tool.

PS Starting from version 8.6 in LabVIEW, special tools for automatic programming have appeared. So far I have not had a chance to use them in my work, however, at first glance, they make the model of the machine gun even more visual. An opportunity - I will tell.

Thanks for attention.

10/01/2009
Kityan Pavel