Erratic behaviour/results using DAQmx

[Gurdas]

Hi!,

One of our PXI based automation systems is not working as expected.

The errors we are observing:

1) Timed while loop hangs and is unable to read the clock source. The clock source is TTL pulse train coming from encoder and fed to Counter 0. When we reset the loop (or force a timeout) it continues to read the pulse correctly. The vi used for this test is attached. We tested with a hardware counter running in parallel to ensure pulse availability.

2) Wrong readings of various digital I/O. For e.g. even when a proxy is in OFF state, the software reads it as ON

3) MAX (version 3.1) got corrupted and we had to repair the same.


Pointers:

1) The above mentioned errors occur at random. There is no pattern or frequency of occurance.

2) When the hardware was first shipped to us, the controller showed erratic behaviour (while booting) which seemingly resolved when we changed the onboard BIOS battery.

3) Do you think reinstalling the OS will help? We have already uninstalled and reinstalled NI-DAQmx 7.2 without any success.

4) We have Service Pack 4 and IE 6.0 (for Win2K) installed. Are there any known issues with SP4 and IE 6.0?


System Specs:

OS is Win2000 Professional.
Development environment is LV 7.1

Chassis / PXI-1031
Controller / PXI-8184
Multifunction / PXI-6025E
Serial / PXI-8423
Connector Boards / SCB-68 (two numbers)

Any help will be appreciated

- Gurdas

[Gurdas]

Further to above post, following updates have taken place today:

1) Used the Phoenix Firstware hotkey funcion and reinstalled the complete OS. This happened smoothly.

2) We tried reinstalling drivers (Driver CD, May 04) from C:\images\NIDrivers. An error was reported. This is in the "Errors.txt" within attachment. A second attempt at reinstallation was made after rebooting. It worked fine.

3) When we ran our test software(attached zip file), the time loop code generated an error. This is the image "TimedLoopScheduler.jpg" within attachment. The test software has other digital and analog I/O which worked fine.


We need immediate help from NI to resolve this issue.

Thanks,
Gurdas

[Sean_C.]

Hello Gurdas,

Thank you for contacting National Instruments.

Have you tried reinstalling LabVIEW RT? From your error description, this seems like it is an RT error.

I see than in frame 1 of your sequence structure that you have two case structures which have empty false cases. This VI will not run until you wire something to the tunnels going out of the false cases.

Also I notice that in your VI, you configure 2 DO tasks for the same DAQ device. This will usually result in a -50103 error. Try configuring both DO channels in the same DO Task. See the following Knowledge Base for more information on this error:
http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/04bedd9e9e91ed3486256d180048116d?OpenDocument

Please let me know if you have any further questions.

Sean C.
Applications Engineer
National Instruments

[Gurdas]

Sean, thanks.

It is not an RT system. Standard Win2000.

The attached vi has been running OK (except for below given behaviour problem) until 2 days back. The fatal error occured after I had reinstalled complete OS and DAQ drivers.
I uninstalled DAQ drivers today and reinstalled them. The given VI is again running OK (except for below given behaviour problem).
The errors you mention (false case and 50103) have NEVER occured.

Behaviour problem with VI (which is actually run as EXE because host controller does not have LV development environment installed):

1) The timed loop stops responding to pulses coming from the encoder. When the timeout is set to -1, it might suddenly go into infinite wait of signal even though signals continue to arrive. This has started happening with increasing frequency. Presently it happens 20% of the total number of test runs. Each test run involves an encoder sending pulses at every 10microns for a distance of 960mm.
Now, we have done tests in which a hardware encoder pulse reader was connected in parallel to rule out encoder error.
Also, today I tested counter input function using the Test Panel in MAX. No error or infinite wait situation occured.

2) In our main VI, we have also observed wrong reading of some digital signals like proximity switches. Again, this happens only occassionally (say 5%).


Is there something wrong with the PXI controller?
Bad sectors on its HDD? Corrupt RAM?

We have run out of ideas and appreciate your help.

- Gurdas

[Sean_C.]

Hello Gurdas,

What is the maximum rate of your encoder signal? I was able see this VI "hanging" in that the front panel would stop updating smoothly, and I was left with a step graph instead of a linear increase in time. I have attached a screenshot of this behavior. Is this what you are seeing?

