timing control signal and data acquisition

[siva0182]

I have a series of relays which when activated will close different elements of a circuit and I also have a sourcemeter(Keithley) sending a constant source current and reaing the voltage back.(But when no relays are closed the circuit is open and no source current flows )

I have a microcontroller(pgmmed for 9600 baud rate) based hardware circuit which closes different relays sequentially based on the input it recieves from labview pgm passed on through a Rs232 cable(9600/8 bit/no flow control)

So i made a sequence structure of sending signal to microcontroller signal then wait for the signal transmission and realy activation and then read the voltage value form keithley sourcemeter back to labview thro a GPIB cable.

These three events are reapeated sequentially in a while loop. 

A schematic picture is attached.

BUt the problem I ma facing is the maximum speed of reading is limited to 200msec/reading even thought the relay activation time is as low as 30 msec.

I tried with many different delay times (140-60 msec...but more or less each reading takes up 200msec irrespective of the delay time..) 

What could be the bottle neck is it the Rs232 setting at 9600 baud rate..can changing that to higher baud rate/including flow control solve this problem?

[Gak]

hi siva,

can u post ur vi?

[siva0182]

please find attached the vi.

[Gak]

i dont have labview 8.6

[siva0182]

I have posted the labview 8.0 version.

[siva0182]

forgot to attach in the previous post

[siva0182]

Can any one tell by their experience if the serial communication is the bottle neck or the GPIB communication with the sourcemeter?

Any way to find whcih is the bottle neck?

any solutions to increase the overall speed? 

[RavensFan]

Probably the GPIB communication is the bottleneck.  I don't have those subVI's, so I can't tell what is going on inside of them.  It couild even be the turn around time inside the meter from how long it takes to get the command until it turns around and sends back the response.

You can benchmark your application.  This is a case where a flat sequence structure is ideal.  If you want to see how long a section of code takes to run, put it in a frame of a flat sequence structure.  In the frame before, put the millisecond timer and also the frame after.  Feed the wires out of the structure and subtract the first from the second and wire it to an indicator.  That indicator will tell you how long the code in the central frame took to run in milliseconds.  Do this in a few places where you are suspicious of the length of time to run and see what is taking all the time.

[siva0182]

Find attached the picture of the vi where I tried to put in timers.one in each of the frame and at the end added one more frame just to measure the time elapsed .

The last frame and the frame with sourcemeter measurment show adifference of about 140 msec.

Is there any way to improve the speed of this portion?

But surprisingly I tried displaying the actual timer value at the start and at the start of sourcemeter read function ..but the display of both indicators is almost equal with little difference of only 10 msec.?????

[RavensFan]

---

siva0182 wrote:

Find attached the picture of the vi where I tried to put in timers.one in each of the frame and at the end added one more frame just to measure the time elapsed .

The last frame and the frame with sourcemeter measurment show adifference of about 140 msec.

Is there any way to improve the speed of this portion?

Probably not.  It sounds like the Keithly VI is taking 140 msec.  You can try opening that up to see if there is anything in there that could be causing an unnecessary slowdown.  But trying to tighten it up too much may cause occasional errors (such as timeouts) in trying to get a response back. 

But surprisingly I tried displaying the actual timer value at the start and at the start of sourcemeter read function ..but the display of both indicators is almost equal with little difference of only 10 msec.?????  I'm not sure which of the several timers you are referring to here.  What is the value going into the wait function between the VISA write and the Keithly VI?

---

When you do benchmarking, the timer functions should be in a frame all by themselves.  Having it mixed with another function or VI causes a bit of uncertainty as to when the time was taken.  For instance, you dont' really know if the Keithly VI was started before the time was taken or after.  (The time was probably taken first, but without a data flow or sequence structure dependency, you can't be sure.)