LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LOOP WILL NOT STOP

Hi Guys,

 

Having a slight problem with the VI attached, If I have used the loggging button (tuned on and then back off) and then press the 'Quit' button;  the while loop that contains the logging of the data to a TDMS file will not stop. (loop @ top right frame 2).

 

I have probing this loop several times and tried changing a few things but cant seem to get it to work. Was wondering if anyone could find something obvious??

 

Rhys

0 Kudos
Message 1 of 20
(3,568 Views)

Rhys,

 

I think that loop will stop, once you let it run.  The three Dequeue Element functions in the Logging Control = True case all have infinite timeouts. Thus, that case will not complte execution until something has been placed into EACH of the queues.  If either the Thermocopule Task or the Voltage Task is not running, the logging loop will not complete its iteration.  Furthermore, the Quit Test local variable is probably read at the very beginning of each iteration. If the Quit Test button is pressed after that, an additional iteration of the loop will be required, meaning that it will wait for each of the queues to get an addtional element.  If any of the enqueuing loop has already stopped (which is likely), The logging loop will wait forever.  The shutdown on error from releasing the queue will not work either because the error values tested in the logging loop are the errors generated by the Obtain Queue functions.  In this situation those will almost certainly be No Error.

 

Other problems:

1. Block diagram is too large.  Style Guides recommend that the blcok diagram not exceed the size of one screen.

2. Stacked Sequence structures should not be used. They obscure code, cause right to left wiring, and are very difficult to modify and troubleshoot. They probably cause execution to be more sequential than is actually required.

3. Avoid the use of local variables.  They break dataflow, are prone to race conditions, create extra data copies, force the code to run in the UI thread, and are slower than most other ways of transferring data. Local variables are not like locals in text-based languages. They are really remote terminals for front panel controls and indicators. For all practical purposes in LabVIEW the wire is the variable.

4. If you want to use the Queue release error to terminate a loop, you must put the error wires on shift registers.  This is an accepted practice, although I, personally, do not like it.

 

Suggestions. First. Learn about dataflow.

Next. Consider switching to a Producer/Consumer plus State Machine architecture for your program.  This would allow you to eliminate the sequence structure, the local variables, and probably some of the loops. It would give you a robust and scalable program architecture.

Also. Learn to use subVIs.  Your Strain, Thermocouple, and Voltage tasks use identical code.  The only differences are the values of the DAQmx Tasks, the enable booleans, and the queue names. By writing one subVI with these as inputs you simplfy your block diagram.  The subVI can be tested without needing the whole program to work. And if you ever need to change the functionality, you only need to change it one place.

 

The front panel looks very nice.

 

Lynn

Message 2 of 20
(3,555 Views)

Hi Lynn,

 

Thanks vary much for the help. I applied the timeouts to the dequeue functions and it did work. But I think I will take your advice and change the architecture of the VI to your suggested Producer Consumer State Machine. Is there a template available for this?

 

To get rid of the stacked sequence, do you suggest that I use a state machine, and have 3 states instead of the 3 frames in the stacked sequence? And then use a producer/consumer to pass data between each state??

 

I have now replaced the local variables of the quit button and created and event structure with a notifier that tells the loops to stop.

 

I also have some queries on the timming of the while loops. The data acquisition loops for example; If i place a sample clock on the DAQMX task outside the while loop, should I also place a wait(ms) function inside the loop? And if so how long do i delay the timming of the loop as I am only acquiring one sample? I am slightly confused about this.

 

Thanks,

Rhys.

0 Kudos
Message 3 of 20
(3,504 Views)

Allow me to clear up the issue about putting delays in loops.  The CPU will always try to execute the code as fast as it can.  During a delay, the CPU has time to perform other functions, like updating the front panel, servicing interrupts, and other functions.  If a loop does not have a delay in it, the CPU will get bogged down and never have time to perform other needed functions (except for critical functions like keeping RAM alive).  So always put a delay inside a loop. 

 

