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