loop iteration count increments by 2?

[EdgeTrigger]

Hi Labview Champs, 

I am using serial port(SPI) to read some data. My code would skip every alternate packet. e.g. Data sent 11,12,13,14,15,16 ; Data received 11,13,15.

By probing into code and using breakpoints, I found that the iteration count of main loop while(or for) loop, which contains most of the code, increments by 2. e.g. 0,2,4,6,8,10... or 1,3,5,7,9... which is very strange..! This happens with both for and while loop.

If I set a breakpoint at the last instruction, and step into code, the iteration count would increment by 1 (which is something I expect). There are no horrific conditions for the main loop, just simple T/F control. i.e. while loop would exit if button has been pressed otherwise stay in loop. 

If I change this condition so that main loop should run once only, and run vi by pressing "run continuously", I would get my lost packet. however, this way of running code clashes with some rules of sub vis I am using. 

Help me, please?

[nyc_(is_out_of_here)]

Your VI would help.

[EdgeTrigger]

Thanks for the reply. I have attached the vi.  

[Darin.K]

I can not look at the code, but in these cases I usually suspect a hardware issue, often from banging the I/O too quickly.  If you happen to have an error line in your loop I would probe it to see if it throws an error.  It could be that you are getting errors in every other cycle and perhaps you could slow down a little bit. 

[nyc_(is_out_of_here)]

I was able to open the VI except for the SPI-related VIs.

My suggestion which is similar to Darin.K would be to do as much data processing outside of your loop.

[altenbach]

---

@EdgeTrigger wrote:

By probing into code and using breakpoints, I found that the iteration count of main loop while(or for) loop, which contains most of the code, increments by 2. e.g. 0,2,4,6,8,10... or 1,3,5,7,9... which is very strange..! This happens with both for and while loop.

---

I assume you are talking about the coerced "Numeric 3" indicator.

• Do you see all the values if you would autoindex it at the loop boundary and run for a short time or does the final array increment by two? Alternatively, hook it up to a chart indicator and see if all values are there.
• You could also place a feedback node and subtract the current [i] from the previous. It should always show "1". Does it?
• Since front panel updates are asynchronous, I would not trust my eyes looking at a changing indicator.
• None of your code stores any data, so all you will see is the instantaneous state when the FP updates. How do you even know if data is skipped? And why do you even care if the values get updated constantly in one big blur? Nobody has eyes this fast!
• Since the SPI read does not depend on [i] it has no influence on the outcome. If the read skips alternate packets, it means that you are not reading fast enough. Read in a seperate tight loop and do some queuing.
• How fast does the outer loop actually spin? What determines it's rate?

[JÞB]

You are sure doing a lot to convert an array of U8s to an array of U16s  Just replacing the array functions (and cleaning up the (i+1)*2-1 to the equivalent i*2-1) saves a lot of BD space

I'm also guessing there is an easier way to cast a U16 into an I16

Spoiler

The convertion to I16 handles the sign bit all by itself.U16 in I16 out and none to the green wires are really needed are they?

[johnsold]

You can also add i+i+1.  No multiply needed.

Both lines on the right carry the same values.

Lynn

[MoReese]

I would suggest Altenback is correct.  I don't know that it's hardware related, but your while loop is not "skipping" iterations.  You say you are using breakpoints?  Have you tried slowing things down by turning on Highlight execution?  You will see your indicator changing at the proper rate with no skips.  I suspect that on odd iterations, your loop is running through faster for you to see it.

[EdgeTrigger]

Thanks a lot for your useful replies. Loop was not skipping iterations which I confirmed by using a auto indexed array. It's not hardware related. Indeed, I needed to save this data in a file, which confirms I am reading it correctly. Thanks again.