Is it possible to exit a hardware timed loop through software?

[randomguy77]

I have a hardware timed loop that is being executed with the rising edge of an encoder. It all works well, except for during high frequencies. If the magnet that controls the encoder is spun slowly it will capture every point just fine. If it starts to move too fast however, the loop will completely freeze, and there isn't a way to get it back without stopping and restarting the vi. Since the loop doesn't execute until the next pulse, everything I have tried to add a software exit doesn't work. Just wondering if there is a way where this is possible, or is it just ensure the input frequency is never higher than what the daq can read?

[Bob_Schor]

Wiring to the Stop terminal of the Timed Loop doesn't work?  If you are using LabVIEW 2016 or above, I highly recommend the Tag Channel Wire for this task, as shown here (with an ordinary loop).

 Until the Stop button is pressed (putting "True" on the Tag Channel Wire), the Read Channel continues to present the earlier, "False", value, allowing the loop to run (very fast, in this case).  But as soon as you push Stop, its value, True, will be "seen" by the Stop Indicator, stopping the loop.

Bob Schor

P.S. -- minor bug in my Snippet -- be sure to change the Stop button to the "Rectangular" Stop button.  I used an ordinary Push Button control in my example.  For Extra Points, why was this a (let's be kind and not say "Stupid") Bad Idea?  BS

[randomguy77]

I actually hadn't tried to use an event structure, was trying to do everything in the loop. That should actually work out well, as I hoping to have a timeout to stop it. 

[Kevin_Price]

I'd start by questioning the assumption that you need to iterate a loop on every encoder edge.  Why are you doing this?  What code is in the loop that needs to execute in reaction to each encoder edge and before the next edge arrives?  

Many threads here start with someone trying to make their software react to every sample individually, not because they actually *need* to, but because they went in with faulty information or assumptions about how DAQmx works.

Let's first make sure that this is the right problem to solve.  One key bit of understanding about DAQmx tasks is that they can losslessly acquire and accumulate data at very high rates while your software can losslessly *retrieve* that data in decent-sized chunks at lower rates.  Sometimes *much* lower rates.   For example, right now I'm working on a little project with 200 kHz lossless sampling, 10 Hz lossless retrieval, and 2 Hz lossy display.

-Kevin P

P.S.  New posts came in since I started my reply.  To clarify my comments, I suspect that at high speed, your encoder edges are overwhelming your Timed Loop.  It can't finish executing one iteration before the next edge comes in and wants to start another iteration.  After enough hundreds or thousands or millions of these queued-up scheduled iterations, the Timed Loop structure simply gets overwhelmed and locks up.

    Hence my question about whether you really *need* to react in software to every encoder edge.  My prediction is that no, you don't, and that in fact it was going to be an inferior method in the first place.  My prediction is that you are trying to capture some kind of software timestamp for each edge this way and use it to calculate motion characteristics.

    You'll be *far* better off with a counter task that can characterize your edge times with precision down in the 10-nanosec realm, depending on your particular DAQ device. 

What DAQ device are you using?

-Kevin P

[randomguy77]

The reason for taking data on the encoder pulse, is so the data can be directly related to the position at the capture. The loop is taking a single analog sample for every rising edge. 

[altenbach]

Your question is quite ambiguous because we don't have sufficient information. What is a "hardware timed loop"? Be very specific! What other code is also contained inside the loop and how long does it take to execute? Are you using a timed loop locked to the scan engine? Can you show us some code? Is this running on windows, RT, or FPGA?

[Kevin_Price]

You do not NEED a Timed Loop and should not be trying to execute code on each encoder edge.  My prediction was mostly on target in principle, not exactly right in all details.

If you want to correlate encoder position with analog sampling, you can do this using buffered DAQmx tasks.  For example, just configure an analog task to use the encoder signal as its sample clock.    Sampling happens precisely at each encoder pulse, the DAQmx driver buffers these samples in the background for you, and you can retrieve them in bigger chunks less often.

-Kevin P