09-05-2010 09:12 AM
Hi,
Im using the 6133 card with the following configuration:
Counters is used for a pulse train generation of 32 pulses in Mach.
This is a re triggered configuration where the input is from a RTSI cable from a 6602 card.
Ctr0InternalOutput is connected as external clock for an analog input task.
The application of the the analog task is waiting until available samples per channel is greater then 16 and the read the samples in the buffer.
The problem is that very often I get that the available samples per channel is 0 although I see on a scope that counter0 output is the 2Mhz clock.
When this is occur I stop and start again labview and all DAQmx VIs return status OK but available samples per channel is still 0.
What solve the problem is reset device in the Max.
One point to mention is that this application worked about 2 years without this problem.
Last month I upgrade DAQmx from 8.6 to 8.9.5 .
I don't know if its because of this but this is the status.
Any Idea what can cause this sporadic behavior?
09-06-2010 08:46 AM
HI,
Sorry for the typing error
"Counters is used for a pulse train generation of 32 pulses in Mach."
should be: Counters is used for a pulse train generation of 32 pulses in 2MHz.
09-07-2010 12:59 PM
Hi barak,
Looking at your block diagram, you do not call DAQmx Clear Task at the end of each session. This releases the resources used by your computer to run these tasks, and allows them to be reused for later runs of the program. Make sure though that you clear both tasks after you finish. There is an example in NI Example Finder called Multi-Function-Ctr Retrigg Pulse Train Generation for AI Sample Clock.vi which uses two threads to generate a user defined sample clock for AI. The important thing about this example is to notice how they handle the tasks after the initiate vi.
09-08-2010 02:50 AM
Hi,
The diagram is only part of the full application.
I do Stop And clear for all my tasks at the end of the reading loops.
Does this related to the fact that some times I get 0 at the available samples per channel property?
Can you please elaborate what are the terms for this property to be zero?
Another thing that I noticed is that after the reading buffer is full for some reason, this property is 0 all the time but there
is no error coming from the property node control.
Thanks for your help.
09-08-2010 04:19 PM
Hello,
Looking into it a little bit more, it is interesting to note that your program worked for years and now it does not. This could point to a driver issue, with the update to your software. We can start troubleshooting a little further with the current software, but a driver upgrade might provide different results for us.
For troubleshooting, have you tried changing the clock to the onboard clock and seeing if the property starts displaying counts properly? What value are you plugging into the DAQmx Read VI as the samples to read per channel?
Did you say that resetting your device causes your board to start behaving correctly? How intermittent is the error?
09-09-2010 04:48 AM
Hi,
Regarding the driver: I upgrade DAQmx from 8.6 to 8.9.5.
This error doesn't happens a lot, once in few days/weeks.depending on the production quantity's.
I haven't tried to change the clock to the onboard clock but I will try it next time I will have the error.
To the DAQmx Read VI as the samples to read per channel I insert : Available per channels in multiplier of 16, for example if there are 17 I read 16, if there are 34 I read 32.This is because of a known issue (approved by NI) of reading the samples in quantities of 16 using the 6133.
Can you please explain what are the terms where this property return 0?
Thanks for your help.
09-09-2010 09:26 AM
The terms for that property returning 0 is that no samples are available to read. This could mean your sample clock is not causing the board to read samples. Using the onboard clock will verify that the read is working as expected, and samples are being taken. Since it is intermittent, it is hard to say why the counter sometimes does not cause samples to be counted. The latest DAQmx driver is 9.2.1, and it may be beneficial to upgrade further depending on the version of your software.
The fact that it can go weeks without this error is interesting. These kinds of errors also make troubleshooting a bit difficult. Intermittent errors sometimes point to the physical realm of things, so make sure the environment noise affecting the card is minimized. Is there any other outside factors that could be affecting the board?
09-09-2010 11:04 AM
Hi,
In my application I also use VISA to read data from a serial port.
Does it can be related to this?
Noise we might have from the linear motor we have,How does noise can effect the clock? And if it effect I assumed it can cause for loosing one or more samples and not freezing the device.
I will upgrade the daq mx driver next week,
09-09-2010 02:02 PM
Hello,
The property is being used by NI-DAQmx, and VISA has its own driver, so the two will not correlate.
Noise can cause the clock to become out of spec, which can throw errors or cause issues on the hardware level. It was an idea, but since you mentioned the error is intermittent, it may be difficult to test and see if the error goes away by turning off the motor for a period of time.
As far as upgrading DAQmx, what OS are you using and what version of LabVIEW you use will determine how far you can upgrade. If you have XP or above you are fine. If you have LabVIEW 8.5 or above, the most recent version of DAQmx will work for you.
09-28-2010 03:34 AM
Hi,
It's happened again and i did some more tests.
In my application the first indication for the error is where AvailableSamplesPerChannel property return 0.
Then I'm doing the following to debug this error:
1) Closing my application and LABVIew.
2) Open test panel
3) Try to sample in all 3 modes (Finite,On demeaned and continues)
and I get the following error: err1 file attached
4)Then I Tried the digital I/O and Counter I/O in the test panel and there are no errors.
5) The self test is PASS
6) After reset device is activated the sampling is OK.