Erratic behaviour/results using DAQmx

[Sean_C.]

Hello Gurdas,

"For how long did you run the code?"
I ran the code once for an hour with no problems. Then I ran it for shorter periods of time, about a minute each. I did run it at least 10 times without seeing any error.

I am running this code with:

1) PC with WinXP, SP2
2) DAQ board Pci-6259
3) Ran on LV 7.1
4) DAQ driver version is 7.4

"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?"
I am not running an RT system, and it ran fine on my machine.

"2) Could there be something wrong with chassis, controller or daq board?"
Yes, I believe that this is a hardware problem. Getting loaner equipment to swap out with yours will be the best way to troubleshoot this problem.

"Do you think I should also request for another 6025 board or maybe a totally different daq board?"
Yes, you should get another 6025 board so we can determine if that is the problem.

FYI... I am also in contact with the NI India office concerning this issue. Until you get the replacement HW, can you please verify that your program still hangs with the internal clock driving your Timed Loop rather than the encoder signal?

Regards,

Sean C.

[Gurdas]

Hi Sean,

I shall ask NI-India to ship a 6025 too. Yesterday, they said it will take them anything between 6-14 days to supply the loaner!! Wish this could be expedited.

1) Is DAQ 7.4 available in public? I received a copy of the latest drivers from NI local and it is version 7.3

2) "can you please verify that your program still hangs with the internal clock driving your Timed Loop rather than the encoder signal?"

I shall test this on Thursday when I am at customer site. Below are three possible permutations that come to my mind. Which of these would you like me to try?

a) Run the Time Loop with 1 KHz internal clock configured in the time loop settings. I have tried this previously and the time loop did NOT fail. Shall try it again.

b) Hard route the 1KHz internal clock to a PFI pin and then use the create timing source VI to read this and run time loop. I am not familiar with routing and readily available help/directions will save me learning time. By hard routing a mean, routing the 1KHz internally to a pin and then connecting this pin to a PFI using wires.

c) Similar to (b) but with soft routing; i.e. route 1KHz to a pin and read that pin. No wires come into picture.

3) Is there something else I need to check? Like say grounding or DAQ board settings in MAX? We have taken care but I might have missed the obvious....


Thanks and warm regards,
Gurdas

[Gurdas]

Sean,

As a confirmation for both of us, I wanted to take your attention back to my first message on this thread.

The controller had a problem from the day we received it in July 2004. It would refuse to boot up immediately after a shutdown/restart command. A wait of anythng between few mins to an hour would prove sufficient for it to get back to life. We found that when it did bootup, the time displayed by Windows was behind the actual time. This lead us to infer that the onboard battery was weak. We had already raised a DOA but decided to try a battery replacement. We replaced the battery and things seemingly normalised. We got lost in developing the application after that.

But now that I think back in detail, the controller retained some odd behaviour all this time.
At times it would mysteriously hangup (without any significant processor load)and go into such a dead state that even ctrl+alt+del would not work. The only way out at such times was to restart from the power button.

Somehow, we never thought the problem could be at NI's end (we respect your stuff tons) and ended-up doing crazy amount of recoding, rewiring and trouble-shooting in the last 3 months. It was only when we ran out of all possible errors at our end did the thought strike that it could be the controller/daq board.

I really hope we can get this resolved for there is much at stake.

Best,
Gurdas

[Sean_C.]

Hi Gurdas,

"1) Is DAQ 7.4 available in public? I received a copy of the latest drivers from NI local and it is version 7.3"
No, DAQ 7.4 has not released yet. It should be out by the end of the quarter. Actually, I am using DAQ 7.3, I must have mistyped...

"Below are three possible permutations that come to my mind. Which of these would you like me to try?"
Actually, you can wire the "/Dev1/100kHzTimebase" directly to the "Source" terminal of the Create Timing Source.vi. You will have to right-click on the channel constant and select "I/O Name Filtering... Then select "Include Advanced Terminals" to gain access to this clock. See my attached VI for an example.

