#execution order

View On WordPress

(start transcription) "Last time we examined dataflow and execution order, looking at the rules that govern how nodes execute. If you haven’t seen that one, take a look at VI High #9, it’s pretty good. At the end, I mentioned that there are ways that we as programmers can easily control execution order. Using the error clusters is one of the best ways. For our purposes, we’ll say there are 2 main reasons to use the error cluster in LabVIEW: 1. Control error handling 2. Control execution order Now, we could have an entirely separate discussion on the first bullet: which is controlling how our application reacts to an error. We’ll leave that for another discussion and focus on execution order. Though we won’t be using the contents of the error cluster in this discussion, let briefly take a look at what’s in there so as to assuage your raging curiosity. There are three items in the error cluster: -a boolean named status, indicating if - yes or no - an error has occurred, -a numeric named code indicating what the error is, -and a string named source indicating where the error came from. For the purposes of our execution order discussion, the most important thing to understand is that the error cluster is simply a single input and/or an output from a node. As such, it dictates when the node will execute. For instance, let’s take a look in our File IO palette at the Open/Create/Replace file. We see that we have the error cluster going into the lower left and out of the lower right, error in and error out. While we have this function out, let’s take a look at some binary file writing. Don’t worry, you don’t need to be familiar with binary file IO to get this concept. To write binary data, I will use this Open/Create/Replace file, and then Write to Binary File, and Close File. The order by which they’re placed is the correct order in which they should run but how do I force them to have this execution order? Well they all have this file refnum input and/or output in the upper left or right so I’ll connect those up and, because of dataflow execution, I know that this Write to Binary File function can’t execute until it receives data from here, same with the Close File. So I have the inherent execution order of open, write, and close. Now that’s easy to do since they have this common input of the file refnum. But what if I wanted to put some other VIs in this VI chain which didn’t have those inputs or outputs? Let’s say I wanted to build a simulated sine wave, perform an FFT on it, and then write that data into the binary file. I’ll go to my waveform palette, analog waveform, sine waveform. And for my FFT, I’ll use this FFT Spectrum. I want them to execute right in between opening the file and writing to the binary file but these 2 VIs don’t have the file refnum input. How do I ensure that they execute in that order? This is where the error cluster comes in, it’s a common input between these different types of VIs and functions. So I’ll just put them in here, connect up the error clusters and now this Sine Waveform VI is waiting on the error cluster output from the Open/Create/Replace File, and the FFT Spectrum VI is doing the same, and so on. Now do you feel that savory sweetness in your mouth? You’ve just had a taste of the LabVIEW dataflow paradigm. There’s plenty more to discuss but that’s all we have time for today, take a look at the text notes for this video for more information. " (end transcription)

(start transcription) "I first saw a LabVIEW block diagram while working in a biomass combustion research lab at school. I looked at the block diagram and asked my senior research partner: how do you know what executes first? Does it go left to right? Top to bottom? He explained it as a mix of science, magic, and love and told me to get back to work building the reactor chamber. Let’s demystify, clarify, and understand dataflow and execution order. Data in LV flows through nodes. Nodes are objects on the block diagram that have inputs and/or outputs and perform operations when a VI runs. In order to determine execution order, LabVIEW follows 2 dataflow rules: 1. An object executes when all data at its input terminals is available, and 2. An object outputs data from its output terminals when it has finished execution For instance, this block diagram has 2 nodes: this add function and this multiply function. How can I determine which of these will execute first? Intuitively you may say that it’s the add function because it comes “first”, or it’s over to the left. But the real reason is that it meets the requirement for execution according to rule 1 that we just looked at: it has all the data available at both input terminals because both of these controls can immediately supply data to the terminals. Looking at the multiply function, we see the lower input can immediately receive its data from this constant, but the upper input is waiting on data from the output of the add function. And we know that the Add function won’t output its data until it has finished executing, according to rule 2. Thus we have an inherent execution order: the add function MUST execute before the multiply function. And if we watch in highlight execution, we see that’s precisely what happens. Now let’s look at this block diagram. We have the chain of VIs we just examined, and then another like it. When I hit the run button, which of these functions will execute first? Obviously of the Add and Multiply functions, we know that the Add will execute first. And of the Subtract and Divide function, the Subtract will execute first. But which of the Add or Subtract functions will execute first? This is a bit more tricky as there does not exist a dataflow dependency between these 2 functions, in other words they don’t share inputs and outputs. In this case, LabVIEW will simply choose whichever it is more efficient for it to run first. This could be either, depending on a variety of factors. Now we don’t want to give the impression that LV is erratic or unpredictable, because if we really wanted to dictate that one of these functions would go first we can do that very easily. However, in this case, by programming the block diagram in this manner, we’ve essentially told LV that we don’t care which of these will go first, and so LV just chooses one. There are several ways of dictating execution order, and we’ll take a look at that next time. Now let’s combine these chains of functions. The question is, will the multiply or the divide function execute first? Think about it. The answer is still ‘we don’t know’. No doubt some of you thought that the Multiply function would definitely execute first. Let’s explore that line of reasoning. The rationale is that after the Add function executes, LV now has 2 choices of which to execute: the Multiply or the Subtract. If Subtract is chosen, then naturally LV will go back and execute the Multiply function. Right? No. Remember, that after the Subtract function executes, now there are 2 possible nodes that have all the necessary inputs in order to run: the Divide function and the Multiply function. So LV could execute either. And so the answer is again, we don’t know. As I mentioned before, there are several ways of eliminating this question of which will go first, however, you don’t need to impatiently wait for the next episode to find that out. Take a look at the text description of this video or feel free to send us threatening and vulgar emails at labviewtraining at sixclear dot com." (end transcription)