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

[Kevin_Price]

---

@RVallieu wrote:

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 

 Gotcha.  I concede.  Sometimes easier to give them something useless that they asked for than try to persuade them they don't need it. 

-Kevin P

[RVallieu]

Kevin,

Follow-up - deployed system - all DAQmx upgraded code (more than just this one!) was working perfectly.  Happy customer.

Thanks for the help.

[RVallieu]

Further Follow-up!

Customer is getting the hw finally back together.

We have two counters that generate output pulses to gate counters that count incoming pulses from the same source.

The output pulse generators are driven by the chopping wheel (3 openings, 3 closing, equidistant).

One input counter is to count when the Chopping Wheel is not blocked (trigger on the falling edge of the chopper wheel, but it is using the generated output pulse) since Pause is set to Pause When Low.

One input counter is to count when the Chopping Wheel is blocked (trigger on the rising edge of the chopper wheel, but it is using the generated output pulse as the Gate signal).

The two Output Pulses should thus both swap high times.

The chopper wheel runs at 100Hz.

The output pulses are set to generate High for 4.5ms and low for .5ms (the time of half cycle).

When we started the task sometimes the output pulses behave nicely - and then for some reason we can't see they double in length on one of the channels.

I can upload some of the code tomorrow - but that is the gist - and here is a VIDEO of the phenomenon:  This is the last hurdle.

This is all done on the same PXI-6608 card that used to work in Legacy DAQ.

Here is a vid of the scope showing the signal behavior: https://youtu.be/Q_waN6L_zyQ

[Kevin_Price]

I'm not getting a consistent picture in my head between your problem description, the prior discussion, and the linked video.

- here you describe a pulse output based on time, 4.5 msec high, 0.5 msec low.  The earlier discussion revolved around output pulses based directly on edges from the chopper wheel signal

- the video suggests that the "right-looking" output is two pretty much square waves that are 180 out of phase.  The "wrong-looking" output approximately doubles up the pulse width and seems to slightly left-shift the timing of the low state.  Dunno where the 4.5/0.5 msec relates to the video.

Your chopper wheel may be nominally 100 Hz, but it likely has some variability and it probably isn't exactly 50.000% duty cycle.  When you define your output pulses by *time* rather than chopper wheel *ticks*, you're going line-to-line with your timing plan.  Add in the variability of the actual chopper wheel motion, and issues could arise.

The fact it shifts behavior but seems to stay quasi-stable for a while makes me suspect the chopper wheel speed itself is quasi-stable, but can vary slowly and occasionally cross some critical threshold that messes up your pulse timing.  Given what I think I understand of your description, if the same output pulse is always the one affected, there's probably a contribution from a not perfectly 50% duty cycle chopper wheel.  One state's just a little longer than the other.  That leads to just one of the counters being affected.

I've gotta say, the way it kinda looks is that the "bad output" is a case where the counter (just barely) missed its opportunity to drop low and thus it emits a double-width pulse when it catches the next opportunity.  The exact nature of *how* this might come to be isn't clear, but I have a nagging suspicion that it may be partly due to the unnecessary use of retriggering.  

This kind of skip-a-cycle behavior is something I've used *intentionally* with a retriggerable pulse as a poor man's digital filter.  It ignores additional incoming trigger edges until it completely finishes the pulse it's outputting.  So there ends up being a maximum trigger rate it can respond to.  

Your situation sounds like it's designed with line-to-line timing where the chopper wheel is likely variable while the pulse timing isn't.  Just the kind of thing where retriggering operation might lead to skip-a-cycle symptoms.

-Kevin P

[RVallieu]

Its not an exact follow-on of the original output timing discussion - that one was a different output used to time a "collection time" based on chopper wheel inputs.  It is the same system though, which is why I didnt start a new thread.  Ignore the previous timer discussion here.

I expect the issue is as  you describe - I believe since we are specifying the pulse High and Low ticks (calculated from the detected 100Hz pulse train from the chopper) and they are taking longer than the ACTUAL pulse widths coming from the chopper wheel we're seeing this issue.  You can't wire a 0 into the Low Time - it has to be some amount of ticks - customer decided 0.5 ms was good to stop collecting data at the edges come in or leave to reduce edge effects (but are not doing that at the beginning of the pulse now that DAQmx does not apply the DELAY to every pulse, only the first pulse.)

These two output pulses are tiggered by the Rising or Falling Edge of the Chopper Wheel, they are on two different CTRs on the 6608.

I did not set up the output tasks specifically calling out Retriggerable True, but I guess since it is default Continuous output that makes sense it is retriggerable.

I had tried making the total width shorter by specifying only 2 clock ticks of Low - but that really messed things up and the pulses did not align at all with the expected start edges (went completely out of phase).

You are correct the two Outputs should be 180 out of phase with each other.  Legacy DAQ had no trouble creating the output pulse this way (I am told) but I have no first hand experience with that on this system.

If I cant get DAQmx to create these signals, I might just rework the code so that the input signals use the ACTUAL Chopper Wheel Edge signals as their Pause triggers since I can set the Pause When level to Low or High.  I would then need to change the code for input timers that are used to monitor the output pulses that are being taken out and have them count the chopper wheel edges of interest.  The bad part is they lose the cut-off at the end.

