Precise timing of digital output

[mjjohnson]

I'm using a PCI-MIO-16E-1, and I'm trying to create pulses on each of three digital outputs, using a hardware trigger.  I've gotten a solution that sort of works using a timed loop; the loop executes once per trigger, and inside the loop I'm using software timing to toggle each of the three outputs at the right time.

However, the problem is that the 1 ms resolution of software timing just isn't good enough.  So I'm trying to figure out a way to do this using hardware, so I can get a finer resolution.

What I've been trying to do most recently is to create a retriggerable pulse train on one of the counters (using the example Generate Digital Pulse Train-Finite-Retriggerable), and use that as the trigger for the timed loop.  I can get the pulse train to give me three ticks for each time I get a hardware trigger, and then put a state machine inside the loop to toggle each of the outputs.  (I'm trying to subdivide the hardware trigger into three equal segments.)

However, although I can generate the pulse train just fine on one of the counters, I can't manage to get the timed loop to use that counter as its timing source.  How can I do that?  Or does anyone have a better idea of how to do this?

[ManLongAtNI]

Can you clarify what you are designating the hardware trigger? Are you triggering the pulses from the pulse train generated from the counter? Can you provide broader scope of your application? I'm having trouble understanding your use of timed loops.

Regards,

Glenn

[mjjohnson]

I apologize for the delay--I got a workaround working acceptably, and in my rush to do that (and satisfaction at getting something going) I neglected to come back.  However, it would still be nice to get a more elegant solution (and one that makes more efficient use of our hardware).

I'm receiving a hardware trigger on PFI0/TRIG1.  I need to send a series of values to three digital outputs at 3x the input frequency.  (Each of the outputs is on for 1/3 of the time, while the other two outputs respectively are off.  I'm using this to control three sets of relays.)  Typical values of this trigger are 20 Hz to 50 Hz, and definitely no more than 100 Hz--resulting in cycling frequencies of 60-300 Hz.  So not terribly fast, but fast enough that millisecond precision isn't quite enough.

What I was trying to do most recently (before finding a workaround) was to set up a retriggerable digital pulse train, which would have three pulses.  I would then use that output as a trigger input to control a timed loop.  However, LabVIEW kept complaining--I don't remember the specifics at this point, but something about the resource not being available.  What I got from it was that I couldn't set up multiple tasks like this on the same board.  If it's possible, something like this would still be better than my current solution.

Even better, though, would be to find a good way to send multiple samples to the digital output, at a specified rate.  However, every attempt I made at configuring DAQmx to do so was met with error -200077, informing me that I could only configure the channel for "on demand" rather than "sample clock."  And since my sample clock is 625 kHz, I didn't really want to send tens of thousand of samples to specify three states.  I suppose this is a limitation of my board?  Is there any way to send just a few states (at a slower frequency)?

(Oh, and my workaround: I'm using the second channel of my function generator to put out a signal at 3x the trigger frequency, and using that as a trigger for a timed loop containing a 3-case structure.  Meanwhile I also read the first trigger with a parallel timed loop and use it to make sure that I'm on the first case when the main trigger comes around.)

[ManLongAtNI]

To simply your issue, (from paragraph 4)

-You want to send multiple samples to DO at a specified rate...

Question, can you give an example of the samples/channels you are planning to use for your DO?

[mjjohnson]

Yes. I'd like to send three samples to each of the three lines, as follows:

line 0: T, F, F

line 1: F, T, F

line 2: F, F, T

...and then repeat that pattern at a specified rate (overall repetition frequency of 20-100 Hz). 

[ManLongAtNI]

It looks like you're just shifting the HI,  I've modified the example Write Dig Chan.vi, to do what I think you want to do.

[mjjohnson]

That's sort of the basic idea, yes, but I'm afraid the timing still isn't quite right.  The pattern needs to be synchronized with an external trigger; and the Wait VI only allows a resolution of 1 millisecond, which isn't fine enough.  That's why I've been looking for something a bit more exotic, and hardware-based: I tried a software solution first, but LabVIEW's software tools just don't allow precise enough timing.  (When each part of the cycle is, say, 5 and a fraction ms long, that extra fraction makes a big difference with getting everything to line up precisely.)  I do appreciate your help, though.

[lab_boy]

Hey

The PCI6070E does not support corelated DIO you need to M series where you can use either external clock or counter to perform hardware timed DIO.

-Lab

[ManLongAtNI · Accepted solution]

Unfortunately, the card you have does not allow for hardware timing DIO. M Series, and the recently released X-Series Multifunction DAQ devices permit such a task. If you like, I can have a technical representative contact you to further discuss your application and provide appropriate suggestions to optimize your application.

Regards,

Glenn

Applications Engineer

National Instruments

[mjjohnson]

Ah, okay.  Too bad this card doesn't support that.  (I'm curious: why does the same card apparently have two names--PCI-MIO-16E-1 and PCI-6070E?  MAX only reports the first name, and I had no idea it went by another.)  Also, I assume this information was somewhere on the data sheet, but I apparently don't know how to recognize/interpret it.  Where on the data sheet would it be?

Glenn: I don't think we're looking to get a newer card at the moment--the workaround I found works fine, and the card otherwise performs very acceptably.  However, if you think a technical representative might be able to offer a better way of doing this with our current card, I'd be delighted to hear from them.