real-time trigger cycle between immed and edge causes edge trigger to occasionally fail

[gfl]

Hello,

We're using a 5112 with NiScope to receive 6 us blocks at 100MS/s of data at ~20 hz.  The 5122 channel 1 trigger is cycled between immediate and positive slope edge mode.  Occasionally we notice that the edge trigger fails and the failed trigger returns a block of data that sometimes appears to be immediate capture and sometimes it appears that the trigger is using a negative slope edge trigger.  Does the 5112 need a specific setup time when switching from immediate to edge trigger mode??  Is there a specific status function that can be used to verify that the digitizer is ready for capture with the specific edge trigger specified?

Thanks,

George

[bspears]

Hi George,

I assume when you say you're cycling between triggering modes that you are stopping acquisition, reconfiguring, and then starting acquisition again. The stopping, reconfiguring, and starting are all done in software which means it's always going to be subject to the availability of the CPU and thus, not constant. This is unless you are using deterministic programming, such as LabVIEW Real-Time (RT). Are you using LabVIEW RT? If you are not using deterministic programming then there's no way to truly tell how long the reconfiguring will take and you will be subject to lost triggers during this time. You can try and benchmark the reconfiguring time, but this will just be a good indicator of how long reconfiguring will take, it will not be reliable. If you need a reliable time, I would encourage you to take a look at LabVIEW RT.

The digitizer is ready to receive a trigger as soon as it has been started (after configuration). Trigger rearm time is 10us, and 2us if TDC is disabled.

Hope this helps!

Brian Spears

[gfl]

Hi Brian,

Thanks much for the reply and information.  

Yes, we stop acquisition, reconfigure only the trigger type, one of:

pScope->Trigger.Immediate.Configure(); 

or

pScope->Trigger.Edge.Configure( pszTrigger, g_fTriggerLevel, CNiScope::Positive, CNiScope::DcCoupling, 0.0, 0.0);

Then directly proceed with another pScope->Acquisition.Initiate ().

Do I understand that there needs to be at least a 10us delay between the Trigger.Edge.Configure() member function call and the Acquisition.Initiate() call?  It's almost like the trigger hardware during the acquisition following the transition to the edge trigger still thinks that it should be in immediate mode.  I was thinking of trying several edge trigger acquisitions in a row following the transition to edge mode and see if the trigger hardware starts to work properly.  Does the Acquisition.Commit() function flush the trigger settings to the card? 

Our scope acquisition need not be hard real-time, but we are running the above code in a THREAD_PRIORITY_TIME_CRITICAL priority XP service and obtain satisfactory timing behavior .  We do have RTX applications communicating with this application and would like to have CNiScope work with RTX.

Thanks again for your help.

g

[bspears]

Hi George,

No sorry, I looks like I was unclear. The programming flow for the digitizers looks like this:

Initialize (open a session)>>Configure>>Acquire data>>Error handler>>Close

You can find more info on this in our NI-High-Speed Digitizers Help file that should have installed with the driver and can be accessed at Start>>All Programs>>National Instruments>>NI-SCOPE>>Documentation

Whenever your program is configuring your digitizer (setting triggering modes, setting horizontal and vertical parameters, etc) you are all in the "software realm" and the digitizer is just sitting there, idle. For example, when your program calls pScope->Trigger.Immediate.Configure(); you are in the software realm.

Whenever you call pScope->Acquisition.Initiate (), the digitizer now takes everything that you set in software and flushes it down to the hardware and it immediately begins to run (and it's now ready for a trigger). The software at this point is mainly idle, except as it's fetching data from the onboard memory of the digitizer. We'll call this the "hardware realm".

If, during configuration, I have set multiple edge triggers (or multiple digital triggers, but NOT a digital AND edge trigger (in other words, not two different triggering modes)) then the rearm time between triggers DURING acquisition is 10us or 2us if TDC is disabled. However, if I am going to change my triggering mode (for example, from edge triggering to immediate triggering) then I have to stop acquiring data and move back to the configuration stage (moving from the hardware realm back to the software realm). As I'm changing my digitizer to another triggering mode, my digitizer is idle, it is NOT acquiring. Thus, if I'm sending triggers to my digitizer my digitizer will not receive them. This is probably why you are missing triggers. After I reconfigure, I have to send my digitizer back to acquisition mode (back to the hardware realm) where it is running and acquiring data.

I don't know your application well enough to make an advisement but you cannot have two different triggering modes set simultaneously (immediate and edge) and whenever you cycle between them, you are stopping your digitizer. If you need both of those triggering modes, then some customers have used two different digitizers, one dedicated for each triggering type and the inputs going into both of them.

Hope this helps!

Brian Spears