program acquisition rate doesn't match my triggering rate.

[mrphud]

Hello,

I have a GAGE data acquisition board that I am collecting data on. There is an SDK kit that comes with the board (basically a virtual oscilloscope) that I can use to acquire data. I decided to use the virtual oscilloscope as a sub vi so I can collect and store/process my data. However, MY program doesn't seem to work faster than 10 Hz!!!

I checked to make sure the oscilloscope program was working at the proper rate (that is, whatever rate I trigger the board), and it was fine. But, when I use the oscilloscope program as a sub vi, the overall program works at a rate no faster than ~15 Hz.

I have attached the two vi's. Let me know if you need the sub vi's for the oscilloscope program.

Cheers 

[johnsold]

One major problem with the GageTOFAcquire.vi is that it completely initializes the DAQ board and also releases it afterwards on every iteration.  This has to slow things substantially.  With all the nested stacked sequence structures and local variables it is apparent that the person or team which wrote that VI was not very skilled at modern LV coding techniques.

Split that into at least 3 VIs. One would contain all the functionality of frames 0-2 of the outer sequence structure and 0, 1, and perhaps 2 of the inner sequence structure in frame 3 of the outer structure.  CsTool-Capture.vi may need to be included in the intialization section or may need to be in the read loop.  I cannot tell.  The contents of frames 3 and 4 of the inner structure become the "Read" subVI. The CsTool-FreeSystem.vi is the third part.  Put the first part before a loop.  The Read part goes inside the loop.  FreeSystem runs after the loop.  The Force Capture part may also need to be evaluated.

Your program could also be a state machine with the Initialization stuff in one state, Read in another, and FreeSystem in a different state.

Lynn

[mrphud]

Hi Lynn,

Thanks for the reply. I am not completely sure how to implement the instructions you gave to me. However, when I run the oscilloscope program by itself the acquisition rate and the trigger rate match. The problem only occurs when I use this program as a sub vi. This is the main issue and I don't know if it will be fixed just by rewriting the GageTOFAcquire.vi.

Is there something in LabVIEW that slows down the acquisition rate when I connect the graph as a terminal?

Is there a faster/better/less costly way to output the data to a terminal or is a XY graph fine?

mrphud 

[mrphud]

---

@johnsold wrote:

One major problem with the GageTOFAcquire.vi is that it completely initializes the DAQ board and also releases it afterwards on every iteration.  This has to slow things substantially.  

---

I forgot to mention. When I test the oscilliscope program independently, I use the continuous option. If the continuous button is pressed I don't think the board is released. It is only when I run it on single acquisitions. This might be the issue.

I am not sure how to check this. I didn't even know the board was being released in the first place.

As you can tell by my other program. I only want to use the oscilliscope for a set number of averages. It seems like I have to prevent the oscilloscope program from releasing during acquisition, but release it in MY program after I'm done. Does this sound right?

[johnsold]

The XYGraph should be OK.  As long as the GageTOFAcquire.vi front panel is closed while you are running it as a subVI, the graph does not get redrawn.

When you refer to the "oscilloscope program by itself" do you mean the GageTOFAcquire.vi? It looks as though it may stay in the loop in frame 3 and repeatedly read data without re-initializing most of the instrument.  If so, this may tend to validate my suggestions.

As for implementation, I would start with cut and paste.  Actually, I would rewrite the whole thing.  But the simplest way for you is probably the cut and paste route.  First, make backup copies of all the original Gage VIs.  Put the copies somewhere so they cannot accidentally be modified.  

Then make two copies with new names.  Take the one which will become the Initialization VI and delete all the contents of the frames I said you did not need for intialization.  Decide whether the CsTool-Capture.vi belongs in Init or Read.  Also remove the while loop in frame 3.  See if you can get what is left to run.  Does it set up the scope properly?

The copy which will become Read gets almost the opposite treatment.  Delete everything that was left in the Init VI. Delete frame 4. About all that is left will be what was in frames 3 and 4 (and maybe 2) of the inner structure.

You may need to rewire some things which had used local variables.  Wires are always better than locals.

Lynn

[mrphud]

Hi johnsold,

I have been looking at the GageTOFAcquire.vi and it appears that when the continuous option is used, there is no release or getsysteminfo being called, which is precisely why I can collect at very fast acquisition rates. 

I am wondering if there is a way to store the signals that are acquired when the continuous option is selected? I would have to remove the for loop in "Collect TOF Spectrum"  because the for loop causes the sub vi to reinitialize every iteration, but would a while loop work? I doubt it, but I thought I might ask. I am trying to explore any solutions I can find by rewriting my program before I try rewriting the GageTOFAcquire program. Any suggestions? Or is rewriting the TOFAcquire program the only option?

Thanks

P.S. From your previous post, I get that there needs to be an 'init', 'read' and later 'free system' that I can add to Collect TOF .... . The 'init' would need to be outside the for loop, 'read' inside the for loop and 'free system' outside. Am I correct? The difficulty is deciding where exactly to split GageTOFAcquire. There will also be a difficulty in transfering the proper handle clusters from sub vi to sub vi right? How do I add the handle cluster to a terminal? I need to create a cluster spot on the front panel right?

mrphud 

[johnsold]

I agree that the continuous option appears to keep the program in that segment which only reads data repeatedly.  That is exactly what I was trying to set it up for you to do by splitting the TOF Acquire into three parts.

LabVIEW is a dataflow language.  That means that any node (such as a sequence structure) must complete it execution before anything wired to its outputs can execute.  Using TOFAcquire as a subVI requires it to complete its execution every time it is called: Init and Free System included.  This is why it works well as a stand alone porgram but is not suitable for use as a subVI.

If you follow the guidelines I suggested above about where to divide it, you should be pretty close.  I was a bit uncertain about a few of the subVIs because I do not have them and could not tell from the names whether they belonged to the Init section or Read section.

A for loop or while loop works exactly the same as far as any code inside the loop.  The only real difference is how you stop the loops.  You can store the signals in shift registers or use parallel loops to separte the data acquisition from processing and saving. Search for Producer/Consumer.

From your question about wiring inputs and outputs to subVIs, I infer that you have not worked with LV very much.  A good starting point for basic concepts such as those is the on-line tutorials.  Also look at the help files. The complete manuals for LV are in those files.  Sometimes searching through them can be a bit frustrating, but there really is a lot of useful information included.  Any control or indicator on the fornt panel can be connected for input and output when used as a subVI by clicking on the terminal on the connector pane and then on the control.

Lynn

[mrphud]

Hello Again,

As an update to this post I am uploading the modified versions of the program. I did as johnsold said and cut and pasted different parts of the original program.

What I did was separate the program into an init, read, and release.

Hope this helps future GaGe card users.

mrphud

[johnsold]

Glad you got it working.

Lynn

[mrphud]

Hello again,

With the previous modifications I was able to increase my acquisition rate from 10 to 20 Hz. I realize it has been awhile, but this is the speed of research. I tried running my program at 40 Hz and was unsuccessful (i.e.. 20 Hz was the maximum this time). I mentioned previously that the original program set in continuous mode will run at several hundred Hz. However, looking at the code for the original indicates that the init portion is done once (like I tried to do before) but it is used within that vi. This is in contrast to the "read" program set in a for loop. In the for loop the read vi is called at each iteration. Consequently, I believe the continual transfer of init parameters to a new read vi is bogging down my acquisition. Are there any suggestions/comments on this. My programs are still uploaded from previous posts I believe.

Thanks