First Iteration of the most inner loop not behaving

[mark.alexis@gmail.com]

Refer to the code,

The most inner loop doesn't behave on the first iteration, 

I'm currently doing a test with laser, but with the first iteration, laser always returning the same value.

After first iteration, it then actually send command to laser and get the reading from it.

I'm curious on why it always happen on the first iteration and ideas to fix it.

Also, any suggestion on how I can clean up my VIs better.

[wiebe@CARYA]

It might help if you save back to LV20... More people (incl. me) will be able to look at your code.

Some embedded, additional images might help, for the lazy ones.

[mark.alexis@gmail.com]

Back to LV20,

Actual problem is current loop not returning the result of loop that just finished.

It's actually saving the result from the previous loop.

250	37
260	37
270	37
280	37
290	37
0	37
10	211
20	200
30	211
40	187
50	188
60	235
70	212
80	204
90	165
100	202
110	171
120	177
130	164
140	166
150	166
160	157
170	157
180	124
190	120
200	135
210	117
220	116
230	64
240	37
250	37
260	37
270	37
280	37
290	37
0	37
10	218
20	215
30	195
40	211
50	206

[altenbach]

Sorry, my laptop screen is not sufficient to efficiently debug (or even look at!) this at all:

[altenbach]

---

mark.alexis@gmail.com wrote:

The most inner loop doesn't behave on the first iteration, .

---

You have a stack of six(?) huge FOR loops containing a stack of two while loops (Aztec pyramid code!).

Can you pinpoint the "loop" you are talking about and where that output is that it produces?

---

mark.alexis@gmail.com wrote:

Also, any suggestion on how I can clean up my VIs better.

---

All you probably need is one (exactly one!) toplevel while loop and a proper state machine architecture.

Also, what is this? (just the tip of the iceberg!)

Hidden wires flowing in all directions. Aren't these just Rube Goldberg versions of simple "built arrays"? Why not use a single 1D complex array for the xy graph data?

[paul_a_cardinale]

You've created a huge mess.

It's not debuggable.

It's throw-away-able.

[santo_13]

---

mark.alexis@gmail.com wrote:

Refer to the code,

The most inner loop doesn't behave on the first iteration, 

I'm currently doing a test with laser, but with the first iteration, laser always returning the same value.

After first iteration, it then actually send command to laser and get the reading from it.

I'm curious on why it always happen on the first iteration and ideas to fix it.

Also, any suggestion on how I can clean up my VIs better.

---

As others have voiced, it is unfortunately a piece of code that even the developer cannot understand or debug after some time.

Few things,

1. use state machine or QMH
2. abstract implementation in logical subVIs

[wiebe@CARYA]

---

mark.alexis@gmail.com wrote:

Back to LV20,

Actual problem is current loop not returning the result of loop that just finished.

It's actually saving the result from the previous loop.

---

I put by bet on adding a shift register... That is, to fix this bug, not the underlaying problem (things are made way too complex).

But there's not really a way to see what the code is supposed to do.

[Yamaeda]

That screams of race condition. I guess there's a bunch of local variables or Value properties spread about?