How to acquire data in BURST mode using DIO32HS, NiDAQmx, and VB.NET

[rikraf]

I have a very simple DIO application which I wrote in VB 6.0 using "Traditional NiDAQ" driver.  I am trying to rewrite it in VB.NET 2005 using NIDAQmx, since the former is no longer supported.  I'm trying to acquire 961 32-bit words.  But I find the data array ("Data") only contains 510 words after first run of code, then 254, then 126, .... then the whole thing crashes.  Here's the code, which I based n a NI example ("ContReadDigChanBurst").  I've tried various parameters....
Thanks for any help.
 
Rick

Private Sub btnGO_Click(ByVal eventSender As System.Object, ByVal eventArgs As System.EventArgs) Handles btnGO.Click
If taskRunning = False Then
Try
btnGO.Enabled = False
btnExit.Enabled = False
taskRunning = True
 
myTask = New Task("diTask")
myTask.DIChannels.CreateChannel("Dev1/port0_32", "DigRead", ChannelLineGrouping.OneChannelForAllLines)
myTask.Timing.ConfigureSampleClock("/Dev1/PFI4", 20000000, SampleClockActiveEdge.Rising, _
SampleQuantityMode.FiniteSamples, 961)
myTask.Timing.ConfigureHandshakingBurstExportClock("/Dev1/PFI4", 20000000, _
DigitalLevelPauseTriggerCondition.Low, ReadyForTransferEventLevelActiveLevel.ActiveHigh, _
SampleClockPulsePolarity.ActiveHigh, SampleQuantityMode.FiniteSamples, 961)
myTask.Control(TaskAction.Verify)
DigitalInReader = New DigitalMultiChannelReader(myTask.Stream)
DigitalInReader.SynchronizingObject = Me
'DigitalInReader.SynchronizeCallbacks = true
DigitalCallBack = New AsyncCallback(AddressOf DigitalInCallback)
DigitalInReader.BeginReadMultiSamplePortInt32(-1, DigitalCallBack, Nothing)
Catch ex As Exception
MessageBox.Show(ex.Message)
taskRunning = False
btnGO.Enabled = True
btnExit.Enabled = True
 
End Try
End If
 
btnGO.Enabled = True
btnExit.Enabled = True
End Sub
Private Sub DigitalInCallback(ByVal ar As IAsyncResult)
Try
If taskRunning = True Then
Data = DigitalInReader.EndReadMultiSamplePortInt32(ar)
 
End If
Catch ex As DaqException
MessageBox.Show(ex.Message)
End Try
taskRunning = False
myTask.Dispose()
End Sub

[Chris_K_]

Hi Rick,

I have implemented your changes into the online example, and I am able to successfully run the program multiple time acquiring all the data points that I am generating.  This tells me that the code is correct.  I just want to ensure that your connections are correct.  Since we are using burst mode, there are three lines that we are concerned about.  You have internally configured the sample clock, however you must also control the REQ and the ACK lines as well.

In you case they are REQ is PFI 2 and ACK is PFI 6.  The following table can be found in the DAQmx Help. 

<img src="Loading Image...">

&nbsp;Also have a look at the following link under the High-Speed Two-Way Handshaking ? Synchronous section.&nbsp; It will give a bit of insight into the overall process of burst mode.&nbsp;

Ensure that you are connecting the correct signals and maybe have re-implemented your modification to the example that you started with.

If you are still having problems, what do you mean when you say the whole thing crashes?&nbsp; When you run the program do you get good data, but just missing samples?&nbsp; Do you always get the same number of samples each time you run it?&nbsp; Again I was able to successfully able to run your code so I am under the impression that there is something else out of order here.&nbsp;

ChrisKMessage Edited by Chris_K_ on 05-28-2008 06:11 PM


Burst.png:
http://forums.ni.com/attachments/ni/70/8935/1/Burst.png

[rikraf]

Hi Chris,
Thank you for that.&nbsp; I did indeed have the signals formerly known as REQ and ACK connected up and working- this application was already working in Trad NIDAQ,burst mode.&nbsp; I believe the problem I was having was a VB.NET related red herring- when I looked at the "data" array with the VB debugger it seemed to say that the array was not full, and tehn when I looked again and again it ultimately crashed VB.&nbsp; But it seems the data was there all along, as I saw by using the "immediate" window.&nbsp; Anyway, the code works now, but I still have an odd problem: it seems that the interface, which was formerly reliable at PCLK=20MHz using Trad NIDAQ, is now flakey (screws up 20% of the time)&nbsp;using NIDAQmx.&nbsp; But with PCLK=10MHz the new NIDAQmx code works perfectly.&nbsp; I've verified the PCLK freq on the scope.&nbsp; Are there any other parameters that might come into play here, that maybe I've not set up correctly?
Thanks much,
Rick
&nbsp;

[Chris_K_]

Hi Rick
I am glad that we were able to get the code running.
About the 20MHz PCLK, if you have ensured that the actual signal is proper using a scope then I am not sure what the problem is.&nbsp; Can you explain what exactly you mean when you say flakey?&nbsp; Are you getting an error? What is occurring that indicates that there is a problem?&nbsp; It makes it a lot easier to trouble shoot the issue if I can recreate what you are seeing.&nbsp;
Chris_K

[rikraf]

Right.&nbsp; By flakey I mean that the data,&nbsp;a known sequence&nbsp;generated in firmware on another device, is corrupt.&nbsp; When I switch to 10MHz it is not corrupt.&nbsp; As though I'm not meeting the hold or setup time req'ts, clock to data.&nbsp; But as I said, in trad NIDAQ it comes through uuncorrupted at 20MHz.&nbsp; I wouldn't be surprised if there were a timing violation, but I wouldn't expect it to change dependent on driver, unless I'd set some parameter up differently.

[Chris_K_]

Hi Rick

&nbsp;

So it is could be like a "one off" issue, where the acquisition is starting a sample&nbsp;early or late.&nbsp;

&nbsp;

One thing we can try is changing your program to acquire on a falling&nbsp;edge instead of a rising edge,&nbsp;(ie SampleClockActiveEdge.Falling)

&nbsp;

Try this and see if you get any better results.

&nbsp;

Chris_K

[Chris_K_]

Hi Rick, I also just found an article that may be helpful.&nbsp;
Check out the following <a href="http://digital.ni.com/public.nsf/allkb/862567530005F09F8625692A0073F172?OpenDocument" target="_blank">link.</a>
Chris_K