LabVIEW 8 Legacy DAQ - Counters, Upgrade to DAQmx 2015, PXI-6608

[Kevin_Price]

I don't have LV on the PC I'm on so I'm going by memory.

I don't understand what you mean when you say that a pulse train is generated only when the gating signal is high.  What I recall of the config was that the chopper wheel was also the timebase source for the pulse generation, and it would require a *minimum* of 6 chopper wheel cycles (2 revs) to produce a single output pulse cycle (3 ticks high, 3+ ticks low).  So when one pulse cycle requires 6 cycles of the signal that's used as both timebase source *and* gate, I don't understand what's meant by saying that the pulses happen when the gate is high.  The gate cycles many times within each pulse.

What is the functionally desired behavior for this troublesome pulse generator?  What do you want it to look like on a timing diagram, relative to the cycles of the chopper wheel? 

You mentioned before that the chopper wheel signal is used to gate some other tasks in a way that sounds like what DAQmx calls a "pause trigger", which is sensitive to the signal's digital state (high vs low) rather than being sensitive to transition edges.  That makes sense to me.  But this 2+ rev per pulse counter, set up to use the same signal in an edge-sensitive way?  Still don't see what that's supposed to accomplish.

-Kevin P

[RVallieu]

I have a little better understanding now - they are using the number of edges of the chopper wheel to keep the output  pulse high.  During the configuration of the test set-up they pick the "duration" that the task should collect data - this is controlled by the number of edges that the Single Pulse (Phase 2) is held high which is the number of edges the signal source (chopping wheel) is putting into the Gate and Source Pins.

So the Output Pulse should Start Trigger on the Desired Edge (Rising) and then 3 timebase source edges Phase 1 would be the low phase, then Pulse should go high and stay high (Phase 2) for desired number of timebase source edges (again generated by the chopping wheel).  I believe they did it this way because they couldn't set a number of edges to count to terminate the task.

I got the code to generate a single pulse output using Time - but I had to use Finite Retrigerrable with Start Trigger.  I am now switched over to Counter Output Ticks (DAQmx) where Phase 1 = 3 = # Low Edges and Phase 2 = arbitrary (just setting a number for testing) = high edges to hold signal high.

I am not getting and Error, but now it is not generating the pulse out...trying to verify my code.

When I did Continuous Output the code generated an output PWM that was not being held high for X number of Edges.

[Kevin_Price]

Still away from LV.   And it still sounds like the old "123" API edge-gating or new DAQmx triggering are at best irrelevant.

Scenario 1 - supposing trigger and source edge are both active on rising edge from chopper wheel:  

   There may be a signal-level race condition between whether the edge that trips the trigger will also register at the source to start counting.  So from the moment the task is started, the 1st rising edge trips the trigger.  Either the 1st or (probably more likely) the 2nd rising edge will start counting (in service of pulse generation.  The internal count register actually decrements toward 0).  Had there been no triggering setup, the 1st rising edge would always start the counting.

   Since there isn't anything unique about any of the 3 chopper wheel openings, all that can be accomplished with triggering is to probably but not definitely delay the counter pulse by 1 chopper wheel opening.

Scenario 2 - trigger edge is active rising while source edge is active falling:

   Same net effect.  If task is started while chopper wheel is in low state, it triggers on the 1st rising edge then starts counting on the 1st falling edge.  If started while chopper wheel is in high state, 1st falling edge is ignored (b/c task not yet triggered), 1st rising edge trips trigger, and 2nd falling edge starts counting.  Had there been no triggering setup, the 1st falling edge would always start the counting.

   So again, the trigger causes the the counter task to maybe or maybe not delay by 1 chopper wheel closing.  Likelihood of which thing happens just depends on the relative sizes of the blocked and unblocked parts of the chopper wheel.

   Whatever would have been accomplished by configuring for retriggering can be more consistently accomplished with a continuous pulse train based on edges from the chopper wheel.  

---------------------------

Now then, on to your specific observations.

1. no pulse out seen with ticks-based single pulse output

   No real particular idea, guess I'd first try edge-counting in MAX to make sure the edges look "countable" to the counter.  

2. continuous output not holding high for expected # edges

   What's the code look like for this?   Is this a tick-based continuous pulse train?  If so, this case of unexpected output might give clues to how to fix the lack of output from the single pulse. 

-Kevin P

[RVallieu]

Your original suggestion was correct on the implementation - it is not a retriggerable task - I took that part out.  The Start Triggering is also not needed, as you noted.  That was an incorrect assumption/understanding on my part.

The Start Trigger being on the Gate Signal does work and starts and counts the appropriate number  of edges, but like you posted, is not needed.

The Idle State is needed Low at the start - Phase 1 is Low, then after 3 chopper rising edges the CTR output goes high and stays High for N number of Chopper Edges.  It is working properly.  The WHOLE task is then Restarted with a new Phase 2 number of edges for the next sample set.  This is where I thought it might need to be retriggered, but it just requires a new Start Task with a High Ticks property Node before it to adjust the High Ticks based on the experiment set-up.

Thanks for the discussion and help!

Edit to add: Looking at the LV help and the original code - original developer used the CTR Mode Config VI according to the LabVIEW help so they could set Mode 5 (Counter Output) allowing the code to be able to switch between using Rising Edge or Falling Edge Triggering.  Otherwise the CTR Pulse Config would always assume Rising Edge.  Gating is not pausing anything in this instance.  I don't know that they actually utilize this but I will try include it in the DAQmx code since it is configurable

[RVallieu]