Is there a way to create an output pulse on every (rising or falling) edge of an input signal but not specify the whole length?

[Kevin_Price]

I don't have a 100% clear picture of everything, so will focus on the part that *can* be clear:

Is there a way to create an output pulse on every (rising or falling) edge of an input signal but not specify the whole length?

What do you mean by "not specify the whole length"?  Are you referring to just the high time of a single pulse?  The full period (high + low times) of a single pulse?  The total length of time a pulse train will continue to generate?

A given counter input signal will need a defined polarity for its active edge.  Just rising or just falling, not both at once.  Many digital boards support a "change detection" mode that can be sensitive to both edges at once, and there's a brief "change detection event" pulse that can be exported.  The 660x boards don't support this mode on their digital io though.

Each of the two counter output tasks could be sensitive to a different edge polarity, but of course that leads to two distinct output signals.

-Kevin P

[RVallieu]

Well since specifying the whole time period for the pulse of 4.5ms High and .5 ms low is causing the issue - how can I create these output pulses one triggered on a rising edge on one counter and one triggered on a falling edge on another counter without the retriggering effect we think we're seeing on the scope.  That is what I am asking.

We want two distinct output signals, hence we're using two different output counter tasks.  One needs to generate a high pulse when the incoming Rising Edge triggers it, the other counter output needs to generate an output pulse high when a falling edge triggers it.  We can't just start a multi-cycle output based on an incoming edge, we want to reflect the actual signal coming in from the chopper, hence only outputting on a half cycle.

Specifying the whole width of the single pulse that ends up being longer than the incoming signal half pulse width seems to be the problem - I'm wondering if there is a way to not specify the whole width of the single pulse as the same as the incoming pulse.  I tried that when I shortened the output pulse Low time to only 2 clock ticks, but the "retriggering" on the next incoming edge did not work at that point.

I see that new boards might be able to do what we want.:

http://digital.ni.com/public.nsf/allkb/204538A044431C9B86257377004EB952

Basically this is what I want to do - have a retriggerable pulse (single pulse) output that has an initial delay, and we specify the high time and the delay time.

"Devices with the STC3 Timing Engine:
If you are using a STC3 based device, you can use a new property node to enable the initial delay on retriggered pulses.  This property can be found under the DAQmx Channel » Counter Output » General Properties » More » Enable Initial Delay On Retrigger. "

[Kevin_Price]

Ok, for *this* problem, it seems like retriggerable single pulses is exactly what you *do* need.

Configure them to have opposite trigger polarity but everything else the same.  Use a minimal low time and initial delay time, 10 nanosec should work.  Then set your high time to be, say,  4.9999 msec for a total period of 5.0000 msec

As far as the task is concerned, the full pulse period is 5.0000 msec.  (It's possible that your board might add init delay and low time on the first trigger to make it 5.0001 msec.  I'm gonna declare that a "don't care" and move on.  The chopper wheel signal timing is undoubtedly less precise than that.)  You should have no issue with skip-a-cycle behavior b/c the the trigger edges come in at a nominal 10 msec.  You'll be nowhere near that.

-Kevin P

P.S.  Just re-read your post.  It isn't clear without code how exactly you have your counters configured.  At a first pass, I'd think any retriggered pulse with ~5 msec period ought to work, especially if init delay is made minimal.  I didn't have an exact road map for how I thought the timing issue was arising, just a general gut feel from seeing "coincidences" related to timing and polarity.

   I now note that you mentioned continuous pulse generation.  I suspect that might be a factor at work, hard to be more specific without code.  I stand by my suggestion above that a retriggerable single pulse with 5 msec total pulse period ought to work fine, and you can select different trigger polarity for each of the two counters.  This mode should work with my 0.0001/4.9999 timing or with your 0.5/4.5 timing.

[RVallieu]

They are set up with opposite trigger edges already, with everything else the same.

I will try setting an initial delay time.

Do I need to specify the task explicitly as Retrigerable with a property node? 

I don't see why it should have an issue with 4.5 ms high time - we'd rather not miss pulses on either channel as then we can't subtract the signals evenly if one misses and one hits on the same consecutive edges.

I will have to switch back to Time for the pulse control as we had switched to Ticks and referencing the internal 100,000Hz clock which seemed to perform better, but still had issues.

[Kevin_Price]

Whenever you can post code, that'll be best.  Meanwhile...

- Agreed that your 0.5 / 4.5 msec timing should not be a problem for a retriggerable single - pulse with a ~10 msec trigger interval. 

- Yes, you do need a DAQmx Trigger property node to explicitly make the task retriggerable.

- Further, to make retriggerable *single* pulses, it's important NOT to call DAQmx Timing during the config.  You mentioned "continuous" pulses in msg #25, so I'm wondering if you've configured a pulse *train* rather than a single pulse.

- Specifying Ticks of an internal clock is no different than specifying Time and leaving it up to DAQmx & the board to figure out Ticks.

-Kevin P