Encoder Position and Velocity Measurements and Force Measurements ( Z_ INDEX ISSUE

[dalvares]

Hi,

I am using a USB 6210 DAQ Card and an optical encoder and force transducer together in an MRI room to measure the power ouput of a patient pedalling on a recumbent ergometer. I would like to obtain synchronous measurements and output this to file. I have started working on the code for the encoder. I am struggling to get the frequency measurement and encoder position outputting fast enough. Any idea why this is? For the force measurements will this be with the same configuration just adding Vi's for analog input. Also I know using the write to measurement file vi is quite slow to write to a spreadsheet what is the more efficient method for doing this.

Regards,
Darren

[mfitzsimons]

Look at the TDMS examples.  These are made for streaming application.  This one should be close to your needs: Cont Acq&Graph Voltage - Write Data to File (TDMS).vi  Open examples in LabVIEW and search for TDMS.

Message Edited by mfitzsimons on 02-15-2008 05:28 PM

[BrowningG]

Hello Darren,

The fastest file to write to in LabVIEW is a binary file.  The specific file type used by LabVIEW is the Technical Data Management (TDM) file.  The TDMS file is a version of this file specifically designed for streaming applications.  You can find several examples of writing to this file in the NI Example Finder (Click Help -> Find Examples).  By using the search tab, you can use the keyword “TDMS” to search for all of the examples that use the TDMS file type.  The example Cont Acq&Graph Voltage - Write Data to File (TDMS) can be found from the search tab, or by using the path Hardware Input and Output -> Analog Measurements -> Voltage.  While the data acquisition part of this example pertains to analog input, the same file input structure can be used with your counter input tasks. 

What do you mean that the encoder and frequency measurements are not fast enough?  Each rising edge of the sample clock source will latch the current value of the measurement into the FIFO and transfer this value into the buffer.  At this point, how quickly you can read the buffer will affect how quickly the user is updated with the newest measurement information.  Since you have specified the number of samples to read in your buffered example, the read VI will wait until that many samples are available in the buffer before returning a measurement (this could slow down the update rate for the user).  By specifying -1 as the number of samples to read, you will read all available samples in the buffer.  If there are no samples available, nothing will be returned, but the VI will continue to execute.  Hope this helps. 

[dalvares]

Hi All,

Thanks for suggesting using the TDMS measurement file. What I mean by not outputing fast enough is that the counts are not being displayed fast enough. When I only have a single task for example measuring the angular position then the count is displayed countinously as I move the shaft. When I add in another task measuring the frequency on counter 2 of the z index it only displays once everything couple of seconds. i.e it can't capturing position information in that time.

Is it because I have them both in the same loop?

Regards,
Darren

[RavensFan]

Almost certainly.  The loop will only run as fast as the long path of execution allows it.  I would bet that the frequency measurement on the Z index takes longer and is thus slowing down your loop.  If it's the code you put in your earlier reply, I don't see any reason why you can't break that into parallel while loops.

[dalvares]

Hi All,

Thanks for your feedback. I have moved along with the code but a bit confused on a couple of issues.

I have 2 counters on USB 6210. One counter I would be using the 3 Channel optical encoder and the other to measure the frequency for z pulses ( so I can use that to calculate RPM). Unfortunately I am faced with two problems. To use the counter to calculate frequency I would have to use PFI2 which is the same pin I require for Z.

So that means I can't measure frequency through hardware counting. I would have to do it via software. So is there any way for me to capture the Z index signal without counting the edge on PFI3 and using an extra counter. Because the Z signal is obviously already read in PFI2 and being used to reset the data from A and B (encoder position). If not I guess I could count the Z pulses on PF13 and then work out the frequency via software timed application.

I have attached my code I wrote to calculate the force and position measurements and use that to output the instantaneous power to the user. ANy comments or feedback on improving that would be hugely appreaciated :manhappy:


Regards,
Darren

[BrowningG]

Hello Darren,

It is possible to change the input pins for your position measurement or for your frequency input to be another PFI line in your device.  By default the PFI lines used for the encoder Z index on counter 0 and the frequency input on counter 1 are both PFI2.  Using a DAQmx property node you can change the PFI line to be any of the other PFI lines for the device.  The properties are CI.Encoder.ZInputTerm to change the Z Index input (found in the DAQmx channel property node in the path Counter Input -> Position -> Z Input -> Terminal) and CI.Freq.Term (in the path Counter Input -> Frequency -> Input Terminal).  This way you will not have to use software for your frequency measurement.  I did some searching and found this knowledgebase on how to use the property nodes to do this.  There is even a link in this knowledgebase that shows you how to ensure that a certain route is available in your device. 

[dalvares]

Awesome I am just working on that now. But that brings me to my next question. Would I be able to get the z index value from the singal on counter 0 measuring the encoder signal. So PFI2 is reading the Zindex value and reseting the counts. Can I capture this  Z index signal without using the other counter. The I can use the other counter to find the frequency of the Z index value via hardware control

If not I would use counter 1 then to count the edges of Z and then calculate the frequency via software or vice versa I guess it doesn't really matter.

Any feedback on my code in general.?? :manhappy:

[BrowningG]

Hello Darren,

I am not quite sure what you mean.  Are you looking to measure your encoder position and measure the frequency of your z-index at the same time?  If this is the case, as long as the frequency of the z-input is relatively low, you can use one counter for the encoder, and another counter for the frequency measurement. A high frequency measurement will require two counters.  From your previous post, you mentioned that you were having issues with the fact that the encoder and frequency tasks shared a PFI line.  PFI stands for programmable function interface.  These lines are designed to be reconfigurable depending on the counter task.  For each counter task each PFI line will have a different default value.  These default values can be changed using the property nodes I discussed in my last post.  I tried using PFI2 for my z-index input for counter0 and PFI2 for my frequency input on counter1.  This did not throw and error and allowed me to use a single PFI line for two different counter inputs.  You can also configure different each counter to use different PFI lines and externally route the z-index input into two different inputs.  Hope this helps. 

[dalvares]

Hi Browning,

Thats great feedback so I just need to hook one counter for encoder and the other for the frequency measurements. However, I also would like to find out how many revolutions I have done in total to calculate the work over the total course of the experiment. So does counter 1 that is hooked up to the encoder allow me to capture this (Z- Once per revolution) or would I have to set up a some code to tell me say how many times the position is an 360.

Cheers,
Daz