Counter Output or Input and re-arming

[jdragano]

I have the following issue: I'm reading an encoder (quadrature signal read with a counter input task) which tracks a sine wave. I want to ideally start triggering and reading for n periods where every acquisition starts on a peak of the sine wave

I know the following to be true: I need to arm the CI task. I then need to trigger it. 

The triggering itself occurs with a counter output. And herein my understanding falters. Since it is a counter task, it also needs to be armed (may not be true)[arming it seems to trigger it immediately too]. Is it sufficient to start the trigger vi and not configure its arming (in does telling it to start trigger on a rising edge arm it too?). 

Perhaps I shouldn't be using a CO trigger but configure it with a digital output? My goal is to pause the trigger when a sine Valley is detected and restart when a peak is detected - so my understanding which I welcome correction on is that the procedure is:

1) start CO - Arm it. 

2) arm trigger

3) start trigger to start acquiring. This starts CO trigger task

4) pause trigger

5) re-arm everything? Or do things only need to be armed once when a trigger is paused (even a counter output based trigger?)

[Kevin_Price]

I'm a little confused by your description of things.  Can you sketch up a little signal timing picture to illustrate and provide more detail about what you're looking to do?  If you really do end up needing to coordinate CO pulses, Encoder capture, Arm Start triggers, and suchlike, I'm one of the folks around here who can help.

My understanding is that you are tracking a sinusoidal motion with an encoder.  In some manner, the time from sine peak to sine trough is of interest to you, while the time from trough back to peak is not?

Do you have any additional signals to indicate when the motion is at a peak or trough?  If not, this can only be an exercise in software post-processing.  And once it becomes *that*, it's relatively easy to capture continuous motion data and discard the portion you don't care about.

The possible problem I anticipate for your plans about triggering is that the "peaks" and "troughs" can only be discovered after the fact by examining the encoder data.  There doesn't seem to be any independent signal  to identify those points in space (or time).

-Kevin P

[jdragano]

Just the person I was hoping for!

I've attached a schematic that hopefully explains things. I can also attach VI's if that helps.

When I refer to the 'Discrete Position Counter Input Vi' I mean a structure along the sort provided in this example:

https://forums.ni.com/t5/Example-Code/Synchronize-Encoder-Counter-Input-and-Analog-Input-with-DAQmx/...

My sources of confusion are mostly tied to what actually needs arming, and when.

Clarifications and general notes:

1) What I ultimately care about is that all of my 'discrete' position measurements at the same continuous position location

2) I can't solely rely on my continuous pos readings, hence the need for the discrete readings (synched with multimeter readings). I don't care when the continuous readings start or whether they're synched, just that they start first.

3) The green area is where I face as conundrum - pausing the trigger tasks, or stopping and restarting things. My concern with pausing is whether or not I will continue to have synched multimeter and continuous position readings. I admit a severe lack of understanding.

[Kevin_Price]

I actually think I'm even more confused now.

- What is the "Multimeter Aperture" signal?  Do you control it?  Or do you have to react to it?  In what way do you consider it to be "synced" to the continuous pos readings -- I'm not seeing it?

- What do you consider to be the purpose of the thing you call the Master trigger, that you (presumably) intend to generate?

- And what's supposed to be the timing relationship between the "Discrete Position Trigger" signal and anything else?  Is this meant to be an external sample clock, driven directly by one encoder channel, but only active while the Multimeter Aperture signal is in high state?  That's all I can figure from the pic.

- Are you actually trying to double-capture the encoder position, once as a fully continuous signal, another time intermittently where you capture some and ignore some?   Why?   What's the purpose here?

I have a hunch that you're getting a little lost in terminology especially as it relates to arming and triggers.  But I think the bigger issue goes back to something I mentioned in msg #2 -- the peaks and troughs are not associated with any kind of signal that can act as a trigger.  They are simply position data whose peaks and troughs can only be discovered *after the fact* as you retrieve data from your task and analyze it.  By definition, you can't recognize that you reached a peak or trough until *after* you pass it.

What's the overall big picture here?  What's *useful* about chopping this up into intermittent chunks?  Is there any reason it needs to be done in near-real-time, or could you just do all of it in post-processing?

-Kevin P