problem with daqmax : counter and DIO update on the same pci-6602 with labview 7.1

[pascalcuos]

Hi forum,

I am moving my software  from old data acquisition style  to new daq max with labview 7.1.

With the Old data acquisition under labview 7.1, I have 3 subroutines, one was "Init counters and DIO", second was "run counter or DIO", third was "Close".

And I was able to run once the init, and after doing some counting and DIO, even continuous generation of pulse and at the end closing everything.

It was really working well, and was easy to use.

I try to do the same with the Daq-max, and it s clearly not working the same way. First I try to run each part (INIT, RUN, Close) separately and It s impossible to work.

Second I try to make a continuous pulse train, and until the program is running I have my pulse train, but when I stop running my program the counter stop, whitout the use of "close".

At the end, I try to run my software on a loop, but I have to make some DIO on the same board that my counter (in continuous mode) and my counter stop when I am using the DIO> Witch is not really connect.

I think, I don t anderstand everything on the new Daq-max.

Do you have some suggestion or advised

Best regard

Pascal

[Laura F.]

Hello Pascal,

I am afraid it is hard for me to understand what must be going wrong.  However, I do have some recommendations for references.  First, have you looked at the tutorial Transition from Traditional NI-DAQ to NI-DAQmx?  Also, another great getting started reference is Learn 10 Functions in NI-DAQmx and Solve 80% of Data Acquisition Applications. 

Finally, the best place to look for information about programming specific application is in the NI Example Finder which you can get to in LabVIEW by going to Help >> Find Examples.  You can then browse to Hardware Input and Output >> DAQmx >> Generating Digital Pulses to see examples of generating a digital pulse train with a counter.  If you need to find out about performing digital I/O you can look at the Digital Measurements and Digital Generation folders. 

Please let us know if we can be of more help. 

Laura

[Kevin_Price]

Pascal,

The first problem you're seeing is actually an intentional feature of DAQmx.  At the end of program execution, any DAQmx tasks created within the LV session are automatically stopped & cleared.  So when you simply run "INIT" by itself, the task gets automatically cleared before you get a chance to execute "RUN".  And if your program is stopped before you call "CLOSE", the task will similarly be cleared automatically.

I think it was a good idea even though it sometimes prevents me from doing certain kinds of debugging I used to be able to do under traditional NI-DAQ.  I like to package many of my Data Acq hw interfaces into "action engines" that store the task id in an unitialized shift register.  I used to be able to open the action engine's front panel to execute one action at a time, knowing that traditional NI-DAQ task id would be retained and would remain valid.  I can't do things that way any more because of the automatic clean up.

There are several advantages to stopping the DAQ tasks when the LV program that launched them stops executing.  Rogue tasks that continue generating signals after the LV program stops can be hazardous to test devices.  They would also get in the way of future attempts to relaunch the program and regain control of the DAQ hw.

As to the conflict between counter and DIO -- some cards share pins between counter and DIO.  I'm guessing that when you configure your DIO task, it grabs control of the I/O pins that were formerly used by the counter.  You should bring out all DAQmx error outputs because they should give you some info in such cases.

Now, it certainly is possible to run both counter and DIO tasks simultaneously on a board if you're careful to avoid pin conflict.  I find this to actually be much easier in DAQmx, especially with relatively few DIO bits.  Just be sure to identify the specific DIO lines you'll be using rather than configuring the entire DIO port.  Syntax would like like "Dev1/port0/line4".

-Kevin P.

[pascalcuos]

Thank you Laura and Kevin for your answer,
The first problem you're seeing is actually an intentional feature of DAQmx. At the end of program execution, any DAQmx tasks created within the LV session are automatically stopped & cleared. So when you simply run "INIT" by itself, the task gets automatically cleared before you get a chance to execute "RUN". And if your program is stopped before you call "CLOSE", the task will similarly be cleared automatically.
Kevin your answer is exactly what I was worry. It is what I was thinking, but all my old software are almost done the same way, and it‘s look like I need to think and learn how to use the new way.
I think it was a good idea even though it sometimes prevents me from doing certain kinds of debugging I used to be able to do under traditional NI-DAQ. I like to package many of my Data Acq hw interfaces into "action engines" that store the task id in an unitialized shift register. I used to be able to open the action engine's front panel to execute one action at a time, knowing that traditional NI-DAQ task id would be retained and would remain valid. I can't do things that way any more because of the automatic clean up.
It was very useful, yes. I have some acquisitions (with trigger) that I start and after I am not using for a long time (from 10s to 10 min) and I am doing again acquisition. Look’s like, in the new Daqmax the board is in timeout and It need to be initialized again. That’s mean I need to initialized my acquisition each time I am using it. I am not sure it will be as fast as before. We have less control that before.
There are several advantages to stopping the DAQ tasks when the LV program that launched them stops executing. Rogue tasks that continue generating signals after the LV program stops can be hazardous to test devices. They would also get in the way of future attempts to relaunch the program and regain control of the DAQ hw.
Normally when you know what you are doing, there is no problem
.As to the conflict between counter and DIO -- some cards share pins between counter and DIO. I'm guessing that when you configure your DIO task, it grabs control of the I/O pins that were formerly used by the counter. You should bring out all DAQmx error outputs because they should give you some info in such cases.
Yes, there is some sharing of DIO pin with counter on the pci6602. But none of them are used twice in my application. And in my DIO subroutine, I am using line “Dev1/port0/line4” as you say not the entire port.
I have no error on my DIO and counter. My counter just stop running, as I can see on my scop.

Best regards

Pascal

[Kevin_Price]

 I have some acquisitions (with trigger) that I start and after I am not using for a long time (from 10s to 10 min) and I am doing again acquisition. Look’s like, in the new Daqmax the board is in timeout and It need to be initialized again. That’s mean I need to initialized my acquisition each time I am using it. I am not sure it will be as fast as before. We have less control than before.

No, the board itself won't timeout and need to be initialized.  A DAQmx task can be ignored for a long time too, provided you don't stop executing the LV program that launched the task.  In the example you described, you could just make a single higher-level vi that calls INIT, then enters a loop that calls RUN each time the user presses a certain button, and then calls CLOSE after the loop ends.  As long as the higher level vi is running (looping), the DAQmx task remains valid even if you go hours or days without calling RUN.

It took me a while to get used to DAQmx, but I greatly prefer it now.  I've encountered many advantages, including some really big ones, and only a few inconvenience-level disadvantages.  I think you'll find it to be at least as fast as traditional NI-DAQ, and it actually provides you with considerably *more* control.  In time, you'll work through the learning curve too.

Sorry, no other ideas about the DIO & counter conflict.  I would only suggest testing by moving the functions to a different counter #, a different output PFI pin, or use a different DIO pin to observe whether the conflict is consistently present in all scenarios.  And like the NI folks always recommend, do the testing with shipping examples or from MAX.

Good luck!

-Kevin P.