Large aperiodic PWM signals

[O11ie]

Hi All,

I'm trying to generate a digital output based off a measured signal that is saved as a tabbed text document (example attached). The time base is 10-nanoseconds, and the total measuring time was 280 seconds, giving a large number of data points. The measurement 'pings' are random, and my goal is to create a 10-nanosecond pulse at each ping. I've thought of a few different methods of creating this digital waveform- currently I've created a VI to read the pings and put 0s into an array, append a 1 to the end and repeat this until the array is complete (attached). I've been reaching a memory limit with this as the array becomes enormous with literally trillions of data points.

I think the other potential solution would be to create a PWM signal, but I'm not sure how to do this. I've tried following a few PWM tutorials, but most solutions I've seen don't seem flexible enough for this solution.

I'm using a PXIe-6537 as the output card. Currently, I'd like to get a single pin on the card outputting the attached waveform. The end goal of this task would be 8 pins playing waveforms simultaneously (probably playing one 8 channel waveform) with the ability to upload different txt files of differing lengths.

I feel like there must be an easy solution for this! I've been teaching myself LabVIEW for a few months so am new to this still 🙂

[Kevin_Price]

A few things:

1. Your 6537 device is spec'ed for a max sample rate of 50 MHz so the shortest pulse you could generate is 20 nanosec, not 10.

2. You're also right that it takes an awful lot of samples to run a digital output task at 50 MHz for several minutes.

3. If pulses are relatively sparse compared to the time between them (i.e., low duty cycle), the PXIe-6612 would probably be a much better choice.  You'd still be limited to 20 nanosec pulses, but you'd drastically cut down on the amount of "sample data" needed to define the precise timing.  You'd only use two "samples" per pulse -- one for the idle time and one for the pulse duration.

   You'd also get the convenience of each of the 8 outputs operating independently if you needed to start/stop just one at a time.

-Kevin P

P.S.  For future code postings, it's helpful to use File->Save For Previous Version and go back several years.  I wasn't able to look at your 2024 code at all.  A lot of experienced people here work in realms with careful config control and thus "lock in" at an older version of LabVIEW for several years.  2019 or earlier should be far enough back for most of us.

[O11ie]

Hi Kevin,

Thank you very much for your reply!

Embarrassingly the 10ns is a mistake on my part, I couldn't do 1/50M this morning, but I'll refrain from editing the original post... I didn't know there was the ability to save for previous versions, I've attached the 2019 version here. It's incomplete as I'm just trying to achieve formatting the data initially and will do the digital waveform and output to DIO after.

On your point 3, what about the PXIe-6612 allows it to implement idle time and pulse duration and is there something in the spec sheet/a tutorial that highlights that? I guess what I'm saying is I don't know what the wording or phrase is that allows the 6612 to do that and not the 6537. 

Thanks again,

Ollie

[JÞB]

First PWM is not what you think it is.  You could look at that online for more details.  In a nutshell, a PWM DO signal is generally used to drive an inductive load like a DC motor at a controlled speed where 0%DC is obviously no effective drive an 100%DC is as fast as possible.   The inductance filters out the base frequency and essentially the motor sees DC%/100 * VSS as drive voltage. 

I can see 2 possible paths to achieve duplicating the file as a DO output.

1) with a Triggered DO Task. Simply advance through the file data and fire a trigger to get a pulse output each time a transition appears in the data.  Each pulse will be exactly the same. 

2) with a continuous generation Task. Write about a half buffer's worth of data from the file data to the device in a loop until the entire file of data has been generated.   That would allow the data file to be exactly generated but, requires attention to timing details. 

Both approaches have excellent quality shipping examples that you should get familiar with. 😉

[Kevin_Price]

As to point 3:  I kinda skipped right over the key point, sorry about that.  The key is to define pulse timing with a *counter* task rather than a DO task.  The 6612 is primarily a counter/timer device with 8 counter channels.  It happens to support some DIO as well, but it's the counters that I was, well, counting on.

What do your output pulses accomplish?  Why the very fine resolution timing demands?

Your input data file has only a very few entries -- what does the data represent?   Are they something like pulse times or incremental interval times between pulses?  How many pulses do you intend to generate during your ~280 seconds?

