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

[RVallieu]

I have some LEGACY code utilizing Legacy DAQ in LV 8 and I think I understand what the code originally attempted - using a wheel like an optical encoder, but with only 3 or so large openings the system used the Rising and Falling Edge of the Chopper Wheel signal into the GATE and SOURCE of the Counter.  They set the counter up to do a Single Pulse Output, and it looks like it is using the Chop Wheel edges to start and stop the output pulse, retriggered.

The physical wiring I see on the drawing has the Chop Wheel input wired into Counter Gate and Counter Source.  It is also wired into the Gate of two other counters so that it gates their basic Counter Tasks (already recreated in DAQmx).

I'm not sure I am aware of all the DAQmx functions to perform this set-up and task in DAQmx.

This is on a PXI-6608.

Uploaded Image of code and actual code - broken run arrow is due to broken driver install on VM machine running Windows 32-bit and LabVIEW 8 With Legacy DAQ installed so I could look at the code and try to use the DAQ help files.

Traditional DAQ 7.4.1f4

Going to Windows 10, LabVIEW 2015, 32-bit DAQmx

[Kevin_Price · Accepted solution]

As a counter old-timer, I thought this was going to be reasonably straightforward.  Unfortunately, these counter vi's didn't look nearly as familiar as I expected.  A little digging around and I learned why.  

I'm pretty sure the only time I used those counter vi's with the "123" icon was for one specific app that used a 10-counter ISA board back in the 90's.  By far, I predominantly used the "STC" icon vi's for E-series boards and "TIO" icon vi's for 660x dedicated counter boards.  So, bottom line is that I don't particularly recognize what I'm seeing.   I'll give it a shot anyway.

This legacy code wasn't run on a 6608, was it?  Do you know what board it ran on?  These days, a pulse is defined in terms of having an initial delay before the pulse occurs.  I'm not certain that was always true for the very old legacy 16-bit counters that needed those "123" icon vi's.   So I'm not sure what behavior the old counter would have had.  But let's march onward nevertheless.  Please note however that I don't have trad NI-DAQ installed, I'm gleaning what I can from the diagram constants and screenshot.

1. The 1st "Mode Config" vi is a good place to start.  A 'timebase source' of "no change" seems to suggest that it will use the counter's default source pin as a timebase.  Makes sense considering that the polarity comes from 'Chopper Source edge' and that the wiring diagram connects chopper wheel signal to counter source.

   However, the gate config looks wrong to me.  It appears to try to use a signal edge for gating.  But in pulse generation mode, a gating operation would normally be like an enable signal and should be set for either "high level" or "low level".   

   The only other possibility might be if the gate signal were used more like a trigger, but if wired to the same signal as the source, it wouldn't be particularly useful.  I don't see other code to suggest that triggering is intended, but again, I'm not so familiar with the "123" API.

   Barring further info, I'm supposing that the gate config is a red herring and has no effect.

2. The "Pulse Config" vi seems to partially overlap with the "Mode Config".  We now explicitly identify the timebase source.  Period one and Period two define the # of edges from the timebase source for each state of the pulse (high and low, not necessarily in that order, may depend on specific behavior of that board's counter type).

3. The "Control" vi in the loop which queries output state seems to be looking to terminate the loop when the pulse goes low.  That in turn seems to suggest that the initial behavior of the counter is to go to high state for "period one" ticks.  It will then go low for "period two" ticks, but the loop may terminate before all those ticks have been seen.

So with all that, my first shot at the DAQmx equivalent looks a lot simpler than might be expected:

-Kevin P

[RVallieu]

I believe it did run on the 6608 as that is how it was written and all the code notations indicated it was a PXI-6608.  I do believe that used the input signal from the chopper to trigger the start of the pulse, as the physical opening is needed to be in place to allow the test article beams to traverse and trigger another counter.

[Kevin_Price]

It seems odd to me that they would use the same chopper wheel signal as both trigger (gate edge) and timebase source.  I don't see how that would accomplish anything.   The place where it *can* accomplish something is if the chopper wheel had both an "encoder" signal (multiple cycles per rev) and a "z index" signal (one cycle per rev).   Then using the z index signal as a trigger lets you place your reaction pulse at the same rotational position.

