Digital I/O

Showing results for 
Search instead for 
Did you mean: 

channel skew in PXI-6551, bug in VB wrapper or hardware limitations?


I'm using the ConfigureDataPosition and ConfigureDataPositionDelay functions in the Visual Basic wrapper supplied by NI as per


CheckErr ConfigureDataPosition(viGenSession, skewedGenChannels, NIHSDIO_VAL_DELAY_FROM_SAMPLE_CLOCK_RISING_EDGE)
'skew the user requested channel(s)
CheckErr ConfigureDataPositionDelay(viGenSession, skewedGenChannels, delay)


 If I run the sample clock below 25MHz (max allowed is 50MHz) PXI-6551 does not output the waveform.  When these function calls are commented out from the code, it all works as desired except for the desired channel delay.


Has anyone seen this ?


Please advise.



0 Kudos
Message 1 of 10

Hey Anand,


The Data Delay feature of the 6551 device works for frequencies of 25 MHz and above. This information can be found in a couple of places. First, check out the NI Digital Waveform Generator/Analyzer Help file that you can either download the .chm file or check out the online version. In the help, you can search for Data Position Delay Resolution, and this is where you can read about the >25 MHz limitation for Data Delay.


Another resource you can check out is an NI DevZone article called Advanced Features of High Speed Digital I/O Devices: Data Delay. The information can also be found in this document.


If you need to have a data delay in your data at frequencies lower than 25 MHz, then one option you can consider is oversampling of your data. If you are using Data Delay for Generating your data, you could run the onboard clock at the max rate, in your case 50 MHz, and then adjust your data accordingly, and still use data delay. For example if you are generating 0010110 at say 10 MHz, you could run at 50 MHz, and then output 00000000001111100000111111111100000 instead. This will give you the same data at your device, and you can still use the Data Delay feature.


I hope this helps. Please let us know if you have any questions or concerns. If you do, please provide more information about what you are trying to do, such as: are you trying to do generation or acquisition, why you need data delay, are you trying to do some kind of edge placement, etc. The more information you provide, the better suggestions we can make. Thanks, and have a great day.




Message 2 of 10

Hi DJ L,


Many thanks for your input.  Yes, I can believe the user guide or help has this information.  I am indeed oversampling the data and then using the > 25MHz sample clock so there is no problem if I need to use the delay.


Another issue I found was that the data array to be generated must contain an even number of elements else 6551 will again not generate any data.  Is it that the waveform does not get written, or does it get written but not generated?


Initially, I read the manual prior to coding, but the nitty gritties keep slipping by.



0 Kudos
Message 3 of 10

Hi ajog,


If you look at page 18 of the NI PXI/PCI-6551/6552 Specifications under Generation waveform quantum, it states that your Waveform size must be an integer multiple of 2 samples.


I would speculate that your waveform never gets written.  Are you checking the return codes after each function call you make?  That should help you determine whether or not your call was successful, and our error information tends to be pretty helpful.


Please let us know if you have any more questions!


Keith Shapiro

National Instruments R&D

0 Kudos
Message 4 of 10

Thanks Keith,


Does the error reported by 'CheckErr' also lead to some clues as to the nature of the problem?   I am able to view errors but can't decipher the error codes (numbers). 


I understand that most errors are due to lack of knowledge and that the manual does provide the most accurate guidelines for usage.  The trick is correlating issues during implementation with what's in the manual.  Not sure if there's an easy way out ...



0 Kudos
Message 5 of 10

Hey Anand,


Other than the Help document and the 655x Specifications document that Keith mentioned, there are also Example programs that NI ships with the driver (C and LabVIEW). But for VB examples, you can find some online, specifically you can find multiple links to VB examples for HSDIO in the following Knowledgebase document called Using NI-HSDIO with Microsoft Visual Basic 6.0. If you download one of the linked examples, you can check out how those handle errors, and you can implement something similar in your code. Working off of examples is a great way to get started, or to refer to how to do certain things.


Here is a function that I found, from one of the examples linked above, that handles the errors:

Public Function CheckErr(X As Long)
    'Function that checks for errors
    Dim errorMessage As String
    errorMessage = Space(1024)
    If X <> 0 Then
        error_message ViSession, X, errorMessage
        Error_Out.Text = "Error Found!" & vbCrLf & "Code: " & X & vbCrLf & errorMessage
    End If
End Function


The errorMessage displayed should give you a good idea of what is going on, but if you have a specific error that is not descriptive enough, let us know and we can give you some ideas. Let us know if there is anything else we can help with. Thanks, and have a great day. 




0 Kudos
Message 6 of 10



I'm testing channel skew (delay) for acquisition.  I've been able to verify using an oscilloscope that generation channel skew works quite well.   The issues with verifying acquisition channel skew are as follows


1.   Not possible to view external to the 6551 since the DUT will send out unskewed data.  The delay for acquisition is done internal to the 6551.

2.   Sample clock (say 40MHz) samples data only every 25ns.  So verifying sub Tsampleclock delays in acquisition mode is challenging.


Basically, I'm trying to compute sub Tsampleclock times of events in the acquisition channel (with respect to the sample clock) by delaying acquisition in steps of (1/256) of Tsampleclock till I recognize the event but can't seem to get this to work.


Thanks for any tips/hints.



0 Kudos
Message 7 of 10

Hi Anand,


Here is a video showing how you can sweep the data delay parameter to determine round-trip delay:
Parametric Characterization and Hardware-Compare with the Digital Waveform Editor


I am not sure if this is what you are trying to do.  For example, what does "verifying acquisition channel skew" mean?  What is the event that you are trying to sample?  If you could include a timing diagram this would probably help make things more clear, at the moment I can't quite tell exactly what you need to do.  Any additional information about your application would be helpful.



John Passiak
0 Kudos
Message 8 of 10



Suppose the data received from the DUT exhibits an event such as a high (1) to low (0) transition.  Since the 6551 sample clock

time period is 25ns (as a example) that sets the resolution with which such an event can be measured.  But if I delay the acquisition in steps of (1/256) of the sample clock time period and note when the '0' is read as a '1' we can improve on the measurement resolution (I think).


So, I place a 'watch' on the '0' of the '1' to '0' transition event.  Then delay the acquisition in steps of (1/256) TsampleCLK until the watch position reads a '1'. Then the '1' to '0' transition may be said to occur TsampleCLK - delay where delay is some multiple of (1/256)TsampleCLK.


Would this work?


0 Kudos
Message 9 of 10

Hi Anand,


Characterizing sub-cycle delay is going to have some inherent uncertainty, since there is a setup and hold window where the data must be stable to be sampled correctly.  This means that as you sweep your data delay, there will be regions of the clock cycle where you move the clock such that the data transition falls into the transition region and will not be sample correctly.


By sweeping your data delay, you'll be able to find that region of uncertainty (in percentage form from the rising edge of the clock).


Once you've discovered the uncertainty region, you can run many many times and average the result to get an idea of where the edge is with respect to your period.


For more accuracy, you'll want a faster board.  The PXI-6552 runs at 100MHz, which gives you 256 steps across 10 ns, which is much finer resolution than the 6551's 20ns min. period.


 Does that help?


 Also, as John says, if you can send us a timing diagram of what you're trying to characterize, we'll be able to help you with the most efficient method to acheive your measurement.


Keith Shapiro

National Instruments R&D

0 Kudos
Message 10 of 10