DAQ CARD cant generate trajectory

[MR1668]

I want to generate trajectory from DAQ Card , I cant write a labview's program . Please Help me  < acidjune@gmail.com > before I use DAQ CARD  I use motion controller  but the motion controller cant change the pulse width .(DAQ CARD I use count/timer generate pulse , it can change pulse on the fly .)

Sorry my english not well I'm stay at Thailand .

[Otis]

Hi controller,

It sounds like you want to generate a pulse width modulated signal with your DAQCard in order to change the trajectory of something.

If you are using a DAQCard 6024E, 6036E, or 6062E with LabVIEW 7.0 then you can use the following example to do pulse width modulation with one of your counters on the DAQCard you are using:
DAQmx : Pulse Train Generation with Changing Pulse Specs (PWM)

Simply run this example and it will show you how to change the Pulse Width and/or frequency on the fly.

Regards,

[MR1668]

Hi Otis  ( Application Engineer National Instruments )

Thanks, Now I use DAQ CARD and I write LabVIEW8.0 not Visual C++ , Please help me again and I have < Update Dig Pulse.vi >

but I cant apply it for my work , < I use DAQ CARD to control X-Y-Z Table , I use driver and motor  from parker >my equation is

1 . . . 0<=T<=T1       V = Amax*T

2 . . . T1<=T<=T2    V = Vmax

3 . . . T2<=T<=Tf     V = Vmax - (Amax*T)

for generate trajectory , my trajectory has 3 section. When I wirte VI program , some position the program not follow to equation

my simply equation  is  V = S / T ,  V = U + AT , S = UT + 0.5AT^2 . I use 3 equation to generate trajectory , I fix Accerelation I vary Time and velocity to calculate position  ( V = S / T ) , the position not equa S = VT because my trajectory has Accerelation , my problem

is when I use Time = 1000 ms and V = 100 mm/s the position must near 10 cm but the position  move to 12 cm and when I set Time = 1000 ms

velocity = 50 mm/s  the position must near 5 cm but it move to 12 cm , I dont know why the position not follow to equation.

I apply program < Update Dig Pulse.vi > to generate pulse , Please help me again.

Thanks

CONTROLLER 

[Otis]

Hi Controller,

It appears that what you are noticing could be problems because there is by default a 100 ms delay in the update time for your system.  Another thing that could be affecting your trajectory is that motors rarely perform exactly as you want, and there may be some inertial components to your system that will mean that you need to adjust your equations slightly.

What does this mean for you?

1. Remove the 100 ms Wait Until Next ms Multiple.vi from the loop so that you don't have such large delays between updates (or use attached VI.)
2. You need to also consider that theoretical values do not always match real-world values, so keep this in consideration for slightly adjusting your values to match your entire test system.

Best of luck,

[ThomL]

Hi Otis!

This is exactly what I am looking for. There is just one problem. The sample is built in LW8.2 and can not be opened in LW8. Is there any posibility that you can provide it in LW8 format?

Thom Leiding

Dept of Biochemistry

Lund University

[Jeff_T.]

Thom,

I downloaded the example and resaved it for LabVIEW 8.0 using LabVIEW 8.2.  Best of luck!

Regards,

Jeff Tipps
Applications Engineer
National Instruments

[ThomL]

Thanks Jeff!

No problem opening the vi now. I can't wait to try it out tomorrow.

Cheers

Thom

[ThomL]

Hi again!

It seemes like it's possible to change frequency and dutycycle if the counter runs continously but not if it is set to generate a finite number of pulses. Is this so?

In my application I want to move the attenuator (by stepper) a distance corresponding to an exact number of pulses. I need the accellration and decelleration provided by a trajectory, calculated as a function of velocity limits, nr of pulses for accelleration/decelleration and nr of pulses generated so far. I built a vi for trajectory calculation and it works fine. But when I try to set the dutycycle and frequency properties on the fly I get an error telling me that they can't be set while the counter is running.

Any suggestions?

Thom

[Jeff_T.]

Thom,

May I ask what hardware you are using?  You are correct though, you cannot change these properties when the counter output task is set for finite generation.   You have to stop the task, use the property node and then start the task again for the changes to take effect.

I have a suggestion that I would like to mention.  We could set the counter task to be "continuous" so that you have the ability to change the properties while it is running.  We could then wire the output of the counter to the input of another counter on the board and use a counter input task to count the number of pulses that have been generated.  We could read the number of generated pulses and make software decisions based on the count (i.e. stop generating pulses or change the duty cycle).

It is important to know that anytime you read the count register though, it is a software timed read.  This means that when you call the read function, there will be a small delay in getting your count because of software calls and the pci bus.  For example, when you call the DAQmx Read function to look at the count register, you may get the number 1000. In reality though a few more pulses may have been generated in the time that it took for you to get that number.  If your output frequency is slow, this will of course not be a problem.  If your output frequency is very fast then you will need to treat the count as an approximation.  If you need a very time accurate count to make real time adjustments to your pwm signal, then a windows / pci solution may not be appropriate for your application.  Again though it would be very helpful to know the hardware and system you are using.  

Best Regards,

Jeff Tipps
Applications Engineer
National Instruments

[ThomL]

Jeff!

Thank you for your answer. I figured it out myself and did just what you suggested. It works just fine. The small delay in the counter causes a very small error for me as the frequency in the end of the trajectory is quite low (and allways the same). The error is within two pulses and if I compensate by stopping att "wanted pulses" minus one the result is good enough for me. Besides, I can read the exact nr of pulses from the counter after its stopped and compensate for it in the next run and thereby avoid accumulating errors. Very nice.

By the way the board I use isa a NI PCI-6221 with a SCB-68 connector block.

Thank you very much for your help

Thom