Running two tasks simultaneously

[mcduff]

Sequences should stay. They are extremely useful for FPGA. Wiring elements together via error wires is more expensive than using sequences.

As with anything, they can and will be abused, but with proper use they have a role.

mcduff

[Mark_Yedinak]

---

@RTSLVU wrote:

Sure, but an extremely limited purpose.

NI could replace that with some kind of "container" for flow control of VI's and primitives that don't have an error cluster and deprecate sequences all together.

---

And that structure is the flat sequence frame. It already exists. No need to create a new one.

[billko]

---

@RTSLVU wrote:

---

@aputman wrote:

---

@bseguin wrote:

ARRGHHH... Never suggest a flat sequence... it creates messy code

---

I disagree.  Sometimes a flat sequence is required, especially if the VI in question doesn't have an error wire (such as the timestamp function in this question). 

---

I have to agree with Benoit here, the flat and stacked sequence both should be deprecated.

But to your example a SINGLE FRAME sequence with an error cluster running through it for sequencing is the only time a Flat Sequence should be used.

---

Technically, you can dispense with sequence structures all together if you put whatever is in the sequence structure in a subVI instead.

Edit: As usual, I forget about FPGA applications.

[kaba2005]

Hey guys, you're off topic.

[aputman]

---

@kaba2005 wrote:

Hey guys, you're off topic.

---

We can't be off topic if we don't know what the topic is.  You haven't answered any of the questions or clarified what you need.  

[mcduff]

On topic:

• You have not provided any code
• Why does the Current Time and Sampling Rate need to execute simultaneously? Me thinks that you want the DAQ Start and Current Time to start simultaneously.
• What does the while loop notation tell us? LabVIEW is graphical, we can tell it is a while loop.

As the Cromulons say "Show me what you got." R&M

Cheers,

mcduff

[Drakelau]

I am appreciated for all the comments and suggestions. I will try Kay's suggestion once I have access to my VI.

What I want the code to achieve is that when the time elapsed is greater than or equal to the "Run Time" (user input), the code will stop. However, when I run the code, the "Sampling Rate" data will send to the DAQmx Read vi first and the time out of the DAQmx Read vi is, let's say, set to 2 seconds, the data will be collected using the Write To Measurement vi for this 2 seconds. Then, the Get Date/Time vi will run. If I want to stop the code after running 10 seconds, then the user will input 10 in the "Run Time". However, when I checked the saved text file from the Write To Measurement vi, the entire time recorded is 12 seconds instead of 10 seconds (I tried different combination, the total run time will still be the sum of the QADmx Read vi timeout and "Run Time"). This makes me think that these two tasks run separately and right after each other.

I am thinking another easy fix, maybe I can use "Run Time" to subtract DAQmx Read vi timeout (using the same numbers mentioned above: 12s total run time - 2s timeout = 10s desired run time). Does this logical?

Thank you,

Drake

[mcduff]

Why not take a finite set of data points instead of a comparison of run time? For example, my sampling rate is 1000Sa/s and I want 10s of data. I set DAQmx to Finite Acquisition instead of continuous, and I take 10,000 samples.

mcduff

PS If you haven't already, you should post your VI. People on the forum can and do modify VIs that are posted.

[paul.r]

Every node in the loop must execute each iteration - just because the loop will stop that iteration doesn't mean that any node within the loop is stopped before completion. So, if each iteration takes 2 seconds, and at the end of one iteration the run time is 9.99 seconds, the next iteration will still run and is going to still take that 2 seconds. As you mentioned you could add the loop time back in to account for this - if the run time + loop time is greater than desired run time, don't do the next loop.

Also, the way you have it wired up right now, you aren't get an accurate or reliable run time measurement, because you have no way of knowing when the second get current time node executes - it could return the time before the DAQ read occurs, or after! Put it in a sequence structure and make that check the last thing that occurs in the loop.

[Drakelau]

Thank you for the suggestions! I tried both Kay and Paul's suggestions on my VI, they don't seem to work. The total run time will still be the sum of run time + loop time. I have attached the VI with Paul's suggestion. Yet, if I use my idea to fix this, the elapsed time count will not be the same as run time value and I found this is a little odd. Is this a good fix for the problem?

I have also another question. It seems like the time elapsed count is a little off, see attached Front Panel picture. Is there a way to improve the count? 

To answer mcduff's question - the reason I am not using the finite set of data point is because I'd like the user has an option to run the code continuously orto specify a run time.

Drake