How to create clean transitions between waveforms on PXI-6551

[JKneale]

I need to create a continuous pulse stream, and inject occasional communications bursts in it without interupting it (or at least not aborting it in the middle).  I tried using a script such as this:

script myscript
  repeat forever
     generate wf1  
     if scriptTrigger0   (this is how I fit in a comms burst)
        generate wf2
     end if
     generate wf3
     if scriptTrigger1   (this is how I hold it at a known point for abort)
        clear scriptTrigger1
        wait until scriptTrigger1
     end if
  end repeat
end script

I found that the 32 sample delay for the script trigger causes the signals to shut down for that period, which is a problem in my application.  I was also seeing one-sample glitches on some of the signals.

I was having better luck with a non-scripted waveform running in continous mode.  If I set niHSDIO_SetNamedWaveformNextWritePosition to use the start of the waveform, initial experiments indicate that I can change things on the fly without missing a beat. 

In order to abort the waveform but let it complete its current cycle, I was intending to change niHSDIO_ConfigureGenerationRepeat to finite and then call niHSDIO_CommitDynamic. 

Is this a reasonable approach to this, or am I asking for trouble?

[JKneale]

Changing niHSDIO_ConfigureGenerationRepeat to finite and then call niHSDIO_CommitDynamic doesn't work.  Neither does changing the associated attributes.

I also found that anytime that one issues a software script trigger, the output waveform has a short dead period, which might occur at anytime in the waveform.

Overwriting waveform memory while the script is running appears to be the only way to guarantee clean transitions.  I'd love to be able to poke a value into the script memory to be able to cleanly exit a repeat forever loop.  Is this possible?

[BROhan]

Hi JKneale,

If you issue a script trigger, you should be able to hold the last value of the waveform. You will likely need to recreate your waveform to accomodate this. Also, I was wondering what you meant by one sample glitches.

Overall are you just trying to output a certain value when you issue the script trigger? If so, I would write that value at the end of your waveform 3.

[JKneale]

The waveform includes a repeating sequence of timing pulses.  If it pauses to service a script trigger when the pulses are low, there is no problem.  If the pulses are high, then there are unwanted side effects.

There is one key pulse which can be asynchronously shut off, and make it safe for anything else to happen.  I was going to try down-programming the high of its voltage variable driver to force a logic 0 (assuming that that is a static operation in the channel electronics) before issuing an abort.

In regards to the glitching, I was observing them at both edges of the 32 sample gap when the script trigger was issued.  It could have been a side effect of earlier experimentation.  In addition, I had the idle state configured, but not the initial state.  Perhaps that will help.

Just as an FYI, In my experimentation I found that although its possible to write over waveforms currently being generated in both waveform and scripted mode, the results are not predictable enough if every sample counts.

[BROhan]

Hi JKneale,

If you do "down-program" a high voltage before aborting, you should be able to get the functionality you seek. You may want to take a look at this KnowledgeBase.

As you mentioned, definitely try to configure the initial state as well as the idle state, and hopefully this will resolve the glitching you noticed.

[BROhan]

Hi JKneal,

You may want to also configure the idle state to hold the last value, which should be able to force to be low. Take a look at this property node.

[BROhan]

Hi JKneale,

I wanted to find out exactly what you are trying to do when you receive the script trigger1. Are you expecting to pause after reaching the end of wf3 or are you trying to pause immediatedly (mid-waveform) upon receiving the script trigger?

[JKneale]

I tried downprogramming the voltage while the script was running, but it caused an error saying that I couldn't do that while a waveform was running.

Thanks for the reference to the KnowledgeBase article.  That is exactly what I observed when writing waveforms while they were running.

In regards to configuring the idle state for the last value, that isn't useful in my particular instance, but might be useful to others.  For those using CVI, the function that lets you do this is niHSDIO_ConfigureIdleState, not niHSDIO_ConfigureIdleStateU32

The purpose of scriptTrigger1 was to permit wf3 to run to completion, and then pause at a known state prior to abort.  I'm in the process of adding external hardware to make it safe to abort so I don't need to do that