Multifunction Synch AO AI Same Clock - restart AO? From different postion in the buffer?

[Mcdan]

One other thought... You may need to wire digital ground between the 6210 and the 6731, since they don't have a common ground reference.

[trouinky]

That's taken care of, the way I have the signal line running, but I'll add another to make sure... I'm reading the manual for the BNC-2110 to see which ports I can use. Looks like PFI0 is an output terminal... I'm going to route the User1 to one of the other PFI ports. I put a scope at the PFI lines on the BNC box and the signal is there, but the hardware must not be passing it up to the card.

[Mcdan]

That sounds like a good approach.  If you continue to have trouble, I can see if I can find similar hardware and reproduce what you're seeing (for now, I've been working with simulated devices since I don't have that hardware handy).

Dan

[trouinky]

Thhhppt. Bad BNC Cable. OK so I started with a bare bones version based on the last VI you sent (ramp up, ramp down) and it works!! PFI4/PFI0

I'm trying to fine tune the delays and such that you introduced me to. The ramp down portion isn't ligning up with the ramp up data (I basically a scan right, then left), but I think that's the (piezoelectric) stage I'm using not having the same position in +X and -X travel directions. I'm going to have to scan only in one direction, move back to 0 (ignore the read data), increment, then scan right again, and repeat. I was hoping to raster back and forth across the sample, but don't think it's going to happen.

My simple triggered version worked too, but I think yours will be better once I move to better (faster) hardware. Unfortunately for me, this little USB box maxes out at 10ks/sec, so that stinks.

Thanks for your help.

[Mcdan]

Glad to hear you have the data acquisition side of things working.  I'm always amazed when something as simple as a BNC cable proves to be the faulty link.

If you're considering getting faster hardware, you may want to look at the X Series family of devices.  Many of these devices have four analog output channels, which may allow you to to run your application with a single piece of hardware.

Best of luck with your application,

Dan

[trouinky]

I have a couple of those, but they are committed long term to other projects unfortunately. It's been my experience that after projects are over, we have these assorted instrumentation devices lying around and I'm trying to incorporate what I have so I don't have to spend any cash.

What I'm perplexed about is this USB-6210 which is supposed to be 250ks/sec max (single channel, and 125ks/sec for two channels, and slower for more....). I get this error when I choose 1ks/sec for the AO (and the AI is then set to 10ks/s), that 10,000 is the maximum allowable value for the rate input. What am I missing??? I'm wasting my time if it's only 10ks/sec, my experiments will take HOURS if I can't get the rate up above 10ks/sec!

[Mcdan]

First a list of questions which may be relevant:

1) How many channels are you using?

2) What error code do you see?

3) What OS are you running on?

4) Is your 6210 connected to a USB 2.0 high speed Host Controller?  In device manager, you should see 'enhanced' in the host controller name.

5) Does this reproduce with one of the examples which ships with DAQmx (Acq&Graph Voltage-Int Clk)?

If you're seeing ADC overrun type errors, I would be extremely surprised because you should be well within the limits of the device.  If you're seeing data transfer errors (ie... FIFO overflow or buffer over-writes), then there are a few things which can come into play.  I'll hold off on speculating until I get your answers to my questions above.

Dan

[trouinky]

Sorry for the delay, finally back in the lab...

1) Two analog outs, one analog in (so I was wondering why the limit to 10kS/sec)...

2) Error code -20081 (Sample rate exceeds max sample rate for number of channels specified)

3) XP 32-bit

4) Have to check and see if the USB is high speed (bet it's not, it's a P4 Dell)

5) Trying a stock example at a higher sample rate as we speak...

[Mcdan]

Tommy,

I think the issue here is the constant I used for the 'DelayFromSampClk.Delay' property.  In attempting to demonstrate that ability to set this, I picked a value of 100uS which is long enough that for sample rates of 10 kHz and above, the delay is longer than the sample clock period.  If you adjust this accordingly, you shouldn't see this problem.

Apologies for any trouble this caused,

Dan

[trouinky]

I like simple solutions. Can I set it to a smaller value if it's still in there? I might have removed it....