scan time is varying drastically

[sathyendra]

Dear Sir,

We are acquiring data from a channel of 6052E card; we are using matrix switches for switching to different sources, which can be programmed using VISA-GPIB commands.
Acquisition will be done by closing the matrix, measure the value from analog input channel and then opening the matrix switch which are closed earlier. This Sequence will repeat for 8 times and the results are written to RT FIFO with the time taken for total scan. All this is done in Time critical VI, which will be running in RT. The RT side also contains The RT Communication part, which writes to TCP\IP by reading from RT FIFO.
The host side will read from TCP\IP and update the front panel and also logs the data to file once user press stop button.
The scan time that is taken during the total scan is around 16msec and it will suddenly rise to 527msec for one reading and then again continues with same 16msec and same loop will repeat. In between all the three values will become 0. Please find the text file for more clarity.

So I want now why the scan time is varying drastically from 16 to 520 msec. It is critical issue please help me out in sorting out this problem. This will be a great help if you put some light on this issue.

Instruments used.
1. PXI-8176 RT controller.
2. PXI-6052E Analog Input card.
3. Racal Instruments 1256-145B Matrix switch Module.

Please find the attached VI’s and test result file in ZIP format, the VI’s are similar to NI example developed using labview 7.0.
Multiple DAQ Board Real-Time Control Example Featuring RT FIFOs, VI Server, and TCP/IP Communication
http://sine.ni.com/apps/we/niepd_web_display.DISPLAY_EPD4?p_guid=B45EACE3E12856A4E034080020E74861&p_node=174827&p_submitted=N&p_rank=&p_answer=&p_source=External

[Russell_G.]

There are a few things you could try to troubleshoot this problem. What are you using to control your Time Critical Loop time? Typically if you are using the DAQ Timing to control the loop rate, you would specify a sample rate for the acquisition. One thing I would suggest is to try to implement your data acquisition similar to an example program. Check out /Examples/Real-Time/ETS/RT Timing.llb/Hardware-Timed Acquisition.VI. In this example, the hardware clock controls the rate of acquisition. AI SingleScan.vi controls the loop rate by sleeping until each scan is acquired. To modify your program, add an AI Start.VI after your AI Config.VI (outside of the while loop), and specify a scan rate. You can try to set the scan rate to about 10 Hz (to start out) and see if that has any effect. The other thing you might want to try is to eliminate the VISA communication from your Time Critical Loop. Does eliminating these have any effect?

Russell G.

[sathyendra]

Hi Russell,
Thanks for the reply. I tried using AI Start after AI configuration but still the same problem is there. We can't take out the visa part from time critical vi since it is required to close the switches if we remove this part then it works fine and the scan rate will not vary. Any other suggestion let me now .
Regards,
Sathyendra N

[Russell_G.]

The reason you are seeing the jitter in your TCL is due to the GPIB communication. Because GPIB operations are not time-bound, they cannot be used in a loop that is intended to be time-critical. 

Another option is to use a different switching system. You might want to consider using a National Instruments Switch System, which will give you deterministic performance.

Russell G.

[sathyendra]

Hi Russell,
Wish you happy New Year. I was still working on same problem I wanted to know is there any way get the accurate timing using same GPIB modules. Please let me now its critical issue.Waiting for your reply.
Regards,
sathyendra N

[sathyendra]

We are basically looking at consistent reading with slight flexibility in the scan time using the GPIB switches and the ADC card. Waiting for your response preferably by tomorrow.
Regards,
sathyendra.N

[Russell_G.]

sathyendra

With GPIB communication, there is not way to determine how long the operation will take, as GPIB communication uses handshaking, buffers, etc. Since asynchronous communication (GPIB) is not deterministic, you cannot use it in a time critical loop and still expect to get deterministic performance.

Russell G