LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Synchronizing the counter and analog inputs

Solved!
Go to solution

Hi,

 

This is Abbishek and I am a student in Auburn university. I am using labview and USB-6341 DAQ board to acquire force and encoder data. The program description is as follows:

 

1. The analog input task in the program is being used to acquire the data from a force transducer.

2. The counter input task in the program is being used to acquire the data from the encoder.

3. The counter output task in the program is used to generate pulse train to the camera.

4. A digital task which acts as the trigger signal to start the acquisition.

 

The counter output task which generates the pulse train acts as the sample clock for the encoder and the force. In this program, all the tasks are starting together. However, the number of samples in the encoder and force tasks come out to be different. I want the sampling rate of the encoder and force to be the same and the data should be acquired simultaneously. The labview program is attached here as well. Can someone please help me out with this issue?

 

Thanks in advance.

 

Regards,

 

Abbishek

 

 

Download All
0 Kudos
Message 1 of 7
(2,974 Views)

You have 2 very different approaches to saving data to file.  One is a conditional call to append to a file inside your reading loop.  The other accumulates all data unconditionally and writes it after the loop ends all at once.

 

Taking a step back, your 2 measurement tasks are hardware-synced by sharing a sample clock.  You should be reading the same # of samples at a time from them in the same loop to keep your data in sync.

 

Beyond that you should spend time learning about the "producer consumer" pattern.  Then you'll have one producer loop that reads from both measurement tasks and sends it off to a consumer.   The consumer loop will do the file logging and whatever other live calcs and display you want.

 

While you're at it, put some time into tidying up all those wires.  Too much unnecessary mess!   Messy code is much harder to trace, understand, and debug.

 

 

-Kevin P

 

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 2 of 7
(2,935 Views)

Hi Kevin, 

 

Thank you for the advice on the programming. I brought in the force measurement (analog input) into the counter loop and used the same source for the sample clock for both the tasks. However, now the boolean is not at all being read in the program. Attached are two programs. "Servo Triggering_iteration3.vi" is the program where both are in different loops. Here the boolean (signal for triggering) is being properly read. "Servo Triggering_iteration4.vi" is the program where everything is read in a single loop. Here the boolean (signal for triggering) is not read at all and the program starts giving error after a while. Can you please help out with this issue?

 

Thanks

 

Abbishek

Download All
0 Kudos
Message 3 of 7
(2,911 Views)

You could just trigger your pulsetrain counter in hardware instead of polling a DI line in software.  You'll need to wire to a PFI terminal because those are the ones that can be used as digital triggers.

 

What error do you see?

 

I'd put more time into trying to analyze your code if you'd put more time into cleaning up the unnecessary messiness that demands much more effort to follow & interpret.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 4 of 7
(2,903 Views)

Kevin,

 

The digital trigger is needed as we are using this trigger generated from a different device and not from a trigger from the encoder programming itself. The trigger in the DI line is not a software trigger but it is a digital signal generated from a different device which is used as the trigger. 

 

When the program is run, the encoder and the force data waits and nothing is displayed. After getting the trigger from another device, the boolean does not go green in "Servo Triggering_iteration4". After sometime, the error pops up says the following:

 

Possible reason(s):

Some or all of the samples requested have not yet been acquired.
To wait for the samples to become available use a longer read timeout or read later in your program. To make the samples available sooner, increase the sample rate. If your task uses a start trigger, make sure that your start trigger is configured correctly. It is also possible that you configured the task for external timing, and no clock was supplied. If this is the case, supply an external clock.

Property: RelativeTo
Corresponding Value: Current Read Position
Property: Offset
Corresponding Value: 0

Task Name: _unnamedTask<3>

 

I cleaned the messiness a bit more than yesterday in "Servo Triggering_iteration4" VI to make it more readable. 

 

Please let me know if any other details are needed and if I need to clean up the program more.

 

Abbishek

0 Kudos
Message 5 of 7
(2,899 Views)
Solution
Accepted by topic author Abbishek94

If the external device issues a brief digital pulse as the trigger signal, that's all the *more* reason not to count on seeing it by polling a DI line in a software loop.  You should instead configure your "camera counter" to use that signal as a digital start trigger.

 

As your code is now, failure to see the external signal go high prevents you from starting your camera counter.  Since your encoder counter and AI task use the camera counter as their sample clock, they never do any sampling.  So when you try to read 100 samples, the attempts time out because no samples have been taken yet.  The error text mentioned this possibility when talking about an external clock that wasn't supplied.

 

I had a little time to kill this evening and did some further tidying.  I didn't make any functional changes to the code, I just neatened things up to show how much easier you can make things on yourself and others trying to help when you spend a little time eliminating unnecessary wire bends and crossings.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 6 of 7
(2,865 Views)

Kevin,

 

Thank you for the suggestion. I get the point of using the digital trigger in the camera counter itself. I will try it out first thing tomorrow morning.

 

Also, thank you for letting me know about cleaning the program. I will keep this point in mind.

 

Abbishek

0 Kudos
Message 7 of 7
(2,826 Views)