Having trouble getting wait(ms) to run in parallel in my While Loop

[M_Peeker]

It looks like you have the wrong order of your Elapsed Time express vi:s. "Elapsed Time 2" will execute before "Elapsed Time", but you read your value from "Elapsed Time 2", so the time difference will be from "Elapsed Time" of the previous iteration until "Elapsed Time 2" of the current iteration. I think you've found one of the reasons why you shouldn't let wires go from right to left :).

[smandal]

I'm not sure if that is the issue. I can see there being a discrepancy between the two, but Elapsed Time is setup to auto reset and is used primarily for the lower frequency data logging. Elapsed Time 2 is what is constantly polled in every loop iteration and displayed on the frontpanel. I'm not arguing that what I've done is good practice :), just that it isn't the cause of the issue I am seeing.

So I am seeing a discrepency between consecutive readings of Elapsed Time 2 when I observe my overall loop delay to be 2 seconds + the loop run time, when in fact it should just be 2 seconds. It is seeming more and more that this might be an issue with conflicting threads due to the post I'd quoted previously, but I don't know enough about LabVIEW to know if that is really the case.

[rgb196]

edit - my bad

[smandal]

Where have all the Knights of NI gone? Perhaps I should have followed protocol and brought a shrubbery along with me? 🙂

[M_Peeker]

Oops, wrong by me there, sorry. Had somehow gotten into my mind that the timing express vi:s were interconnected. 

I doubt there is something wrong with the wait(ms) function, I would look at what behaviour in the rest of the code the wait will lead to. I can't import your snippet since I'm on Linux, so I can't see the configuration of your timing express vi:s, but one thing that would change is for example in how many iterations the logging will be triggered by its timing vi.

[NarayananK]

Would suggest to probe and check the error out variable of the tc08 Read.vi.

On a quick look of the snippet I suspect that could be the case.

[LV_Pro]

The 2000 mS timer's execution is not in parallel with the execution of the rest of the loop it is in, it is most likely before or after the core executes, thereby doing the 2000+execution time timing you are seeing. You can make a determination of the actual data acquisition timing, and change the loop delay accordingly.

Ideally you would have error checking at the time difference calculation for those instances where the daq time went over the desired delay, so that you don't send a "negative number", which, as these are U32 values, would be a VERY large number (no sign value for Unsigned Integers!) , on the order of  4.3 billion seconds!.

Also, the cleaner way, as mentioned earlier, is using the "Timed Loop" structure.

[smandal]

Thanks for the example VI Putnam. I did try something like that and it can work, but I still don't understand why the timer is not running in parallel. The LabVIEW documentation indicates that it should, and the example snippet I posted on my first post (the smaller snippet) seems to indicate that it does indeed work in parallel as I do see the expected behavior in that piece of code.

[smandal]

M_Peeker - I think the data logging (at least to the file) can be ignored as that is not so much the issue as the main loop itself. In the main loop, the Elapsed timer is simply measuring the time elapsed since the first iteration of the loop, and this is being output to an indicator that is updated through each loop iteration. Since I know that the execution time of my main loop is around 0.9 seconds (that is the update rate when I remove the loop delay of 2s), with a 2 second loop delay in the main loop, I would expect consecutive readings on the elapsed time indicator to change by ~ 2 seconds, but it changes instead in steps of around 2.6-2.7 seconds.

Naru_F1 - I don't get any errors from any of the modules, so I don't think that is the issue

[LV_Pro]

The timer function doesn't run in parallel when it is in the same loop. It will run, then everything else that is connected by "data flow", which in this case it the error wire. Or everything else will run, then the timer. It is just the way it is, and has been. To get things to operate in parallel they essentially have to be placed in different loops, which I guess signals the compiler to handle them that way.