Long DAQ Output Signal

[Jo-Jo]

I am using a USB-6351 to control a stepper motor by generating step and direction signals. I have to ramp the motor up and down to keep if from stalling during starting and stopping, so I can't just put out a periodic signal. Also, the test needs to know exactly how many steps were taken, so I can't just keep track of time on the PC, because the steps are less than 1ms apart from each other. What I have done so far is create an array to hold step and direction data, then feed the array into the DAQmx write using a finite samples task with hardware timing. Everything works as expected, but now I am being asked to have have the motor run for several hours while still putting out an exact number of steps. I have to use a ~240kHz clock to get the motor to move the way it is supposed to, so there is no way I can create an array that big.

I thought that maybe I could use a finite samples task with regeneration then replace the ramp signal when the motor is up to speed. When I am ready to ramp down, I would do the opposite, but I'm not sure that's possible, especially not without interrupting the output.

Does anyone know how I might output a very long, digital, hardware timed, non-periodic DAQ signal?

[Kevin_Price · Accepted solution]

1. I would first aim to generate the step signal with a buffered Counter output rather than a DO task.  It'll be far less wasteful of memory space (2 pulse params per step rather than 1 sample per 4 microsec) while also giving much better step timing resolution (10 nanosec vs 4 microsec).

2. I'm pretty sure you'll need to run a continuous generation task in order to first feed a ramp up, then keep feeding a constant slew rate, then feed a ramp down.

   I know I'd *like* it to be possible to configure the task for regeneration so that you'd only need to ever do 3 writes (ramp up buffer, slew buffer, ramp down buffer).  I'm not totally sure about this, but I don't think you can do that.  There's either regeneration mode where you write 1 time or there's non-regeneration mode where you *must* keep feeding the buffer, even if you just keep overwriting the contents with more of the exact same contents.

3.  There will be latency between when you want to start ramping down and when the output signal actually does start ramping down.  This is the nature of *all* buffered output tasks in DAQmx.

4. To be certain of an accurate step count, you may need to use another edge-counting counter task.  I have a vague memory that the DAQmx property "TotalSamplesGenerated" wasn't something you could rely on.  You can't know the final total until the task stops and as I recall, once the task stopped the property returned a 0.

-Kevin P

[Jo-Jo]

Here is what I ended up doing, and it seems to work:

I'm not too worried about memory usage, so I stuck with DO tasks and used 2D arrays, since I already have VIs that create them for me. I created three arrays of step and direction data; ramp up, cruise for one revolution, and ramp down. I then created a task using continuous samples, as suggested, and set it to NOT allow regeneration. I then feed in the ramp up to the write task with a timeout of -1 in a loop. I continually feed in the cruise task until I reach the necessary number of revolutions, then I feed in the ramp down. I have at least 1/3 of a second to feed in each array, so my computer is plenty fast enough. I made the ramp up and down equal to 1 revolution each, so each of my control signal segments are 1 revolution, which makes it easy to keep track of how far the motor has gone. After I feed in the ramp down, I just wait for the task to finish.

One small irritation is that as soon as the last of the ramp down signal is consumed, the wait for task to complete generates an error saying the task stopped itself to prevent reusing old samples. In my case it isn't an error, it's a feature, so I just clear it and keep going.

[Kevin_Price · Accepted solution]

You could just get rid of that "Wait Until Task is Done" function, it no longer serves a purpose now that you're configured for continuous sampling.  You'll need another method to know that all the ramp down samples have been generated.  You should probably also follow up the ramp down by writing a buffer worth of samples that maintain the previous direction bit but just keeps the pulse bit in a constant low state.

You can query the DAQmx property named something like "TotalSamplesGenerated" to figure out when the generation has transitioned from the end of the ramp down to the extra samples of non-stepping.   When you detect that you're there, *then* stop the task.

-Kevin P

[Jo-Jo]

Good idea. I'll see if I can get it implemented today.