DMM Multipoint Software trigger works as immediate

[gremlm]

There is no any other place for sending software trigger in our code.

In you code it is time out when you send no trigger at all.

Try to send less amount of triggers than samples in the set. Will it timeout?

We reciving all samples even when we send less amount of triggers then samples in the set for case when each sample in the sequence should be triggered

[JaredRo]

Hi gremlm,

I just ran the code sending only 9 triggers instead of 10 and I received a timeout error.  If you are not sending triggers anywhere else in your code, I am not sure why you would be experiencing this behavior.

Could you possibly try installing the .NET Class Libraries and running one of the included examples?  There is an example titled Software Triggered Multipoint Acquisition that is similar to what you're trying to accomplish.  I'd be curious if you still see the strange trigger behavior with the .NET API rather than using the DLL wrapper like you are now.

[Laszlo]

Hi,

I have the same probelm. I use the 4071 dmm from CVI. I attached the NI I/O trace log. I inserted some niDMM_ReadStaus call to the code. The Acquisition_Backlog parameter of the niDMM_ReadStaus function is the number of available samples.

At point 40 I call the niDMM_Initiate. At point 42 you can see the niDMM_ReadStaus before calling the niDMM_SendSoftwareTrigger. The Acquisition_Backlog parameter of the niDMM_ReadStaus function is 1901. That means the acquisition was started before I call the niDMM_SendSoftwareTrigger.  

I use the NIDMM 3.0.6 and CVI 12.0.1.

Because if I set the trigger source first to NIDMM_VAL_EXTERNAL, and after set to NIDMM_VAL_SOFTWARE_TRIG at point 38, the software works correctly.

[gremlm]

Unfortuntely, it looks like there is an error in SourceTrigger property.

If setting it value first to External than to Software resolves it, it is indication of the error for sure

[JaredRo]

Hi Laszlo,

Thank you for the information.

I was able to reproduce some of the behavior you described.  Also using CVI 12.0.1 and NI-DMM 3.0.6, I added some niDMM_ReadStatus functions to the Cont Multi Point - SW Sample Trig example from the Example Finder.  Using NI I/O Trace, I was able to see that a sample is taken before the SW Trigger is ever asserted.

I was not, however, able to fix the issue by setting the trigger source to External prior to setting it to Software Trigger.  I tried setting various values as my trigger source, but my results were always the same.  Would you be able to attach the code you used to implement this fix?  I'd like to recreate the workaround on my machine.

I will be speaking with some developers to see if we can determine why the DMM trigger functionality is behaving in this seemingly incorrect manner.

[JaredRo]

Hi Laszlo,

After some further investigation, it seems like the behavior I saw was expected.  There was an issue with the example code I used that caused me to believe I was seeing the behavior you were describing.  The Trigger Source parameter was set to Immediate by default, causing a sample to be written to the buffer as soon as Initiate executed.  I saw this data point returned from the ReadStatus function and assumed it was a result of the problem you described.  Changing the Trigger Source setting caused the problem to go away.

Based on your I/O trace, I see that you're performing a software triggered waveform acquisition.  I first ran a SW triggered waveform acquisition with a couple of ReadStatus functions added.  I attached the I/O trace (Trace.png).  The ReadStatus function before the SendSoftwareTrigger call shows no data in the buffer, and the one afterwards shows data in the buffer.  This appears to be working properly.

Just to see if anything would change I also created a version of the code in which I set the Trigger Source to External, then immediately set it to SW Triggered.  This I/O trace is also attached (Trace 2.png).  The behavior did not change.

Any advice or code you could give me that would help replicate the erroneous behavior would be greatly appreciated.  

[gremlm]

Using ReadStatus function before and after SendSoftwareTrigger call does not confirm that acquisition happened based on SoftwareTrigger.

Acquisition could happened just slowly and you will havbe the same result.

Propper testing approach should be the following:

For the same configuration of Multipoint data acquisition with Software Trigger - two tests:

Test1:

Init

some delay,

ReadStatus

some delay,

SendSoftwareTrigger

ReadStatus

Fetch

Test2:

Init

some delay,

some delay,

ReadStatus

Fetch

[JaredRo]

Hi gremlm,

I actually did have delays throughout my code before every ReadStatus call.  Even when I set a large delay (5 seconds) however, the return values from ReadStatus still didn't indicate any values being in the buffer.

[Laszlo]

Hi JaredRo,

I have a large functional test software. This software run a test sequence that consist of test steps. Every steps contain a DMM measurement, and other functions (LIN bus, Power Supply, ...)

If I run alone any step from the sequence, the measuremet will be ok. If I run the whole sequence, the error occurs. But the first some steps always will be good.

Please write a test program that contains every DMM calls from my trace.

After I call the niDMM_Initiate, I set other instruments (power supply, switch, LIN bus, ...). When every instrumets configured, I call the niDMM_SendSoftwareTrigger. Therefore, there are some milisec between the Initiate and SendSoftwareTrigger functions.

[JaredRo]

Hi Laszlo,

I went through and wrote a test program including every function call from your trace and I was finally able to recreate the issue you've described.  Thank you both for your diligence in describing the problem so I could get to this point.

The incorrect behavior has been filed in our system as Corrective Action Report (CAR) #412395.  There may be a fix for the bug in a future version of NI-DMM.  When a new version comes out, you can see which issues have been fixed in the Bug Fixes section of the driver readme.  

For now, I recommend you use the workaround that gramlm discovered - first set the trigger to External before setting it to Software.

Thanks again!