Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

How to make a ramp for a stepper on PCI-6221

Hello!

I'm looking for a solution/example in ANSI-C to make a ramp for a stepper that is connect at PCI-6221 CTR-port.
The function I'm actually using is:

DAQmxErrChk (DAQmxCreateCOPulseChanFreq (taskHandle, "Dev2/ctr1", "", DAQmx_Val_Hz, DAQmx_Val_Low, 0.0, 1000.0, 0.5));
DAQmxErrChk (DAQmxCfgImplicitTiming (taskHandle, DAQmx_Val_FiniteSamps ,1800));

So this works fine when the stepper have to run constantly. But for my application I need the use of a ramp. To change the frequency value I have to write in a running Task, but that is (IMHO) not possible? Please correct me, if I'm wrong.
I don't not know how to change the value unless to stop the task and start it with new value. But this method is not a solution, cause i always stop the motor and start it with a higher frequency from zero. So what I'm actually do is to look after the correct NI-function for my problem.

If someone has an idea/example/solution, please post it. I'm thankful for all kinds of feedback.

Best regards,
Oliver

0 Kudos
Message 1 of 14
(7,548 Views)
Unfortunately, ramping a stepper is not straightforward using the counter hardware.  Under finite generation, the freq cannot be changed on the fly.  And under continuous generation, where freq *can* be changed on the fly, it must be done under software-timed control.  Also,  under continuous generation, it will be pretty tricky to both change the freq on the fly *and* control the exact total # of steps.
 
If you need a well-controlled ramp and a well-controlled # of steps, I'd suggest you start figuring out a scheme to use the hardware-timed digital output port (see also "correlated dio").  The big downside is that you'll need to generate a large buffer of digital states to define your pulse train because you'll probably need to output at something approaching a MHz.  Out of those million samples per second, probably only about 0.1% of them represent transitions.
 
When these kinds of apps come up, I always put in a good word for one of NI's Alliance partners - Viewpoint Systems, who sells a digital board that works much more sensibly for these situations.  With the DIO-64, you create buffers containing only the timestamps of the transitions and the digital state at those transition times.  So to generate 1000 steps in a second, you'll buffer 2000 states rather than 1,000,000.  You'd also get ~20x better quantization error for your available step rates.
 
I've been requesting a buffered counter output capability from NI since before Y2K, so I'm no longer holding my breath...
 
-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 14
(7,547 Views)

Would it be a solution for you to use a NI Motion Controller ? These boards are designed for this type of task ! You have then only to set some parameters like start velocity, aceleration, deceleration, end velocity, number of steps... and the board will generate the pulse train.

The solution with a buffer of digital states will give you more control over the ramp but the programming will be much more difficult than with a motion controller. A new pattern must be computed if you change the microstepping of the driver. Much work that the motion controller can do for you !

 
0 Kudos
Message 3 of 14
(7,544 Views)
First of all, thanks for reply.

@JB:
I've read yesterday about the motion controll modules and I'm guess that they are the solution for my problem. But before I were started with my project, the cards (PCI-6509, PCI-6221) were already bought and I've to make it right with them. The decision for the cards is that the current application (made in Turbo Pascal) is running in DOS. This have to upgrade to XP by coding it in C++ with Qt. They build for the DIO card a generator in to simulate samples and to handle the ramp, they using a simple array. That made them believe to use this method in other languages too. So...

@Kevin:
If I've understand your post correctly, there are no possibilities to make any buffer operation with the PCI-6221 and to write in a running task is not possible? So I'm should start holding my breath...

Thanks,
Oliver
0 Kudos
Message 4 of 14
(7,529 Views)

A motion controller *may* work, but I'm not sure if it can generate a sinusoidally-varying frequency.  I don't know NI's well at all, but most of them tend to produce a ramp region that can be either linear or cubic (possibly a couple other choices) followed by a constant speed slew region.  

Now to answer your question:

