synchronizing multiple generators using tclk and script triggers

[gregoryng]

I've been trying to combine the arb script example and one of the tclk examples to make a demo that generates synchronized pulses on two PXI-5422 signal generators when they receive a software trigger. The software trigger is sent whenever the user pushes the "Send Software Trigger" button on the front panel.

This is an intermediate demo to the ultimate goal which is to have two signal generators and a 2-channel digitizer that will simultaneously generate and acquire whenever a digital edge is received.  The attached VI has some disabled code toward that effect.

When I run the attached VI, it seems to initialize, but when I push the button to send a script trigger, I get an error message "Invalid value for software trigger name."  The error code listed in decimal (-1074135039) comes out to bffa0001 in hex. Since I'm using the enumerated string names "Script Trigger 0" for my trigger IDs, I don't know what I am doing wrong.

I'm sure I'm missing some simple thing, and insight into what I'm missing is greatly appreciated, as well as input as to whether I am on the right track to do what I ultimately want to do.

-gn

[gregoryng]

By the way, I am running Labview 2009 real-time on a PXIe-8130 controller.

[TimmTheEnchanter]

Hi Gregoryng,

Which version of NI-FGEN are you using?  I'm curious if this is a known issue (I'm looking through the readme for FGEN 2.7.2 for known issues, but I haven't quite found anything that hits the nail on the head.)  Other examples, online and in Example Finder, seem to indicate your program flow and syntax for the triggers are fine.  This example uses HSDIO, but it seems to have a similar setup.

One suggestion I found was to try using the "Initialize With Options" VI instead of the "Initialize" VI.  Could you give that a shot?

Regards,

Andrew

[Liusdi]

Hi Gregoryng,

You will need to recreate the Trigger ring constant. It is the constant that is wired to niFgen Send Software Edge Trigger.vi. Please refer to the attached screenshot if you have trouble finding it.

The problem is the constant value in your VI maps "Script Trigger" to an integer value of 104, it should be 103 instead. Can you recall how did you create that constant in the first place?

Thanks,

- Liusdi

[gregoryng]

Hm, that's a good catch about the constant. This VI is actually derived from one given to me by an applications engineer about two months ago.  I just inspected the original VI that he sent me, and it does indeed have the Script Trigger=104 constant.  The reference number for that ticket was 7304633.

I've made the modification and now the signals generate fine, so that seems to have fixed it.  I didn't try initializing with options.  I am using NI-FGEN 2.6.3.

Moving on, I also re-enabled the scope code which I had before to try to digitize the generated waveforms.  The problem that I'm having now is that I seem to only receive the data from an acquisition tied with what occurs prior to the first script trigger, even on subsequent triggers.  Using a real oscilloscope, I have verified that the the correct sequence of waveforms is being output, according to this script from the VI which programs the signal generator:

script scriptGenerateHF
  repeat forever
  Generate wfmChirpHF
  Generate wfmSine
  wait until scriptTrigger0

  Generate wfmSine
  Generate wfmChirpHF
  wait until scriptTrigger0

  Generate wfmChirpHF
  Generate wfmChirpHF
  wait until scriptTrigger0

  Generate wfmSine
  Generate wfmSine
  wait until scriptTrigger0

  end repeat
end script

Hopefully the answer to this part of the problem is as easy as the previous one...

[TimmTheEnchanter]

Hi Gregoryng,

I'm a little confused what you mean by a "real" oscilloscope?

In the description for the niTClk Initiate VI, it explains that it is actually starting all the sessions passed to it.  Since you are not configuring any sort of triggers for your scope task, I suspect you may be reading a backlog of samples somehow.  You might try putting in an arm start trigger in your scope task to make sure it is starting at the same time you expect your script trigger to start.

Also--you might want to make the sample rates more comparable.  If you're generating an output at 50MHz and reading in from your scope at 10MHz, you may be seeing some sort of aliasing effect.

Also--what are you getting for your "size of returned data" parameter?

Hope this helps,

Andrew

[TimmTheEnchanter]

Also, I checked into that service request and couldn't find anything to indicate why those enum items would be changed to non-default values.  I'd like to document that if it is an issue, but we would first need to find a way to reproduce it.

-Andrew

[gregoryng]

Hi Andrew,

size of "returned data" is typically 1000x2, if "# or records" is 1, and 1000x4 if 2, 1000x6 if 3, etc.  this is for both the initial sent trigger and all subsequent ones.

When I say "real" oscilloscope, I mean a dedicated, physical HP oscilloscope with a max samplerate in the GS/s range.  I hook up the outputs of the signal generators to the inputs of the oscilloscope, and put it in Single Trigger mode as I successively step through the trigger script. So when the waveform comes through, it shows up on the oscilloscope and pauses acquisition.

---

@TimmTheEnchanter wrote:
Also--you might want to make the sample rates more comparable.  If you're generating an output at 50MHz and reading in from your scope at 10MHz, you may be seeing some sort of aliasing effect.

---

I think the setup is fine.  The waveform is a single triangle/sine wave 1024 samples wide, so it spans 102us, which is a frequency of ~10 KHz, well below anything that would cause aliasing.  And this is backed up by the real oscilloscope which should have no problem either way.

 

---

@TimmTheEnchanter wrote:

Also, I checked into that service request and couldn't find anything to indicate why those enum items would be changed to non-default values.  I'd like to document that if it is an issue, but we would first need to find a way to reproduce it.

-Andrew

---

Yes, I expect that this faulty ring constant was probably some sort of unintentionally copy-pasted old code and we should assume that it is as simple as that.

Regarding the arm start trigger, I will try it, but my question is why that is necessary?  My impression was that for tclk, there should be only one master session in the group, and I would assume that by adding another trigger criterion that would make another master?  What are the correct principles to follow here?

[gregoryng]

I just re-read your arm-start trigger suggestion and now I realized that what you meant.  You meant that adding the arm start trigger would prevent the scope from reacting to triggers prior to when the signal generator is generating, and therefore generating a backlog of records that would need to be read to be cleared. 

But if this were happening, the records should show a zero waveform, because the script trigger would not be generating the proper waveforms that I am seeing.  (I am seeing the first waveform in the sequence).

So I'm inclined not to think that adding an arm start trigger (which would need to be triggered and seems unnecessary) would not solve the problem.

Also, I realized that my math in the previous post was wrong, and the output waveform at 1024 samples, 50 MS/s output would have a ~50 KHz frequency.

[gregoryng]

I've made progress.  I looked at "niScope EX Multi Record Fetch More Than Available Memory.vi" in the examples folder and used this to set things up in the continuous acquisition pattern, which is what I am going for. I also configured the script trigger to be exported to PXI trigger line 0, and for the niScope to look for a digital edge trigger on the same line.

I've attached the resulting VI.  I think it does everything I want at this point, which is that when you press the Send Software Trigger button, a pulse waveform comes out, and is received by the PXI-5122 (assuming you have signal cables connected).  If you press the button successively, you will see the waveforms loop through the sequence of Triangle,Sine; Sine, Triangle; Triangle, Triangle; Sine, Sine.  The "number of records" parameter is set really high and therefore I haven't reproduced the logic to quit the loop at the end of acquisition from the example.

One concrete question: In looking at the NIScope Configure Horizontal Timing VI: Number of Records parameter, is there any parameter value that causes the acquisition session to run forever?  In similar functions, a value of -1 might encode this preference, but that doesn't seem to be the case from the documentation.

And second, I would welcome any comment on anything in the VI that goes against the spirit of how the acquisition VIs are supposed to be used (general comments on not using VIs right).