timing violation two channels/external trigger NI 7966R with 5772

[PatrickR]

Hi, I have an NI 7966R with an NI 5772 digitizer.  I am attemping to modify the example code to allow for two channel acquisiton, and add an external trigger.   However, when I compiled the attached code, I get a tiiming violation (also displayed in the screenshot). Whats strange is that even though it says the timing requirement is 2.50 ns, and the total delay is 1.95 ns, that I missed the timing requirement by 0.02 ns! Either I'm missing something, or someone is doing their math wrong...   

Also posting a URL to the image code: https://docs.google.com/file/d/0B4meZgrUVk5ocUlpLU9aSnNBSFU/edit?usp=sharing Thanks for any help

[PatrickR]

Ok, I have resolved the timing violation ... it involved changing the the record size addition from +4 to a simpler increment. ... 

Now I need to figure out why the external triggering doesn't work...

[fromm8]

Hello PatrickR,

What do you mean with the external trigger doesn't work? The compilation was successful? or you are gettting an unexpected behavior without error codes? or the trigger is doing nothing?

Regards

[PatrickR]

I put an indicator on the triggers (async and sync) and ran the FPGA VI by itself.   The trigger indicators do seem to light up by it doesn't seem to make the transition from a 'Wait for Trigger' to an 'Acquire' state ...  I need to double check to logic

[PatrickR]

I tried adding a change to be able to determine the state of the acuisiiton (Idle, Wait for Trigger, or Acquire), but  now its back to the stupid timing violations.  Even after reversing that change and taking more stuff out, it keeps generating timing violations .

[fromm8]

Hello PatrickR,

Have you identified the specific node or function that is causing the error? You can use different strategies to fix timing violations.

key points to check

Regards

[PatrickR]

I figured out the timing violation ... it was strange, but I thought it made sense to change the behavior on the 'Acquire' state from 'Idle' to "Wait for Trigger' after all samples had been acquired, so the trigger would not have to be rearmed ...  but apparently this causes a timing violation.  

The external trigger problem was in the host code ... the trigger wasn't being "armed" in the case of external trigger so the FPGA was never got to the the 'Wait for Trigger' state.

[PatrickR]

Ok, I'm a bit stuck with the external triggering.. I added indicators and you can clearly see them turn on and off.  Whats strange is, this will only work unless the triggers are always high logic level.  Even a 90% duty cycle, causes a FIFO read timeout at the host.  Since the host has tto re-arm the trigger anyway, I don't see how adding the external triggering could cause a timeout.   I have attached two screenshots of the logic.  

[fromm8]

Hi PatrickR, could you point me to that example that you are modifying (LabVIEW example finder)? 

[PatrickR]

The FlexRIO examples.    Path to the examples should be something like:

C:\Program Files (x86)\National Instruments\LabVIEW 2012\examples\FlexRIO\IO Modules\NI 5772

I am modified the Clock Select example, but the two FIFO idea comes from the TIS Mode Enabled example.

What I can't figure out with the TIS Mode Enabled exampled, is if 200 MHz loop is trasffering 8 samples per loop iteration, and the 100 MHz is transferring 8 samples per iteration, should the Target-Scoped FIFO that transferrs the data between them time out ?

I am trying to redesign the example, so that instead of collecting N samples, them stopping, it will collect N samples, then go back to Wait For Trigger, and collect another N samples when it gets another trigger.   It will keep doing this, until a user defined trigger count is exceeded.   Sort of like how the IMAQ camera interface works (esp. with a line scane camera, with only one dimension, so you get essentially two dimensional data (with one channel),  S(sample, trigger) although this must be flattened to one dimension because of the Host interface.

I do have it responding to an external trigger now, but am having timeout issues... will post more later.