Can I do continuous digital input and/or output with my PCIe-6259?

[280Z28]

Now we're talking

All my digital outputs that require specific duty cycles or pulse widths are dead accurate. Those are easy to verify with my multimeter.

Simple question:

Can I read a single sample/single line from port1 or port2 while I have continuous output task running on port0?

More complex question:

Say I have a continuous output task running that I wrote 10 samples to, so it's looping those 10 samples. If I make a new buffer of 10 samples sometime later and write it to the [still running] task, will it wait for a cycle of the old 10 samples to finish before switching to looping over the new 10 samples?

[280Z28]

I got to test the timing of events today. I'm using a frequency generator to simulate the reference pulses of a flywheel. When the frequency (rotational speed) is steady, the timing is very close (within the resolution of my output clock). Unfortunately the skew is very bad when the frequency is changing. As soon as the frequency steadies out again, it's right on the timing again. Not sure what I'm going to do about this yet.

[Jarrod_B.]

Hello 280Z28,

"Can I read a single sample/single line from port1 or port2 while I have continuous output task running on port0?"
Yes.  You should be able to do static DIO while a time DIO task is running. 

"Say I have a continuous output task running that I wrote 10 samples to, so it's looping those 10 samples. If I make a new buffer of 10 samples sometime later and write it to the [still running] task, will it wait for a cycle of the old 10 samples to finish before switching to looping over the new 10 samples?"
Yes.  The old 10 samples have already been written to the FIFO buffer on the DAQ board, and those 10 samples will be output before the new samples arrive.

In reference to your second post, I don't really understand your setup.  You say that you are using a frequency generator to simulate the reference pulses of a flywheel.  How is this signal then connected to your DAQ board?  Is this the clock source for your digital ouptut task?  What do you mean when you say that the "timing is very close" when the frequency is steady, or that "the skew is very bad" when the frequency is changing?  How were you measuring this timing, and exactly did you see?

One thing to keep in mind is that when you specify the frequency of your clock signal in your application, if you are using an external clock signal that will be changing, you always want to specify the highest frequency that you expect that signal to reach. 

I hope this information helps. 

Best regards,

[280Z28]

Frequency generator is connected to Ctr0 and set to continuous acquisition of period. One tick is sent every 90 degrees the flywheel turns.

ao0 is a continuous output "dummy channel." I just wrote [0,0] to it so the ao/SampleClock is running. I'm using the ao/SampleClock to time my digital outputs. I set the output rate to 90*x times the frequency measured by Ctr0. x is arbitrarily set to 4 right now, so the ao/SampleClock in theory gives me 1 pulse for every 0.25 degrees the flywheel turns. Every time Ctr0 gives me an update, I update the ao sample clock rate.

My DO task uses a 90*x sample buffer for continuous output. Each element in the buffer ideally represents the output state at a known flywheel angle with a resolution of 1/x degrees.

Ctr1 is set to measure two edge separation between a reference digital output "at 45 degrees before a pulse" and the next reference tick from the flywheel (frequency generator). Basically, I placed a falling edge exactly halfway through the DO buffer on one line (used as a circular buffer, explained below). I use the two edge separation measurement and the current speed of the wheel to calculate where the falling edge actually fell. The difference between the actual pulse location and where I tried to place the pulse is what I am calling "skew." "Total skew" is basically a summation of previous skews for use in the next step. I use the total skew to determine the starting index for the DO circular buffer. So if the current total skew is 5 degrees, then the first sample in my 90*x length DO sample buffer will fall at 5 degrees before one of the 90 degree reference marks. So for an event I want to happen at 3 degrees past a reference mark, I set that value at the location (5+3)*x in the sample buffer.

When the flywheel is moving at a constant rate (or close), the skew is less than 1/x degrees, meaning my outputs are timed as accurately as possible. If I raise (or lower) the frequency generator output frequency (flywheel speeding up or slowing down), and then let it stay ~constant at the new frequency, the error correction algorithm quickly re-aligns the DO sample buffer and the outputs are with 1/x degrees again.

The problem is while the speed is changing, the measured skew is very bad (many degrees).

[Jarrod_B.]

Hello 280Z28,

That sounds like a pretty involved application!  The behavior you are seeing makes sense to me.  Keep in mind that the period measurement task requires a finite amount of time to actually measure the period.  The way a period measurement task works is that the counter is configured to count pulses of a known timebase between consecutive rising edges of the gate input signal (your signal with unknown period).  This means that the longer the period of your signal (or the lower the frequency), the longer it takes to actually measure that period. 

This means that the frequency of your digital output task may not keep up with the frequency of your external signal when it is changing.   If you want a nearly immediate response, you will have to use a finer resolution encoder to measure the position of your flywheel.  If you had a 1440 pulses/revolution encoder, then you could directly use its ouptut signal as the clock for your digital output task to achieve one output point per 0.25 degrees. 

I hope this information helps!

Best regards,

[280Z28]

That's genious. Now I need to get the encoder on the belt drive of this. I don't need 1440 of course, I could use any high resolution encoder as long as I know the PPR, plus I get the advantage of step-up if I use a smaller pulley on the encoder than the crank pulley (bottom center here).

[280Z28]

You think if I get an R series device my hardware limitation problems will be solved?

[Jarrod_B.]

Hello 280Z28,

I had considered that, but with your original approach, there is still a finite amount of time required to measure a signal's period.  Even with the flexible nature of the R series devices, you are still limited by this constraint.  I think that the only feasible solution is to use an encoder with adequate resolution. 

Best regards,

[280Z28]

Nobody does that right now though. The motors I've always been around have either 4 or 28 PPR, and the 28 PPR wheel is considered very accurate.

[Jarrod_B.]

Hello 280Z28,

With a higher resolution encoder it may be possible to do what you are trying to do, but with the lower resolution, I just don't see any options.  If you figure out a better way to do this, please post back to this forum so that everyone can benefit from your solution. 

Best regards,