Conditional Loop Slow - LV2016

[JPCatABB]

Any Labview Expert,

I am trying to read data in from a laser displacement sensor and having it coordinated with the position of an encoder. 

My test setup consists of an encoder with a 3D printed wheel and a laser displacement sensor "looking" at the wheel (see image). I designed the wheel such that the radius changes linearly with rotation therefore a graph of the data should produce an angled line regardless of the rotational speed.  

The laser manufacturer has provided drivers that bring the reading in continuously, this seems to work. I have written a Labview program that looks for an incoming encoder pulse. When the pulse happens, I attempt to put the current value of displacement into an array. The problem is, the loop seems to be too slow to accomplish this. 

If I move the wheel by hand slowly, say 0 to 100 pulses, I only record 50% or less values.

I do not understand why the conditional loop is so time restrained.

Does anyone have a better approach to accomplish the task?

Any help will be appreciated! 

[richjoh]

Each time the loop is processed you using "Insert into an array", this will allocated memory to make a copy of an array insert your new value then use the new copied array. Then repeat next iteration. 

You may also have not set the correct data format when your reading DAQmx. Your format is set to Counter U32, 1Chan, 1Samp. 

Some dependent VIs were missing but this is what I noticed from the download.

Remove the Insert into Array is a good start. 

[RavensFan]

What exactly do you mean by "conditional loop"?  You have a while loop.  And that always has a conditional terminal to tell it when to stop.

You didn't attach the subVI's.  While loops themselves execute fast, it all depends on the code inside of it.  I suspect the missing subVI related to measuring an instrument is what makes your loop slower than you want.  Put some timers and indicators in that loop so you can see how fast it is actually running and tell us.

If you are just putting an element at the end of an array, then don't use Insert Into Array.   You should be using Build Array.  99.9% of the time Build Array is what  you want to use.  Only use Insert into Array if you know you actually need to Insert an element into the middle of an array.

Use Block Diagram Cleanup.  There is a lot of dead space and unnecessary wire bends.

[JPCatABB]

I said Conditional loop when I should have said Case structure. 

Inside the case structure is what seems to be too slow.

The GetCalcData.vi is from laser manufacturer and streams the reading continuously. Output from the laser is 10,000 samples per second. I don't think this is a bottleneck. While running the vi the indicator "Live Value" is continuously displaying values.

The EncoderDaq.vi is from DAQexpress to set up the encoder channel. 

I have attached the complete zipped project which should include all sub-vis.

I also have a screenshot after a short run. 

See the encoder pulse count went to 159 and the array only stored 13 values.

I also want to mention before using the build array I had a waveform chart in the case structure. I went to the array thinking the chart was the bottleneck.

[altenbach]

1. Your subVI returns a SGL, so you shift register should be SGL too. Half the memory!
2. The correct way to append an element to an existing array is "built array", not insert into array.
3. There is nothing obvious that defines the loop rate. What should it be?
4. If your VI runs forever, you'll run out of memory (and before that you'll get constant memory thrashing because of ever-growing arrays. Since arrays need to be contiguous in memory, reallocations need to occur occasionally.
5. What does the output represent in your picture? It's just data and code has no control over it.
6. Since you apparently only want the array outputs after the loop has finished, an autoidenxing conditional output tunnel can replace the entire case structure and array building.
7. Shouldn't there be some defined execution order between the DAQ IO and the missing subVI? (I don't have your drivers)
8. Your blue shift register is not initialized. Is that really want you want?
9. ...

[JPCatABB]

1. I changed all to SGL

2. Changed to build array

3. Loop is running at the quickest rate. I can add a ms delay.....

4. VI can run forever because the array is only added to under the true condition (encoder pulsed/ moved). Under the false condition (No encoder movement) the array wire just passes thru.

5. The waveform graph is a picture of each laser displacement reading at that particular encoder pulse. This should be a sloped straight line if it was collecting a point at every encoder pulse.

6. I started with a waveform chart in place of the array but thought it may be the bottleneck. That's when I switched to an array and waveform graph.

7 ? 8 ?

[altenbach]

---

@JPCatABB wrote:

4. VI can run forever because the array is only added to under the true condition (encoder pulsed/ moved). Under the false condition (No encoder movement) the array wire just passes thru.

Not really! If the VI runs forever, there can be an infinite amount of encoder pulses. Right?

What is the typical rate of the encoder pulses? I don't understand how the returned SGL value relates to timing. (As I said, I don't have DAQ and drivers installed here, so I cannot look at that part of your code).

How is the communication with the laser implemented? Maybe you can do do hardware triggering instead.

For testing, can you autoindex the counter output at the right loop boundary and graph that?

[JPCatABB]

Yes, you are right on the infinite comment. This is only a bench test and I am turning the encoder by hand.

In a real word setup the encoder would reflect the rotation of a ball screw and have a fixed number of expected pulses.Typical encoder rate 24,576 pulse /sec.

Attached zip file will have the drivers.

I don't see how I can trigger the hardware with the encoder. 

[RavensFan]

I see in a screen shot you added a 1 msec wait timer.  That means the loop run no faster than 1000 times per second. 

But you still didn't put some timer functions in there to measure how fast the loop is actually running.If you took a timer before the loop, a timer after the loop and divide it by the number of loop iterations, you'll see how long each iteration takes.

We don't know what is in the missing subVI (your zip file didn't contain it), but it sounds like an instrument driver.  Is it talking through a serial port?  I doubt you'll achieve sub-millisecond rates which it sounds like you are expecting to do.

[JPCatABB]

This is interesting. I decided to replace the sensor sub vi and just count the pulses as data for now. I got rid of the error shift register and change the encoder pulse count shift register to a Feedback Node.

So with this setup I am getting much better response. Graph is a straight line.

I can spin it physically at about 6400 pulses per second and only lose 40.