Error in buffered digital output

[helder]

Hi

I am using a NI-USB 6229 and making a buffered digital output on port 0. It works fine up to approximately 10 kHz clock frequency, when it stops outputting the digital values. I registered a "Done" software event and it is actually triggered with type "1073754400".

I can't find that error code anywhere. The datasheet states maximum output frequency for the digital I/O port of 1 MHz. I am soooo far away from this. Help would be appreciated.

Regards

Helder

[ElRambo]

Hi Helder !

Thanks for posting on our forum.

Can you send your VI so that I will be able to help you with it ?

Regards,

[helder]

Hi Maxine

Thank you for your reply.

I attach a simplified VI that reproduces the problem. Connect a square wave to PFI 12 as sample clock and measure port0:line0. At about 8 kHz the portoutput switches to permanent "High", and it doesn't come back even if you lower the clock. You have to restart the VI.

I have also put the "Done" event in, but now it is not triggered anymore - don't know why.

Thank you in advance for your help.

Regards

Helder

[John_P1]

Hi Helder,

I was able to run the code (although on a different device).  One thing I notice is that you're not breaking out of the loop if your DAQ task reports an error.  I would add something like the following to check for errors during the loop:

Are you receiving any errors from your DAQ task?  If I give my device a noisy clock I get Error -200621:  Onboard Device Memory Underflow.  This is occurring because the rising edge of my clock is registering as more than a single edge (even though the clock itself is not too fast).  Is it possible that this is what you are seeing?

If so, there is a workaround for enabling the PFI digital debouncing filter on your 6229, you might want to give this a try.

The Done event isn't going to register for continuous tasks, since the task is never technically "done".  When do you need the software event to occur?  Perhaps there is another event you can use such as "EveryNSamplesTransferredFromBuffer". 


Best Regards,

[helder]

Hi John

Thank you.

I use the DAQError event just to check if some error is generated, but no, there isn't any error. Still, the output stops when I get to about 8 kHz, the bit of the port is permanently high.

In my original program it is not PFI12 that is clocking the buffered output, but a pulse train generated by counter 0 and routed internally to the clock. To check if I was doing something wrong, I tested using PFI12 with a function generator, and the result is exactly the same. That's why I think that debouncing the input is not going to help, but I'll give it a try anyway.

I add that I tested the same code with a NI-USB 6259 and the result is exactly the same! Shouldn't I be able to get to much higher output frequencies?

Well, I am going to test the debouncing and I'll post the result soon.

Regards and thanks to all

Helder

[helder]

Hi again

Just tried the PFI debouncing workaround, but things got even worse.

I will wait for further advice.

Thanks

Regards

[John_P1]

Try running "Cont Write Dig Port-Ext Clk.vi" from the LabVIEW Example Finder.  You can navigate to it under:

Hardware Input and Output >> DAQmx >> Digital Generation

We can see if the shipping example gives the same behavior--if there are any errors it should break out of the loop and report them.


Best Regards,

[helder]

Hi there

Actually, with the example I get an error -200621 (onboard device memory underflow), because it uses the "Is Task Done?" function instead of the error event.

But I still get this error at about 8kHz, shouldn't I be able to transfer at higher speeds? Is there any workaround? The laptop we're using is a brand new i7 ...

Regards

Helder

[John_P1]

Hi Helder,

That's the error I was suspecting--it means that data isn't getting to the device quickly enough for the sample clock.  I can think of two plausible explanations for you to be seeing this error at a sample rate of only 8 kHz:

1.  The clock signal is noisy.  If you register multiple edges per clock tick then this could cause the underflow.  Double-check your connections, and if that doesn't help try to implement digital filtering (see the attached code).

2.  Are you connected directly to your PC using a High Speed USB (2.0) port?  Going through a hub or using an earlier version of the USB protocol could result in high latency that would prevent you from achieving full rates.

One way you can verify if the problem is #1 or #2 above is to use an Internal Sample clock.  If the problem persists, then this means you aren't able to send data quickly enough over the bus.  If the problem does not, then this means that your clock is likely too noisy and is registering multiple edges per cycle.

Best Regards,

Message Edited by John P on 06-02-2010 01:45 PM

[helder]

Hi John

Both problems #1 and #2 do not occur. #1: Although the simplified code uses an external clock, the original problem occurred when using a counter output routed internally to the sample clock.  I used the external clock to simplify reproducing the problem. The sample frequencies that I achieve are the same with the external as with the internal clock. Concerning the PFI debouncing filter, I had already tested it without success (see previois post). #2 I have a brand new laptop, don't think it has a USB2.0 port, the DAQ board is connected directly.

In any case, I will try it with another laptop, and with minimum number of applications open and freeing all the USB ports(mouse, pendrive, etc.). We are more or less on the minimum transfer rate we need for the application, but as we were expecting a lot more (which we will eventually need in the future) I was asking for support. If you have any other ideas, please let me know, if not, we'll just continue with what we have.

Thanks! 

Regards!

Helder