I was able to recreate this by wiring a 10 MHz signal to the counter source. It seems like this behavior is occuring because the code in the loop cannot execute within the period of your created Timing Source.

Can you reproduce this behavior with a slower timing source? Try wiring your 100 kHz Timebase to the source of the Create Timing Source VI. (You will probably need to right-click on the channel constant and select IO Name Filtering >> Allow Advanced Terminals to have access to this signal.) I am able to run this VI with no problems with the 100 kHz Timebase.

Let me know if you can reproduce this problem at a slower rate.

Sean C.
Applications Engineer
National Instruments

[Gurdas]

Hello Sean,

Our encoder generates pulses at 500 Hz (each pulse takes 2ms on an average).
We intend to run the time loop once in every 10 pulses (as set in my code).
Thus, the time loop runs once every 20ms (50Hz) approximately.

I guess that is very slow and thus we can safely rule out code execution time as the cause.

Best,
Gurdas

[Sean_C.]

Have you tried wiring the 100 kHz Timebase to the source terminal of your "Create Timing Source.vi"? I would like to see if this is a problem with the encoder signal. When I ran the VI, I could only stall the program be using an extremely fast timebase. When I used the 100 kHz Timebase, the vi ran fine.

Regards,

Sean C.

[Gurdas]

Sean,

I have not tried the 100KHz timebase but what I did try yesterday was using the encoder pulses to simultaneously run a counter and trigger the time loop.
My VI for this is attached. Sequence 0 and 2 in my VI are used to powerup and powerdown the motors and can be excluded from our discussion.

I have inserted a note in the blockdiagram that explains VI results and behaviour.

To restate: The encoder pulses (at PFI8) were being edge counted by Counter 0 and simultaneously acting as source of timing for counter 1 which in turn was the tick for timeloop. What was observed is that while the time loop went into an infinite wait (if my timeout was -1) or continuous timeout (if say timeout was 50ms), counter 0 continued to successfully count encoder pulses.

This, to me, strongly points that either the timing source for the timeloop is failing to do its job OR the timeloop is failing to read the ticks coming from timing source OR both are failing to do their job.

What inference can draw from this?
I guess we can rule out encoder pulses to be the issue since counter 0 does not fail. Do you think something is wrong with my PXI-8184 controller? Is this a bug?

Eagerly awaiting some answers that can help me resolve this deadlock.

Thanks,
Gurdas

[Sean_C.]

Hello Gurdas,

I have set up this VI on my system, and I cannot reproduce your error. I set the timed loop to have a timeout of "-1." When I run this VI, the timed loop never hangs. It is consistently iterating every 10th pulse on PFI8.
Have you tried replicating this problem on a different computer? We have verified that it is not your code (as it works on my system). Some things to try are:
Reinstalling LabVIEW.
Running this code on a PC.
Running this code with a different DAQ device.

Let me know your results.

Sean C.

[Gurdas]

Sean,

This is major news and I must thank you for the time you've invested.

For how long did you run the code? I see an error atleast once in every 5 runs. Each run is maximum 3 minutes.

Could you give me exact specs of the setup you used? Do let me know your setup details against each of the below specs of my setup.

I am running my code on a system with:
1) PXI 1031 chassis and PXI-8184 controller
2) The controller has embedded Win2000 with Service Pack 4
3) This is NOT an RT system.
4) DAQ board PXI-6025E
5) Serial Board PXI-8423 (used in some other part of my master code)
4) LV dev is NOT installed (however we have seen the problem even with original VI running on same h/w setup having LV 7.1 FDS).
5) DAQ driver version is 7.2 (May 2004)


Questions which you could help with:

1) Is any part of my code known to give errors in non-RT Win2000 systems? For e.g. the create timing source used for the Time Loop?

2) Could there be something wrong with chassis, controller or daq board?

I have reinstalled the complete OS and drivers but the problem continues. I cannot try this code on another PC because the system is already delivered to customer and it being PXI, the same h/w is non-compatible with standard PC. I do not have spare NI h/w to swap and check.

However, I am trying to work with NI's India office and your inputs are definitely helping me take concrete steps. I have requested them for a loaner controller to check if the problem is with the controller. Do you think I should also request for another 6025 board or maybe a totally different daq board?

Many questions for you to answer!

Awaiting your reply.

Thanks again,
Gurdas