The amount of time for the delay depends upon the application.  If you are running a time critical loop, or need to run as fast as possible, wire in a zero to the delay input.  Even a 0 delay will allow the CPU some time to perform other functions (don't ask why because I really don't know how this happens - I guess that 0 actually means less than 1mS, so the CPU will take several uS away from the loop to perform functions).  If your loop is waiting for user input, you can use a large value.  I typically use 100mS.  It is something that you  have to play with sometimes, and experience will teach you the proper values to use.

- tbob

Inventor of the WORM Global
0 Kudos
Message 4 of 20
(3,475 Views)

tbob,

The answer to why is just a crtl+h away

!1.png


"Should be" isn't "Is" -Jay
0 Kudos
Message 5 of 20
(3,469 Views)

Rhys,

 

The delay issue has been well addressed by others.

 

A Producer/Consumer Design Pattern is found in the menus: File >> New.. >> From Template >> Frameworks >> Design Patterns.  A state machine  and some other useful design patterns are there also. The actual DAQ Reads would be in the Producer loop (or Loops) running in parallel with the Consumer. The Consumer loop would have the state machine as its structure.

 

Certainly the starting point for the state machine would be the three frames of the sequence structure.  I would probably split the first frame into at least two states, one to initalize the DAQ tasks (or this might be in the Producer) and one for the file.  The second frame would probably be divided into several states. Logging or not logging, front panel updates, perhaps a separate state to retrieve the data from each DAQ queue, an error handling state, and so on. The Queue releases, the file close, and other shutdown stuff go into another state.

 

The DAQ Read timing can be controlled several ways. The choice depends on what you are doing with the data and what your hardware can handle. It appears that you have set each task for continuous hardware timing at 500 samples per second = take a sample every 2 ms. Then you try to read one sample every 10 ms. You will be building up a backlog at the rate of 400 samples per second. At some point a buffer will overflow and you will get an error.  I would suggest reading all the available data every time and discarding the excess data if you do not need it. Also consider averaging the extra data points to reduce noise rather than discarding them.  Even though the Wait function is set for 10 ms, the OS will not reliably give you 10 millisecond intervals. The timing of the DAQ sampling is set by a stable oscillator on the DAQ board and will be more precise than software timing.  Use that for your data timing.

 

Similarly, you have zero chance of relaibly writing to the file at 10 ms intervals, again due to the OS. Accumulate the data in shift registers. Write less often and when you do write, write all the data which has accumulated.

 

Lynn

 

0 Kudos
Message 6 of 20
(3,456 Views)

Lynn,  Apparently Rhys has LabVIEW 2012.  One of the best features ever are the new project templates.  This sounds suspiciously like a "continuous measurement and logging (DAQmx)" project.  starting from that template will handle all of your design pattern problems and the documentation is excellant!


"Should be" isn't "Is" -Jay
Message 7 of 20
(3,446 Views)

Good point. Thanks, Jeff.

 

Lynn

0 Kudos
Message 8 of 20
(3,444 Views)

@JÞB wrote:

Lynn,  Apparently Rhys has LabVIEW 2012.  One of the best features ever are the new project templates.  This sounds suspiciously like a "continuous measurement and logging (DAQmx)" project.  starting from that template will handle all of your design pattern problems and the documentation is excellant!


Wow, that makes starting a new project so simple it's almost.... cheating!  I never bothered to look at the new templates, thanks for the mention. Smiley Happy

 

But why didn't they have this stuff when I was learning LabVIEW??? Smiley Mad

LabVIEW Pro Dev & Measurement Studio Pro (VS Pro) 2019
0 Kudos
Message 9 of 20
(3,427 Views)

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. But I have made some changes to my VI which has hopefully improved it.

 

But I was wondering wether you could take a quick look at another problem I have, with regards to the data logging. Two things really. I want an user selectable sampling rate for the data, which could be down as low as 1Hz. The problem I have is that the Strain module (NI9235) has a minimum sample rate of around 700S/sec. So how can I get a sample rate down this low with the module I have?

 

On another note, for the time being I have set my sample rate to 1000S/s. But I am finding in the TDMS file, there are only around 500 samples for 1 Sec? I dont understand this?

If you could take a look it would be great.

 

Many Thanks,

Rhys

0 Kudos
Message 10 of 20
(3,390 Views)