From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Digital I/O

cancel
Showing results for 
Search instead for 
Did you mean: 

HSDIO conditionally fetch hardware compare sample errors (script trigger to flag whether or not to wait for software trigger)

I am moderately new to Labview and definitely new to the HSDIO platform, so my apologies if this is either impossible or silly!

 

I am working on a system that consists of multiple PXI-6548 modules that are synchronized using T-CLK and I am using hardware compare.  The issue I have is that I need to be able to capture ALL the failing sample error locations from the hardware compare fetch VI... By ALL I mean potentially many, many more fails than the 4094 sample error depth present on the modules.

 

My strategy has been to break up a large waveform into several subsets that are no larger than 4094 samples (to guarantee that I can't overflow the error FIFO) and then fetch the errors for each block.  After the fetch is complete I send a software reference trigger that is subsequently exported to a scriptTrigger that tells the hardware it is OK to proceed (I do this because my fetch routine is in a while loop and Labview says that the "repeated capbility has not yet been defined" if I try to use a software script trigger in a loop).

 

This works fine, but it is also conceivable that I could have 0 errors in 4094 samples.  In such a case what I would like to do is to skip the fetching of the hardware compare errors (since there aren't any) and immediately begin the generation of the next block of the waveform.  That is, skip the time where I have to wait for a software trigger.

 

I tried to do this by exporting the sample error event to a PFI and looping that PFI back in to generate a script trigger.  What I thought would happen was that the script trigger would get asserted (and stay asserted) if there was ever a sample error in a block, then I could clear the script trigger in my script.  However, in debug I ended up exporting this script trigger back out again and saw that it was only lasting for a few hundred nanoseconds (in a case where there was only 1 injected sample error)... The sample error event shows up as a 1-sample wide pulse.

 

So, my question is this:  is there a way to set a flag to indicate that at least one sample error occurred in a given block  that will persist until I clear it in my script?  What I want to do is below...

 

generate wfmA subset (0, 4094)

if scriptTrigger1

  clear scriptTrigger1

  wait until scriptTrigger0

end 

clear scriptTrigger0

generate wfmA subset (4094, 4094)

...

 

I want scriptTrigger1 to be asserted only if there was a sample error in any block of 4094 and it needs to stay asserted until it is cleared in the script.  scriptTrigger0 is the software trigger that will be sent only if a fetch is performed.  Again, the goal being that if there were no sample errors in a block, the waiting for scriptTrigger0 will not occur.

 

I am probably going about it all wrong (obviously since it doesn't work), so any help would be much appreciated!

0 Kudos
Message 1 of 6
(5,636 Views)

Hi Spinach19,

 

In the Help Document for NI Script Editor, you will find that script triggers are held if a clear is not used. It does not need to be a long pulse, but any pulse will register:

 

wait

Pause execution of a script. You can pause the script until a particular Script trigger is received or until a specified number of samples are generated.

Usage:

Pause the execution until a particular Script trigger is received:
wait until scripttrigger0

  Note If the Script trigger is received before the wait instruction then the script moves to the next instruction with the smallest possible delay. If you want to ignore Script triggers received before a wait statement, use the clear instruction.

 

 

At this point, the only thing I can tell that may be wrong is "end" should be "end if".  Otherwise, the behavior you want to achieve should be possible.  For further troubleshooting, what behavior are you seeing with your current script that is not desirable?

Kyle A.
National Instruments
Senior Applications Engineer
0 Kudos
Message 2 of 6
(5,595 Views)

Please disregard most of my previous post... after some more debug work today I have been able to achieve the desired effect at slower frequencies.  I did straighten out my script too:

 

generate wfmA

if scriptTrigger1

  clear scriptTrigger0

  wait until scriptTrigger0

end if

generate wfmA

 

scriptTrigger1 = sample error event flag

scriptTrigger0 = software trigger (finished fetching error backlog in SW)

 

However, I am still having a related issue.

 

I am exporting the Sample Error Event to a PFI line, looping that back in on another PFI line, and having the incoming version of the Sample Error Event generate a script trigger.  My stimulus has a single injected sample error for debug. For additional debug I am exporting the script trigger to yet another PFI; I have the sample error event PFI and the script trigger PFI hooked up to a scope.

 

If I run the sample clock rate less than ~133MHz everything works... I can see the sample error event pulse high for one clock period and the script trigger stays around until it is consumed by my script's if statement.

 

Once I go faster than that I am seeing that the script trigger catches the sample error event occasionally.  The faster I go, the less often it is caught.  If I widen out the error to be 2 samples wide then it will work every time even at 200MHz.

 

I have tried PFI0-3 and the PXI lines as the output terminal for the sample error event and they all have the same result (this implies the load from the scope isn't the cause).

 

I don't know what else to try?  I can't over sample my waveform because I need to run a true 200MHz. I don't see anything that would give me any other control over the sample error event in terms of its pulsewidth or how to export it directly to a script trigger instead of how I'm doing it.

 

Any other ideas?

0 Kudos
Message 3 of 6
(5,593 Views)

Hi Spinach19,

 

According to Pg. 28 of the manual for the 6548, the minimum required pulse width for a trigger is 15 ns. Next, in the NI Digital Waveform Generator/ Analyzer Help (Start -> All Programs -> National Instruments -> NI-HSDIO -> Documentation), it states that Marker Events "can be asserted synchronous to any even numbered sample within a waveform within a script." When your sample clock is configured to run at 133 MHz, 1/133MHz = 7.5 ns which is doubled to the 15 ns limit. Running faster than this will cause the Marker Event to have a pulse width below the required 15 ns which will lead to the missed triggers you are seeing.

 

The easiest solution here I believe is to oversample and use 4 samples per 1 sample of your waveform. However, if oversampling is not a viable solution, you may need to rearchitect your code. It's possible to return whether the FIFO used to store the sample errors has overflowed. If so, you can stop storing error information for further errors but rather continue to compare data and count the sample errors encountered. You will lose the location of the error, but you should be able to run at 200 MHz.

Josh Y.
Applications Engineer
National Instruments
Message 4 of 6
(5,571 Views)

JoshY,

 

Thank you! This is indeed the issue I am having... Apparently I missed this detail in the spec for the 6548.

 

It is unfortunate that I can't set the sample error event width or export it directly to a script trigger.  Either of those would make my task much easier.  I don't need the sample error event to be as wide as the error event itself, just wide enough to set a flag that a particular waveform subset had at least one error.

 

As noted in my original post, I must capture all of the failing locations in my particular application and not just the total fail count.

 

I think I'm going to try to look into a separate piece of hardware that can catch a very narrow pulse and widen it out to send back to the 6548.

 

Thanks for the input!

 

 

0 Kudos
Message 5 of 6
(5,562 Views)

Hi Spinach19,

 

I believe it's because hardware compared events are read every cycle, so this is why you cannot change the event width. Good luck with your application!

Josh Y.
Applications Engineer
National Instruments
0 Kudos
Message 6 of 6
(5,546 Views)