Array of U8 used as digital out with 0.1Hz for each array-index

[ruth2]

Hi

I am trying to write a code which lets me output an array of 36'000 values U8 to an NI USB-6009 as digital output.

The problem starts as soon as i try to define that the clock should be 0.1Hz giving me 3600 seconds out of my 36k samples.

Seems like it is not possible to use DAQmx Digital Out together with a specific sample-clock (Or i am doing something wong).

Does someone know a smart solution to this problem? How do you output a defined dataset with a given frequency trough the digital-port?

Thanks in advance! 🙂

[JÞB]

Rufer-

The NI USB 6008/6009 have Static DIO.  This means that there is no memory to hold a waveform and all timing is "On demand software triggered"

To obtain the type of operation you want use a loop to iterate through your 36000 element array and write one value use the wait function to control how fast the loop spins.  Bear in mind that the OS timer is not highly accurate If you need deterministic timing you will need to upgrade your hardware.

here is an example

[ruth2]

Ah... Thanks Jeff!

I indeed need some accurancy in switching the signals (Timewhise).

Is it possible with a NI USB-6216 to somehow use the hardware-onboard-clock to trigger the next array-index being sent to the Digital output?

I have found some evidence for that, but by the datasheet, this device also has static DIOs. If i understood your post correctly, static DIOs are the kilelr for my application, right?

[JÞB · Accepted solution]

---

@RuferT wrote:

Ah... Thanks Jeff!

I indeed need some accurancy in switching the signals (Timewhise).

Is it possible with a NI USB-6216 to somehow use the hardware-onboard-clock to trigger the next array-index being sent to the Digital output?

I have found some evidence for that, but by the datasheet, this device also has static DIOs. If i understood your post correctly, static DIOs are the kilelr for my application, right?

---

What is the killer for your app is the DIO trigger source.  Software timed DIO just won't work for high accuracy so you need to up the hardware to something that supports hardware triggering of the DIO - in a USB form factor that means a USB 625x for an M-series or a 634x for the X series (caution the 6341 x series only supports hardware timing on 1 port- check the specs for yourself before you decide)

[ruth2]

Unfortunately i am not allowed to hand out details.

But i can summarice:

- I read in 2 voltages. One is supply and thwe other is a shunt-voltage ( = current)

- I manipulate a bluetooth-remote by shortwiring the keys on the remote with the digital out over some FET's.

- with the remotely controlled remotecontroller (hehehe) i manipulate the device under test (DUT).

- I have to be sure i follow a quite precise (timewise) script consisting of around 600 keypresses.

Now you see: If i have a summing error with each keypress (= digital out) i end up with a result out of sync with the script intended.

Since i know the limits of the current consumed in each state and since i need to find the errorous ones, i have to be sure to know in what state the remote and the DUT.

Of corse this can be synched. But because i also have to be sure evers DUT is tested the same way, i cannot affort to have the script taking +/- 10% time in total.

But i may have come to a solution:

Since we use LabVIEW 09 i can use timed structures.

I made a quick and dirty test with a timed loop and sat it to 100ms. In every loop i latch out a new state of the digital out.

Even if every loop takes +/-10 to 20ms to process thats no problem. Why? Because the timed loop always stays in sync with the clock.

So as far as i can tell (and assume) the total-timeerror is only 1x the error of the loop and not 36'000x the summed error of the loop.

Will try to verify with a longtime-experiment. 🙂

EDIT:

I see the question as such is resolved: If i want to let the hardware internally handle stuff, i whould need to update the HW which is unfortunately not possible. Ill mark your post as solution as it. It whould be the best way, but not doable for us ATM. 😉

[ruth2]

I totally forgot to post the results of my longtime-tests!

I made a timed loop and latched out one signal-step each iteration.

The individual time-error in every iteration was around 3-10ms.

BUT: It didnt sum up! Since after each iteration the timed loop "synched" itself to its own pace, the wait for sending the next signal was adjusted to the start of the next "tick".

I made many tests and the error stays te same. No matter if i latch out data in 10Hz worth 1h or 10h: 2-10ms is the error i get from the last and every individual signal in betwheen.

Works for me! 🙂