From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LOOP WILL NOT STOP

Rhys,

 

You still do not have a true state machine.  All you have done is replace the stacked sequence structure with a while loop and a case structure.  Your looging loop is more like a state machine because the next state is chosen based on values within the current state.

 

Timing: Your VI is still complicated enough that estimating the exact timing of the writes to file is not straightforward.

- Each of the DAQ loops has a 1 ms Wait. If everything else in the loop runs faster, the Waits may run in parallel but it is not guaranteed. With the DAQ sampling rates set at 1000 samples per second, you might have to wait for a sample to be available.  You also have 1 ms timeouts on the Dequeue functions in the logging loop.  With all these things competing for the same millisecond, it seems likely that 2 ms cycle times could occur.

 

You are using the Available Samples ... property node but not taking advantage of the data. What if there are 2 or more samples available? Your code will never catch up.  Reading all available samples might be a better choice.  Since you seem to only be logging the data, why not read data a few times per second or less and write bigger chunks to the file each time. Your hard drive would probably like it better, too.

 

You only check Dequeue Timed out on two of the queues.  What happens if the voltage task is turned off?

 

The Data Table loop only runs 4 times per second.  The way the DAQ loops run, the Data Table will only see 4 samples per channel per second, not the 1000 that the DAQ acquires.  Is that what you want?  You have not posted the Data Table.vi so I cannot tell what it does.  If peaks and troughs can occur on time scales of milliseconds, you may miss them.

 

Lynn

0 Kudos
Message 11 of 20
(804 Views)

Lynn,

 

So when you say, state machine, should I have a loop within my 'run' case, which is a state machine, doing something like this:

state 1 = Read Data

state 2 = Write to file

With the state machine looping continuously between these states?

 

The dequeue timeout is just something that I was playing with because i was getting more time data in the file than measured data.

 

So i could delay my read loops to 200mS etc, but read all the available samples each time, and log to file at the same rate? 

 

The reason i have delayed the data table loop to 250mS is to stop the values in the table fluctuating so quickly, so that they are possible to read. It might be better if I put the peak and trough VI in the read loops so that they catch all potential peaks and troughs and then pass the data using a queue to the data table loop.

 

I am out of the office currently but I will attach the Data Table.vi when I return.

 

Rhys

0 Kudos
Message 12 of 20
(785 Views)

@Rhys_CKTC wrote:

Hi Guy's, Thanks for your help so far.

To be honest I havent gone down the route of using the template, I opened it up and found it quite difficult to modify it towards my VI.

  

Many Thanks,

Rhys


That is unfortunate.  Perhaps I should have been a bit more elaborate discussing the new feature.

Capture.PNG

It Appears that NI thought to include some really amazing things in the feature! See that "More Information" bold text?  It gets you right to here

 

Of course that template help suggests you read this which goes into much more detail about the Queued Message Handler Template and how to modify it.

 

Both of them contain this link:

Capture1.PNG

Those links take you here or Here

Capture2.PNG

Where the actual developer of the template will walk you though using the template you chose!

Really, this feature might just start hurting my Forum Post count.Smiley Very Happy


"Should be" isn't "Is" -Jay
0 Kudos
Message 13 of 20
(780 Views)

Rhys,

 

What I envision is making the outer while loop and the large case structure into the state machine. Split the 'run' case into multiple states such as Read Data, Process Data for Table, Write to File, and perhaps others.  The inner loops would all go away.  The loop with the event structure woule probably be a separate parallel loop.  That  would convert the program to a standard Producer/Consumer (events) design pattern.

 

If you do not mind hurting Jeff's post count too much, follow his advice and read up on the new features. You could probably start from scratch with that sample project and get a good result in about the same time it would take you to modify what you have now.

 

Is there any reason why you cannot put all the measurements into a single DAQ task? You are sampling and reading at the same rate. When you have  the Thermocouple or Voltage tasks diasbled, simpy discard the data for those channels.  You would use Read N Channels, N Samples and get a 2D array.

 

Lynn

0 Kudos
Message 14 of 20
(766 Views)

Hi Guys!

 

So I have taken your advice and attempted to use the sample project that you suggested. At the mo I'm getting an error with regards to the DAQ Channels. Lynn, i took your advice of putting all the measurements into one task, I concatenated each task into a string (In the initialize channels State of outer SM). But something within the VI does not like it. Was wondering if you could have a look at this?

 

Rhys

Download All
0 Kudos
Message 15 of 20
(739 Views)

Hello,

 

be careful when you use a while loop in labview VI, because according to the documention of the function(labview Help), the instruction execute at least once before testing its conditions of réitérartion.

 

Alexandre,

0 Kudos
Message 16 of 20
(735 Views)

Alexandre,

 

I do not understand the relevance of your  comment.  There is no probleem with the termination condition in Rhys' most recent code.

 

Rhys,

 

Nice. I do not have DAQmx and many of your subVIs are not included, so I cannot tell what the problem might be.  What errors do you get? Simply stating that the VI "does not like it" is not very helpful in troubleshooting.

 

Your Strain Channel Setup SUB.vi has way too much duplicated code. If you ever need to change anything in there, it will be a big job to make sure each change is correctly made in 16 places. Create an Add Channel to Task subVI. Place it in a for loop with autoindexing of the arrays.  That block diagram which was about 4 screens in area now fits on < 1/4 of a screen.  Also make the Strain Gauge 1 cluster into a typedef. Then any changes only need be made to the typedef and they will propagate throughout the code.

 

Lynn

 

Duplicate code.png

0 Kudos
Message 17 of 20
(718 Views)

Sorry I was a bit vague with that. See the attached PNG which shows the error I get. Let me know if you want to see any of the subVI's to troubleshoot this problem. Would there be a problem with passing the task to the next state using a shift register?

 

Thanks for the advice with the masses of repeated code I have!  Deffinately something i need to change.

 

Thanks,

Rhys.

0 Kudos
Message 18 of 20
(692 Views)

OK, the PNG didnt attach on the last post.

 

Should attach now,

 

Also, another PNG show's how I concatenate the tasks into a single DAQmx task. Is it correct to do it this way?

 

Rhys.

Download All
0 Kudos
Message 19 of 20
(672 Views)

@Rhys_CKTC wrote:

OK, the PNG didnt attach on the last post.

 

Should attach now,

 

Also, another PNG show's how I concatenate the tasks into a single DAQmx task. Is it correct to do it this way?

 

Rhys.


No.  You need to use the Create Virtual Channel VI (in the DAQmx palette) to add channels to a task.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 20 of 20
(666 Views)