Another thing is that you described the chopper wheel as having effectively 3 block/pass cycles per rev.  Meanwhile, the reaction pulse appears hardcoded to go high for 3 edges followed by going low for a variable # of edges.  It won't be able to be retriggered until both "period one" and "period two" have completed.  It seems that'll always be more than a full rev.  Further, unless "period two" is also a multiple of 3, consecutive pulses won't correspond to the same rotational position.  And if that's not important, why trigger?

I don't recall how to set a parameter like "initial delay" under trad. NI-DAQ and I don't see any code to suggest it was explicitly configured.  I don't recall how or if pulse retriggering was supported with those "123" vi's,  but I get the idea that it would functionally make sense if this reaction pulse did indeed keep retriggering and repeating.

There's also a difference in behavior for retriggered pulse generation under DAQmx vs. trad. NI-DAQ.  The linked article isn't the final word though.  I can't find the followup just now, but a more recent version of DAQmx brought in a property to make the delay behavior for non-1st triggers configurable, though I'm not confident that the 660x boards support that property.

I'm starting to arrive at the idea that maybe a literal translation of the trad. NI-DAQ code isn't the best way to arrive at the needed functionality.  Probably better to derive DAQmx code from scratch based on a clear functional & timing spec.  I'm guessing though that you're stuck with old code, no working system to observe and measure, and code translation *is* your method to try to create a spec.

Anything else to go on?  Any idea how triggering was thought to be helpful?  How is that gating signal used on other counters?  What function are they serving?   Basically, what other clues are there for how this counter function fits into the overall system?

-Kevin P

[RVallieu]

I have asked the HW owner with the most history knowledge - right now system isn't running.  Original developer is long gone!

Now that I think about it you are probably correct - I can see triggering on an edge of the opening to start the pulse and then knowing how long the pulse should be based on part 1 and part 2.  I'll update when I find out more on the actual physical wiring.

The gating signal is used on the other counters to allow them to count things getting through the openings in the chopper wheel - the counters should only run when the opening is in front of the detector.

[RVallieu]

The chopper wheel signal is generated using an LED and a photodiode that are mounted on opposite sides of the chopper wheel – when the chopper wheel is blocking the LED, the photodetector sees no light, so no signal is generated.  When it is not blocked, the detector sees the light, and generates a few-V signal.  There are three equidistant slots on the chopping wheel.  As the wheel rotates, and the slots rotate through the LED/photodetector assembly, a square wave signal is generated. 

The motor on the chopper doesn’t have an encoder or anything more sophisticated than the above.  So the software has to time everything off that square wave signal.

__

Thus this needs to retrigger to capture the edges of the three different areas and keep triggering on the opening edges.

Ryan

[RVallieu]

Hmmmm

Maybe this is the answer!

http://digital.ni.com/public.nsf/allkb/4A9AF19480E50C6D862571B70058142A?OpenDocument

[Kevin_Price]

I hear you, but that info doesn't help the code seem more sensible to me.

Using the photodiode signal as a gating signal for the other tasks *does* make sense.  Use it to triggering from an arbitrary "next" edge (whichever one it may be), followed by counting more than 1 rev worth of edges to make a delayed pulse, and then retrigger on a possibly different edge?   That doesn't make any sense to me.  Honestly, it sounds like it was programmed wrong, but in the particular kind of wrong way that was still usable for the real purpose.

In the scenario above, re-triggering accomplishes nothing apparent to me.  You'd get the same pulse train output without any triggering, simply from defining the pulse train to be based on edges of the photodiode.

Just because it *was* configured that way, I'm not convinced it *should* have been.  I see no functional purpose for it and am not at all sure it ought to be replicated during code migration to DAQmx.

You seem to think the triggering is important though.  What's the line of thinking that I'm not seeing?

-Kevin P

[RVallieu]

Ah duh - yes if it was just told to start and output based on the incoming signal then retriggering is not needed since it is a continuous task.

I am going to test this implementation on a non-PXI card and see if it works for us.  Thanks for talking it through.

[RVallieu]

The implementation I linked somewhat works - a pulse train is generated only when the gating signal is "high" (the simulated signal of the chopper wheel is showing the open space.)  The problem is the output pulse is not the width of the chopper wheel signal, and also when it pauses the counter is not returning to Low output, it is sticking at High.