Counters on 6014 become 'linked' using daqmx

[dacad]

The Scenario:   I have inherited a test system running LV 8.6 on an XP box with a 6014 daq.  The system controls a pump motor, two solenoid valves and other misc paraphernalia.  Recent work on revising the pump motor found some portions of the testing were not being performed correctly and an audit found several tests were not testing to the required protocol.

The Setup:   The motor and both solenoids have periods where they are activated, not activated, or are pulsed/pwm'd at different points in the sequence.  The motor is driven by an analog output controlling an ssr.  A steady output voltage is used when the motor runs continuous and a square wave drives the AO when a pwm control is required.

The valves use the two counters to control the pulsing (via ssr's) as the timing on the pulses is very critical. Herein lies the problem.

The Problem:    After I use a counter to control one of the valves (ctr0 or ctr1) when I attempt to control the other valve with the other counter, the first counter goes high during the task and returns to a low state at the end of the task.  This completely screws up my sequencing.  It does not matter which counter is used first, as soon as I go to the other counter, the first counter goes high during the task and then goes low.

The existing setup used a combination of parallel and serial ssr's and DIO's to work around this but it didn't completely solve the sequencing problems as the audit of the test sequence revealed.

I have researched and found reference to something called 'lazy uncommit' that affects the PFI's which kinda explains the problem but doesn't offer a real fix.  I have tried rerouting the counter outputs to different PFI terminals to no success (limited or no support of this on 6014 daq?)   Note that this effect does not occur when using the test panels to control the counters no matter how many times I switch from one to the other which points to something in the daqmx controls.

One:  Is this behavior expected when using daqmx to control the counters

Two:  Is there a proper software approach to correcting this condition

Three:   Is there anything else I can do that isn't incredibly complicated to address this condition.   I can expand on the multiple ssr approach to further segregate the signals to the solenoids but this is a pretty messy approach and is my last resort and doesn't really address the root cause.

Any input on the what's, why's and how's for this are appreciated.  I have attached the vi I use to control the counters for reference but it is pretty boiler plate stuff in my opinion.

Thanks....   Doug

[Kevin_Price]

Just some educated guessing and ideas as I don't have similar hardware for testing.

I think that yes, the "lazy uncommit" is part of the problem.   I suspect that the other part of the problem is that you are configuring your counter output task for finite sampling, i.e., a finite pulsetrain with a hardware-controlled # of pulses.  When you do that, the paired counter is also used behind the scenes to "pause trigger" the counter whose output you're using.  Combined with "lazy uncommit", the single pulse it generates to act as a pause trigger shows up on the output pin.

I have a two part idea for you to try.  The first part is fairly straightforward.  Instead of letting DAQmx *implicitly* use the paired counter as a pause trigger, you're going to *explicitly* set it up to behave in the same way.  The importance of this step is that you will have a separate task refnum for the paired counter that lets you do the other config stuff.

In short, you'll configure the counter that drives the solenoid as a continuous pulsetrain.  You'll need to configure it to use the paired counter's "internal output" as a pause trigger.  The pause trigger polarity should be set to pause when the paired counter is in idle state (guessing low, but may depend on your external wiring).  You'll start the active counter first, but it will be "paused" until you create a single pulse with your paired counter.  The duration of the pulse needs to be exactly the time needed to generate the correct # of pulses from your active counter.   After the paired counter's pulse is done, stop the paired counter before stopping the active counter.

The second part of the idea involves a subtle technique I've read about here, but haven't had need to try it, and don't know for sure whether it's universally supported by all boards that support DAQmx.  When configuring the paired counter's single pulse, there are properties that let you route the "internal output" to various possible PFI pins.  If the terminal name you feed in as the routing destination is an empty string, that *should* prevent the paired counter's output from reaching any pins on the terminal block.

<time passes, including a bit of time to whip together a quick example>

Here's something I threw together pretty quickly to show the idea I mean.  It ran without error using a simulated E-series device that has the same counter chipset as your 6014.  Try it and verify that (1) it suppresses the output pulse of the paired counter at the terminal block, and (2) it generates the specified # of pulses from the active counter.

-Kevin P

[dacad]

Have not had time to try this yet and I want to take the time to wrap my head around it before I would implement it.  In the meantime, I have been able to use a simplified combination of hardware and a counter state control funtion to get me going.

Thanks for the example.

Doug

[Brad_K]

Kevin's explanation is correct. Here's some more background and another potential solution:

"Lazy uncommit" is designed to prevent unnecessary output transitions when repeatedly starting and stopping the same task. If you would like to tristate the output terminal when you're done using it, you can do so by calling DAQmx Tristate Output Terminal VI after clearing the task. Note that you can read the CO.Pulse.Term property instead of hardcoding the terminal name. The NI 6013 has pull-down resistors, so if the output state is high at the end of the task, tristating the terminal will cause a output transition.

Another alternative is to use this VI to explicitly tristate the paired counter output terminal before creating a finite pulse train. This might require hardcoding the terminal name, though.

Brad

[ForrestGan]

Hi, 

    I am facing the same problem.

    I use the counter to generate pulse train to drive two step motors. But due to the second counter's state change, If i move one step motor, the other one will move a few steps.

    you mentioned you used a combination of hardware and counter state control to solve the problem, would you please share more detail?

Thank you very much!

Forrest

[Kevin_Price]

I think pretty much all the detail you need is right up there in msg #2.  That was why I linked you over to this old thread from the new one you just started.   The discussion should really stay over there where you've identified your *actual* DAQ board as a 6030E.

-Kevin P