Unintentional/ unwanted clock and index reset

[J0SI]

Hello everyone,

I would like to record data depending on the runtime of the programme and then output it in a txt document. Unfortunately, for reasons that are not entirely clear to me, the value of the clock that I use as an index is reset to 0 at random times (sometimes around 31000, sometimes around 72000).
Can anyone tell me if there is an explanation for this reset?
Or if there is a better way to record and output the current runtime of the programme in milliseconds?

Have a nice day together and I hope you see what I have overlooked
Josi

[ZYOng]

Why don't you use Elapsed Time Express VI instead?

[pincpanter]

You are logging the very same data multiple times. You forgot to initialize the shift register to an empty array. As a consequence, new data in the inner loop are added to the whole history of already accumulated data.

[Bob_Schor]

There are several problems with your code.  Some have already been mentioned, but there are other problems (more fundamental).

• There are several "timers in LabVIEW.  Since you are wanting to "do something after a period of time has elapsed", you do not need a "High-resolution Timer" that can report times in fractions of a microsecond (as a Dbl) -- a timer that gives you a count in milliseconds (as a U32) will do.
• Did you notice (by reading the Help entry) that the High-resolution Timer (being derived from the same PC clock as the TimeStamp) is in seconds, and not milliseconds?  Multiplying a time difference by 1000 gives you "Elapsed time in kilo-seconds", a little weird.
• If all you want is the current runtime of the program in ms, do the following:
  • Outside the While Loop, drop a "Tick Count (ms)" (the first Timing function in the Palette).
  • To compute the elapsed time inside the loop, drop another Tick Count (ms) and subtract the first Tick Count (brought in through an ordinary Tunnel).

Here is a Simple Elapsed Timer example.  I'm deliberately saving it as a simple "picture" to encourage you to open the Timing Palette, look at the offerings, drop down some of the functions, and read the Help to understand what they do.  Then predict what the value of "Elapsed ms" will be -- I almost guarantee you'll be off by at least 8 ms.  For "Extra Credit", explain this.

 Bob Schor

[altenbach]

---

@J0SI wrote:

Or if there is a better way to record and output the current runtime of the programme in milliseconds?

---

• If you really want milliseconds, convert to U32 after multiplying with 1000 because integers are cheaper and easier to handle. Most likely your orange values have many irrelevant extra digits.
• I don't know your "lingo". What do you mean by "index" because there is nothing resembling an "index or "index array" anywhere in your code.
• Your loops run millions of times per second for no real reason.(Yes, you can't really use "tick count" because it might wrap at these speeds!)
• Why is "y" inside the inner loop? Do you expect it to change during the inner loop run?
• Your outer while loop is a glorified FOR loop because you know the final number of iterations before the loop even starts, so use a FOR loop!
• Why do you need to take the relative time twice in the inner loop? Once is sufficient. You can branch the wire.
• What is a typical value for "y" (and why doesn't it have a useful label)? Currently the default is zero which is not really reasonable. What value do you use and why not make it default for us before attaching?
• It seem silly to append an array of two values (x and x+1) because the second one can be calculated from first principles any time in the future so all you really need is a 1D array.
• Maybe you want to initialize and anchor the array on a shift register of the outer loop too and maybe build the array after the inner loop (it is not really clear what output you want. Maybe you only want 10 values!)

So please tell us all the control values you are using, how you run it, what you see, and what you expect to see instead as result. Where is the "data" you mentioned coming from?

[Bob_Schor]

Oops.  My second bullet point shows that I was confused, not the Original Poster.  Yes, the High Resolution Relative Seconds is in seconds, but multiplying it by 1000 (of course) turns it into milliseconds, which is probably what the OP intended.  

Bob Schor