Need to understand a part of code

[AdityaAbhishek]

What is happening in the above code? Can someone explain it in detail?

Also, I need an explanation for the below question. What is the difference between the size of the write to text vs write to binary file.

Write to Text vs Write to Binary

https://www.youtube.com/watch?v=a7DHQ5XGXEc&list=PLmB_zX4D2E9nP9-F8qWl_k4ey6YgFtvXv&index=98

Thanks in advance

Aditya

[Bob_Schor]

I find "Delay Lines" (or "Feedback Nodes") a little confusing, myself.  One way to learn about them is to put one on a blank Block Diagram, right-click it, and read the Detailed Help description.  Next, code up this simple example and watch (use Hightlight Execution and single-stepping) what it does.  Now see if the Result makes sense to you.  If you think it does, change something (like initialize with a different array) and see if you "get the right answer".

For the second question, the difference between Text and Binary files, you need to understand how strings are represented in text files and in binary files.  Again, read the Help for Write to Text and Write to Binary.  Text is written one byte per character, ending with a system-dependent End-of-Line.  Here, the answer given by the video is technically wrong -- the End-of-Line for Windows is the pair of characters <CR> and <LF>, while for other operating systems (Linux and MacOS), it is just <LF>.  When you are writing text in a binary file, since all the bytes are "binary", the File I/O system needs to know where the String starts and stops, so the convention is that you use 4 bytes to give the number of characters in the String (so the maximum string length can be pretty long ...), then the String itself.  So each string takes 4 bytes for the length + the number of bytes in the string.

So here's a Bonus Question.  LabVIEW is often used to acquire data from instruments, data that is frequently numeric in nature, say digitized voltages acquired at 1 kHz for 1 hour.  That's a lot of numbers.  What is an argument for writing these data in as a Text file?  Are there any advantages in writing the data as a Binary file?

Bob Schor

[RavensFan]

---

@AdityaAbhishek wrote:

What is happening in the above code? Can someone explain it in detail?

---

Of course there are input and output terminals on every iteration.

The 2 means you are pulling data from 2 iterations ago.

The ? mark is an enable that tells whether the data is being input or not.  In this case, it is always True.  I've never used that feature for any reason to know how it affects results if the condition is occasional faluse.

The i node is the initializer.  You are putting an array of data in to put data in the buffer to reflect values that would have been put in there if the loop was able to execute prior to iteration 0.  That way you can get a value besides default out of the node on iteration 0, and don't have to wait until 2 iterations have passed before you start seeing data on the output terminal.

[altenbach]

Feedback node question:

Is there anything in the help that confuses you?

File question:

Text is human readable formatted with numbers represented as bytes that are interpreted as characters accordong to the ASCII standard (numbers 0..9, decimal delimiter, column delimiter, row delimiter, etc.). A binary file contains bytes that directly mirrors how the data looks in memory (e.g. 4 bytes/SGL, 8 Bytes/DBL, 2 Bytes/I16, etc.). You can find the details here. (see also)

A file is just a linear sequence of bytes. What they mean depends on context. Try to open it in "notepad" and if you can read numbers it is probably text. If you only see garbage, it's probably binary. 😄

[billko]

That diagram is question 39 of the CLD-R sample exam.  And I skipped that question.  I have trouble wrapping my head around feedback nodes, too.

[AdityaAbhishek]

I tried running the above code in highlight, but still couldn't get. Can you help me out.

[RavensFan]

What does "but still couldn't get" actually mean?

What are you looking for?  What are you actually getting?

If you have trouble with code, then you should attach that code (as a VI, not screenshot), so we can see what you are doing.

[crossrulz]

Note: I have yet to run into a situation where I needed this delay capability except for some weird FPGA situations.

Now for the code...

The Feedback Node is set to delay a written value by 2 iterations.  So it keeps a history of the last 2 elements written to it.  You could think of it as a shift with overflow.  The history is initialized with the first 2 values in the initialization array, giving a history of [2,1].  So with the first iteration, i=0, so 0 will be written to the Feedback Node and 2 (the "oldest" value) will be the Feedback Node's output.  Now the history in the Feedback Node is [1,0].  Next iteration, i=1, so 1 will be written and 1 will come out, resulting with a history of [0,1].  Perhaps a nice ASCII chart will help...

Iteration        History   Output

Initialization  [2,1]        ---

0                  [1,0]        2

1                  [0,1]        1

2                  [1,2]        0

3                  [2,3]        1

4                  [3,4]        2

5                  [4,5]        3

[Bob_Schor]

I'm with @billko -- I have occasionally used Feedback Nodes (preferring "Do-Once For Loops"), and had never used Feed-forward loops until I started getting interested in the (somewhat arcane) Art of High Throughput FPGA Code.

I was going to cook up a simple example using a For Loop and Shift Registers (which can handle this example because of the "2" in the problem), but realized while I could "scale it up" for higher delays (3, 4, ...), I couldn't figure out how to do n=1.  So I'll go back to "Read the Help carefully".  

Bob Schor

[altenbach]

As I said before, I absolutely love the feedback node. You can cosmetically switch direction for better code layout, you don't need a dummy while loop for much cleaner code, and if you use the global initialization feature right, it can often eliminate the use of a "first call" primitive. You can place parallel FN in different cases eliminating tons of telephone wires (would even be better with this 11 year old idea, though. <hint, hint> :D).

Feedback nodes also don't have that abomination of resize-ability, leading to rigid code that never scales very well. Good riddance!

(Bob, not sure what a "feed-forward loop" is in the context of this discussion)