A. No, there is no possibility of performing a buffered pulse train output using a *counter* on the 6221.  I've been wanting buffered counter output support from NI for almost 10 years, but none of their boards provide it.

B. You *can* perform buffered output using your DIO.  The method I described is kinda complicated, but it can get you there.

C. What do you mean about "writing into a running task?"  If you're wondering about changing a buffered digital pattern output on-the-fly, well, yes it can be done, but it'll be an additional significant complication to make it work seamlessly.  Why might you need to do this?

-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 5 of 14
(7,377 Views)
Hey Kevin.

After spending of many nights on this stuff, I've got a notation that I've found a solution to handle the ramp with the 6021 board.
Maybe some would it call as a workaround but all tests were successful...till now.
Let me try to explain:

I'm starting the stepper with the following functions:
DAQmxCreateCOPulseChanFreq & DAQmxCfgImplicitTiming

Additionally, I'm using the Event-Method:
DAQmxRegisterSignalEvent

So everytime the event-func is going to call, I'm checking the board if it's ready to accept new values:
DAQmxGetCORdyForNewVal
Otherwise I'm waiting till the next event-call:

If I'm getting a true response, I'm increasing the freq-value:
DAQmxWriteCtrFreq

I'm not really sure of that solution but the stepper sounds good, it looks good and he makes exact the value of steps he has to.

As long as NI doesn't provide any home-made solutions or any NI-pro shows me another way, I'm staying on this.

Best regards
Oliver


Message Edited by oliver_enns on 03-18-2008 07:21 AM
0 Kudos
Message 6 of 14
(7,374 Views)

Oliver,

The good news is that I think your approach is probably about the best you can hope for using the onboard counter.   It likely produces a somewhat cruder approximation to a sine wave, but as long as the results are good enough for your needs, you've got simpler code to develop and maintain.

Quite a while back I threw together an example using a similar idea with a Timed Loop using the counter output as a timing source.  All it did was to (try to) generate a linear ramp though.  Your needs are more difficult.  Still, in case it helps to look it over and compare, here's a link to the thread.

-Kevin P.

P.S.  Editing this message -- just realized I had a couple threads confused.  Ignore my comments about sinusoids here, they were left over in my head from a different thread about running a stepper with a sinusoidally-varying freq.  Sorry for the confusion.



Message Edited by Kevin Price on 03-18-2008 11:44 AM
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 7 of 14
(7,368 Views)
Hey Kevin,

JP 376 needs are nearly the same. Before creating my thread, I had read this one already.
But I was looking for an example in ANSI C, you know.
I've didn't mentioned that I'm not using LabView, sorry for that. So I can't open the VI's to see the example.

I've generally that "problem", that almost all examples are made for LabView...if I don't find any codes for C, I've to use the horrible commented C-Reference of NI.
...

And if a "Proven Active Veteran" is approving my solution, I've no doubt about it ;-).

Thanks for feedback.

Best regards
Oliver


0 Kudos
Message 8 of 14
(7,352 Views)

Oliver,


Would you mind posting the source code for your solution to the forum?

 

Jonathan

0 Kudos
Message 9 of 14
(6,158 Views)

Hi Jonathan,

 

The thread is over 2 years old, we'll see if Oliver is still around and has the code handy to post.

 

 

Just in case, here's some code in LabVIEW that can be used to get around the fixed rate of a Finite Counter Output; this might be a good starting point if you need to generate a fixed number of pulses and keep SW-timed control of the frequency and/or duty cycle:

Reconfigurable Finite Counter Output Using DAQmx on E or M Series

 

 

 

X Series boards were released last year and do have buffered Counter Outputs--this is the ideal solution which gives HW-timed control of Counter Outputs.

 

 

I don't have much else to say for now, but if you provide more details about your application and what HW you are using we might be able to give more advice.  I hope this helps for now!

 

 

Best Regards,

John Passiak
0 Kudos
Message 10 of 14
(6,151 Views)