Software Timed Pulse Generation - USB 6009

[tdb867]

Hi there.

I've been looking for a reliable way to produce a point by point pulse signal with the USB 6009. My question is whether or not it is possible to produce such a signal without hardware timing or a counter as the USB 6009 supports neither. The closest I've come is to produce a square wave with a very small duty cycle. However, what I would ideally be looking for is the ability to produce a single pulse inside a loop that I can iterate once every minute or so. Also I would like to know what parameters I would be sacrificing to produce a pulse in this fashion.

I do also have access to a function generator and since this appears rather difficult I will most likely just be triggering its pulse function to the same effect, but I would like to explore this obstacle before I move on.

Thanks,

Travis.

[Hooovahh]

How do you expect to maintain any precision without hardware?  That's like saying please turn on and off this lightbulb 100 times a second using a toggle switch.  How quickly do you think I can do it?  And how precise do you think it will be?  Even if you said turn it on and off once a second it won't be precise.

[johnsold]

What you sacrifice is speed and precision.

Please tell us wht the ranges of pulse widths and frequencies are. Also specify how much jitter, variation, and error in the timeing is acceptable. Then we can advise you on how close you can come with the USB-6009. One pulse per minute may be OK if the pulse is 1 second long. If the pulse needs to be 1 microsecond +/- 1 picosecond, forget it.

Lynn

[tdb867]

Thanks Lynn,

I'll be driving a series of LEDs at a reasonable pulse width (far removed from the microsecond scale) maybe around once every minute. I really don't know how much jitter, variation, and timing error is acceptable at this point. I just want to know if it's possible, assuming a large degree of flexibility. I probably will end up using a different method once all's said and done, so I'm looking at this problem with more of an academic perspective.

Travis

[Hooovahh]

No problem.  Make a state machine where one state sets the output, then the next waits until the time elapsed is correct, then change the value.  If we are talking about minutes on and off then you'll probably be fine with software timing having +/-10ms depending on how the software is written.

[johnsold]

I agree with Hooovahh. A state machine is probably a good choice for the program architecture.  If you are using a recent version of LV, there are very good templates for state machines included. 

Lynn

[tdb867]

Sounds good, I'll look into it.

Would this approach still be fairly reliable with a 20ms pulse width?

Travis

[johnsold · Accepted solution]

20 ms is getting into the region where you will begin to see significant amounts of timing jitter. You really need to write your program and make some careful measurements - over an extended period of time - to see how much of a problem you will have. The actual performance will depend a lot on all the details: The OS, other software processes running in the background, and how the LV program is set up.  You should minimize as much as possible everything else on the computer: No network connections, no anti-virus, no Bluetooth or WiFi, and so on...

Lynn

[Hooovahh]

---

@tdb867 wrote:

Sounds good, I'll look into it.

Would this approach still be fairly reliable with a 20ms pulse width?

Travis

---

Think about this.  Have you ever been using your computer and it just stopped responding for seconds.  Moving the mouse does nothing, clicking does nothing, CTRL + ALT + Delete does nothing.  What do you think will happen to your LabVIEW program when this happens?  Will it be able to keep running and handle a process every 20ms?  Probably not.  When you are using software timing you are at the mercy of Windows and whatever else it wants to do.

[tdb867]

Thanks for all of your input.

I' ve written the program at this point and have chosen not to implement a software-timed pulse. Instead I used an externally triggered function generator which sends a 20ms pulse at a controlled delay. My problem at this point is much the same as I am attempting to collect a number of data points for the duration of each pulse. Currently I can reliably obtain about four data points inside of the pulse width, but i am hoping for a few more. If there's any way to trim up the vi a bit I'd be happy to hear it. Also if anyone has an alternative solution I won't be too terribly upset.

Travis