LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

PXIe-6556 Continuous Generation with PMU measurement

I am developing a test where I want to use a PXIe-6556 to generate a continuous 100MHz clock on one signal in an 8bit bus.  Once the clock is up and running I then need to use an Agilent N3280 PMU to make a DC measurement on another pin on my Device Under Test (DUT).  I am using LabView 2012 on a Win 7 system.  The PXIe-6556 card is a 200MHz 64Mb version. I am relatively new to LabView and in particular programming the PXIe-6556, having been working at for about 9 months.

 

After some suggestions from colleagues I decided to try using a software script to generate the continous clock. I couldn't attach the VI so I've taken a screenshot of the block diagram and added it here -

 

DCoOUT VI.JPG

 

 

The script to generate the continuous clock is very short -

 

script dcoinToggle

  repeat until scriptTrigger0

     generate myWfm

  end repeat

end script

 

After the PMU measurement is made I send a software trigger to a previously configured trigger (Trigger0) to stop the script.  While this seems to work the clock is not running at a 50% duty cycle like I expected.  In fact the duty cycle constantly changes.  Here's what the screenshot of the clock signal looks like.  In this picture I'm only running at 2MHz just to prove out the concept.  You can see that the pulse width is 500ns (or 2MHz), but the duty cycle is not 50%.

 

Waveform Screenshot.jpg

 

Just curious if anybody has any ideas why I'm not getting a 50% duty cycle clock?  Have I missed something in the setup of the PXIe-6556?  Is the concept just wrong?

 

After some more research I'm going to investigate using the NIHSDIO Configure Generation Repeat VI to try to generate the continuous clock.  I would use the Abort VI after the DC measurement (not currently added) is made to stop the clock.  Here's the block diagram for this VI -

 

Continuous VI.JPG

 

I have not tried this yet as I don't get tester time until later this week.  Any comments on this method?  Any obvious flaws that I have missed?  I have the same questions - Have I implemented the concept properly?  Is one method better than the other? 

 

Thanks in advance for any help.

 

 

0 Kudos
Message 1 of 11
(3,702 Views)

Hello,

 

I have a few questions for you. The clock that you are reading, where are you reading that clock from? The clock out terminal? 

 

Are you able to upload you code so I can test it out to see if it exibits the same behavior on my PXIe-6556?

 

As for your questions, nothing stands out at first glance. They are similar to the HSDIO examples that we have. 

 

Is your goal for this code to create a 100MHz clock out of the 6556? 

Brad S. | National Instruments | CLA
0 Kudos
Message 2 of 11
(3,668 Views)

Hi Brad,

 

Thanks for the quick reply.  Since a picture is worth a thousand words, here's a simplified block diagram of what I'm trying to do.

 

DCoOUT Blk Dgm.JPG

 

I'm trying to use the 6556 to generate a clock to my DUT.  The clock provides a sample clock for measuring the duty cycle of a separate DUT system clock..  I am using the N3280 to measure the output from the DUT that will tell me what the duty cycle is. 

 

The Scope Probe is where I captured the scope screenshot and is channel DIO8 from the 6556, and it goes directly into my DUT.  The goal is to produce a 100MHz clock from the 6556.  As you can see from the scope screenshot, it's sort of working, except that the duty cycle is wandering all over the place.I'm currently runnning the 6556 clock at 2MHz for debugging. 

 

Unfortunately I am not able to upload or attach my VI.  I keep getting a "The contents of the attachment doesn't match its file type." error when I do.  This appears to be a somewhat common problem, and I'm tryng to chase that problem down in a separate thread.  I would be happy to send you the VI via an email or other method if you'd like if the attach doesn't work.

 

What do you think of the NIHSDIO Configure Generation Repeat VI to try to generate the continuous clock as shown in my second VI image?  I have tester time tomorrow and Friday, and so I can try out some suggestions if  you'd like.   Also let me know if this doesn't make any sense and I will try to provide more details.

 

Thanks again - Bob

0 Kudos
Message 3 of 11
(3,660 Views)

 

Bob,

 

What data are you putting into your data array? Your output looks more like a bit stream then a signal with a varying duty cycle. If it were the duty cycle changing the pulse width would also change. 

 

