Why do feedback node changes direction?

[Dushyant]

Hello,
The program that I am attaching is a small part of code that I am writing for an application containing photodiode n stepper motor. However, this test code does not need any stepper motors or diode.
Photo_Diode.......vi is the main and other is a subvi.

Basically I am acquiring successive photodiode intensity (reading) and forming 2D array. Later on, I will display it (not included in test code). I am using while loop and feedback node to create 2D array with successive photodiode reading. I just noticed that the feedback node on second hile loop has changed direction and if I am trying to change it direction (by removing n adding new), I am getting error.
It may be a very dumb question. But please respond to it, if u have any idea.

Thanks,
Dushyant

[tst]

What kind of error are you getting?
I replaced it and the only thing I needed to do was reconnect the initializer terminal.
You are talking about the outer loop, right?

[Dushyant]

Oh, I am so bumb. I forget to intialize. Thanks a lot for helping me out.

[altenbach]

---

@Dushyant wrote:
I just noticed that the feedback node on second while loop has changed direction and if I am trying to change it direction (by removing n adding new), I am getting error.

---

The arrow direction on the feedback node is irrelevant for its function. It's just a cosmetic issue, and depends on the arrangment of the wires leading to it. In this case, you can just select the feedback node and move it down about 11 clicks using the cursors and it will flip. 🙂
(Alternatively, you can also simply shift the wires around a bit.)

[altenbach]

Just a few general comments on your program design.

Photodiode Program

The number of iterations of your two while loops is known before they start, thus they should be FOR loops.

You don't need any of these feedback nodes. Simply wire to the right edge of the loop and make the tunnel autoindexing.

To get the first element of an array, use "Index array". Converting it to a cluster followed by unbundling of the first element seems like a detour ;).

your big sequence is not needed. place the contents of the first frame to the right of your loops, then calculate the loop counts directly. Use the Z-array and y-array outputs to initialize the lower shift registers (see below).

your middle sequence is not needed at all. There is no reason that the x100 should occur before the other steps, let it run at the same time.

Your inner case structure (outer i=?0) is not needed if you would also add shift registers in the outer loop and initialize the shift registers with the z-array and y-array.

Your inner sequence structure is not needed. Both processes can occur at the same time. Stacked sequences tent to make code maintenance and debugging more difficult because they hide code.

Your N_Z and N_Y calculations on top are very dangerous and can lead to unpredictable behavior. Since there is no data dependency, it is theoretically possible that the loops run before these detached code fragments execute. In this case the loops would stop at i=1 if these values are still zero. These should be calculated directly from the control terminals, and not from local variables.

None of your local valuables are needed after making the above changes.

Experimental Path Program

Here you use a FOR loop, this is better. Instead of the shift registers you can autoindex on the outer loop, then reshape to a 1D array (with size of the product of the dimensions) outside the big loop.

The formula nodes seem like overkill. Wire math would be much simpler.

Happy wiring! 🙂