niScope EX Polled acquisition: Single pulse capture?

[kuchean]

I have built a rather useful digital storage scope application around the Polled Acquisition that NI furnished.

My problem is that I can't capture a single pulse from a lamp circuit. The vi always re triggers at the worst

moment and wipes the initial trace. Is there a simple way to implement a single trace mode as in the Soft Front

Panel application?

Kuchean

[dansch]

Hi Kuchean,

Even if the scope retriggers, the data will be placed in the onboard memory of the digitizer in a separate record as opposed to immediately overwriting the last record. In fact, the retriggering is all handled in hardware and is independant of what is happening in software after the Initiate function is called. That data is not pulled into LabVIEW until you call the Fetch function. You can place some logic inside of your fetch loop such that you can keep the Fetch function from getting called until you are ready (and thus overwriting the graph). For example, the polling application I posted does not call the Fetch until the acquisition status shows that a trigger occurred. In addition to that, you could use a case structure and attach a button or some other logic to tell it when to fetch the new record.

However, remember that if you are acquiring a lot of records, you will want to fetch them off the digitizer at some point to keep the digitizer's memory from overflowing. This may not be an issue in your application, it simply depends on how many records you are getting, how often they are being acquired, how often you are fetching, etc. Hope this helps!

[kuchean · Accepted solution]

Dan.

Unfortunately I do pretty badly on logic states. If it weren't for the fact that LabView is so user obsequious I couldn't

program at all. Ever since LV 5.1 I have been using the "blind squirrell occasionly finds a nut" method with ever diminishing

results. I have attached a screen shot of the best I could figure out from your explanation. Obviously I missed something.

Kuchean

[dansch]

Hi Kuchean,

Thanks for the screenshot, it helped me just realized that your particular program does not perform standard hardware retriggering. It is actually retriggering based on reconfiguring the board in software. So in that case, you cannot let the board run while holding off on the fetching of data. If you do not fetch the data in the same loop iteration, you will end up reconfiguring the board and then waiting for a new trigger (and thus a completely new record). In this particular case, you need to basically implement a loop in the signal path before the fetch function gets called, such that the loop will not exit until you press or a button or some other logic occurs (ie- a timer completes or you finish some process). In fact, I am still unsure of exactly what you wish to implement in terms of having your program just run a single acquisition.

What I assume you really want is a setting, such as a checkbox or something similar, that can be checked to tell the program to either acquire a single record and not acquire again until some button press or to run normally and just constantly take records in a loop. This can be done by adding a small loop inside your main loop that will not exit until a button is pressed. This small loop should be inside a case structure that is controlled by a checkbox or some boolean that will determine if you are in "single shot" mode or "retriggerable" mode. The small while loop will be in the single shot case and thus after you fetch a record, it will not advance to the next record until the button is pressed. In the retriggerable case, you can just pass through the signal wires such that nothing different happens.

[kuchean]

Daniel.

Now I understand some of those error messages I got early in the project. They were telling essentially me that I couldn't reconfigure the board

at times I only thought I was holding off acquisition. By the way what is in the non-visible cases? I am working on the program in between

measurements done by another engineer. If he had his way I would be doing a full emulation of a LeCroy Wavesurfer.

Kuchean

[kuchean]

Daniel.

I am having a hard time reconciling your screen shot with the layout of niScope EX Polled acquisition. It looks more like configured acquisition.

As to what I am trying to accomplish, I want to trigger acquisition only at the start of the pulse and not re trigger at the end. None of us here has

enough experience with triggered acquisition to make good use of either Hysteresis or Window triggering. Our current mode with our Tektronix

is edge trigger, single sweep.

Kuchean

[dansch]

Hi Kuchean,

That program is the niScope Configured Acquisition with Polling that I linked to you in your other thread. You can find it here. All I modified in the program is the small case structure at the back of the loop. In the false case (meaning the "Enable Single Shot" boolean is off/false), there is nothing and the error wire and digitizer reference wire are passed through. This means that the outer loop will not pause and will constantly reconfigure and retrigger acquisitions. In the true case (meaning the "Enable Single Shot" boolean is on/true), which is shown in the screenshot, you can see that there is a while loop which will execute until the "Advance" button is pressed to stop the loop. This means that you will effectively be able to control single shot acquisitions that will not retrigger your device until you press the "Advance" button.

If you truly only want a single acquisition and don't even want the option to press the Advance button, then all you need in that true case would be a boolean 'true' constant attached to the stop condition of your outer/main while loop. Thus, if you are in single shot mode, the loop will only execute once. The false case would just have a boolean 'false' constant wired out of it such that the outer loop does not stop. Hope this helps,

[kuchean]

Yep.

Helps bunches.

K