Here is a picture of what I tried. Using a static dummy task outputting a low signal on the data line, I created a 100 MHz clock signal on the CLK OUT terminal. I ran it on my PXIe 6556 and it did not show any errors or warnings but I did not have a scope available to check the clock signal. 

 

I mainly asked for code to see what all the values were that you were writing to in the controls such as the data array. If you can give me that information for me to check then I can create your code on my end to see what happens for me. 

 

CLK_OUT.png

 

Brad S. | National Instruments | CLA
Message 4 of 11
(3,635 Views)

Hi Brad,

 

Well time on the tester makes a world of difference. Unfortunately I only get 1-2 days a week because it's really busy with production.

 

First to answer your question about what I'm putting in the data array.  The image below shows that.  What I'm trying to do is to have the DCOIN line drive be a clock signal to my DUT, while the other lines are held low.  The DCOIN line is channel DIO8 on the PXIe-6556.  Thus the alternating value of 128 in the data array.  I was using the 1D U8 version of the Write Named Waveform VI to produce these waveforms.

 

WaveformGraph.JPG

 

I have things working a couple of different ways now.  The first method is still using the scripting method, but I changed the script to be -

  script dcoinToggle                       //

     repeat forever                         // repeat loop runs until the system receives a Trigger0 signal

         generate dcoin_Clk             // generate the actual waveform named dcoin_Clk

     end repeat

  end script

 

and I got rid of the script trigger VIs.  The new block diagram looks like this -

 

BlockDgmScript.JPG

 

I added the Abort VI to stop the DCOIN clock after the PMU measurement is made.  This works just the way I want, but I still don't understand why the original script using "repeat until scriptTrigger0" produces the non-50% duty cycle output.  And the image that I showed of the clock output isn't the best representation of what I am seeing.  From your perspective it does indeed look like a bit stream, but the pulse widths are really changing, randomly.  The non-50% clock did run until it received the software script Trigger0.  I suppose it could still be viewed as a bit stream, but with a random pattern of 1's and 0's.  I'd still don't understand why this method didn't work.

 

As I was poking around looking at some of the niHSDIO program examples I came across the Configure Generation Repeat VI and so I built up a VI using it.  The block diagram (without the PMU) looks like this -

 

BlockDgmContinuous.JPG

This works exactly like I want as well, and is a little simpler than the scripting version.  So this is probably the version I will go with.  I still would like to understand why the original script version didn't work as expected.

 

Thanks for your help, and the quick response you provided. 

 

-Bob

0 Kudos
Message 5 of 11
(3,609 Views)

Bob,

 

I see what happened. In your first version of your code, you are using Scripted as your generation mode. In the woring version you use Waveform. The Dynamic Generation VI works as described below with those settings. 

 

 

Dynamic Generation:Repeat Mode

 

Specifies whether to generate a single waveform a finite number of times or continuously. This property is valid only when the Generation Mode property is set to Waveform; it is not used if you select Scripted. If this property is set to Finite, use the Repeat Countproperty to specify how many times the named waveform is generated.

 

Source: 

http://zone.ni.com/reference/en-XX/help/370520K-01/hsdiopropref/cnihsdio/

 

 

 

Because you were using Scripted as the generation mode, that is why you were getting the in correct output.

 

 

Brad S. | National Instruments | CLA
0 Kudos
Message 6 of 11
(3,555 Views)

Hi Brad,

 

I can get the correct output using a Scripted generation mode, but it has to be

 

script dcoinToggle                      

     repeat forever                         // repeat loop runs until the system receives a Trigger0 signal

         generate dcoin_Clk          // generate the actual waveform named dcoin_Clk

     end repeat

  end script

 

This actually works quite well.  The Scripted  version that didn't produce the desired output was

 

script dcoinToggle

  repeat until scriptTrigger0

     generate myWfm

  end repeat

end script

 

It did produce an output, but the output duty cycle randomly varied all over the place.  I'm curious as to what is the difference between the two scripts.  Whey did one work and not the other.

 

-Bob

0 Kudos
Message 7 of 11
(3,542 Views)

 

Hello Bob,

 

I did some digging and found out that it was a known issue in NI HSDIO 2.0. It was not fixed in NI HSDIO 14.0 (the next version) as far as I can tell. I looked at the readme for the NI HSDIO 14.0 Driver.

 

According to a known issue report: 

 

