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. Will there be other publications on the topic, partly up to you too, so please actively comment in the comments on the relevance and quality of the material.
Some time ago I changed my specialization. It was not just a transition to another programming language or focus on a different area of tasks, but also a very tangible change in the paradigm that I followed. 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, therefore I will try to fill in the gap.
I do not pretend to be a complete exposition of the material, I am not going to write a textbook - they are enough. The main task that I set for myself is to cover the LabVIEW concept and some software technologies in this environment. Perhaps this will help someone make the best choice of development tool, someone will push them to solve problems in their field with a new method. Finally, it is useful to simply broaden one's horizons.
Now, I would like to make a short pause and invite you to get acquainted with the only post about LabVIEW, which still appeared on Habré. My colleague, alas, didn’t show himself on this topic anymore, so I take the baton. I hope that after reading his publication you will return to mine, and we will continue ...
* * *
In this publication, I would like to briefly talk about how to implement the simplest machine on LabVIEW. I will not go into explanations about what automatic programming is, images will say more. A well-thought-out state diagram of the machine will make the code convenient for the developer, and the program stable. But in the beginning, a little digression. I will clarify some points of LabVIEW.
So, to the left of the loop we see a scalar variable with a value wounded to zero. A five attached to N tells the loop about five iterations, i.e. i = 0..4.
We start a variable in a loop 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" just go through the cycle through, but the output is different. The first top output has auto-indexing, so the output will not be zero, but an array of five zeros. The second output will give us the same zero as the input. The third output, the swdig register, will also give us zero. It seems to be no difference from a simple tunnel, however - read on.
Let us now look at the "wiring", which in the loop are wound up on the addition node. We will add with the variable i, i.e. with iteration number.
What will be the output? Since we add up to zero (the variable that is wound up outside the loop), we will see the array [0,1,2,3,4] at the fourth output (with auto-indexing). Is logical. What will happen in the fifth? Last value i. The tunnel does not have auto-indexing and is being rewritten.
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 transmit the previous output value to the next iteration of the loop, and, only at the first iteration - the external zero that we applied to the input.
Check it out.
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 that implements 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 determine the state of the machine: init, listen, say, quit.
And here are the small nested cases (handling the connection error and processing the click of the exit button) in more detail:
The remaining cases of the main structure:
Run the program, connect telnet localhost 10000 and see “hello, world!” In the console. Then the connection breaks.
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 dataflow wiring. However, LabVIEW has a number of tools (queues, local, global, network variables, control properties, etc.) that can improve code readability. True, to the detriment of the ideology of dataflow. What can I say, there are even special structures for monitoring user interface events. There is OOP! And in LabVIEW 2009 there is even a recursion, which by no means fits into the dataflow. However, despite everything, LabVIEW is more than worthy of having it in mind when choosing a development tool.
PS Starting with version 8.6, LabVIEW introduced special tools for automated programming. So far, I have not been able to use them in my work, however, at first glance, they make the model of the machine even more visual. There will be an opportunity - I will tell.
Thanks for attention.
10/01/2009
Kityan Pavel
Dataflow + G = LabVIEW
Some time ago I changed my specialization. It was not just a transition to another programming language or focus on a different area of tasks, but also a very tangible change in the paradigm that I followed. 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, therefore I will try to fill in the gap.
I do not pretend to be a complete exposition of the material, I am not going to write a textbook - they are enough. The main task that I set for myself is to cover the LabVIEW concept and some software technologies in this environment. Perhaps this will help someone make the best choice of development tool, someone will push them to solve problems in their field with a new method. Finally, it is useful to simply broaden one's horizons.
Now, I would like to make a short pause and invite you to get acquainted with the only post about LabVIEW, which still appeared on Habré. My colleague, alas, didn’t show himself on this topic anymore, so I take the baton. I hope that after reading his publication you will return to mine, and we will continue ...
* * *
In this publication, I would like to briefly talk about how to implement the simplest machine on LabVIEW. I will not go into explanations about what automatic programming is, images will say more. A well-thought-out state diagram of the machine will make the code convenient for the developer, and the program stable. But in the beginning, a little digression. I will clarify some points of LabVIEW.
Tunnels and shift registers.
So, to the left of the loop we see a scalar variable with a value wounded to zero. A five attached to N tells the loop about five iterations, i.e. i = 0..4.
We start a variable in a loop 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" just go through the cycle through, but the output is different. The first top output has auto-indexing, so the output will not be zero, but an array of five zeros. The second output will give us the same zero as the input. The third output, the swdig register, will also give us zero. It seems to be no difference from a simple tunnel, however - read on.
Let us now look at the "wiring", which in the loop are wound up on the addition node. We will add with the variable i, i.e. with iteration number.
What will be the output? Since we add up to zero (the variable that is wound up outside the loop), we will see the array [0,1,2,3,4] at the fourth output (with auto-indexing). Is logical. What will happen in the fifth? Last value i. The tunnel does not have auto-indexing and is being rewritten.
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 transmit the previous output value to the next iteration of the loop, and, only at the first iteration - the external zero that 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 that implements 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 determine the state of the machine: init, listen, say, quit.
And here are the small nested cases (handling the connection error and processing the click of the exit button) in more detail:
The remaining cases of the main structure:
Run the program, connect telnet localhost 10000 and see “hello, world!” In the console. 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 dataflow wiring. However, LabVIEW has a number of tools (queues, local, global, network variables, control properties, etc.) that can improve code readability. True, to the detriment of the ideology of dataflow. What can I say, there are even special structures for monitoring user interface events. There is OOP! And in LabVIEW 2009 there is even a recursion, which by no means fits into the dataflow. However, despite everything, LabVIEW is more than worthy of having it in mind when choosing a development tool.
PS Starting with version 8.6, LabVIEW introduced special tools for automated programming. So far, I have not been able to use them in my work, however, at first glance, they make the model of the machine even more visual. There will be an opportunity - I will tell.
Thanks for attention.
10/01/2009
Kityan Pavel