Let me know if you can get this to run without any errors.

Sean C.

[Gurdas]

Hello Sean,

Heres are new insights into the problem:

1) We replaced the PXI-6025 with the PXI-6031 and the problem continues
2) We ran the code on a PC with PCI-6025 and the problem continues. The PC is Win2000 with SP4 (same as our PXI 8184 controller)
3) When we use 100KHz internal clock, the code works without any problem (except that it stops awhile to breathe and catchup)
4) The same encoder pulses give no problem when used as counter input

With this update, I believe the problem could be with compatibility between the three things which havee remained same when we run the code on PC or PXI:

1) OS = Win2000 with SP4
2) NI DAQmx 7.2 (May 2004)
3) The test VI containing timeloop and create timing source function

I request that you run the test VI on a platform EXACTLY as described above and see if the problem can be recreated.

Looking forward to your reply.

Best,
Gurdas

[LA 75]

Hello Gurdas,

Sean is currently out of the office, but I was reading throughout all the threads posted between you and him and I I believe we should try to isolate the problem first, that is, see if the problem is hardware or software related. To do this, I would recommend you to run one of our example programs and see if you the same behavior you mentioned above. If not, then it may be a problem from your VI. If the problem still exists, it can either be a problem with the hardware or the installation of the actual software. To test the hardware, the best thing would be to use another PC and try it out. You mentioned thought that this would be difficult to do, so you use an oscilloscope or a DMM to probe your signals and monitor them before they actually get into the channels of the hardware. IF we see an unusual behavior of the signals, then you would have to check your instrument generating them.

Hope this helps,

LA

[LA 75]

Hello Gurdas,

Sean is currently out of the office, but I was reading throughout all the threads posted between you and him and I I believe we should try to isolate the problem first, that is, see if the problem is hardware or software related. To do this, I would recommend you to run one of our example programs and see if you the same behavior you mentioned above. If not, then it may be a problem from your VI. If the problem still exists, it can either be a problem with the hardware or the installation of the actual software. To test the hardware, the best thing would be to use another PC and try it out. You mentioned thought that this would be difficult to do, so you use an oscilloscope or a DMM to probe your signals and monitor them before they actually get into the channels of the hardware. IF we see an unusual behavior of the signals, then you would have to check your instrument generating them.

Hope this helps,

LA

[Gurdas]

LA,

Thanks for pitching in.

I guess we have done the required tests at our end. Let me restate the same wrt your reply:

1) The VI I have sent (and which Sean tested on an XP system with DAQmx 7.3) does not run on our PXI/PCI with Win2000 and DAQmx 7.2 > This rules out any problem with the code

2) The same encoder signals continue to be counted flawlessly when I use the counter input VIs. We have run the counter input and the timeloop simultaneously to see if both 'hang'. The counter continues counting while time loop goes into wait mode. We have also used a standalone h/w counter to ensure encoder pulse availability > These tests rule out problem with the encoder signal.

3) We have changed the DAQ card on the PXI. Infact we have run the same code from a desktop too. The problem remains. The ONLY similarity between the desktop and the PXI are OS (Win2000 with SP4) and drivers (May 2004). Both have Intel processors (different models though, PXI has Celeron 800MHz, desktop has P4 2.6 GHz). > I cannot say for sure but this probably rules out problem with chassis or daq boards (unless the daq board we used in the desktop has the same defect).

I am not averse to testing further but I hope you'd appreciate that the system is now at customer site and far out of town. Moreover we have been doing all kinds of tests to diagnose the problem for 3-4 months now!!

Is it possible for you to test the code I've shared with Sean on a config that is exactly matching ours?


Thanks again,
Gurdas

[Gurdas]

Hi Sean and LV,

I am eagerly awaiting your updates on test done using a system exactly similar to mine.

Pls take this as urgent.

Thanks,
Gurdas

[Sean_C.]

Hello Gurdas,

I am currently working with your local Branch AE to get this system set up to test your code. I will let you know when we have any results.

Sincerely,

Sean C.