Is it possible to change waveforms on the fly. NI PXI 5421 Arb

[AlanKnowler]

Hello All,

I have a requirement to be able to change the output of an Arb (PXI 5421) while the arb is currently generating a waveform.

Because of the nature of the waveforms I’ll have to use either sequencing or scripting to achieve my desired arb output, which will be something like...

[frameheader_1][frame payload][frameheader_2][frame payload] [frameheader_3][frame payload]….. [frameheader_20][frame payload] [frameheader_1][frame payload]

Where the frame payload is static for several minutes. There are 20 different ‘frameheaders’ which are repeated.

The period of the frameheader + frame payload is 40ms.

I need to have the capability to download a multitude of different ‘frame payloads’ to the  arb and switch to the new ‘payload’ without breaking the sequence of frame headers.

The frame headers are relatively small and it is my intention to retain these in the arb memory, and double-buffer the 'payload' to allow me to switch between frame payloads on the fly.

My question is... is it possible to download different ‘frame payloads’ to the arb whilst it is generating a waveform?

My UUT will reset if there is a break in the frameheader sequence, so I am unable to stop arb from generating a waveform to download different payloads.

Thanks

Alan

[kirsch]

Yes, it's definitely possible. If the frame payloads are all the same size (i.e. number of samples) then you can just replace the data for any of your waveforms even while the device is generating. Use scripting so that you can name your waveforms and refer to them by name. In order to avoid glitches in your output, you want to make sure that you replace the data of a waveform that is not currently being generated. If you need additional details, let us know.

If your frame payloads are of different sizes, then things get more complicated. 

[AlanKnowler]

Marcos, thanks for your reply. 

> If your frame payloads are of different sizes, then things get more complicated.

How so?  (as this will probably be the case).

[kirsch]

Because in the solution I describe, waveforms are allocated in device memory ahead of time, and the script that plays them is also created ahead of time. Then you replace the waveform data while the script is being generated. The script knows where (in device memory) the waveforms start and end, and retrieves the waveform data during generation. If the waveforms are of different size, the script cannot know where they begin and end.

Perhaps more details are needed from you, since there still may be ways to accomplish what you want:

- what are the possible sizes for the payloads?

- how many different payloads will you have?

- what sample rate do you need to use?

[AlanKnowler]

Thanks for your response Marcos. At the moment I'm looking at the feasibility / requirements so I do not have the detail you've suggested.

From your description it looks like a sensible approach would be to keep each 'payload' the same size and pad-out as necessary.

Thanks for your advice.

[kirsch]

I noticed you were asking about VideoMaster somewhere else in the forum. If that is for the same application as this, and the payloads are video frames, then you should be in luck, a video frame has the same number of samples no matter what you are displaying. You can use scripting to play back the same frame several times and then triggering to switch to another frame. A long time ago, when scripting support was first released for the 5421, I remember someone working on a demo along these lines that worked very well.

Then again, they may be two completely different applications...

Hope this helps. 

[AlanKnowler]

Marcos, No the video frame is a different arb application, which runs synchronously with the arb running the [frameheader][frame payload]... scheme.

Thanks for your information - very useful. Bit delayed in answering as I attended the Labview Core I and Labview Core II last week.

Alan