Capture.JPG

http://www.ni.com/tutorial/14585/en/

 

 

This explains the image that you showed from you output with you scoped it. There was a random delay between all of the pulses. Using Repeat forever alleviates this error because it is not looking for any triggers. 

 

 

 

Brad S. | National Instruments | CLA
0 Kudos
Message 8 of 11
(3,519 Views)

Hi Brad,

 

Well there's a new twist to my attempts to use the 'continuous generation' approach.  But first a comment about your last post.  I'm not really using script triggers with hardware compares.  I'm simply trying to drive a continuous clock out of the PXIe-6556 on one pin at a clock sample rate of 200MHz.  I'm not doing any compares, hardware or software.  So I'm not sure if the issue report you mention really applies to me or not, but perhaps it still affects the PXIe-6556 output.

 

So today I tried running my 'continuous generation' approach, and as before everything seemed to be working perfectly fine.  At least until I went above a clock sample rate of 115MHz.  Then the clock became non-continuous.  See the image below which was actually taken with a clock sample rate of 150MHz. 

 

dcoin_150M.jpg

 

As you can see the output from the PXIe-6556 is no longer continuous.  The clocked section is running at 75MHz (1/2 the clock sample rate of 150mHz).  The width of the active clocked section randomly varies from about 133ns to 633ns.  In other words it is not a fixed value.  This is a little hard to capture in this screenshot, but does come through as different widths in the clocked sections above.  The width of the 'high' section of the waveform is pretty consistent at about 140ns, although it does vary maybe +/-10ns. 

 

The width of the clocked section gets much longer when the PXIe-6556 clock sample rate was slowed down to 120MHz.  Then the width of the clocked section varies from 1.4us to 4.8us, while the 'high' section is still about 140ns.  Any clock sample rate 115MHz and below always produces a continuous clock output.

 

I see the same behavior no matter if the generation mode is 'continuous' or 'scripted'.  So apparently I can't run the PXIe-6556 with a continuous clock output above a clock sample rate of 115MHz, which produces an actual clock output signal of 57MHz. 

 

Then I noticed that both methods produce the same error output after the Abort VI is run at the end of test.  The error message displayed is (error # -1074115901) -

 

"Device data underflow. The device was not able to move data fast enough to keep sample for the active script. Run operation at a lower sample rate, or look for the following in the active script: markers might be too close together, waveforms might be too small, waits might be too short, or subsets might be too small. If you are using an external clock, the provided clock might have gone away during your generation."

 

So this may make sense when running the scripted version, but I certainly don't understand in relation to the 'continuous generation' version of the test.  I used MAX between test versions to reset the PXIe-6556.

 

I 'googled' the error number and found this one explanation pertaining to scripting using the NI Arbitrary Waveform Generator.

 

"This functionality is not part of the Signal Generators specification. Depending on the system configuration and the sample rate, the user may receive Error -1074115901 Device data underflow. The device was not able to move data fast enough to keep up with the sample rate for the active script. This occurs because the device memory is accessed by the driver as part of the niFgen Write Waveform function call, and also at the same time by the device as part of the waveform generation process. This simultaneous access to the device memory can cause the waveform generation of the device to no longer keep up with the sample rate and output properly. When changing the waveform of the Arbitrary Waveform Generator during generation, the user should take care in verifying that the output waveform is as expected."

 

Pasted from <http://digital.ni.com/public.nsf/allkb/3B41388E5BF23D8986257A1D00129B40>

 

So this might help explain the error in the scripted version, but how does it explain the 'continuous generation' test example?

 

Any explanation of how this applies not only to the PXIe-6556, but why it applies to the 'continuous generation' example?

 

-Bob

0 Kudos
Message 9 of 11
(3,506 Views)

 

Hello Bob,

 

I have a solution that will work. I have it running on a PXIe 6556 and using a PXIe 5160 Digitizer to see the output of channel 7 just as you are doing. 

 

Below are the images. I have attached the code as well in 2014 version and 2012 as well. Try this code out and let me know what happens. 

 

Front Panel:
FrontPanel.PNG

 

Block Diagram:

BlockDiagram.PNG

Scope Output:

Scope.PNG

 

 

 

Brad S. | National Instruments | CLA
0 Kudos
Message 10 of 11
(3,483 Views)