While loop runs too many times after update to Windows 10

[EdHarris]

This VI has been running continuously for years but I recently updated from windows 7 to 10 and cannot work out why the whole VI now randomly outputs to file 2 or 3 times with about 11 seconds interval between each data time. It should only run once.

I have added Altenbach's superb NTPparse(2) as a sub VI and didnt notice the error before that but changing back to the usual time stamp VI the error persists. I tried putting the Modbus open and close VIs outside the for loop so that it is streaming to file but this made no difference. This is Labview 2014 but the same thing happens with Labview Community Edition.     Can anyone suggest what is wrong?

Data example

73.474350,0,1,14:52:56.670 04/02/2023, 2.4
73.475082,0,1,14:53:08.024 04/02/2023, 2.4
73.474564,0,1,14:53:19.374 04/02/2023, 2.1

[altenbach]

Hard to tell without more information and all these missing subVIs, but this VI will run forever, until the stop button is pressed. Since there is no data dependency, the stop buttons is one of the first things that gets read, so if you press it even a nanosecond later, it will run for another iteration.

That said, LabVIEW 2014 is NOT officially supported on windows 10. So there are no guarantees.

Did you also upgrade to a new computer? New serial interfaces? It could well be that it runs differently on a faster computer with more CPU cores.

Overall, the VI seems a bit strange. Are the control defaults reasonable? (I.e. are you really constantly opening and closing the same serial port (COM5)? What's up with the one iteration FOR loop, which is basically a glorified sequence frame where you need to undo the autoindexing later. Somehow, I get the feeling this could be made into a simple state machine that fits on a postcard. 😄

[EdHarris]

Its the same computer and hardware. Its interesting you say there is no data dependency as I thought the error wire keeps the sequence in order?

I have a version of the VI on Community Edition which is 2022 Q3 and have the same problem.

The one iteration FOR loop normally runs for 40 iterations I just put it low for testing. 

[altenbach]

---

@EdHarris wrote:

Its the same computer and hardware. Its interesting you say there is no data dependency as I thought the error wire keeps the sequence in order?

---

The terminal of the stop button does not depend on the sequence.

Your toplevel loop contains two main independent "code islands": (1) The sequence train, (2) the stop terminal wired to the termination condition. With every iterations, both will start running immediately and in parallel. Once the stop terminal is read, the stop condition is set and the terminal won't get read until the next iteration. To delay reading the stop button until the bulk of the loop code has run, you could put the terminal into the last sequence frame.

Still, a state machine would be significantly simpler, avoiding all that code duplication.

And yes, except for the waits, the sequence is irrelevant because the error wire already determines execution order. (Except, the sequence also delays reading of some of the controls, so if you would operate them during the run, the outcome would be different (but probably similarly wrong...).

[EdHarris]

---

@altenbach wrote:

---

To delay reading the stop button until the bulk of the loop code has run, you could put the terminal into the last sequence frame.

---

So that is the stop for the outer While loop you are talking about? The program is intended to run for ever by the way.

[altenbach]

The outer while loop writes to a file once for every iteration. I don't understand why you only expect one entry if the code runs forever?

[EdHarris]

---

@altenbach wrote:

The outer while loop writes to a file once for every iteration. I don't understand why you only expect one entry if the code runs forever?

---

It caries out a process then writes the data collected. This should happen continuously but I dont know how it is getting three lots of data to write together at the end when it writes to file at the end of the iteration. 

[altenbach]

Well, your loop content takes a little more than 11 seconds (150ms+3000ms+4000ms+4000ms, plus the communication overhead, so that sounds about right.

It will take longer if you increase the number of FOR loop iterations again (i.e. 4000ms longer for each iteration).

[EdHarris]

So its definitely going through three iterations before writing as all the other data is collected - not just that in the FOR loop. Could the final build array function be collecting three sets of data before passing it on? 

[altenbach]

Yes, it collects all the data with the various sequence steps, and they take a total of ~11 seconds. each iteration of the outer while loop creates one log entry. Why not put an indicator at the iteration terminal of the outer while loop to see how often it starts over.

The final build array includes exactly one timestamp per dataset. A "build array" has no history memory! It only operates on the current inputs.

Do you get errors? Maybe one of the communications errors out and does not return data.

We need to assume that the motor is already stopped for the inner while loop to only take 3 seconds (assuming the termination logic is correct)..