Stopping frequency generation with PCI-6602

[JimSchwendeman]

Hey Everybody,

This is my first post to forums, though I've been reading devzone for quite some time!

First, a quick bit about my system.  I have 2 separate DC servos that I'm controlling, from which I read encoder channels A, and B, and I provide a step and direction to the motor controllers.  (I should note that the controllers that I use require step (pulse frequency), rather than PWM).  Currently, I am working with just one motor to get the code up and running, and then will expand to the second motor.  The code I'm currently using is attached, and has come largely from examples I found on the devzone.

So, the issue at hand:

The DaqmxIsTaskDone.vi throws a fit if you try to update the frequency before it has finished completing the cycle from last time.  If I don't I get this error:

Measurements: Cannot update the Pulse Generation property.

The pulse generation with previous property settings must complete a full cycle before the property can be updated.

Task Name: _unnamedTask<58>

To resolve this, I have set a lower cap on the frequency I can request to twice the while loop period (2*10ms=20ms=50 Hz).  This works great, and I can be sure that the task is complete before the loop completes.

However, implementing the next step is what has me a bit confused.  For all requested frequency generation values of <50 hz, I'd like to just drive the frequency to zero.  I can't try to use a really small frequency (like 0.00001 hz), because then the task will take much longer to complete than my while loop, so any new requests will result in the error above.  Any suggestions on how I can implement a "stoptask" function if the value is <50hz?

Thanks!

.jim

[Kevin_Price]

Don't have LV at hand and can't look at code now - hope to get a chance later.   Here's a few thoughts in no particular order.

I admit that I find the use of "DAQmx Is Task Done?" a bit puzzling based on your description of the app.  Sounds like you change the pulse frequency (servo command speed) on-the-fly which only works in continuous generation mode.   And continuous tasks should never become 'done' on their own -- only if an error occurs. 

Don't know what kind of servo you've got but many of them allow you to configure the distance implied by each step pulse you generate.  Increasing the position resolution will in turn require a higher driving frequency for a given shaft speed.

If you need a "stoptask" function, um, why not "DAQmx Stop"?

You've got the right kind of idea about the relationship between pulse freq changes and loop delay time, but have you considered inverting your solution?  Instead of limiting the pulse freq to satisfy a particular loop rate, why not vary the loop delay according to the desired pulse freq?  I would think that the servo operation should be the driving consideration, and your software timing could adjust as needed.

Summary: you've got a good start here.  But the kinds of questions you've got sound like you're painted into a corner.  Answering just those specific questions will leave you with something you would settle for, at least for now, but will probably not give you a system that behaves entirely the way you'd like.   So, what is the big picture here?  How critical are the servo motions?  Must the 2 be coordinated?   Are you updating the motion commands in a near-real-time control loop?  Do you really need to allow a user to ask for a freq like 0.00001 Hz?   It seems doubtful that the servo can produce usefully smooth / continuous motion when commanded with fractions of Hz. 

-Kevin P.

[Matthew_W]

 Hi Jim,

 If you stop your counter output task, then the Counter configuration parameters are still stored. You can then re-start the DAQmx Task and it will resume Pulse Train Generation. The thing to be aware of is if you issue a DAQmx Start task while the task is already executing it will throw an error. You will want to use flags or ensure you don't
try to Start a task that has already started.

 You could use this to stop generation if the user desires less than 50hz output, resume generation when the control is greater than 50 hz.

 Kevin P. brings up some good points, the loop rate is going to have a maximum rate of 1khz (approximately).

 Please do post back if you have any further questions.

Best regards,

 MatthewW
 Applications Engineer
 National Instruments

 

[JimSchwendeman]

Kevin, thanks for the suggestions!

I'm currently looking at using the DaqmxStop function to handle the 0hz issue, that seems like the right way to go.  Control-wise, I'd prefer to have the loop speed constant, so that was my thought process for not inverting the solution and varying the loop delay...

Here's perhaps a better breakdown of the system, as I'd like to be able to control it:

1 of the servos is following a trapezoidal velocity profile that will later be defined in an excel spreadsheet, and loaded by the user.  Specifically, I have a wire-wound drum that I am cycling back and forth, that I'd like to define specific velocity profiles for.

The other servo is moving based off of a reading from a pancake load transducer (trying to maintain a constant force applied).

During all of this, I'd like to take readings at timed intervals of both servo positions, and the load cell.

This initial code was an attempt for me to be able to accurately read position, as well as attempt to drive the motor, all with a specific update rate.  I'd definately be interested to hear any opinions/recommendations on how to better implement the requirements above, though!

Much appreciated!

.jim

[JimSchwendeman]

Matthew,

Do you have any thoughts on what would be the best way to implement a Daqmxstop task?  I ask because in my current .vi, I call the start task outside of the main while loop, and then just update using a property node.  This makes me think that I'd need to handle start and stop tasks inside the main loop, correct? 

If I continue on the path I'm on right now, I have to initially start the task with some non-zero value for my frequency choice, and then immediately stop it inside the loop until the value changes to a value that can require the task to be restarted.  Any thoughts?

Thanks!

.jim

[Matthew_W]

 Hi Jim,

 I've attached a example that shows one implementation of stopping/starting the task inside the loop. I'm sure there's several other ways of doing this, please let me know
  if it does not meet your needs.

You are correct that you will Stop then Restart the task inside the main loop. One variation would be to holdoff on starting the task until the frequency value is above the minimum requirement.

You might look into the Master/Slave architectures, this would allow you read the control knob at a fixed rate and pass the data periodically to the
slave loop. This would keep the user from changing the frequency before one cycle had been generated.
The design templates can be found at: File->New->VI->From Template->Frameworks->Design Patterns->Master/Slave Design Pattern. The notifier (Master/Slave) will pass only a single value, the queues will pass an array. In this case you would want just the latest value to be passed so you would use the notifier.

 Have a great morning,

 MatthewW
Applications Engineer
 National Instruments

 

[JimSchwendeman]

Matthew,

Thanks for the example!  It definately was a much better method to perform the start/stop task than I was initially thinking.    I have noticed that I am still able to produce this error, but I believe I know what's causing this and how to resolve it:

"The pulse generation with previous property settings must complete a full cycle before the property can be updated."

The master/slave loops seem like an ideal way to pass my setpoints from the excel into the loop.

Much appreciated!

.jim

[JimSchwendeman]

Matthew,

I made some minor modifications to the code you posted (to handle 0 freq value at startup, error output, and finally increased the loop speed to 20ms).  One of the things that I'm noticing is that, as I approach the cutoff frequency (50 Hz), I get an error:

Property Node DAQmx Channel (arg 1) in Gen Dig Pulse Train-Continuous_stopstart_JRS_10252007.vi <append>
<B>Task Name: </B>_unnamedTask<D4>

However, this only seems to occur very close to the cutoff.  I discovered this by setting the dial range from 0-100, and then slowly moving the dial back and forth around that region.  Also, I notice that if I have the loop speed set to 100ms, as you did in your example, I don't get this behavior.

Any thoughts?

.jim

Message Edited by JimSchwendeman on 10-25-2007 06:46 PM

[JimSchwendeman]

All,

I believe I have got it all worked out!  I have pieces of the sample code from Matthew integrated into the rest of my code, and it seems to work great.  I have attached the code for anybody who's curious, comments welcome and greatly appreciated.

Thanks very much Matthew and Kevin P, your help really got me through this hurdle!

.jim