niDigital pattern editing options

[svl123]

Hello!

I have a PXIE digital pattern instrument which I'd like to be able to load with patterns during LabVIEW VI program execution (my program has a feedback loop which determines the next pattern based on current results, etc.) I have looked at the "Load Pattern" VI but it only accepts an input file of a specific format. I know that the digital pattern editor creates patterns that the VI can use but it cannot be used to make patterns that are edited during run-time.

What is the best approach to creating new patterns as LabVIEW is running? Do I need to open a pattern file in plain text editor, fill it with my pattern and then load the file into the "Load Pattern" VI every time? Or is there a faster/more elegant way of doing this?

On a related note, how does one make a pattern file in plain text? I tried to open one of the example .digipat files in a text editor but the file came out looking like garbage (bunch of non-ascii characters, etc.)

Thank you for your help!

-svl123

[Case_in_Point · Accepted solution]

Hi svl,

There are two basic approaches to accomplishing the goal of doing digital pattern operations determined at run-time/in the middle of test execution. The first is as you're describing, programmatically generating pattern files. The compiled .digipat files have a raw ASCII format, .digipatsrc, talked about in the help here: 

http://zone.ni.com/reference/en-XX/help/375145b/digipat/text-pattern-file-syntax/

It's pretty similar to other ATE pattern formats, if you're familiar. You would have to do text editing to generate these files, and before you can load them onto hardware they have to be compiled to the binary .digipat format. That happens automatically if you load them into the Digital Pattern Editor, but you can do it programmatically with an included executable: http://zone.ni.com/reference/en-XX/help/375145b/digipat/compiling-patterns/. Fun fact, that same program can be used to de-compile from patterns to text file. So the workflow would be, generate/edit text files, compile into .digipat, load them onto device, burst.

All that said, depending on what you need to generate, it's possible you can just use the source/capture waveform functionality. That's the more elegant way to do I/O determined during test execution. You'd include some opcodes in your patterns to load capture and source waveforms, then call the source/capture opcodes to actually generate or read in data. For generating, you can write source waveforms very simply with the API in application memory, and for reading in you query the capture memory after the fact to see what you read in. There are examples that show off source/capture, and here's some help doc:

http://zone.ni.com/reference/en-XX/help/375145b/digipat6570/source-capture/

http://zone.ni.com/reference/en-XX/help/375145b/digipat/source-waveform-config/

http://zone.ni.com/reference/en-XX/help/375145b/digipat/capture-waveform-config/

http://zone.ni.com/reference/en-XX/help/375145b/digipat/opcodes-source-capture/

Cason

NI Applications Engr.

[svl123]

Cason,

Thank you! I will study those links.

-svl123

[Jumper=Bones]

Hi Cason, the company I work for is an early adopter of your PXIe-6570 Digital Pattern Instruments. We recently procured about a half dozen of these. I currently have a ticket in your support team to accomplish a variable-timing delay feature that we need, into the user-interface of some very crude, first-try, LabVIEW 2017 code for a simple DUT "write-only" communication task using niDigital VI's. I suspect we will succeed on this soon.

But that is just part of our problem: we are not digital test engineers, we are a small crew of RF/microwave test engineers, and we need to get ourselves educated very quickly on how to master these new PXIe-6570 Digital Pattern Instruments. I chose your forum-post to place this request into, because you made the comment "It's pretty similar to other ATE pattern formats, if you're familiar."

Well, what if a test engineer is not familiar with these formats, nor the terminology (Shmoo plot?). We have come to the realization that the relationship between pins, pin-groups, channels, levels, timing, etc seem to be abstract and variable, and we are looking for resources that will drive our understanding towards mastering these instuments. So my request is simple: besides the documentation and examples that ship with the NI-Digital driver package (currently at v18.0.0), what would you recommend as resources (textbooks, training-materials, industry white-papers, anything...!) that could lead a talented and motivated crew of test engineers by the hand into the world of "ATE pattern formats" and beyond. My guess is that any replies you could offer would go a long way to helping your "non-digital-test-engineer" customers, of which I would suppose there are many. Thank you if you can help us. JB

[Neil.Pate]

Hi Cason,

Resurrecting an old thread, I need to generate the digital pattern at runtime. I have managed to get the source waveform feature as expected, and can programatically do it from LabVIEW and it all works, I can generate the source waveform at runtime.

One big problem I have though is that when my source data is "1" I do not actually want to drive my output pin high I would just like to tri-state the pin (i.e. set "X") and I do not know how to do this when using a source waveform.

Any tips?

[Cortega]

Hi Neil, could you tell me if you are usign the API for NI-Digital with LabVIEW, or which API you are usign to configure the source waveform? Also, could you share with us the code you are usign to configure the source waveform.  

[Neil.Pate]

I am using the NI-Digital API. The two screenshots show how I have it working.

Essentially I need to be able to insert "X" into the source waveform. I have tried changing the data to a "5" instead of a "1" which I believe corresponds to "X" but this did not seem to tristate the bus.

[Kevin.MN]

Hi,

I would highly recommend moving this question to a new thread to increase community visibility as well as to increase its trackability for us.

It would also be useful to know what hardware and version of NI-Digital you have installed. 

I haven't found much in the NI-Digital API to support that tristate set except the Termination Mode property. Where did you see that a 5 would force it to tristate?

Additionally, there is an opcode outlined in the 18.0 New Features that might do what you are after. Unfortunately my depth of knowledge in NI-Digital is pretty shallow at this point.

If nothing I said here was helpful, I would highly recommend migrating to a new thread.

[Neil.Pate]

Hi Kevin, Sorry for the late response I only saw this now. We did actually solve the problem in the end. As you alluded to, we were able to use an opcode to do a real-time replacement to tri-state the pin.