-Kevin P

[O11ie]

Hi Jay,

When I was talking about PWM, I was thinking of creating the inverse of the signal I need and then taking that away from an on signal- I guess it would be pulse gap modulation? Either way, you're right, PWM isn't the correct phrase for this application

With your point 1, is there a way to improve the triggering accuracy? I had a version using the same idea (for loop checking against the file), but it was too variable using software timing. From Accuracy of Software-Timed Applications in LabVIEW - NI, the accuracy on Windows is +-1ms, when I'm looking for tens of ns accuracy.

Point 2, do you have any recommended examples to look at? I hadn't realised that it would be possible to chunk the waveform in this way

Thanks for the help!

Ollie

[O11ie]

Hi Kevin,

I see what you mean about the 6612 now, I'm going to look into getting or trialling one. I'm assuming it would be using the 6612 instead of the 6537?

I'm looking to play recorded data to simulate a sensor suite. I can't guarantee the sensor outputs, so I'm going to make a few different recordings and then play them back through the testbench setup. I'm trying to match the output of the sensors as closely as possible and in as repeatable a way as possible, so the timing is the important information- it doesn't matter if it's not exact, so long as it's repeatably not exact!

I've not recorded the real data yet, but the file format is already set. I would expect the data could be anywhere from a few minutes to nearly an hour, with an unknown/unpredictable amount of time between and number of pulses.

-Ollie

[Kevin_Price]

Given your latest reply, you may have a real opportunity to use the 6537 you already own after all.

Timing *repeatabilty* for a DO task on the 6537 will be on par with that from counter tasks on a 6612.  Timing *resolution* (which is maybe about the same thing as "accuracy" here) is the thing where high demands can lead to very high data bandwdith requirements from a DO task, but probably much less so from a counter output task.

That is going to be your decision point.  If you use the 6537 you already own you'll be trading off timing accuracy / resolution against sample rate and data bandwidth.   Timing repeatability would be very very good though, affected mainly by any temperature fluctuations around the clock chip on the 6537, and that won't usually amount to much over the course of a few minutes, aside from the first few minutes after power-up.

    A lot of NI DAQ device clocks are spec'ed to around 50 ppm absolute accuracy.  In my observations, any inaccuracy is pretty nearly constant over the course of a day or two.  Repeatability is just looking for variation in the amount of inaccuracy, and that's a pretty small contributor in a typical indoor lab environment.

Changing to a 6612 and counter output tasks won't appreciably improve repeatability.  It will only let you accomplish better accuracy without nearly as much data bandwidth trade off concern.

-Kevin P

[Henrik_Volkers]

I don't know the driver and hardware details, but I assume that you can write raw U32 to the 32 channel port 😉

next assumtion is that most of the time you send zeros to the output channels

so prepare your channel files in a manner that you have the number of zero samples and the following data sample (for all channels , a U32 here, but maybe also works with U8). Here the one channel file just need to be adjusted to the 50 MHz samplerate of the 6537 (maybe minus one, if the the data is a timestamp difference 😉 )

Your 6537 is build to run via DMA on a circular buffer , so you need to fill that buffer fast enough.

pipe the number of zeros and the following data via a producer loop to the fast running consumer loop (without UI interaction) to fill the buffer . the pic show the idea.  I pre build a block of 2048 zeros .. that is send to the DAQmx buffer via raw write ( please check the dataformat .. never used it) and create a new flex array sized with the data attached.   

(DAQ handling like init ... is missing, have a look at the shipped exsamples)

I'm shure there are faster ways , like using a bigger fixed block size of zeros and preparing just a list of data to exchange by block number and index , depending on your system check block sizes can be much higher and should match system used block sizes (say 1Mbyte?)

Hopefully the consumer loop part is fast enough to generate samples

[O11ie]

Hi Kevin,

I'm going to try and work with the 6537 for the time being then, but with a view to potentially using a 6612 in the future. I'm currently using a Thunderbolt connection, but if I hit bandwidth issues, I know where the problem is now!

I'm going to try Henrik's suggestion- using a circular buffer to output the waveform as it goes. Hopefully this will cut down on the data size issue at the expense of having to constantly stream data.

Thanks for your help,

Ollie