LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Running two tasks simultaneously

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

Message 11 of 31
(1,119 Views)

@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.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 12 of 31
(1,115 Views)

@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.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 13 of 31
(1,108 Views)

Hey guys, you're off topic.

Smiley Frustrated

0 Kudos
Message 14 of 31
(1,094 Views)

@kaba2005 wrote:

Hey guys, you're off topic.

Smiley Frustrated


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.  

aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
0 Kudos
Message 15 of 31
(1,090 Views)

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

 

0 Kudos
Message 16 of 31
(1,084 Views)

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

0 Kudos
Message 17 of 31
(1,056 Views)

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.

0 Kudos
Message 18 of 31
(1,045 Views)

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.

0 Kudos
Message 19 of 31
(1,041 Views)

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

0 Kudos
Message 20 of 31
(999 Views)