The only difference that should be noted (and it is documented online by NI) is the difference in functionality between the Legacy DAQ delay and Phase 1, Phase 2 implementation vs the DAQmx implementation.

Since this is a single pulse and the old system did 3 Source Edges for Phase 1 (low) and then went high for Phase 2 for N source edges, the new code needs to use Initial Delay (as in your solution).  The Low Ticks are added at the end, which is fine and in this case doesn't affect the application.  The Gate settings in the Legacy are to control which edge to count on, Rising or Falling on the Gate Signal, changing the edge that is used by the Ticks for Phase 1 and 2.  The Gate also controls when the pulse output task starts - on Rising Edge or Falling Edge - hence the thought for the Start Trigger setting in DAQmx referencing the Gate Channel as the source of the Start Trigger.  The old system could start on either edge - so the new system should as well.  This works fine.

I do not see how to change the reference edge for High Ticks and Low Ticks - Is this even possible in DAQmx?

[Kevin_Price]

Scattered notes/comments as epilogue:

- DAQmx and your board will allow you to use 2 Ticks for a pulse phase if you so desire.  The old API forced a minimum of 3 b/c it was designed to support a very old counter chip that must have had that restriction.

- Maybe you misspoke, but the Gate settings in the legacy code do not relate to counting, per se.  Only Source edges get counted.  The Gate input could act as a trigger, as a sample clock, or as an enable signal.  But the internal count register is only affected by Source edges.

- Tiny little tip: since you'll be firing off single pulses iteratively via software, initial delay ticks will always need to be defined.  Then depending on the chosen pulse polarity (you mentioned wanting to keep this configurable, I believe), only *one* of (high ticks, low ticks) will be used.

   Since this will be variable from pulse to pulse, I'd recommend you wire it to both inputs.  One of those inputs will get ignored anyway, but this way you don't need extra logic to decide where to wire that value depending on the chosen pulse idle state.

-Kevin P

[RVallieu]

I can only go by the Legacy DAQ help for CTR Mode Config.vi

Gate Parameters:

Gate Mode: 4 = Rising Edge.  The Counter Counts when the gate goes from Low to High and continues according to the config mode. (config mode in our Legacy is Generate Pulse, Chopper is wired into the Gate).

5 = Falling Edge.  The Counter Counts when the gate goes from High to Low and continues according to the config mode. (config mode in our Legacy is Generate Pulse).

Source Edge: Specifies whether the counter counts on the rising edge or the falling edge of the Timebase Source (in our case this is the Chopper Signal)

___

So it sounds like the Gate Mode is really just the Start Trigger, but Source Mode definitely allows you to select which edge to use for the Tick Count setting.  I don't see how to do this part in DAQmx.  The Legacy Code I uploaded combines these two and allows to start on falling edge and then count on falling edge, or start on rising edge and count on rising egde.

The High and Low of the Output Pulse are not changing - sorry for being unclear.  The order is always the same in the old Legacy Low was first (according to the help file I am looking at, phase 1) and High was second (Phase 2).  I am going to stick with 3 pulses for the Low since that is how the old system was configured and we want similar timing for the new data sets.  Therefore I won't be changing the Idle State - it will still be set to low all the time so that the first part of the Pulse is low for 3 edges (DAQmx Initial Delay) and the output stays high for N pulses. 

Legacy: N (high source edges) is configurable, Gate (Start Edge) is configurable, and Source Edge to count on is configurable.

DAQmx: N (High Ticks Source Edges) is configurable, Gate (Start Trigger Edge) is configurable.  The only thing missing from the DAQmx implementation now is the Source Edge to count - rising or falling.

[Kevin_Price]

You're right, the old DAQ help isn't totally clear but Gate Mode's 4&5 really *do* refer to start triggering.  Better wording would have been, "The Counter is allowed to start counting when the gate goes...".  

All my prior soapbox-y stuff comes into play here.  (See scenarios in msg 13).  All that gets accomplished by configuring a trigger, either polarity, is to add more uncertainty to the delay before starting the counter output pulse.  Just configure an untriggered pulse task and you'll get equal or better consistency.  (Granted, achieving this "consistency" may be a pyrrhic victory, as the whole business starts from when the software calls DAQmx Start, and that probably has *no* correlation to the instantaneous position of the chopper wheel.  But again, as I keep saying, triggering the pulse from the chopper wheel signal doesn't really help.)

Setting polarity for the Source edges is less obvious under DAQmx, but it's definitely possible.  You need a DAQmx Channel property node.  Then pick "Counter Output->General Properties->Counter Timebase->Active Edge".  Right click to make the property write-able, then you can choose rising or falling edge polarity.

There's an amazing amount of configurability under the DAQmx property nodes, but it can sometimes be an adventure navigating the tree to find the right stuff.

-Kevin P

[RVallieu]

Thanks!  I was digging around the property node for the channel but wasn't finding the source edge selection.

I agree "starts" are not correlated when the task starts in software to the position of the chopper.  Still they want to be able to Start on either rising or falling edge of the openings and then also count on the rising or falling edge of the openings, so that is what they get 😄

The Low ticks do get used when Idle State is Low - and we set Initial Delay to 3 (to mimic the Legacy Phase 1/Phase 2 implementation) but as I noted it is stuck at the end of the Pulse which is fine, and this I can set to 2 as you noted.  I will test leaving it unwired out of curiosity.

[RVallieu]

You were right again - Low setting does nothing - always low for 2 pulses of the Gate/Source at the end after the Initial Delay and High.  Edge shifting on start and Source Edge to count works perfectly.